Magic Crypto Dust Presented by Damian Profancik integrisec

$whoami Damian Profancik • • Principal Security Consultant Trustwave Spider. Labs dprofancik@trustwave. com @integrisec

Agenda • Encryption Explained • Encryption Issues • Proper Encryption Use © 2012

Encoding vs. Hashing vs. Encrypting © 2012

Encoding vs. Hashing vs. Encrypting • Plaintext – Magic Crypto Dust • Encoded – Base 64 => TWFna. WMg. Q 3 J 5 c. HRv. IER 1 c 3 Q= • Hashed – MD 5 => d 8 b 097 eed 611406613919697763838 bd – SHA 1 => c 834 eb 5 d 48 b 9354 bc 938332276008 f 426114 b 39 d • Encrypted – AES 256 => H 9^ÒÔZz#�â� c'D¾æ ; *b 5Á¬'� ½æ © 2012

Symmetric Encryption • Shared secret key between parties • Example algorithms: – RC 4, 3 DES, Blowfish, IDEA, AES • Stream cipher – One byte at a time is encrypted • Block cipher – Plaintext is padded to be a multiple of the chosen block size, and then each block is encrypted • Weaknesses – Key distribution, known/chosen plaintext, cryptanalysis © 2012

Asymmetric Encryption • • Different key to encrypt vs. decrypt Public key and private key Used for confidentiality and authentication Example algorithms: – Diffie-Hellmen, DSA, RSA, El. Gamal • Weaknesses – Mit. M, side-channel/timing, computationally expensive, quantum computers © 2012

What could go wrong? • Mistaking encoding for encryption – Hex && Base 64

What could go wrong? • Homebrew/proprietary ciphers © 2012

What could go wrong? • Poor random number generation – Weak functions • C/C++ = > rand() without seeding srand(), not 3 rd party lib • Java => Random, not Secure. Random • . Net => System. Random, not System. Security. Cryptography. Random. Number. Generator • Python => random, not random. System. Random – Insufficient seeding, such as timestamp or static value – Defective algorithms • Dual Elliptic Curve DRBG (DUAL_EC_DRBG) and the NIST/NSA controversy © 2012

What could go wrong? • Weak or no salt – – Salt too short Reuse of salt for every hash Poor salt selection, such as username Concatenation mistakes • Weak hashing algorithms – MD 5 and SHA 1 – Hash collision attacks – Single round hashing © 2012

What could go wrong? • Hash Length Extension MD 5, SHA 1, SHA 256, and SHA 512 are vulnerable SHA 224 and SHA 384 are not vulnerable Plaintext and secret key lengths are known Internal state of algorithm at time of hash can be computed – Additional information can be added to the hash – Mostly used forging signed data – – © 2012

What could go wrong? • Hash Length Extension – Original Data: count=2&lat=20. 361&user_id=1000&long=-19. 821&piza=pepperoni – Original Signature: 7 d 5 f 857 e 23 db 212 bc 254 a 2 fbe 2 d 6759 b 0 f 5 f 5 d 90 – Desired New Data: count=2&lat=20. 361&user_id=1000&long=19. 821&piza=pepperoni&pizza=sausage – New Data: count=2&lat=20. 361&user_id=1000&long=-19. 821&piza=pepperonix 80x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 00x 02&pizza=sausage – New Signature: 1 e 412732605959693 c 7 fff 3898 bb 85768963 aaa 0 © 2012

What could go wrong? • Insufficient certificate checking – Failure to validate expiration date,

What could go wrong? • Key mismanagement – Storing keys with the encrypted data

What could go wrong? • Weak block cipher mode – Electronic Code Book (ECB)

What could go wrong? • No Initialization Vector (IV) for CBC mode – First block of cipher text will always be the same • Using encryption key as IV – Allows for key recovery if decryption oracle exists © 2012

What could go wrong? • Encryption Oracle – Allows for arbitrary encryption of known

What could go wrong? • Decryption Oracle – Allows for the arbitrary decryption of

What could go wrong? • Padding Oracle – Side channel attack that allows for complete decryption and encryption – Caused by padding errors in CBC mode block ciphers – ASP. NET, Ruby on Rails, Java Server Faces, and IBM e. Commerce Server have all been vulnerable in the past © 2012

What could go wrong? • Padding Oracle – PKCS 7 padding example 01 02

What could go wrong? • Padding Oracle ALRIGHT STOP. . . DEMO TIME ©

The Solution • Use proven and vetted algorithms • Password hashing – Use "key stretching" algorithms, such as PBKDF 2, bcrypt, or scrypt – Prepend a long, unique, and random salt to value prior to hashing © 2012

The Solution • Symmetric Encryption – Practice proper key management – Use a more secure block cipher mode, such as ideally GCM, CTR, or CBC – Do not reuse encryption keys or IVs – Sign encrypted text with an HMAC and validate it prior to decrypting – Do not directly display encrypted output – Randomize plaintext prior to encrypting © 2012

The Solution • Asymmetric Encryption – Practice proper key management – Use valid certificates with sufficient key strengths, such as 2048 and strong algorithms, such as AES 256 – Perform certificate pinning where possible – Use perfect forward secrecy © 2012

Resources • Customizable Vulnerability Testbeds: – Magical Code Injection Rainbow - Crypt. OMG https: //github. com/Spider. Labs/MCIR/ • OWASP – https: //www. owasp. org/index. php/Guide_to_Cryptogra phy • http: //blog. spiderlabs. com/2013/01/defeating-aes-without-a-phd. html • http: //c 0 nn 3 ct 0 r. blogspot. com/2011/11/automated-padding-oracleattacks-with. html • https: //github. com/GDSSecurity/Pad. Buster • https: //code. google. com/p/bletchley/wiki/Overview © 2012