Complexity Fail

Those of you passingly familiar with the concept of entropy no doubt let out a groan there. For the rest, here’s why: using a date of birth reduces the complexity of the password into the realm of “trivially weak”. Entropy is a common measurement of information complexity; how “surprising” a piece of information is, or how “unknown” it is (…stick with me on this). Simply knowing that the password is a date reduces the unknown-ness of that password from a reasonably-secure level to an entirely unacceptable level.

For comparison, if we assume an 8-character password with the 94 standard keyboard symbols, we have an entropy of (8 log2(94) ) = 52.44 bits (or equivalently, just over 6 quadrillion possibilities), which is reasonable for most purposes.

On the other hand, a date isn’t just an 8 character password. It’s not even an 8 character numeric password (with obviously 99,999,999 options, or 26.8 bits of entropy), which would be weak but not laughable. In fact, it’s really a 3 character password: a month, a day, and a year. Those are respectively ~30.44 possibilities  (days per month), 12 possibilities, and 60 possibilities (assuming our account holder was born between 1940 and 2000). In bits, that’s approximate 4.93 + 3.58 + 5.91 = 14.42 bits. An analogous password described in characters we are familiar with would be a three character password made up of: a single number, followed by a single lower-case letter, followed by a single alphanumeric. So, your password options are no different (entropy-wise) than “1aA” or “8q3″, and you didn’t even get to pick your wussy three characters.

Solving 14 bits of Entropy

Let’s put this to work. First, a list of every date between Jan 1, 1940 and Jan 1, 2000. Python is my sketchpad of choice:

from datetime import datetime, timedelta
 
max_date = datetime(1999, 01, 01)
date = datetime(1940, 01, 01)
day = timedelta(1)
f = open("datelist.txt", "w")
 
while(date < max_date):
    f.write(date.strftime("%d%m%Y")+"\n")
    date = date + day
 
f.close()

Now datelist has a properly formatted date for each day in our range. How many possibilities is that?

$ head -n 2 datelist.txt
01011940
02011940
03011940
$ wc -l datelist.txt
21550 datelist.txt

That’s in line with our estimate above. Cool, let’s use that list to break a PDF created with this password scheme. Pdfcrack is a simple open-source password bruteforcing tool that helpfully takes a wordlist.

$ pdfcrack -f SensitiveDoc.pdf -w datelist.txt
PDF version 1.4
Security Handler: Standard
V: 2
R: 3
P: -1028
Length: 128
Encrypted Metadata: True
FileID: 9f86e55a12672dcd9b9a9cd3423303da
U: b89fd170770d5b802423d0ec2ae7ec6d00000000000000000000000000000000
O: 301981f88c00ebdafde32360d24b7ae0f6b8a3e1865ac314cbaec4f7cc7a3f49
found user-password: '13051959'

How long did that take?

$ /usr/bin/time -p pdfcrack -f SensitiveDoc.pdf -w datelist.txt cmd 2>&1  | grep user
found user-password: '13051959'
user 0.20

One fifth of a second. Super secure!

General Advice

So, to wrap up. Less complex passwords are reasonable in a security context where a system can monitor password guessing: web based systems, network logins, etc. Then you can respond with enforced guessing intervals, CAPTCHAs or secondary validation. However, when the attacker can take the data for offline cracking, the required strength of passwords goes way up. Using and trusting weak passwords in this instance caused this company to broadcast sensitive information that it wouldn’t intentionally expose.

The company would be much better off providing users a random 10 character code that they can write down and use to decrypt the account statements (yes, seriously, write down your passwords), or simply asking users to log in for the statement information.

The winners were just posted, and my entry got the nod for Best Creative Entry. This is particularly awesome for me since the original Counter Hack (by Skoudis) was one of the first security books I ever bought.

I highly recommend reading through the contest and the answers; as always, the technical walkthrough is hugely informative, and they cover a massive toychest of wicked VoIP hacking utilities. There’s also some pretty nice command line kung foo (hat tip) that makes me remember the power of the Unix philosophy of small tools.

~PST

——————————————

I. You have the right to remain silent.

You do not need to blog. You do not need to “Reply to this post.” You
do not need to Get MySpace, and you do not need to Facebook Me. If you
say nothing, the blogosphere will not deflate and strangers on
message boards will not miss your advice. If you say nothing, the
internet will not notice.

II. Anything you say can and will be used against you in the court of public opinion.

Nothing on the internet is private. Your real name, your AIM handle,
your livejournal, and the email address you had in high school are all
out there for anyone who cares to look. Just because you don’t know
how to find it doesn’t mean it can’t be found. The internet has a very
long memory. You should be willing to bet that it’s longer than yours.
Anyone you meet could know things about you that you have forgotten
you ever said. Speak slowly and carefully… there are a lot of people
listening.

