Institute of Cybernetics, Tallinn

Main menu

Post navigation

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.

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:

Check the list of users logged in right now

cat /proc/cpuinfo to see how powerful my machine is

Try to change the password to 123cetatea (cetatea is “fortress” Romanian)

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.

7 thoughts on “A stupidly easy way to hack into computers”

> 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.

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.

This is too funny. So basically you’re admitting to having hacked into all the people who hacked into you using the exact same method. I’m not hating but you sorta ratted yourself out. Otherwise, how would you know?