Wednesday, June 24, 2009

Using online password crackers

Online password crackers are extremely popular and it's easy to see why. Instead of having to go through the trouble of cracking the password yourself, why don't you just submit it to someone else who has gigabytes, (to terabytes), of pre-calculated hashes to crack it for you. Just as a warning though, there are some privacy concerns when using these sites, (what? You don't think they store the hashes that are submitted to them?).

According to www.hashkiller.com, which keeps track of the effectiveness of these sites, (quick disclaimer: recently the reporting mechanism seems to be having issues), most of these sites crack around 20 to 40% of the passwords submitted to them which is fairly good, (actually really good since most of them rely on quick lookups in pre-generated tables). This statistic matches what I've seen both from my own testing and looking at other people's results, (aka the person who attacked phpbb.com submitted some of the passwords to one of the sites and cracked around 24% of them according to the textfile he/she posted online).

Recently I've been playing around with md5-utils, (available here), which is a program that will submit your password hashes to 33, (as of right now), different online password crackers. The advantage of course is that as a group online password crackers do very well. Where I've really found it useful though is as a sanity check on my own work. Aka as I posted before, I've cracked 90% of the phpbb.com list, but when I submitted a small subsection of the passwords I haven't cracked yet using md5-util I quickly found out that I needed to spend more time brute-forcing passwords that only contained uppercase letters and numbers, (I knew that was popular and even mentioned it back in my Shmoocon08 talk but for some reason I had forgotten that. Probably because I had associated it with LANMAN hashes.) People really hate hitting the shift key.

The main problem with md5-utils is that it is very "polite" in that it will only submit one hash at a time and it takes several minutes to check it. This means running even several hundred hashes though it takes a while. It would be fairly trivial to crank it up a notch, but I've been hesitant to do so since I like to live my life by the rule, "Don't be a jerk" and I don't want to hammer the online cracking sites with requests.

Now for some trivia. One password that md5-utils cracked was "HPw2207!@#" (without the quotes of course). Looking at it I was really impressed. Ok the "!@#" is fairly easy since it just is a keyboard combo, but to make a rule try three letters, (the first two capitalized), followed by four random numbers and then a keyboard combo of symbols is pretty impressive. It certainly wasn't pure brute force, that's for sure.  So of course I decided to do a google search to see if HPw2207 might actually mean something.
No, not Laura Croft. Look at the bottom right corner of the screen. Yup, the person had used the label on their monitor, HP2207, as their base password and then just added !@# to the end. I'm sure that's also how their password was cracked, aka in one of the input dictionaries someone has, they've probably listed out all the computer monitor types. Hey, I found it amusing plus it gives me a chance to post tomb raider pictures to this blog ;)

Sunday, June 14, 2009

Site News Update

As stated in the previous post, I'm in the middle of creating a new site to hold all the tools, custom dictionaries, and research papers I'm working on. It's fairly bare bones right now but I'm plugging away at it. Expect the layout to change quite a bit. I'd recommend only linking to the main page for the next month just because I'm still juggling around which pages should go where.
I'm making the change since everyone ,(including me), hated the old googlepages site. The new site also allows comments so if you want to talk about a specific tool, file a bug report, or make a request please do. My one worry is hosting space, (aka some of these dictionaries and the rainbow tables in particular are large), but I'll cross that bridge when I get to it.

The new site can be acessed from the link in the sidebar to the right or by going to

http://sites.google.com/site/reusablesec/

Friday, June 12, 2009

Cracking Web Hosting Talk

I'm working on completely redoing my tools page so hopefully I'll be able to start posting some new dictionaries, password cracking programs and scripts sometime this weekend. Enough site news, on to the post!

I've talked previously about cracking password lists from phpbb.com and the finnish78k list. Now I would like to discuss another list that I've been working on. Back in March, a site called "Web Hosting Talk" was compromised via a flaw in their backup server. The attacker then distributed a list containing user information, (usernames, e-mail addresses, and password hashes), to several file sharing sites.

I wasn't able to obtain a copy of this list, (and trust me, I tried), but I'm actually pretty happy about that as it means WHT was able to yank most copies of it offline quickly. What I wasn't happy about was the "advice" WHT gave their users regarding changing their passwords...

"Passwords are hashed with salt. It would be an unprecedented event to reverse engineer our passwords. I change my password periodically though, so maybe today is a good day for that."

That's like saying, "The building is on fire, but I can't imagine it burning down. Occasionally when there is a fire burning out of control I go outside. This might be a good time for you to grab some lunch, or whatever..."

Now there are a couple of things they could have done.
A) Force users to change their passwords when they logged on again
B) If the user logs on to the site from a different IP address then they normally do, prompt them with a "secret" question, or send them an e-mail with a new password. <--More secure, but a pain in the butt from a system admin side of things
C) Warn users they need to not only change their password, but change it on other sites they may have used it on <-Yah it's bad PR, but it's necessary

