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

In the Verizon DBIR report they have an interesting graph on page 26. It shows the percentage of malware infections that have been customized. (That is to say that the malware itself is customized). In 2005-2007 the percentage held steady between 21%-28%. In 2008 is jumped to 59% and in 2010 is it still high at 54%. Perhaps not surprisingly, even though only half of the malware is customized, that half is responsible for 97% of the stolen records. Presumably non-customized malware and all other methods are responsible for the remaining 3%. Why the huge discrepancy? It’s easy – antivirus. Non-customized malware gets detected, customized doesn’t. This just goes back to something many people have started to feel in the last few years – antivirus is inherently flawed, and we’re starting to see it’s flaws. Blacklisting is inherent a losing battle, because there will always be new bad things, and there will always be something you didn’t think of. Whitelisting may seem like a pain at first, but in the long run it’s almost always easier and more efective.

It’s amazing how quickly something can go from “brand new” to “mandatory reading’, but that’s exactly what the Verizon Data Breach Investigations Report has become in its short existence. The 2010 report has been released. The total number of cases analyzed since the inception of the report is now over 900, and is easily the largest data set to date.