

We got hacked - codegen
http://www.plumbr.eu/blog/we-got-hacked

======
krobertson
"my fellow co-founder who just happens to have a lot more experience in the
field of hacking and getting hacked"

I see irony in the "getting hacked" part. But seriously, if he is more
experienced, then why do they have machines unpatched like that for 6 months?

"it seems it was indeed a kid who did not understand how to install a proper
rootkit and cover up his tracks"

It is rather bold to be posting about how _you_ just got hacked by not
applying simple patches, and to then bash the "kid" who couldn't install a
proper rootkit.

~~~
ivom2gi
That is indeed the case - both players in this match were not careful. We are
open about our shortcomings and also think that the other player was not too
careful to say the least ...

------
scoot
_no customer data was exposed during the attack_

How did you confirm that?

~~~
jlgaddis
That's a good question. Given some of the "fundamentals" of security that were
obviously ignored, I'm reluctant to believe that they can make that assertion
with any confidence.

------
OptimusSubprime
This whole post reads like "How Not to Use AWS" instruction guide.

If you're running anything important on a single EC2 instance, you're doing it
wrong. If you're logging in and manually configuring an EC2 instance, you're
also doing it wrong.

~~~
alan_cx
That's helpful, cheers.

How about letting us lesser plebs know how to do it properly then?

~~~
zacharydanger
This is probably beyond the scope of such a thread, but configuration
automation via Chef or Puppet is where you'd start.

~~~
eli
You really think that's the best place _to start_?

I would begin with a figuring out a more secure, desired configuration before
trying to automate it. (Especially given, IMHO, the very steep learning curve
for Chef & Puppet)

------
VaucGiaps
Clear and open about it. Good.

------
priitp
Asked my team to review their Jenkins passwords and Jenkins user rights...

~~~
reginaldo
I don't know if you're doing this, but I think it's a bad idea to leave
Jenkins publicly accessible. Indeed, IMHO, it's a bad idea to leave stuff that
should not be accessible by the general public publicly accessible. Especially
things that have access to your code.

Do ask your team to review passwords and user rights, but also put this
service and others like it behind a VPN. Then both the VPN server and Jenkins
will have to have holes simultaneously before you get hacked.

~~~
Nikem
As the main hero of that story, I can assure you that we are working on VPN
setup right now. I guess this is not in top-10 checklist for a startup.

------
ladzoppelin
"C source named backdoor.h" Why would an attacker leave a file with that name?
Seems like misdirection or a mistake. How are you going to verify they did
nothing else?

------
waitwhat7
Was the original attack via jenkins? all it says some vague privilege
escalation was used to upload c file. what?

~~~
ihsw
No the author seems to indicate that it was on their application code and an
attacker was able to get OS access, and the attacker subsequently replaced the
ssh service with one that instead ignores login attempts and harvests the
username/password pairs.

It seems to have been a coincidence that their Jenkins service was not
secured.

------
drivebyacct2
First of all, your stupid copy/paste script has completely broken copy-paste.
When I copy, I get nothing except the spam you're trying to inject, so
congrats on managing to piss me off right off the bat.

Second, why even list A, B, or C? Whoever thought running Jenkins as a
passwordless sudo user shouldn't be doing sysops. Why was Jenkins even public
facing? At worst, put it behind a VPN.

------
OGC
So... if the attacker would not have had deactivated SSH by accident they
would not have noticed?

