My next class:

So what passwords are those ssh scanners trying?

Published: 2013-05-14. Last Updated: 2013-05-14 02:01:51 UTC
by Jim Clausing (Version: 1)
10 comment(s)

If you run an ssh server (especially if you still run it on the default port), you've no doubt had plenty of folks scan your machine and do password guessing attacks against it.  BTW, you'll never get in mine that way, I only allow public/private key authentication, but that is beside the point here.  I've done a couple of other reports analyzing passwords, and I really like pipal by Robin Wood for much of the analysis (you can grab it from here).  I've been running a kippo ssh honeypot for the day job for about 2 years and I've done a couple of reports on the password guesses for the ThreatTraq webcast, but then I discovered that in addition to firewall logs and the 404 logs, we also collect kippo logs here at the SANS Internet Storm Center.  Ooh, more data!!  If you'd like contribute, please grab https://isc.sans.edu/kipposcript.pl.  So, without further ado, here is what I've found in our kippo data (as of about 15 April 2013).  I should note here, though, that these are the guesses the bad guys are making.  They've developed their lists most likely based on what has worked for someone at some point, so they will be somewhat different from what you find in analyzing passwords from breaches like my analysis of last year's Yahoo breach.

The Basics

Total entries = 15415314
Total unique entries = 46840
 

The Results

Top 10 passwords
123456 = 167854 (1.09%)
password = 113640 (0.74%)
cacutza = 99492 (0.65%)
__--_-__-_ = 79153 (0.51%)
123 = 63557 (0.41%)
root = 61560 (0.4%)
1234 = 58103 (0.38%)
123456789 = 57270 (0.37%)
12345 = 53445 (0.35%)
test = 52231 (0.34%)

Okay, the first thing to note, is that the default password for kippo is 123456, so that may skew the above a bit.  The one I personally find most interesting is the 4th one, '__--_-__-_'.

Top 10 base words
password = 295354 (1.92%)
test = 192825 (1.25%)
pass = 127086 (0.82%)
root = 121704 (0.79%)
cacutza = 99492 (0.65%)
temp = 97145 (0.63%)
p@ssw0rd = 92650 (0.6%)
p4ssword = 88344 (0.57%)
changeme = 74842 (0.49%)
p4ssw0rd = 74329 (0.48%)

So, some variation on password (with or without substitutions).

Password length (count ordered)
6 = 2708563 (17.57%)
8 = 2275062 (14.76%)
7 = 1550776 (10.06%)
9 = 1394644 (9.05%)
10 = 1234997 (8.01%)
4 = 1143617 (7.42%)
5 = 1025693 (6.65%)
12 = 766462 (4.97%)
11 = 647696 (4.2%)
3 = 437702 (2.84%)

The password guesses varied in length from 1 (do people actually allow 1 character passwords?) to 70 characters in length.  The longest ones being shown below

56 = 4504 (0.03%)
57 = 180 (0.0%)
58 = 465 (0.0%)
60 = 17 (0.0%)
62 = 800 (0.01%)
63 = 69 (0.0%)
64 = 369 (0.0%)
70 = 9 (0.0%)
71 = 908 (0.01%)

The mix

One to six characters = 5463941 (35.44%)
One to eight characters = 9289779 (60.26%)
More than eight characters = 6125535 (39.74%)

Only lowercase alpha = 5126974 (33.26%)
Only uppercase alpha = 140773 (0.91%)
Only alpha = 5267747 (34.17%)
Only numeric = 1906165 (12.37%)

First capital last symbol = 135964 (0.88%)
First capital last number = 958843 (6.22%)

One to six characters = 5463941 (35.44%)
One to eight characters = 9289779 (60.26%)
More than eight characters = 6125535 (39.74%)

Only lowercase alpha = 5126974 (33.26%)
Only uppercase alpha = 140773 (0.91%)
Only alpha = 5267747 (34.17%)
Only numeric = 1906165 (12.37%)

First capital last symbol = 135964 (0.88%)
First capital last number = 958843 (6.22%)

Last digit
3 = 1621502 (10.52%)
1 = 1394507 (9.05%)
0 = 620126 (4.02%)
4 = 593100 (3.85%)
6 = 548727 (3.56%)
2 = 478758 (3.11%)
5 = 420699 (2.73%)
9 = 407320 (2.64%)
8 = 318715 (2.07%)
7 = 303304 (1.97%)

Last 3 digits (Top 10)
123 = 1156095 (7.5%)
456 = 380369 (2.47%)
234 = 340074 (2.21%)
345 = 234638 (1.52%)
321 = 212258 (1.38%)
789 = 192424 (1.25%)
678 = 166984 (1.08%)
567 = 154030 (1.0%)
001 = 146204 (0.95%)
111 = 91160 (0.59%)

Character sets
loweralpha: 5126974 (33.26%)
loweralphanum: 4803721 (31.16%)
numeric: 1906165 (12.37%)
loweralphaspecialnum: 803707 (5.21%)
mixedalphanum: 768137 (4.98%)
mixedalphaspecialnum: 641067 (4.16%)
loweralphaspecial: 344881 (2.24%)
upperalphanum: 181283 (1.18%)
mixedalpha: 151523 (0.98%)
special: 149786 (0.97%)
upperalpha: 140773 (0.91%)
upperalphaspecialnum: 133340 (0.86%)
mixedalphaspecial: 91536 (0.59%)
upperalphaspecial: 81044 (0.53%)
specialnum: 66165 (0.43%)