III. You have the responsibility to be skeptical about everything; if you lack the ability to do so, find someone who will do so on your behalf.

The internet is not a library. The internet is not a newspaper. The
internet is a cacophonous bazaar of peddlers, kooks, and unruly
children sharing the same advertisement littered street corner as
politicians, scientists and parents. There are no signposts that
announce when you’re in the wrong part of town, and no one is going to
tell you when you’re being lied to or misled. An open and  skeptical
mind and a sense of personal responsibility are the rules of the road;
no shirt, no shoes, no service.

At BlackHat: (Wed 7/28, 1515) BlindElephant: Web Application Fingerprinting with Static Files

At Defcon: (Fri 7/30, 1400) Web Application Fingerprinting with Static Files

The Defcon talk is essentially a shorter, more technically focused version of the BH talk. Links to code available here after the talk!

I’ve been sorting through the massive amount of content on display over the next week, and the various posts others have made on what they intend to catch have been useful. Here’s some of my “want to see” list (I actually found there’s usually at least two presentations I really want to see in each timeslot, but I gotta choose):

Wednesday:

• 1000-1100 Wayne Huang, Caleb Sima: Drivesploit: Circumventing both automated AND manual drive-by-download detection
• 1115-1230 Charlie Miller, Noah Johnson: Crash Analysis using BitBlaze
• 1345-1500 Barnaby Jack: Jackpotting Automated Teller Machines Redux
• 1515-1630 Me! BlindElephant: Web Application Fingerprinting with Static Files

I’m kinda bummed I’m at 1515 because I actually really wanted to catch Arshan Dabirsiaghi:
JavaSnoop: How to Hack Anything Written in Java.

Thursday:

• 1000-1100 Nathan Hamiel, Marcin Wielgoszewski: Constricting the Web: Offensive Python for Web Hackers
• (My colleague Ivan Ristic is also giving his talk State of SSL on the Internet: 2010 Survey, Results and Conclusions Routers in this slot; it’s good stuff, so I’m torn.)
• 1115-1230 Julien Tinnes, Tavis Ormandy: There’s a party at Ring0 (and you’re invited)
  • (Gunter Ollman is also talking a 1115. If you’ve never heard him speak or want an intro to the economic underpinnings of malware and botnets, definitely check it out)
• 1345-1500 David Byrne, Charles Henderson: GWT Security: Don’t Get Distracted by Bright Shiny Objects
  • (Though I am interested in the TitanMist project, I’m skeptical of all “frameworks”)

And finally, my coworker Rami is going to be giving the details on the malware detection he built. He’s modest about the underlying techniques, but the full system is pretty cool. Do check it out.

• 1515-1630 Rami Kawach: NEPTUNE: Dissecting Web-based Malware via Browser and OS Instrumentation

I hope to get to BSides for at least a while, and I haven’t even figured out what I’m going to catch at Defcon (somehow it seems less amenable to planning than Black Hat)

If you’ll be be around, look me up! As usual, email or @coffeetocode on Twitter.

Here is the text that has been going out to cell phones in the 530 area code [1]:

From: NOTICE3319@yolofcu.org

NOTICE: Your YOLO-FCU CARD starting with 4661* has been put on hold. Please call us at (888) 819 9661.

Calling the line (which is still active as of this morning, 6/19) gives you a synthesized-voice prompt:

Thank you for calling Yolo Federal Credit Union 24 hours (sic) credit activation services.

For card card activation, press 1.
To change your pin, press 2.
To end this call, press pound.

The usual first line defense of simply reading the text (and listening) in this case should be a least a mild tipoff. The first detail that jumps out is the use of the first four digits of the account number (“starting with 4661″)[2]. Banks and card issues always refer to accounts by the last four digits, because the first four are always the same for a given issuer; they’re called the Issuer Identification Number (IIN). What’s particularly devious about this detail is that it lends false credibility to the phish because it invites users (victims) to improperly generalize from the familiar security practice of referring to an account by only the last four digits.

The next detail that seems a bit incongruous is the synthesized voice message. While not entirely unknown, one might expect a reputable credit union to use a real voice in the recorded message (if only for customer service reasons).

Other than those couple details (and the fact that no bank should ask for the information it’s requesting), this is a pretty decent phish. I give it a C+.

Feeling Insecure Is As important as Feeling Secure

Using SMS is a new twist, and is devious for the same reason the IIN was. The use of the cell phone as out of band (OOB) authentication (for email, banking and brokerage accounts) is beginning to permeate the public consciousness. Likewise, SMS doesn’t (in the US) typically get spam or solicitors the way email and land lines do, so it has a bit more of an aura of authenticity. These two pieces help make this particular incident nastier than your average phish.

We all need to remember that the more something feels secure, the more value there is to the criminal in subverting it or co-opting it. User training and UI design can’t just be about making users feel secure, it has to be about making them feel secure when they are actually secure, and likewise (and just as important) making them feel insecure when they are actually insecure.

