crypto failures every developer should avoid
TRANSCRIPT
Crypto failures every developer should avoidFILIP ŠEBESTA - OWASP CZECH CHAPTER MEETING - PRAGUE DECEMBER 7 2015
What the conventional wisdom tells us about cryptographyCryptography is dangerous because you get no feedback when you mess it upNever implement your own crypto – what does that really mean? Most of the code using cryptography is not written/reviewed by cryptographers or qualified architects.Crypto built into products is oftentimes broken.Broken crypto might be more dangerous than no crypto as it gives you a false sense of security.
Veracode’s State of Software Security (June 2015)
The crux of the problemMany programmers think that they can just link to a crypto library and they're done, but cryptography is hard to implement robustly if you don't understand the finer aspects of it.You can easily develop an insecure crypto scheme using only “secure” algo.Longer keys don't always mean more security etc.Penetration testers rarely scrutinize crypto as it is a complex and demanding task.Crypto libraries are too complex – since they were designed by and for cryptographers.
Area of confusionWhat level of knowledge is requred to deal with crypto as a programmer?Do developers need to be cryptographers in order to use crypto correctly?Do we even have a choice?Rather then arguing who’s fault it is shouldn’t we work towards fixing this issue?
The way out of it1.train developers to use it securely2.Use high level crypto libraries
What is this presentation about?The goal of this presentation is to show the disconnect between what is expected from developers leveraging cryptography and the reality.
It will show some of the most typical crypto failures so that developers can learn from them.
It will also emphasize the importance of abstraction of crypto primitives to not allow developers to screw things so easily.
What kind of crypto pitfalls will we cover?
In his essay „Security Pitfalls in Cryptography” (1998) Bruce Schneider divided cryptography attacks into following categories:
- Attacks Against Cryptographic Designs
- Attacks Against Implementations
- Attacks Against Passwords
- Attacks Against Hardware
- Attacks Against Trust Models
- Attacks on the Users
- Attacks Against Failure Recovery
- Attacks Against the Cryptography
Failure #1 – Improper password storage
LinkedIn leaked out approximately 6.5 million passwords in 2012.
What went wrong?The social networking website LinkedIn was hacked on 5 June 2012, and passwords for nearly 6.5 million user accounts were stolen by Russian cybercriminals
LinkedIn failed to use a salt when hashing the passwords
LinkedIn also stored the passwords using just SHA-1 algorithm
Due to these flaws attackers were able to unscramble the password hashes using standard rainbow tables
Ashley Madison Leak
What happened?User passwords were cryptographically protected using bcrypt, an algorithm so slow and computationally demanding it would literally take centuries to crack all of them.
However, apart of storing user passwords with bcrypt, security researches identified two instances where passwords were stored using MD5 for “automatic login”
$loginkey = md5(strtolower($username).'::'.strtolower($password));
md5(lc($username).”::”.lc($pass).”:”.lc($email).”:73@^bhhs&#@&^@8@*$”).
The right way to do itNever store passwords in plaintext (obviously)
Never store hashed passwords without using a unique salt (ideally a random one sufficiently long)
Use a cryptographically secure & slow hash functions (PBKDF2, bcrypt, scrypt). Apply a sufficient number of iterations.
Slow hashing is desirable as it makes processing of a single password more expensive for the attacker
PBKDF2: good enough but can be optimized with GPU
bcrypt: less GPU friendly then PBKDF2 but vulnerable to brute-forcing using Field-Programmable Gate Arrays (FPGAs) with relatively small SRAM
scrypt: requires not only exponential time but also exponential memory
however doesn’t have a cryptanalytic pedigree required to gain most cryptographers' trust
Do not allow users to use weak passwords. Even with the strongest crypto, weak passwords are easy to crack.
As soon as you receive a password, remove it from memory.
High level approach examplestring password_hash ( string $password , integer $algo [, array $options ] )
password_hash() creates a new password hash using a strong one-way hashing algorithm.
Uses bcrypt or PASSWORD_DEFAULT (a constatnt which may change in time)
Options Cost and Salt are secure by default
http://php.net/manual/en/function.password-hash.php
Failure #2 Improper use of hash functionsIt’s 2015 and developers still use MD5
SHA- 1 has been considered insecure for long time, yet it still used widely.
Comparing hashes also causes problems – timing attacks
Using certain hash functions for what they are not might also cause issues e.g. length extension attacks
Comparing Hashesif ($hash1 === $hash2) { //mac verification is OK echo "hashes are equal" } else { //something bad happened }
For a given message, attempt to send it with a hash of all one single character. Do this once for each ASCII char e.g. 'aaaa...', 'bbbb...' etc.
Measure the time each request takes to complete. Since string equality takes a tiny bit longer to complete when the first char matches, the message that takes the longest to return will have the correct first character.
Length extension attacks key = “secret attacker doesn’t know”
value =“send $100”
Signature = sha256(key + “:” + value)
Length extension attack allows us to append data and be able to compute a valid signature without actually knowing the key.
value =“send $1000”
Signature = “valid signature”
https://blog.skullsecurity.org/2012/everything-you-need-to-know-about-hash-length-extension-attacks
The right way to do itDon’t ever use insecure algo such as MD5 or SHA-1. Use SHA-2 instead (SHA-256, Sha-384, SHA -512)
For signed MAC use HMAC-SHA2
If you compare hashes, use only cryptographically secure functions e.g. :
.NET : RSACryptoServiceProvider.VerifyHash https://msdn.microsoft.com/en-us/library/system.security.cryptography.rsacryptoserviceprovider.verifyhash(v=vs.110).aspx
Failure #3 Using encryption without authentication
Encryption doesn’t automatically protect data against modification
Chosen cipher text attacks are a real threat
Bit flipping attacks
Padding oracle
Bit flipping
Padding oracleFrequently present in web applications
Occurs when a web service reveals whether there was a padding or integrity error when decryption (can be also base on timing)
If you can feed in ciphertexts and somehow find out whether or not they decrypt to something with valid padding or not, then you can decrypt ANY given ciphertext.
Typical scenario : Using AES in CBC mode where have a ciphertext encrypted by a web service.
POODLE
How to do it right?Never underestimate the importance of message authenticity even in situation without an obvious attack vector.
There is rarely a reason for not doing authentication checks when decrypting data
Prefer authenticated modes of operation e.g. GCM, OCB (patented)
If forced using AES with CBC use HMAC to ensure message authenticity
Failure #4 Reusing nonces and IVsNonces should be used only once – that’s what the word stands for
The purpose of their use is to avoid replay attacks
IVs should usually be non-predictable
Length of IVs is also important (WEP)
Attacks on WEPWEP uses 24b IV
For RC4 security is important that the same key is never used twice
For every 24b IV there is a 50% chance that the same IV will repeat after approximately 5000 packets
The right way to do itNever reuse nonces
Do not use static IVs
Always use random, unpredictable IVs with sufficient length
Pitfall #5 Dealing randomnessA good source of true randomness is an integral part of most cryptosystems. Common mistakes include:
Using no or limited randomness when required
Using sources of “randomness” which are actually not random at all
Leaking internal state of PRNG
Random Number Bug in Debian MD_Update(&m,buf,j);
[ .. ]
MD_Update(&m,buf,j); /* purify complains */
Removing this code had the side effect of crippling the seeding process for the OpenSSL PRNG.
Instead of mixing in random data for the initial seed, the only "random" value that was used was the current process ID.
Modulo bias int x;
int modulus = 4;
x= rand() % modulus; // random string 0-3
Assuming that rand() returns values (0,1,2,3,4,5)
Probability of 0: 33.33%
Probability of 1: 33.33%
Probability of 2: 16.66%
Probability of 3: 16.66%
Modulo bias #2 You will get modulo bias if max(rand()) + 1 is not evenly divisible by your modulus.
int excess = (RAND_MAX + 1) % modulus;
int limit = RAND_MAX - excess;
while (x = rand() > limit) {};
return x % modulus;
The right way to do it.NET : https://msdn.microsoft.com/en-us/library/system.security.cryptography.randomnumbergenerator
C++ (Windows): CryptGenRandom function in MS-CAPI https://msdn.microsoft.com/en-us/library/windows/desktop/aa379942(v=vs.85).aspx
Linux: read from /dev/urandom
recommended reading: http://www.2uo.de/myths-about-urandom/
Failure #6 SSL/TLS CertificatesUsing TLS in non-browser software is a challenging task
Using standard SSL/TLS libraries is not enough
Certificate validation is sometimes completely disabled
Certificate revocation check is oftentimes missing
Full chain check is sometimes not complete
Subject is sometimes not verified at all!
The right way to do itImplementing proper certificate validation is not a trivial task. It requires a deep understanding of the protocol.
Don’t assume that using SSL/TLS libraries ensures proper certificate validation.
Don’t disable SSL for testing purposes, it may backfire.
Implement unit testing (especially negative one) to verify that certificate validation is implemented properly.
To mitigate the risks of rogue certificates consider certificate pinning.
www.badssl.com
Failure #7 Insecure key provisioningA very common mistake is to spend lots of time designing an impenetrable crypto scheme and then not protecting keys properly
Keys are often generated in an insecure environment, stored on developers machines, hardcoded in the source code etc.
People also don’t think through the scenarios when keys get leaked
The right way to do itAvoid using passwords as keys as they don’t have enough entropy and use truly random keys instead.
If you have to use passwords as keys apply key derivation functions e.g. PBKDF2
Don’t reuse the same key on many devices.
Don’t reuse the same key for multiple purposes (encryption, authentication)
Generate keys in a secure environment
Store keys securely
Account for periodic key rotation and disaster recovery
Make a plan for creation, rotation and removal of encryption keys!
TakeawaysNever implement your own crypto primitives
Never leverage cryptography if you don’t understand it’s fundamentals
Learn the fundamentals!
Avoid using low level crypto libraries (OpenSSL, Bouncy Castle, Java JCE, PyCrypto) unless you are a pro
Beware of compositional weaknesses. Consult person with advanced knowledge of cryptography.
Use high level crypto libraries (KeyCzar, NaCL, libsodium )
KeyczarKeyczar’s goal is to make it easier for application developers to safely use cryptography.
Keyczar defaults to safe algorithms, key lengths, and modes, and prevents developers from inadvertently exposing key material. It uses a simple, extensible key versioning system that allows developers to easily rotate and retire keys.
Java, Python, and C++ implementations
Key rotation and versioning
https://github.com/google/keyczar
http://jay.tuley.name/keyczar-dotnet/
Example: encryption Crypter crypter = new Crypter("/path/to/your/keys");
String ciphertext = crypter.encrypt("Secret message");
Recommended resourcesMatasano crypto challenges: http://cryptopals.com/ Standford Cryptography https://www.coursera.org/course/crypto Standford Cryptography II https://www.coursera.org/course/crypto2 Schneier on Security https://www.schneier.com