Brute force password-guessing attempts on SSH

January 6th, 2012 at 20:32 UTC by Steven J. Murdoch

I recently set up a server, and predictably it started seeing brute-force password-guessing attempts on SSH. The host only permits public key authentication, and I also used fail2ban to temporarily block repeat offenders and so stop my logs from being filled up. However, I was curious what attackers were actually doing, so I patched OpenSSH to log the username and password for log-in attempts to invalid users (i.e. all except my user-account).

Some of the password attempts are predictable (e.g. username: “root”, password: “root”) but others are less easy to explain. For example, there was a log-in attempt for the usernames “root” and “dark” with the password “ManualulIngineruluiMecanic”, which I think is Romanian for Handbook of Mechanical Engineering. Why would someone use this password, especially for the uncommon username “dark”? Is this book common in Romania; is it likely to be by the desk of a sys-admin (or hacker) trying to choose a password? Has the hacker found the password in use on another compromised system; is it the default password for anything?

Over the next few weeks I’ll be posting other odd log-in attempts on my Twitter feed. Follow me if you would like to see what I find. Feel free to comment here if you have any theories on why these log-in attempts are being seen.

Entry filed under: Authentication, Security psychology

20 comments Add your own

  • 1. Stalin  |  January 6th, 2012 at 23:21 UTC

    Among the random and often repeated common logins, I once spotted someone trying to login to my system with username ’stalin’… That was… oddly scary…

  • 2. Theo Markettos  |  January 7th, 2012 at 00:08 UTC

    This appears to be the rootkit:
    202.29.15.25 senate .x gb
    (intentionally not a live link: replace spaces with slashes). Get gb.tgz if you want to download it all.

    Your passwords come up in the files 2 and 36. Looking at some of the other usernames in there, I think this is an amalgamation of disparate compromised password databases. Some are clearly Unix passwords. Some appear to be website passwords. Some of them are unique enough to pin down to individuals. There’s a distinct Asian bias (I have found them in Indonesia, Taiwan, Bangaladesh and the above server is in Thailand).

    So I think some now-gone websites were hacked and the password databases stolen. These were collected together with all the other password databases kicking around. For good measure there’s a limited amount of crossing of user/password pairs (ie try every password with every username). Then those make up the database for the rootkit. And since trying SSH servers is cheap, that also crosses pairs too (creating huge inefficiency).

    It sounds a similar MO to spammers… hoover up as many emails or passwords as possible, jam them all together, than just go thrash the network… not caring too much about targeting, efficiency or technical merit.

  • 3. Presence  |  January 7th, 2012 at 02:02 UTC

    I patched my box up following your diff, but can’t figure how to get the failed password logged if “root” is attempted when sshd_config has PermitRootLogin yes.

    Still, pretty silly results so far in auth.log!

  • 4. dahamsta  |  January 7th, 2012 at 07:53 UTC

    Obviously not what you’re trying to achieve now, but for people actually trying to keep their logs clear, the simplest solution is to change the port ssh listens on. The kits don’t port scan.

  • 5. finid  |  January 7th, 2012 at 15:24 UTC

    Is the machine behind a firewall, a router?

  • 6. Steven J. Murdoch  |  January 8th, 2012 at 22:33 UTC

    @Stalin

    I haven’t seen ’stalin’ but someone did try ‘hittler” as a root password.

  • 7. Steven J. Murdoch  |  January 8th, 2012 at 22:38 UTC

    @Theo Markettos

    Thanks for your insightful comment. It does look like those files are the source of some, but not all of the passwords I’ve seen so far. There might be multiple attackers though, each with their own list. IP addresses don’t help distinguish people of course, but I think there are at least 2 different attack tools being used.

  • 8. Steven J. Murdoch  |  January 8th, 2012 at 22:59 UTC

    @Presence

    One option is always to set PermitRootLogin to “no”, which is probably a good idea for other reasons :-) Alternatively, you could put the call to sshpam_log_invalid_user() before the test for whether the user is valid, but that would log all username/password attempts, including successful ones, so is probably a bad idea.

    A better option would be to move the call above “debug(“PAM: password authentication failed for…”. This would only work for password authentication. Fixing keyboard interactive is harder, because by the time a decision has been made as to whether the password is correct I don’t think the password is stored anywhere.

    This problem could be fixed by doing the logging in PAM, however OpenSSH will still need patched because it gives PAM a fake password if an account is invalid.

  • 9. Steven J. Murdoch  |  January 8th, 2012 at 23:02 UTC

    @dahamsta

    I’ve seen some people do this, and it’s not a bad idea. My motivation for keeping SSH on port 22 however is that there are some highly restrictive networks where that might be a problem (including Cambridge’s wireless service, which only permits traffic on white-listed ports).

  • 10. Steven J. Murdoch  |  January 8th, 2012 at 23:03 UTC

    @finid

    It’s behind a firewall which blocks most ports, but doesn’t do anything more clever than that.

  • 11. martin  |  January 9th, 2012 at 15:09 UTC

    You can use https://www.blocklist.de to report the infected sever automatically over fail2ban.

  • 12. Antonomasia  |  January 10th, 2012 at 21:51 UTC

    I did this in 2004 when the brute forcing started. I don’t think I’ve kept a list of the usernames/passwords I collected.

    http://www.notatla.org.uk/SOFTWARE/SSH_mods_2004-08-06.txt

  • 13. Clive Robinson  |  January 12th, 2012 at 11:02 UTC

    @ Steven,

    With regards your reply to Theo, it gives me a thought ;-)

    If you leave your server up collecting all attempts you could build your own DB of what various script kiddies etc are trying.

    You could then use the DB to do a number of usefull things such as,

    1, Build Black Lists
    2, Detect new scripts being used

    But more importantly from the research point of view you can use it to do various forms of statistical analysis to track the usage and aging of the various scripts as a form of traffic analysis.

  • 14. Jonathan Abbey  |  January 12th, 2012 at 20:16 UTC

    If you’re worried about mass SSH spamming on Linux, you can always use iptables to start dropping connections if you see more than (n) incoming ssh attempts within a (m) interval.

    I.e.,

    -A INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –set
    -A INPUT -p tcp –dport 22 -i eth0 -m state –state NEW -m recent –update –seconds 300 –hitcount 5 -j DROP

  • 15. Steven J. Murdoch  |  January 14th, 2012 at 01:45 UTC

    @Jonathan

    I’ve seen this being done, but have found it very frustrating on computers I use for non-interactive SSH sessions (e.g. Subversion/Git over SSH). Blocking frequent connections breaks such tools. Fail2ban is a lot more complex, but has the advantage of only blocking repeated failures, not merely repeated connections.

  • 16. Fredrik Staxäng  |  January 19th, 2012 at 06:29 UTC

    I thought it was the consensus that logging failed passwords is dangerous? The log will contain valid users failed attempts. Simple typos, caps-lock. Most importantly, password for other computers/sites.

  • 17. Lawrence Munro  |  January 19th, 2012 at 10:09 UTC

    Cool stuff! You should chuck up some honeypots if you have some time, you get all sorts of interesting stuff on there! Often you get script kiddie attempts which baffle and make you think you’re missing a trick, but they turn out to be people who dont know what they’re doing. Like you dark and mechanic attempt could be someone who’s downloaded a file called ‘dictionary’ (or whatever the Romanian for this is) and it’s a mechanics dictionary where some words happen to be delimited correctly or something weird like that! Who knows!

  • 18. Steven J. Murdoch  |  January 20th, 2012 at 14:20 UTC

    @ Fredrik

    In general you are correct, it is not a good idea to log failed passwords for the reasons you stated. However, for the particular case of this computer, it is not a problem because there are no valid passwords. Only one username will work (mine), and that will only allow public key authentication so I am not going to enter a password. So there is no risk that there will be valid passwords (or typos thereof) in these logs.

  • 19. jbmoore  |  January 26th, 2012 at 22:41 UTC

    Why aren’t you using kippo (http://code.google.com/p/kippo/) in addition to the ssh brute force logging honeypot? Then you’ll discover what attack tools they are using as well as their dropservers.

  • 20. m  |  January 27th, 2012 at 00:04 UTC

    Actually that’s a romanian password (Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?) and it means ’smoking can kill really really bad’. A funny password lol.

Leave a Comment

Required

Required, hidden

Some HTML allowed:
<a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Subscribe to the comments via RSS Feed


Calendar

January 2012
M T W T F S S
« Dec   Feb »
 1
2345678
9101112131415
16171819202122
23242526272829
3031