If you regularly teach your users to “look for the lock icon” when connecting to a secure site, it can’t just be rote (though I know sometimes that’s what we have to settle for). What we should also teach along with it are the implications of what it means when the lock isn’t there. This is the type of knowledge that can help internalize and instinctualize security behavior (yes, I made up a word).

Banks: Please Meet Us Halfway

The last thing that I thought was interesting was the website for the real Yolo Federal Credit Union.

Here’s what I saw when I visited:

Wow, nothing about the scam? Seriously? That’s unconscionable. Oh wait, let me turn off NoScript:

Better-ish.

Here’s a catch 22 for YFCU; I’m sure they would advocate secure browsing practices (using NoScript while doing online banking is a no-brainer), and yet users trying to do that right wouldn’t see this important security information on the site. You’ll notice that it’s all an image, and wrapped inside a flash object. So, again a plea to site designers banks and everyone else; please, at least meet your security conscious users half way.

[1] I’m including the entire text of the scam message to raise the visibility of

[2] Similarly, the first five digits of a Social Security Number (e.g. 224-87-XXXX) are also fairly public information. Data that is presumed private has the effect of legitimizing a communication, making it all the more important to help users differentiate public and private data.

(Saturday Morning Breakfast Cereal — don’t wait, just add it to your feed reader)

Ben didn’t just lose the battle to get one bug fixed, he also lost an ally in the fight. Daniel (of OpenCart) was and still is in the best position to make small changes to vastly improve the security of OpenCart for all users, but after a public browbeating what are the chances he’ll be willing to get help from security folks? That’s the critical part.

The bug by bug approach to information security is trench warfare: it will take us too many years and too many lives (or at least careers) to gain ten feet of mutilated ground. We need people and practices on our side, and “wins” in security should be measured in those terms, not just in bug counts.

Yes, we as security people often have to tell people that some code or process or idea is absolutely wrong. But to say those things without destroying the human capital we desperately need, we must do it with an overabundance of patience, humility, goodwill, and tact.

I think Ben did a reasonable job of trying to be respectful and helpful, but there was something jarring in it for me.

See it? “…otherwise I will make the issue public.” Now, as a security person that may not seem hugely disconcerting; we know that when the carrot of coordinated disclosure fails, the stick of public disclosure can get results.  However, put yourself in Daniel’s position: he just got threatened. Reread the email, and think honestly about whether anything else constructive that Ben said will have as much of an influence on Daniel as the mere feeling that he’s being bullied.

So, Daniel gets a lot of emails from people that misunderstand some code, and he sends back a quick response (on a Friday evening no less):

So, clearly he didn’t get it. Amazingly, he still seems to be receptive to Ben. On the technical side, he may not even have checked out the PoC Ben provided. Ben responds with a lot of good information. It’s a technically accurate and helpful response for someone who is ready to learn about CSRF, but this is how he leads off:

Ouch. I’m sure it wasn’t Ben’s intent (or maybe he was just frustrated; understandable), but that line right there is going to put Daniel in defense mode. It’s subtle, but it’s an “I’m right, you’re wrong” moment. Even if Ben is right (he is), anyone’s ego would step in and interrupt rational thought right there.

Imagine if the second email had been even more patient and humble.

Instead, things kinda spiral downward. It ends with:

followed immediately by:

Communication is no longer occurring. We as security people must take the responsibility to prevent that. What if, at the moment that things were spiraling downhill, Ben had sent an email like.

Yes, I know it’s crazy. It’s over the top, it’s above and beyond the call of duty, and it’s kinda weird: use the telephone… really? But that might, just might, have helped Ben win not just the battle over a single bug, but might have won an ally in the security of an entire application, and gained the cause of security goodwill in the bargain.

I’m not saying that there aren’t complete, incorrigible, asshat people out there, or that killing them with kindness is any kind of panacea. Ultimately, Ben may not have been able to make progress even if he was a genetic hybrid of Mother Teresa and Bruce Schneier. What I am saying is that we too often forget that real security comes from the people, not just the code.

So, when you find yourself in a situation like Ben, please consider digging deep into your well of patience and giving a bit more when you’re tempted to give less.

I’m going to go ahead and say that fuzzing is ready to come out of the cold, from being primarily thought of as something security researchers and blackhats do, to eventually being something as expected as unit tests (…though I’m probably about 2 years late in saying that). With fuzzing a part of the SDL (gj MS) and Charlie Miller publicly calling on companies to get with the program, it’s well on its way.

Now, unit testing (and code coverage) took a while to be considered expected practice (and depending on where you work, might still raise eyebrows), but by and large they’re generally considered something that helps improve quality and reduce risk in a project. I have hopes that fuzzing will get there too.

