In the last few weeks there have been a few stories about criminals using stolen credentials to steal large amounts of money from unsuspecting victims. The Zeus botnet stole about a million dollars from UK banks. Criminals stole a million dollars from UVA, and the Diocese of Des Moines had 600K stolen. All of these followed a similar pattern – criminals used stolen credentials to move money to other bank accounts. I’m reminded of the 2010 Verizon Data Breach Investigations Report (if you haven’t read it, please do). One of the recommendations was to limit the amount of damage that can be caused by compromised credentials. If these banks had been following that advice, their customers might not now be out millions of dollars. If they had implemented any sort of program to look for fraud indicators, they likely would have avoided this whole mess. I know of many banks that have such a program in place, and let’s just say that I haven’t seen any of them show up in the news lately.

• The top 17 or so passwords accounted for about 25% of all passwords in use. That means you could crack one out of every four passwords in 17 guesses.
• The most common password (accounting for 9.4% of the passwords in use) was the extension itself.
• Shorter passwords were greatly preferred over longer ones. (This shouldn’t shock anyone).

The most interesting thing though, was the distribution of passwords by length, which I’ve reproduced below:

So, even though shorter passwords are more common, passwords of an even length are more common than the odd number which immediately precedes them. (The one exception is 7-8, where 7 is more common, perhaps because people use a 7 digit phone number as a password). The main question on my mind of course is why – does the human brain find it easier to remember string of numbers in pairs? Do people just like even numbers more?

When extracting images from the report, the front cover has 2 main images – one of a blue fingerprint, and one of a grey one. When run through stegdetect it says that the later has 10 bytes of data before the 0x9d flag. I tried to get the data out with fphide, but fphide requires a key to extract. Since I had no more leads on another key, I had to give this up quickly. I tried stegbreak using both the john the ripper wordlist and the report itself as a dictionary to no avail. I also manually obtained the 10 bytes with a hex editor and tried using that as a key to break the encrypted data, but what algorithm uses an 80 bit key? (And I still don’t know the algorithm or the iv). I’m currently leaning back to my initial position that there is no steg data for four reasons:

1. What can you really hide in 10 bytes?
2. If you google this, you’ll see a lot of people have this issue. It could very easily be an artifact of the program which created the image. *cough*Adobe*cough*
3. Getting the images out of the doc seems to require either Acrobat pro or a third party app. I find it hard to believe that the creators of the puzzle would require either of those.
4. The clue on ZDnet says so.

That is of course speculation on my part, and I could be wrong, but that’s the assumption I’m working on going forward.

On a related note, this is far more fun to do with other people. I think I finally see the value of twitter.

The first thing to note is that on the back cover, in black text on a black background, is the following block of code:

U2FsdGVkX1/igcsdctD3brMu4vDXkswNZZoHL6QVcI6eBlfN4aqvBBowRhf9wfsk
hb5RIGVSpphM2bJe33tVKh7koZ85V5ebFI1mPlXEhnKHO+er8EIyDRYuVvju08qv
u/jITmGEM4Mpk4gvL7aVeFB5lxoMFo0ds/CEA6zK80QprvV5B+c6+MWciIzLFJWI
/4OcO96UGM2riMKj2iy4JgmRxjEUyX/TKQEIB1s7WLh6cW30JpvgAI8wILVdTWpt
+gnIfyEGxio4Q2T9LM1ncA5K2P4lg/DsTiDIEEg3Ws4uW5sbz22qfE91frW7NnBg
t46Iy0WhZgw0+wj4DCLzF4GBnIkplanSMdA+hiwhdR629KL7O8X1ZLg5eFHmjS6C
VCXXuQJVSaVG77/5113N/eNMboD2RhXyq1kWzZZaW/lpJ8vIDs5OK7d1TPG6aVLJ
hINx3qPZzNvtK4r4KfZ5fhjUXLcufOpE46gGnD0aHW+SCcGl2k7NPqbYfGtYSwuJ
HYne4VTxR772vsV5RFgirw==

Clearly it’s no stretch to imagine that this is a major clue. After spending several hours convinced that there was steganographic data encoded in the image on the front cover, I turned to analyzing the code block. The first several characters – U2FsdGVkX1/ – are the base64 encoding of “salted__”. What I have since learned is that when you encrypt something with a salt, the resulting ciphertext includes that string followed by the actual salt so that it can be decrypted. (Thus an awful lot of cipher text begin with U2FsdGVkX1 – the slash is sometimes a different character that has to do with the peculiarities of base64 encoding). If this has been salted, that means is has been encrypted. If it’s been encrypted, that means it can be….. unencrypted! I tried a lot of educated guesses at the passphrase, none of which have yielded a positive result yet. Part of the problem is that I know neither the key nor the algorithm. My last ditch attempt was to take the DBIR, convert it to text, use it as a dictionary, and then try each word as a key for AES128, AES256, DES, 3DES, blowfish, etc. My quick and dirty shell script is here:

for line in `cat dict`; do
  `openssl aes-128-cbc -d -base64 -in textblock -k $line`
done

for line in `cat dict`; do
  `openssl aes-128-ecb -d -base64 -in textblock -k $line`
done

repeat for 3DES, blowfish, etc., etc.

I have a feeling that the answer to either the algorithm or the key must be in the report somewhere, I just can’t find it. I hope this helps someone. (And if it does, please let me know).

“Most organizations are struggling with the rising tide of email attachments, which can rapidly consume all available email storage when left unchecked.”

They attributed this quote to Matthew Cain, which I can’t verify, but my only response is: Really? I mean really? In this day and age? Are you sure this quote isn’t from…. 19992?

To prove my point, I decided to look at the 10 largest banks in the US and discovered that four of the ten exhibited this flaw. (Bank of NY Mellon does not seem to have a login on their main domain, and therefore don’t utilize SSL period). One would think that for a large financial institution like one of these, getting a multiple domain certificate would be a simple task, but apparently they never thought to do it. In the mean time, they’re training their users for poor security practices.