Well, the Verizon DBIR contest hasn’t been solved yet (or at least, Verizon Business hasn’t announced that it’s closed), so I decided to take another stab at it. Twitter doesn’t seem to include my tweets in searches, so no one saw my initial tweets on the subject, but today there were other people tweeting about it. The main focus right now seems to be stego data in the image on the front cover. I followed this line of thought for some time on Monday, so I figured I’d law out my thoughts here.

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.

This morning Verizon Business announced that the DBIR contains a secret code. I promptly set about to try and crack it. I feel that I’ve made significant progress, but I have to stop now and I won’t have a chance to resume for a few days, by which point I’m sure it’ll be over. In the mean time, I’ve decided to share my results so far here in the hopes that my experience will help others, or perhaps others can point out flaws in my logic.

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).

Although not strictly related to the infosec field, I’ve found that at least in the DC area a lot of infosec professionals need security clearances, and a lot of budding infosec professionals are always asking questions about them. The University of Fairfax has put out a very good security clearance handbook which addresses most of the issues you’d want to know about. You can download it directly from here.

If you hire a criminal…

Convicted TJX hacker Albert Gonzalez earned $75,000 a year working undercover for the U.S. Secret Service, informing on bank card thieves before he was arrested in 2008 for running his own multimillion-dollar card-hacking operation.