Earlier this month, I blogged about monitoring password-guessing attacks on a server, via a patched OpenSSH. This experiment has now been running for just over two weeks, and there are some interesting results. I’ve been tweeting these since the start.
As expected, the vast majority of password-guessing attempts are quite dull, and fall into one of two categories. Firstly there are attempts with a large number of ‘poor’ passwords (e.g. “password”, “1234”, etc…) against a small number of accounts which are very likely to exist (almost always “root”, but sometimes others such as “bin”).
Secondly, there were attempts on a large number of accounts which might plausibly exist (e.g. common first names and software packages such as ‘oracle’). For these, there were a very small number of password attempts, normally only trying the username as password. Well established good practices such as choosing a reasonably strong password and denying password-based log-in to the root account will be effective against both categories of attacks. Surprisingly, there were few attempts which were obviously default passwords from software packages (but they perhaps were hidden in the attempts where username equalled password). However, one attempt was username: “rfmngr”, password: “$rfmngr$”, which is the default password for Websense RiskFilter (see p.10 of the manual).
There were, however, some more interesting attempts. One category was passwords far too complicated to be in a standard password dictionary, or even found through offline-brute-force attacks on a hashed password database (e.g. “TiganilAFloriNTeleormaN”, “Fum4tulP0@t3Uc1d3R4uD3T0t!@#$%^%^&*?”, and “kx028897chebeuname+a”). The best guess is that these passwords were collected from an unhashed password database, or from a trojaned SSH server or client. Theo Markettos identified a likely source for this password database. Other odd password attempts include plain hashes (e.g. E4F89B211D997C1D5ECCE2153DC9184A which is the MD5 of “upintheair”, found by Google), salted hashes (e.g. $1$EdkQIoSn$T3gzKLxlcxF7tsTCFqC8M) and filenames (e.g. “/var/run/sshd22.pid” and “/var/run/sshd”).
One conclusion which can be drawn is that this attacker does not care enough about the quality of the password database to filter out passwords which it makes almost no sense to use. This carelessness is supported by the fact that after I initially enabled my patched SSH server, I received many log-in attempts but no passwords. It turned out that the default FreeBSD configuration is to only support keyboard-interactive authentication, rather than the more limited password authentication. The brute force attack tool only attempted password authentication, and therefore was always rejected before any password was sent, so the attack was running for days without ever having a hope of succeeding. I did enable password authentication, but some later attacks, presumably using a different tool and probably from a different attacker, attempted both keyboard-interactive and password authentication.
One attack I hadn’t seen before was to try a large number of usernames, and parts of the hostname as password. For a hostname of the style MACHINE.DOMAIN.DEPARTMENT.cam.ac.uk, the attack tried DOMAIN, DOMAIN.DEPARTMENT, MACHINE, then MACHINE.DOMAIN. This clearly isn’t a dictionary but a bit of custom code which did a reverse DNS lookup on this host then generated some possible passwords. Using the hostname as a password for a host isn’t a good idea, but I can imagine some sysadmins doing so. The fact that some attackers are taking this approach might merit some explicit statement in password selection guidance.
Another curious trend was receiving meta-data as username/passwords. This might be due to the brute force tool not properly interpreting comments in the dictionary file, or the attacker not understanding the comment notation. For example I received the following username/passwords:
- [uratu/was HERE]
- [I`m/A HaCkER ON]
- [This/Is A Blow ShiT]
It looks like the attacker thinks that square brackets are comment notation, but the brute force tool simply sends the text as SSH username/password pairs. There also seems to be a Romanian language connection. For example, “acest este varza” according to Google means “this is cabbage” (perhaps an idiom), “contzine” means “list any”, “peste de usere” means “over the user”, “setate” means “set”. The Romanian connection also came up in the previous post where Romanian for “Handbook of Mechanical Engineering” was tried as a password.
Attentive readers will note the “\par” in the above list perhaps indicating that the file was converted to RTF at some point. This appears indeed to be the case from the later attempt of username: “\*\generator”, password: “Msftedit 188.8.131.528;}…[checking uratu]\par”. From this we can also conclude that the attacker is using Windows WordPad.
Overall it was an interesting experiment, with some conclusions confirmed but a few surprises. However, this was only a two week experiment on a single machine, so care should be taken in drawing generalisations which assume that these results are typical.