Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Fishing for Hackers: Analysis of a Linux Server Attack

draios.com

Post reply on HN
Print view View original

41–50 of 53 posts

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#42

Post by pmh »

fragmede wrote: post #8

So a DO/Rackspace/AWS VPS with a guessable root password can expect to be cracked in ~4 hours? That's terrible! AFAIK, AWS defaults to ssh-key logins with password logins disabled. Can someone comment about Rackspace/DO?

At least in the early days of EC2, there were more than a few higher profile AMIs with password logins enabled, e.g. some of Oracle's AMIs used a trivial default password.

As far as I know, you can still create/publish AMIs where password auth is enabled, but all of Amazon's stock images only allow ssh-key auth.

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#44

Post by kilolima »

Fascinating! Two questions:

Wouldn't it have been better if the attacker had removed only the last few lines recording his commands from the log files instead of the entire files? Wouldn't the lack of continuity in the log files be very noticeable?

Also, is this a script running this sequence of commands or an actual person?

And, is there a log somewhere on the system of 'make' activity?

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#45

Post by gighi »

kilolima wrote: post #44

Fascinating! Two questions: Wouldn't it have been better if the attacker had removed only the last few lines recording his commands from the log files instead of the entire files? Wouldn't the lack of continuity in the log files be very noticeable? Also, is this a script running this sequence of commands or an actual person? And, is there a log somewhere on the system of 'make' activity?

To answer your questions:

1) Yes, it would have been better but I honestly think this attack was completely botnet-driven and the attacker didn't really mean to cover his footprints too much: in the timespan of 10 minutes, he sent over 800 MB of UDP traffic. That would have been caught even by the most oblivious sysadmin pretty quickly, so these guys are just playing a number game, trying to break in as many hosts as they can knowing that the lifespan of the hacked hosts will be very short, maximizing the short-term profit then.

2) The attacker directly ran these commands on the login shell (no script was copied over scp or something else), so there was no script executed on the host itself, but the whole thing lasted roughly 2 minutes and a lot of commands were "typed", so I am almost sure this was just an automated script ran from another probably compromised host.

3) I didn't check if the build left logs, but by showing every executed process with "evt.type=execve" (which goes deeper than the spy_users chisel) you can see all the processes executed by the build: 99% are just uninteresting sed/gcc/autoconf.

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#46

Post by thefreeman »

jwcrux wrote: post #12

OP may also benefit from the use of an SSH honeypot. I use kippo ( https://code.google.com/p/kippo/ ) with great success. It tracks all commands run, as well as keeps copies of all downloaded files. In addition, it limits available commands to a certain predefined subset, allowing the host to prevent damage caused (e.g. a DoS attack in this case) by the system being compromised.

If you like this kind of stuff, http://www.honeyd.org/ is pretty full featured as well and provides a lot more emulated services (http, ftp, network file shares, smtp). It is also built so it is (relatively) easy to add your own emulated services.

Not to say that kippo isn't good, I didn't look too closely but it seems to be mainly focused on ssh and terminal capture.

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#47

Post by nounaut »

pmh wrote: post #6
dthakur wrote: post #3

Great article. I had not heard of sysdig previously. Based on the timestamps of the entered commands, I guess one of the takeaways for the attacker is to look into config management tools (eg ansible) :)

Since you hadn't heard of sysdig before, you might also be interested in this article posted[1] a couple of weeks ago: http://bencane.com/2014/04/18/using-sysdig-to-troubleshoot-l... [1] https://news.ycombinator.com/item?id=7622121

I hadn't either and thank you very much for that link!

Re: Fishing for Hackers: Analysis of a Linux Server Attack

#49

Post by akx »

wazoox wrote: post #33
fragmede wrote: post #8

So a DO/Rackspace/AWS VPS with a guessable root password can expect to be cracked in ~4 hours? That's terrible! AFAIK, AWS defaults to ssh-key logins with password logins disabled. Can someone comment about Rackspace/DO?

This is not limited to AWS/rackspace... Here's from my home PC: $ uptime 22:09:07 up 30 days, 12:19, 2 users, load average: 0,17, 0,09, 0,07 $ sudo fail2ban-client status ssh-iptables Password: Status for the jail: ssh-iptables |- filter | |- File list: /var/log/messages | |- Currently failed: 1 | `- Total failed: 1757 `- action |- Currently banned: 0 | `- IP list: `- Total banned: 242 1757 attempts from 242 IP addre…

My home NAS is also exposed to the internet.

    up 298 days, 20:42,  1 user,  load average: 0.00, 0.01, 0.05
"zgrep ssh auth.log* | grep -i failed" has no traces of any intrusion attempts whatsoever, just me not being able to type.

The distinction is, though, that the SSHd on that box is running on a non-standard port (220)... so that certainly makes a difference.

Post reply on HN