Honestly for a site like WHT, they probably should have gone with both options A and C, as B might have been overkill for the value of the site, (aka someone could log on a make a couple of posts or read private messages, but it's not like they store financial or medical data ... at least for a user to see).

So if I wasn't able to find that list, what have I been cracking? Well, when WHT reopened they apparently missed a backdoor the attacker had left in their system. About a week or two after the initial attack the hacker released another list containing all the user data. This time though the attacker also included Credit Card numbers, expiration dates, and the CCV number on the back, (which online retailers are not supposed to store). That's the list I actually stumbled upon. Full disclosure: when I found out I had downloaded stolen CC info I deleted those files as quickly as possible and had visions of FBI agents kicking down my door for the next week. Luckily the user info was stored in a different file.

The list contained 202111 unique user/password combos. The attacker also included a file talking about the attack which contained one very interesting fact, (among all the swearing and racist comments). In the time between the initial attack and the most recent one, only 1348 users, (counting system administrators), changed their password. That's less than 1% or the userbase (0.6% to be precise). To put this in perspective, according to the link above the list also included 2,218 credit cards, (the site was storing 9,561 credit cards but the hacker kept the rest of them to him or herself).

Assuming that this password hash was "impossible to reverse engineer" this wouldn't be a problem. The question of course was, how true is that statement? The first step was to find out what forum software WHT uses. A quick Google search revealed they use vBulletin. The next step was to figure out the function that was used to hash the passwords. Once again Google provided me with the answer:
  • MD5(MD5(Password).Salt)
Modifying the password cracker that I had used previously to attack phpbb.com's passwords, (I'll try to post it this weekend), I was ready to go. Of course, how should I test it? I mean WHT could have changed the hashing function to make it almost impossible to figure out. I could spend days/weeks trying to crack those passwords only to find out I was hashing it wrong... So I loaded up the password list and entered the guess "password" since I guarantee that a site with 200k+ users and no password creation policy at least one of the users is going to pick "password".

And .... nothing.

I didn't crack a single one. Feeling slightly less smug, I tried "Password123!", "password123", "monkey", "football", well you get the idea. Still nothing. At this point I was feeling really sheepish and had all sorts of scenarios going through my head. A couple of days later though I realized that the problem was I wasn't converting the first hash of the guess to its ASCII representation before rehashing it. Once I made that change, I reloaded all the password hashes, crossed my fingers and tried "password" again.

Yup, that did it. Watching several hundred cracked hashes flash across the screen was a sight to see. I had accomplished the "unimaginable" and reverse engineered their password hash using only Google and my horrible programming skills. Of course since then I've found out that I wasn't the only one. There already exists a 3rd party patch for John the Ripper. Also, over at hashkiller.com, there is an entire forum devoted to cracking vbulletin and other forum hashes.



All I can think of is the image to the right. "Unimaginable! I do not think that word means what you think it means..."

Of course, once I started to launch my actual attack reality set in. But this post grows long and it's a Friday night so that will be left for another day ;)

Thursday, June 11, 2009

In which a milestone is reached..

I think I've made as many posts this month as I have readers ;)  I just want to remind the four or five of you that your input really matters to me. If there is something you want me to look into or you disagree with a post, please let me know.

Rule #31 of Hacking: Bypass the Crypto

It's a story as old as time. A webmail company says their security is unbreakable. They give out their CEO's username/password and offer a $10,000 reward to anyone who can break into his account. Guess how this ends? Despite the predictable outcome, this story has been really interesting to me, not only for the issues it brings up but how the security community has been reacting to it.  

I think security contests can be a good strategy for a company. That being said, it really matters how they approach it. Google's take on it with their Native Client hacking contest was spot on. Not only did they get a lot of positive buzz, but they also attracted some of the smartest hackers out there to compete for only $8,192. You normally can't even get a CISSP to give you a Nessus scan for that type of money. The reason for this of course is that hackers don't do it for the money, but for the challenge and bragging rights.

Looking at other such events, a couple rules of thumb to holding a successful hacking challenge seem to come to mind.

1) Don't ever use the words, "un-hackable", "un-breakable", or "perfect". You need to approach these competitions with a healthy dose of realism and the knowledge that your security system probably will fail.

2) Treat the participants with respect. Bring them into the process and take the time to actually listen to them. You want them to feel like they are part of the team making a better product. If this doesn't happen then they will instead write posts talking about how you "don't get it".

