A stupidly easy way to hack into computers

Do you have a SSH server running somewhere? Have you ever wondered why it gets hammered by brute-force password guess attacks all the time? My server got 4669 login attempts on 2013-01-12. Have you ever wondered what these guys do if they actually manage to get into your server? Have you ever wondered which passwords actually get tried, in order not to use them yourself?

To answer all these questions, I set up a SSH MitM attack to my own server. I configured the real sshd to listen on port 443, and set up a program (taken from here, if my memory serves) that accepts incoming SSH connections just like the regular sshd, logs down the passwords and all the traffic, then forwarding the connection to the regular sshd.

In the spirit of the previous post, SSH, like SSL is also susceptible to MitM attacks. The difficulty is different, though: the attacks against people connecting for the first time are trivially easy (who checks the fingerprint manually anyway?), but introducing a MitM to somebody who has already connected once is hard, as the SSH client will scream a ridiculously big warning message that somebody is trying to intercept the connection:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
fingerprint:goes:here.
Please contact your system administrator.
Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/user/.ssh/known_hosts:19
ECDSA host key for [ip address goes here] has changed and you have requested strict checking.
Host key verification failed.

In my case, I was only interested in fooling new users (existing users, that is me, know they must connect to port 443), so keys and fingerprints mattered not at all.

Top logins

77 root 123456
68 root 1q2w3e
66 root qwerty
64 root redhat
62 root password
62 root abc123
61 root 111111
50 test test
50 root 123456789
50 oracle oracle
48 root passw0rd
47 root 1234567
46 root p@ssw0rd
45 root 12345678
45 root 12345
45 root 1234
44 root 1
41 root 7hur@y@t3am$#@!(*(
41 root 123
40 root abcd1234
40 postgres postgres
37 nagios nagios
36 guest guest
35 root P@ssw0rd
35 root 1qaz2wsx
34 root 1q2w3e4r
33 root pa55w0rd
33 root 1234567890
32 root root123
32 root root
31 root q1w2e3r4
30 root 123123
29 root changeme
27 root Password1
26 root rootroot
26 root a
26 root 654321
25 root zaq12wsx
25 root test123
25 mysql mysql
24 test 123456
23 test test123
23 root r00t
23 root asdfghjkl
23 root 1qa2ws3ed
22 oracle oracle123
20 user user
20 root server
20 root linux
20 root asdf1234
20 root 987654321
20 root 1qaz@WSX

Why are 42 out of 52 top login attempts for “root”? Doesn’t everyone know that allowing root login over SSH is stupid and dangerous? Apparently not, as further experiments show.

What do the evil criminals do once they get into my computer? To figure this out, I actually let them in, by letting them guess the “guest guest” username-password combination. The machine was an old throwaway PowerPC box running Debian. Here’s a summary on what got done on one attempt:

  1. Check the list of users logged in right now
  2. cat /proc/cpuinfo to see how powerful my machine is
  3. Try to change the password to 123cetatea (cetatea is “fortress” Romanian)
  4. Download and try to run some kind of rootkit or bot
  5. Download Windows 2000 Service Pack 3 (presumably to test download speed)

One guest tried to run some kind of IRC bot (presumably backdoor), which failed because the machine architecture was PowerPC. Then he tried to compile it from source, which failed because I had replaced gcc by a script that spewed out arbitrary syntax error messages. Then he tried to run another bot, written in Perl, which again failed because Perl was treated similarly to gcc. I remember these hackers with fondness, they gave me overdoses of fun.

Talking back

Although the attacks originated from everywhere in the world (China, France, Italy, Spain, Netherlands, Germany, USA, Russia, South Korea, even one attack from Malaysia and Tanzania), the scripts the intruders use contain Romanian messages, the passwords tend to contain Romanian words, and the attackers themselves have logins in the logs originating from Romanian IP addresses. This lends evidence to the theory that the attackers are actually innocent (unless you count gross stupidity of enabling remote root login with a weak password), themselves victims of Romanian script kiddies (the behaviour of these attackers does NOT show any sophistication). It looks like the attacks originated somewhere, then after getting a hold of some servers, the attacker installed their scripts on it for parallel, faster scanning and then hit me. Therefore there is basis to believe that whatever passwords were tried against me, would likely also work on the attacking server.

Tests (which are illegal, by the way) show that this theory is partially correct. Perhaps ⅕ of the attackers run SSH server on port 22 and actually have a valid username/password combination listed in the ones tried on my server. This translates to finding around 5 working logins per week, around 80% of them root accounts. The logins do not stay valid for long, apparently the administrators, although stupid, are not blind and eventually block the access somehow. Disclaimer: the statistics in this paragraph are based on gut-feeling and measuring by eye, not hard figures.

About these ads

3 thoughts on “A stupidly easy way to hack into computers

  1. > 4. Download and try to run some kind of rootkit or bot
    One fun thing to do is to remove non-SSH downloading binaries and disable incoming SSH file transfers, what’s left for the user is to enter his login information and connect to another SSH system.

  2. Update: I just discovered that it is possible to reuse your SSH host keys with mitm-ssh. This means that if someone manage to get a hold of the private keys for your sshd, MitM attacks against you will become trivial.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s