Cатсн²² (in)sесuяitу / ChrisJohnRiley

Exposing Crypto Bugs through reverse engineering – Philippe Oechslin

“In this talk simple errors will be demonstrated that were discovered when reverse engineering three products for evaluation or forensic purposes. In each case, a simple error gave access to information that was supposed to be protected by the best crypto algorithms.”

• MXI stealth USB key
• EISST E-capsule PrivateSafe
• Data backers Private Safe

MXI stealth USB key

This USB is similar in design to the Ironkey product, but also offers fingerprint access. The product is FIPS 142-3 level 2 certified. Information on the certification is available on the internet, and provides full specs and information on the USB device.

Passwords are stored on the EEPROM in salted SHA-256 format. Upon a failed password attempt a delay of 500 milliseconds is imposed to prevent brute-force attacks.

In testing it was found that the library responsible for the encryption between the computer and the USB key still had debug and symbols present. By further looking at memory with a debug it was possible to discover a SHA-1 hash of the current password and the previous 2 used passwords (these hashes where not salted and not SHA-256). This location was without entering any password and provided the ability to retrieve the hashes and perform an offline brute-force (bypassing the imposed 500 millisecond delay).

Correcting the issues: The company where very responsive and provided a fix within a week of being notified.

EISST E-capsule PrivateSafe

The software has 4 different passwords to enable deniable encryption (similar to Truecrypt hidden volumes). Each password shows a different volume to allow for multiple levels of deniability.

By looking at the control file of the product itt is possible to see that there are 4 sections to the file (numbered 1..4). y reverse engineering this file it was possible to find that the encryption used was AES 256 CTS mode. The key is a SHA256 hash of the corresponding password for the section. The IV is based on ripemd160.

Once the password is know it is possible to decrypt the control file using openssl as it supports both AES and ripeMD160.

As the blocks in the control file represent the sections 1 through to 4, it is possible to edit the control file to alter which password opens which section, without knowing the password. This can be easily achieved by simply changing the hex values for section 1 and section 2. This will result in the password for 1 being now valid for the 2nd section.

Correcting the issues: The vendor was made aware, but insisted that the product worked “as advertised”

DataBacker PrivateSafe

This software creates an encrypted data container. There is a control block at the beginning of the file (instead of separate as in the previous example). The data is encrypted using Blowfish CBC 4096, with an IV that is always the same (012345) with a key of the users password.

By loading the software into a debugger (in this case Ollydbg) it is possible to find the location in the code that loops through each character of the password to create a checksum (by XORing all characters of the password shifted one bit. The program then uses this checksum to see if the password is valid.

By examining the process and the checksum to match, it’s possible to see if the characters create an odd/even result. This would allow an attacker to cut down on the characters to check (cut down by 50%) and permit easier brute-forcing. If a password is found that matches the checksum, it “might” be correct. If it’s wrong it will crash the program as it fails the decoding (even though it matches the simple checksum test).

As blowfish was designed to prevent brute-forcing (~25,000 per second), it is possible to only attempt possible passwords that match the checksum. This cut down the brute-force from 1.7 years, to 2.5 hours (in this case).

Correcting the issues: Software discontinued.

Conclusion

• Crypto is hard to implement correctly
• If no source code is given, only reverse engineering can find the errors
• When possible, prefer open-source solutions over closed-source, they are easier (and cheaper) to verify.

More information can be found on the CCC wiki