3) On the other-hand, you can put so many rules and restrictions on the contest that it becomes almost impossible to win. Of course this is not ideal as you don't actually test the security of your system and this approach should only be used for marketing reasons. Normally this only works with abstract problems like with the Bodacion challenge where you can control everything. Otherwise you get hacked and just look dumb when you claim you weren't really hacked. Also, most security professionals will avoid your product like the plague but then again, we generally are not the ones buying this type of stuff.

Now about the merits of StrongWebMail's particular product:

They claim to be the most secure webmail service out there. For a nominal fee, when you attempt to log on to their site they will then call your phone for confirmation. While I haven't seen the details on their exact protocol, (nor do I want to spend $5 to start an account), I think I can safely say they call you after you typed your first password in successfully. If not, forget denial of service, think denial of sleep as someone brute-forces your account at 2am in the morning...

The thing is, the authentication mechanism doesn't matter much when you can bypass it. StrongWebMail's back-end website had several XSS vulnerabilities that apparently were trivial to exploit. This means that in a targeted attack you would be safer off using yahoo's webmail. That being said, I do have to admit that StrongWebMail is more secure against conventional password attacks. This isn't trivial. When singles.org was hacked their password list was leaked. The 4chan crowd then got ahold of it and proceeded to try those passwords on other accounts associated with the e-mail addresses provided to the site.  Since people often use the same password for all their accounts, webmail accounts were hacked. Horrid e-mails were sent out to family and friends. The same goes for paypal accounts, facebook accounts, amazon.com accounts... well you get the idea.

It really comes down to what you are trying to protect against. Personally I advise just using a unique password for your e-mail account. That way you get the back-end security of google or yahoo for free, but also are resistant to the above attack.  Yes I know, remembering different passwords is hard which is why I normally have different classes of passwords. My bank password is different from my mail password, but I use the same password for many of my other less important accounts. Oh, and write your password down. If someone is willing to sort through and read all the papers in your filling cabinet, they probably already stole your computer, (robber), or installed a keystoke logger, (government or a really smart robber).

Please don't take this as a knock against two factor authentication. Two factor authentication really raises the bar for a hacking attack to be successful. By using two factor authentication, it moves the security requirement away from the user having to select a strong password. That's huge. It also often forces an attacker to time their attack to coincide with the user logging into the site, (though CSRF and other attacks can get around this). That being said, StrongWebMail's approach is pure overkill. A much better implementation is this free I-Phone app made by Blizzard for World of Warcraft. Sure there are security implications, (what if they hack your I-phone?), but at that point we're getting into, "you're screwed already" territory.

So in conclusion: Don't ever believe in perfect security.



Wednesday, June 3, 2009

ASCII Art in Password Cracking

Just a quick warning but almost all the links presented here are NSFW, (more from an embarrassment factor due to ascii representations of male and female genitalia).

As pointed out in the comments of this post not all passwords are created from dictionary words or pass-phrases. One other way of creating a password is to use ascii art instead. For example:

