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.
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…
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.
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!
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.
Is the machine behind a firewall, a router?
@Stalin
I haven’t seen ‘stalin’ but someone did try ‘hittler” as a root password.
@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.
@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.
@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).
@finid
It’s behind a firewall which blocks most ports, but doesn’t do anything more clever than that.
You can use https://www.blocklist.de to report the infected sever automatically over fail2ban.
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
@ 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.
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
@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.
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.
@ 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.
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!
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.
Actually that’s a romanian password (Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?) and it means ‘smoking can kill really really bad’. A funny password lol.