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

Because we're damned if we do, and we're damned if we don't!

Tag Archives: crypto

{BruCON LT} A quick rant about WebApp crypto

After mulling over possible topics for a BruCON lightening talk I settled on a quick rant about how Web App testers in general are treating crypto. I know crypto doesn’t lend itself to a 5 minute format, and the generalisation (that Web App testers don’t check crypto) is a little broad… but I thought it was a good topic to bring into the small spotlight.

If you have any feedback on the slides (rush job, sorry), or the content in general then please let me know… feedback is gratefully received!

More details about the TYPO3 vulnerability (TYPO3-2009-SA-001) mentioned can be found in the advisories section of this site.

Blackhat Europe: Practical Crypto Attacks Against Web Applications

Practical Crypto Attacks Against Web Applications (Thai Duong & Juliano Rizzo)

Abstract (source: Blackhat.com)

In 2009, we released a paper on MD5 extension attack ([1]), and described how attackers can use the attack to exploit popular web sites such as Flickr, Vimeo, Scribd, etc. The attack has been well-received by the community, and made the Top Ten Web Hacking Techniques of 2009 ([2]). In the conclusion of that paper, we stated that we have been carrying out a research in which we test-run a number of identified practical crypto attacks on random widely-used software systems. To our surprise, most, if not all, can be attacked by one or more of well-known crypto bugs. In this talk, we present the latest result of that research, where we choose another powerful crypto attack, and turn it into a new set of practical web hacking techniques.

We show that widely used web development frameworks and web sites are using encryption wrongly that allow attackers to read and modify data that should be protected. It has been known for years in cryptography community that encryption is not authentication. If encrypted messages are not authenticated, data integrity cannot be guaranteed which makes systems vulnerable to practical and dangerous chosen-ciphertext attacks. Finally, we list several popular web development frameworks and web sites that are vulnerable to Padding Oracle attacks, including, but not limited to, eBay Latin America, Apache MyFaces, SUN Mojarra, Ruby On Rails, etc. These are all 0-day vulnerabilities. We show that even OWASP folks can’t get it right, how can an average Joe survive this new class of vulnerabilities? We strongly believe that this is just the tip of the iceberg, and the techniques we describe in this research would uncover many more vulnerabilities for years to come.

Talk Abstract –> Practical Crypto Attacks Against Web Applications

Speaker Bio –> Thai Duong, Juliano Rizzo

Practical Padding Oracle Attacks

First introduced by Vaudenay at Eurocrypt 2002

Two assumptions

  • Adversary can intercept padded messages encrypted in CBC mode.
  • Adversary has access to a padding oracle.

Demo (fail) –> Exploiting RubyOnRails ActiveSupport::MessageEncryptor

Finding potential padding oracles

  • Crawl the target to find BASE64 strings that look like ciphertext
  • Look for known source code keywords like javax.crypto.BadPaddingException
  • Look for routines that perform encryption and decryption that have some code to handle error while decrypting

Confirming the existence of padding oracles

  • Confirm the block size b
    • All padding oracle attacks need a correct b
    • Most common attack sizes are 8 and 16 bytes – Trial and error

POET – Padding Oracle Exploitation Tool –> Not yet publicly released

Cracking CAPTCHA

Some CAPTCHA systems are open to the padding oracle attack demonstrated earlier. A method to perform this has been developed using just JavaScript (in the browser).

Decrypting JSF viewstates

JavaServer Faces (JSF)

Although the JSF specification advises that view state should be encrypted and tamper evident, not many implementations follow that advice.

This means the Padding Oracle attack can be used to decrypt the view states of most JSF frameworks

By default, all JSF frameworks would display a very detailed error message if it fails to decrypt a view state

If error messages are turned off, it is still possible to perform the attack

JAVA ignores the extra (padding blocks) while decrypting and deserializing the viewstate. This allows for sending random padding at the end of the string to see the response. If the viewstate returns the same information the padding is valid. If the server returns a HTTP 500, then it’s invalid.


CBC-R turns a decryption oracle into an encryption oracle

Only a single bit of information is necessary to exploit a padding oacle

Cross-domain leakage bugs in web-browsers can help


  • Padding oracle attacks allow one to decrypt ciphertext without knowing the key.
  • We can use padding oracle attacks to crack CAPTCHA, and decrypt JSF view state, etc.
  • CBC-R turns a decryption oracle into an encryption oracle, and allow us to create malicious JSF view states.
  • Distributed cross-site padding oracle attacks allow one to distributively build a code book to map all ciphertexts to corresponding plaintexts.

Note: Blogging Crypto talks is almost impossible….. I’d suggest grabbing the slides, whitepaper, video and a lot of coffee!

Additional Links

For more information please see the Blackhat Europe website

26C3: Exposing Crypto Bugs through reverse engineering

Exposing Crypto Bugs through reverse engineeringPhilippe 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.


  • 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