/><{{{{">     --fish

///\oo/\\\  --spider

d[ o_0 ]b    --robot

You get the idea. Of course the most common ascii art used is that of the male genitalia. I'll spare you the examples of that on the front page of this blog ;)

The question then is what is the best way to attack these passwords? My gut feeling is that a standard dictionary based approach is the way to go, but instead of input words you can use a wordlist full of ascii art instead. To test this I googled various terms such as "ascii penis", "ascii porn", "one line ascii art", along with some actual pictures of said ascii art to collect as many examples as possible. One a side note, I hate to envision what Google thinks of me based on my browsing history...

What I found is that most people used variations of common "construction" techniques of their ascii pictures. For example the shaft is usually either '=' or '-'. There are common heads, bases, depictions of sperm, and depictions of what said ejaculation is landing on. I then threw all of this into a script and had it output all the possible different combinations. The end result is a little over 3 million examples of NSFW ascii art for use in password cracking. You can get a copy of the wordlist here. In all likelihood it's the largest collection of ascii porn on the internet. That's exactly what I thought I would be creating when I decided to go for my PhD. Sigh, at least it's better than frog fluffing, (a reference to the movie beerfest). 

The list is rather large since I included a lot of options that probably won't be used in real life, such as 'p' to represent someone with only one ball, (people on the internet are inventive, what can I say). Also spacing added quite a bit to it since in password cracking the spaces used/not used do make a difference. If you have any examples I missed please post them in the comments of the site where I'm hosting the wordlist as I'd rather avoid getting my inbox filled with depictions of ascii penises and vaginas.

The next step is to create another wordlist containing "normal" ascii art such as hearts, frogs, etc. Once I have that done I'll post that as well.

One final note. Despite all the joking, I seriously considered not writing this post or making this wordlist available since I do like to maintain a shred of dignity, professionalism, etc. The thing is, people actually create passwords this way so something like this wordlist is needed by the community. I'd really appreciate it though if you kept this post off of digg, slashdot, don't submit it for an ignobel award, etc so it stays "in-house".

Monday, June 1, 2009

Re: Test the Strength of Your Password Policy

Reading sraveau's twitter posts, I was directed to this article by Robert Grimes on evaluating password policies. It's an interesting read and it includes an Excel spreadsheet where you can enter in your password creation policy, (aka passwords must be 8 characters long and contain an uppercase letter), the expected attacker strength (number of guesses per minute), and your password expiration policy. In turn it will output the probability of an attacker being able to crack one of your user's passwords. I do have a few issues with it though, hence this post.


1)I'm becoming more and more convinced that the protocols that govern login attempts are a bigger deciding factor on password security than password creation policies. This actually merits it's own post, but the short answer is that login attempts need to become more "costly" as the number of incorrect logins increases. This prevents a legitimate user from being locked out due to a password guessing DoS attack. On the flip side, if you can limit an attacker to one guess every two minutes it can make even a "weak" password fairly resistant to password cracking attacks. Of course, the downside is that your normal user/sysadmin usually can't do anything to implement this as they are dependent on the tools/operating system they use. That's why I have a blog though, to hopefully convince people this is something they need to demand from their vendors ;)


2) The size of the user-base should also be taken into account. Trying to crack 1,000 passwords vs 1 is much easier because you are almost guarenteed to have one person who selected the password 'Password123!'


3) While trying to measure the entropy of password creation policies is useful, I agree with about every single written paper on the subject that measuring the entropy is a HARD problem. Humans just don't do random well, and an attacker can take advantage of that in various ways that are hard to abstractly model.


4) While this doesn't apply to evaluating password policies, I do think evaluating the strength of individual passwords is a much easier problem. This is the engineer in me speaking, (vs the scientist), but we already know the main attack techniques out there. Access Data makes their ruleset available online. We can download Cain&Able, and L0phtcrack (It's back!!!), to see their rules. John the Ripper is a little trickier since many users create custom rules, but some samples are available here and here, (or my own examples here). Same goes for Hydra or any of the other popular password cracker programs.


5a) The problem is that even when there is no hashing, running these password crackers can take a long time, (especially Access Data's PRTK which will run pretty much forever). To help solve this, one approach is to use a modified edit distance to evaluate passwords to try and figure out what base words + mangling rules were used to create them


5b) Take the password 'P@$$Word123'. It's fairly trivial, (as a human), to look at it and say that I created it by taking the word 'password', capitalizing the 'P' and 'W', changing the a->@ and s->$ and finally adding '123' to the end. I can then look at the various password cracker rulesets to try and find a rule that would match it. Once you have that it's a piece of cake, given an input dictionary, to find out how many guesses it would take to crack that password. This gives you a very accurate idea of how strong your password is.


5c) As I said, my main approach to this is to use a modified version of edit distance to identify the mangling rules it required to create a password. I very briefly mentioned it in my Defcon talk last year and you can see a horribly coded version of this in my defcon submission packet.


5d) The advantage of using edit distance is it's really fast, (seconds), though I admit that I use a bunch of shortcuts so I probably should use "finger quotes" when mentioning the term edit distance, (calculating the true edit distance isn't really necessary).


5e) The main downside is that to calculate edit distance it requires an input dictionary similar to one that you expect to be used by the attacker. This is the hardest part to estimate since input dictionaries vary widely depending on the attacker.


6) As to the conclusions presented in the article: I've said it before but I'm not a big fan of password change policies to prevent password cracking attacks. Password length does help a lot, but once again it puts the burden of security on the users which never ends well. Ideally the security to limit password guesses should be built into the back-end of the system. In the meantime I think checking passwords against existing password cracker rulesets as part of a user's password selection, (rejecting the password if it is deemed crackable),  has a much better chance of increasing security vs. forcing everyone to choose a long password and then having users take shortcuts, (such as typing the same password two/three times, using keyboard combinations, etc).


7) Of course, what do I know? If you disagree please leave comments as I truely value the feedback. I admit, I've been wrong about many things before and I have no delusions that will change in the future ;)  

Frequency Analysis for Stronger Passwords

