[Previous entry: "Entry point is not the entry point!"] [Next entry: "ring3 vs ring0"]
04/05/2005: "Trading Security for Convenience"
I have been using the Opera web browser for a long time now, but just the other day I decided that I wanted to know more about how the Wand feature works. Basically, what the Wand feature does is it saves form data such as login names and passwords and later recalls them at the click of a button. So for example, when you go to check your e-mail, instead of always having to enter the same login information over and over you can have Opera remember it and submit the form for you. Pretty handy, don’t you think?
My primary interest was not in the Wand technology itself (Internet Explorer has a similar feature called AutoComplete and I’m pretty sure FireFox has one as well). I was more interested in how the passwords are stored on disk. I did some research on the security of Wand files but there’s not much information to be found. The few relevant hits I did find are all rewrites of the same mailing-list response. The response originates from the Opera mailing-list, is about two years old (first published in February 2003) and can be accessed by going here.
The whole description of Wand security sounds pretty confusing but I get the feeling that it’s intentionally made out to be that way. The author of that post (Alex) also mentions that they’re using 3DES but knowing this is only marginally helpful. We still have to trace the code and see how it parses and processes the Wand data; hence, in time, we would have learnt about the cryptographic algorithm being used. My favorite part of the e-mail is “…it is possible to decrypt the wand.dat, however quite some Opera hacking and cryptography expertise would be necessary”.
I have tried making sense of the format of wand.dat but there is nothing sensible about it. It’s pure horror from beginning to end. Variable sized structures (possibly many different fixed size structures), unaligned data and a myriad of different flags. But, as luck would have it, there is a clean and straightforward structure for the actual encrypted blocks stored inside wand.dat. A highlighted block can be seen in this image. There are two very important points to note: The key length always equals 8 and, to try and put it simply, the size of the entire block always equals the size of the encrypted data plus 0x14.
Knowing this we can parse the blocks as we encounter them. It is sufficient to scan the Wand file for blocks and make sure any candidates conform to the observations we made earlier. The next logical step would be to figure out how the blocks are supposed to be decrypted. With a bit of debugging trickery it’s easy to find where Opera reads the key of a block and hashes it. Opera creates two hashes using MD5. The first one is of a hard coded key and the key from the encrypted block, and the second one is of the first hash, the hard coded key and the key from the encrypted block.
The resulting hashes together consist of 32 bytes of data. It’s around here somewhere that we are able to confirm what they said about 3DES. The first hash is split in two halves and used to schedule the same amount of keys. The second hash is also split into two halves. The first half is scheduled as a third key and the second half is stored away for a brief moment.
Let’s recap. We have three DES keys and a buffer with eight bytes in it, not to mention the buffer with encrypted data. The second half of the second hash is resurrected from wherever it was hidden away, and pushed on the stack. As now becomes apparent, Opera is using 3DES-CBC and the “extra” eight bytes are the Initialization Vector (IV). And that’s pretty much all there is to it. The unencrypted data will need to have any padding removed but that’s the story of Opera Wand passwords.
I wrote a small tool to do the decryption. It gives output similar to this and the source for it can be viewed and downloaded from here (needs OpenSSL to compile and link). By the way, the passwords shown in that image are bogus so don’t get your hopes up.
Supposedly, if you set Opera up to use a master password the Wand file will be encrypted in such a way that the password must be available to successfully decrypt it. I tried enabling a master password, but alas, it was all in vain as it refused to work. The master password dialog simply does not show and the Wand data is not encrypted differently. Visiting the Opera support forums I was able to confirm that this is a common problem as the forum is literally flooded with complaints about it.
I’m not sure exactly what the moral of the story is. It’s open to individual interpretation but if I were to comment on it I fear the subject would drift far from technical realms pretty darn quickly. Also, this is not an “attack” on Opera Software as I’m sure other browsers and their password-managers would be just as easily dealt with. I just happen to prefer Opera and use it for personal web browsing which is the only reason I chose it for this article.
As a final note, I’d like to suggest to Opera engineers that they hash the URL before storing it inside the Wand file. This limits the user in their ability to manage Wand passwords but it raises the security by so much that it is definitely worth it. It’s almost the same thing as having stolen a set of physical keys: If you can’t figure out which doors they open they’re not going to be of much use to you.
Edit: Somehow, when uploading this entry the second-to-last paragraph disappeared. It's been fixed now.