The tooling is there, except that I think coming from the security community has hindered it a bit. There’s no standout leader like xUnit (cpp, n, j, etc), and instead we have dozens of tools grown from individual developers, which range from utterly broken to pretty good, and most serious fuzzing undertakings end up having to piece together a solution out of a number of other partial solutions. If you’re Charlie Miller, you have it figured out and built into a fusion powered spaceship, but the rest of us are still getting there (seriously, if you read one thing on fuzzing, check out that presentation from CANSECWEST this year… we all can aspire).

Trying to piece together such a solution myself, I started with FileFuzz and the excellent text Fuzzing: Brute Force Vulnerability Detection by Sutton, Greene and Amini.

Get Started Quickly With FileFuzz

If you’re looking to start file-based fuzzing as quickly as possble, FileFuzz is a good bet. It’s a mutational fuzzer so all you need to get started is a single sample file, and it’s “batteries included” (unlike many solutions) in that it incorporates the three big moving pieces of fuzzing: sample creation, test running, and error detection. Crash triage automation is a task that it doesn’t try to address, but if you’re just trying to get started, it’s going to help immensely.

While using it though, I found some bugs. Fuzzing a series of binary files, this pops up:

The output char buffer is too small to contain the decoded characters, encoding 'Unicode (UTF-8)' fallback 'System.Text.DecoderReplacementFallback'. Parameter name: chars.

A bit of googling suggests that PeekChar can’t reliably be used on binary data. I made the following change in the readBinary() function of Read.cs (line numbers are approximate because I made some other changes):

            //while (brSourceFile.PeekChar() != -1)
            while (brSourceFile.BaseStream.Position < brSourceFile.BaseStream.Length)

If you’re running FileFuzz on a modern .NET runtime (or through VisualStudio) you may see problems such as:

InvalidOperationException: Cross-thread operation not valid: Control 'Foo' accessed from a thread other than the thread it was created on

It looks like the FileFuzz UI was written before these cross-thread checks were enforced in .NET, so if you don’t want to spend a lot of time writing threadsafe delegates, you can add one line to revert to the old (unchecked) behavior. Add this at the beginning of InitializeComponent() in Main.cs (again, line numbers are approximate):

            Control.CheckForIllegalCrossThreadCalls = false;

At one point I thought I found that FileFuzz was only generating different files for the first 10 bytes or so, and identical files after that. It may have been some config error on my part and I couldn’t duplicate it later, but you may want to give your files a quick run through md5sum, just to make sure you don’t waste a lot of CPU cycles. (Has anyone else see this?)

Structured Exception Handling

While running FileFuzz against a particular target, I found a number of hits that didn’t reproduce nicely when run alone. When the target binary was executed via crash.exe (included w/ FileFuzz), it would show a access violation:

[*] "crash.exe" "C:\Program Files\xxx" 1000 C:\fuzzing\xxx\output\136
[*] Access Violation
[*] Exception caught at 1001c06d mov eax,[esi+0x8]
[*] EAX:0011f050 EBX:00000030 ECX:00000000 EDX:00000092
[*] ESI:00000000 EDI:0011f54c ESP:0011f0ec EBP:0011f0f4

When run with the same file from the command line, nothing; just an error message and a clean exit. Initially puzzling, I found that this is a result of windows Structured Exception Handling. (Here’s an old but worthwhile read on what really goes on under the hood in SEH) So, hook it up under OllyDbg or IDA and boink, there it is.

When I get a chance I need to get set up with !exploitable (presentation here ), but I’ll have to share that in a later post.

If you sign up and log in, you’ll be able to run other interesting queries like every webserver in Nigeria (find your favorite spammer!).

I’ve personally been using Shodan heavily to calibrate a webapp fingerprinter, and the biggest pain has been inability to export more than 1000 results. I emailed John and begged for the feature and after some back and forth, as of Sunday night, it’s ready! If you click the Export button, you’ll now be prompted with the number of hosts you want to export (in increments of 1000). He says it will accommodate up to a million hosts, but might take a while to make the xml available.

Incremental export (essentially pagination) isn’t yet supported, but if there’s demand he might add it.

I still think that $50/20 credits (20k hosts) is highway robbery (more begging is probably in order), but it’s a unique tool and may save you a lot of time with nmap and a scripting language.

Here are the slides as a PDF: 200 Milliseconds to Owned

The first “mother may I” exploit was MS06-014. The second demo I did was the more interesting MS10-002, a heap spray used in the Aurora attacks. Symantec has a good writeup.  If you actually want to play with either of these, you’ll find them both in Metasploit. You should have little trouble duplicating the demos on XP virtual machines with IE6, and with a little websearching you can probably find a version of the MS10-002 exploit that will work on Vista and IE7 machines.

The small reversing demo with the serial number checking program was from crackmes.de. Grab a copy of OllyDbg and start poking around.

Happy hacking!