As a commenter pointed out in my last post, the previous frequency analysis was based on a set of passwords where there was no strong password creation policy in place. What happens when you look at only "strong" passwords? Well, I went through the MySpace list, the Phpbb.com list and the Finnish list and extracted all the passwords that would meet stronger password creation rules, (at least 8 characters long, containing at least 1 lowercase letter, 1 uppercase letter, 1 digit, and 1 special character). This gave me a grand total of 214 passwords, (an impressive number I know...).  I belatedly realized that I forgot to copy a couple of other lists, (such as from Millw0rm, singles.org, etc), from my school computer back in Tallahassee, so I'll try to get someone to send them to me so I can update this post with a larger data set.

As you can see below, uppercase characters dominate the first character set, and numbers/special characters dominate the last character set. Admittedly this is a small sample size. If anyone has a better data set or can point me in the right direction I'd love to take a look at it. Oh, and keep those good comments up ;)

Here is the data:

Overall Character Frequency Charset:
1ear!i0t2soln3#dbA4mcu5$h89S7y*kgPCD@_w-TG6EB.pRHxvQFMLJqYONfKW%VI/&zZXj^U}]\[)(:,+

First Character Frequency Charset:
SPDFCAGT1MBRLNKJVE*!mdcQIH$tqbO432#}zvusk^YXW960-(

Last Character Frequency Charset:e
1!5*327$r94#0e.%kdba]8-wuomlgc^\ZVTSQNKHCA6/

Overall Character Frequecy Analysis:
1 5.81745
e 5.2658
a 4.81444
r 3.91174
! 3.81143
i 3.36008
0 3.15948
t 2.70812
2 2.65797
s 2.60782
o 2.60782
l 2.25677
n 2.10632
3 2.05617
# 2.00602
d 1.80542
b 1.80542
A 1.65496
4 1.65496
m 1.60481
c 1.60481
u 1.55466
5 1.50451
$ 1.45436
h 1.40421
8 1.40421
9 1.35406
S 1.25376
7 1.20361
y 1.15346
* 1.15346
k 1.10331
g 1.10331
P 1.10331
C 1.10331
D 1.05316
@ 1.05316
_ 1.00301
w 0.952859
- 0.952859
T 0.852558
G 0.802407
6 0.802407
E 0.752257
B 0.752257
. 0.752257
p 0.702106
R 0.651956
H 0.651956
x 0.601805
v 0.601805
Q 0.601805
F 0.601805
M 0.551655
L 0.551655
J 0.551655
q 0.501505
Y 0.501505
O 0.501505
N 0.501505
f 0.451354
K 0.451354
W 0.401204
% 0.401204
V 0.351053
I 0.351053
/ 0.351053
& 0.351053
z 0.300903
Z 0.250752
X 0.200602
j 0.150451
^ 0.150451
U 0.150451
} 0.100301
] 0.100301
\ 0.100301
[ 0.100301
) 0.100301
( 0.100301
: 0.0501505
, 0.0501505
+ 0.0501505

----------------------------------------
First Character Frequecy Analysis:
S 7.94393
P 7.00935
D 6.07477
F 5.14019
C 5.14019
A 5.14019
G 4.6729
T 4.20561
1 3.73832
M 3.27103
B 3.27103
R 2.80374
L 2.80374
N 2.33645
K 2.33645
J 2.33645
V 1.86916
E 1.86916
* 1.86916
! 1.86916
m 1.40187
d 1.40187
c 1.40187
Q 1.40187
I 1.40187
H 1.40187
$ 1.40187
t 0.934579
q 0.934579
b 0.934579
O 0.934579
4 0.934579
3 0.934579
2 0.934579
# 0.934579
} 0.46729
z 0.46729
v 0.46729
u 0.46729
s 0.46729
k 0.46729
^ 0.46729
Y 0.46729
X 0.46729
W 0.46729
9 0.46729
6 0.46729
0 0.46729
- 0.46729
( 0.46729

----------------------------------------
Last Character Frequecy Analysis:
1 21.4953
! 18.2243
5 6.07477
* 4.6729
3 4.20561
2 3.73832
7 3.27103
$ 3.27103
r 2.80374
9 2.80374
4 2.80374
# 2.80374
0 2.33645
e 1.86916
. 1.86916
% 1.40187
k 0.934579
d 0.934579
b 0.934579
a 0.934579
] 0.934579
8 0.934579
- 0.934579
w 0.46729
u 0.46729
o 0.46729
m 0.46729
l 0.46729
g 0.46729
c 0.46729
^ 0.46729
\ 0.46729
Z 0.46729
V 0.46729
T 0.46729
S 0.46729
Q 0.46729
N 0.46729
K 0.46729
H 0.46729
C 0.46729
A 0.46729
6 0.46729
/ 0.46729