Character set ordering
allstring: 5419270 (35.16%)
othermask: 3833967 (24.87%)
stringdigit: 2622232 (17.01%)
alldigit: 1906165 (12.37%)
stringdigitstring: 478523 (3.1%)
digitstring: 446101 (2.89%)
stringspecial: 184687 (1.2%)
allspecial: 149786 (0.97%)
stringspecialstring: 117368 (0.76%)
digitstringdigit: 114141 (0.74%)
stringspecialdigit: 101918 (0.66%)
specialstring: 25205 (0.16%)
specialstringspecial: 15951 (0.1%)
 

Some final thoughts

Okay, there is some interesting stuff there and if you are interested in the pieces of the standard pipal report that I didn't include there, I've put the full report up on my handler page.  One of the other thing I took a look at was how many in the mix satisfy the standard definition of a "complex" password [lower case, upper case, digits, special characters] (choose 3) and length >= 8.  620413 (4.02%) of the passwords satisfy this definition of complex.  However, when you look at unique passwords, only 1286 (2.75% of the 46840 unique ones) are complex.  So, at least one takeaway is that the more complex you make your crucial passwords the less likely you are to fall victim to this type of password guessing attack.  Of course, 173 of those 1286 were some variation on 'password' with subsitutions or digits and/or special characters tacked on the end.  So, what do you think?  Is there some other aspect of the passwords that I should have looked at?  Let us know in the comment section below or via our contact form.

---------------
Jim Clausing, GIAC GSE #26
jclausing --at-- isc [dot] sans (dot) edu

The opinions expressed here are strictly those of the author and do not necessarily represent those of SANS, the Internet Storm Center, the author's spouse, kids, or pets (except maybe the ornery cat).

Keywords: passwords
10 comment(s)
My next class:

Comments

Personally, I would never push an SSH server on the net that allowed password logins... key based authentication or nothing. That said, for those people that do allow passwords, you need a fail2ban module or a PAM module that causes all password attempts to fail after no more than 5 failures. Let them keep guessing... they'd have to be pretty lucky to get the right password in their only five attempts for the hour. And then you need a permanent account lockout after too many failures. Or implement a second authentication factor like A "PAM" for Mac OS X (Intel & PPC) and Linux at https://www.grc.com/ppp/software.htm .

PHolder

May 14th 2013
1 decade ago

I'm seeing quite a lot of SSH attempts on my (key-only) boxes as well, and wanted to analyze the attempts for quite some time. Too bad that stock SSH doesn't allow for logging of failed passwords, and I'm rather reluctant to modify and build my own SSH to achieve that feature. I've experimented with PAM logging modules, but they caused weird behaviour for key-based logins. I'd be rather grateful for hints in that direction.

Visi

May 14th 2013
1 decade ago

Key based logins are all very well but you need to be sure you can control your private keys to guarantee security. Given that once a key pair has been generated, the private key can have it's password reset to null completely independently of the server and easily left lying about on any remote machine, this has always seemed like a very insecure method of authentication to me if you can't be sure your users are going to treat keys sensible. Passwords may be able to be brute-forced but at least you can enforce complexity.

moogmusic

May 14th 2013
1 decade ago

I know we usually see these analyses every so often, but it's funny, I was actually curious about these numbers yesterday... Now that I've seen them, I'm not very surprised. Use better passwords people!

joeblow

May 14th 2013
1 decade ago

Personally, I think the ability to collect this data is a weakness in the SSH protocol.

So what if an org ran one of those daemons as a honeypot, and an admin accidentally entered a root password also used on 50 other boxes? Maybe they got frustrated when the login didn't seem to work, and started entering more root passwords; you know... enumerating all the shared privileged credentials commonly used in their organization.

So maybe Kippo isn't just a tool for detecting what passwords the bad guys are using, it's also a demonstration of a vulnerability in SSH's security also.

There ought to be a requirement for the client to hash the password before logging in, preferably using a Scrypt or a Bcrypt hash with very high work factors, incorporating the password and a nonce.

If all SSH logins were guaranteed to be some form of hash with challenge response, passwords never in the clear, then; at least the risk of a naughty compromised or non-standard SSH daemon snooping on passwords could be mitigated.

Mysid

May 14th 2013
1 decade ago

The 4th password looks like it’s supposed to be binary or Morse code.
Its great be able to collect data on failed logins and to intentionally collect the passwords gives great insight into what attackers are trying and how password policies could be tailored.
SSH internet facing however, yea gotta be key based.

T1tu3

May 14th 2013
1 decade ago

@Mysid great idea for a pentest but hopefully the admins would notice the server key isn't matching in a real environment.

Not that there can't be an improvement to identity proof, just that it shouldn't be as big a deal for real admins hitting trying to login to known (SSH) servers.

ckruslicky

May 14th 2013
1 decade ago

OK, so one of the SSH hacking tools must be coming from Romania. The third of the top 10 passwords is undoubtedly a phonetically transcribed scatological word in that language. Why would they assume that the rest of the world must be using this particular password?

al

May 16th 2013
1 decade ago

@Mysid: The consequence of that is the server would have to do something like save the password plaintext, which is just about as bad.

Joshua

May 21st 2013
1 decade ago

As the sysadmin, I can require you to have a good password on my machine (just to make sure, I can throw cracking tools against it). I can not tell whether your ssh private key even has a password, and I can't test it. IMO, ssh-keygen's default ought to be that the public key should have an IP restriction by default, something like .......
from="example.org" ssh-rsa AAAA......XYZ== user@example.org
..... and sshd should allow the sysadmin to disallow any authorized key that has no restrictions ("options").

M_T

May 22nd 2013
1 decade ago

Login here to join the discussion.


Top of page
Diary Archives