Crypto ASD
Randomness¶
Applications should not rely on the output of pseudo random number generators when used in a security context,¶
Whitebox:
Keep a lookout for applications which use non-SecureRandom output for creating auth tokens, crypto, passwords, etc). Most standard "random" libraries use Mersenne Twister, which can be broken when only a few hundred outputs are obtained. "Broken" in this context means future outputs of the PRNG can be predicted.
Blackbox:
See https://github.com/altf4/untwister.
Application not susceptible to Seed Racing Attacks¶
Blackbox:
Try sending two Password Reset requests at the same time for two different test accounts. If the tokens you get back match, the application is likely vulnerable. Apply this concept to other sensitive transactions involving randomness.
Whitebox:
Look for PRNG seeding based on the current time, or other values that may not always change in between requests. https://neolab.wordpress.com/2008/04/29/seed-racing/
RNG only seeded during application startup¶
Whitebox:
Look for PRNG seeding only occurring during application startup.
Dual EC DRBG random number generator is used by application¶
Whitebox:
Dual EC's security is controversial due to a suspected backdoor. Search the codebase for variants "Dual_EC_DRBG" and flag any findings. https://www.lawfareblog.com/nsa-crypto-back-door
Review GUID implementations if randomness of the token is required¶
Whitebox:
Many UUID/GUID libraries do not use cryptographically secure PRNG. Research or view the source code of the UUID/GUID library used to determine if this is the case.
Application's use of /dev/urandom may lead to usage of insecure value if entropy pool is not validated¶
Whitebox:
Search codebase for use of /dev/urandom and evidence of validating entropy (e.g. by reading /proc/sys/kernel/random/entropy_avail). https://blog.cloudflare.com/ensuring-randomness-with-linuxs-random-number-generator/
Hashing¶
User Passwords must be stored using adaptive cryptographic hashing algorithm or strong key derivation function (bcrypt, scrypt, PBKDF2)¶
Whitebox and Blackbox:
Determine if the application displays any user passwords back to the user in the browser, in hidden HTML, or possibly in an e-mail during a password reset. If so, it is unlikely to be hashed.
Whitebox:
If the application hashes passwords using a MD (e.g. MD5) or SHA (e.g. SHA-1) family function, then it is a bug (even if they are performing iterations). They should be using much slower algorithms like bcrypt, scrypt or PBKDF2.
An appropriate amount of work-factor should be configured when using the adaptive cryptographic hashing algorithm¶
Whitebox:
Parameters should be set to reflect available server resources as well as an acceptable amount of latency (e.g. 100ms for interactive login).
Special attention to throttling, account lockout, etc. should be taken to prevent app DoS (these features should exist anyway).
For scrypt, recommended minimum params as of 2017 are N=32768, r=8 and p=1.
The client can run openssl speed on the server to test the performance of cryptographic algorithms.
Blackbox: This can be challenging to test for, but if authentication takes a very short period of time (e.g. 70ms), this can be a red flag that the algorithm isn't tuned appropriately.
- https://blog.filippo.io/the-scrypt-parameters/
- https://stackoverflow.com/a/30308723
- https://security.stackexchange.com/a/3993"
Password Salts must be unique for each user.¶
Whitebox:
Look for evidence of a cryptographically secure PRNG being used to generate a unique seed for each user. If none exists, this is a finding.
Blackbox:
Difficult to determine unless you get access to password hashes and the same two passwords generate the same hash. If so, it's not using a salt.
User Password Salts should be at least a 64 bit value generated using a securely random function¶
Blackbox:
1. Difficult to determine unless you get access to password hashes and the same two passwords generate the same hash. If so, it's not using a salt.
2. Use BurpSuite's Sequencer to check the entropy of cryptographic tokens.
3. Additionally, try to perform seed racing attacks against functions which generate cryptographic tokens. You can do this by scripting up a tool which performs simultaneous (multi-threaded) requests to functions which generate the cryptographic tokens. This should be performed more than once, considering latency issues.
Whitebox:
Look for account creation, login, password reset routines, etc. Ensure that the salt is at least 64 bits and generated using a cryptographically secure PRNG.
Application should utilize HMACs instead of MACs when authenticating user input¶
Blackbox and Whitebox:
Attempt to determine if the application is using a keyed MAC of some sort. If the MAC is made up where the secret key is first and then the message is concatenated to it, then it is probably vulnerable to a length extension attack.
They should use an HMAC which is not vulnerable to Length extension or Collisions (even if using MD5 or Sha1).
Common Attacks:
- Length Extension Attacks
- Key recovery (harder)
- Spoofing attacks (if they opt for a simple hash instead of a true MAC)
Symmetric Cryptography¶
Block Ciphers¶
Only cryptographically secure encryption algorithms should be used to protect sensitive data,¶
Blackbox:
1. If you control the plaintext then you can fuzz it to determine if it is a block cipher or a stream cipher, which encryption algorithm is being used and what encryption mode is being used. See ECB Mode Slides for fuzz techniques, such as chosen plaintext attacks where you send in a large stream of ""a"" to see if and when the block cipher starts to repeat itself. If it does, it is definitely using ECB.
Common Attacks:
1. Block Swapping
2. Chosen Plaintext Attack
- See slides for Proof of Concepts
- If you do not control the plaintext then you can send the ciphertext to Burp Sequencer to analyze its entropy. It may be able to possibliy spot repetitions in the ciphertext. Do block sizes grow in 8 bytes? 16 bytes? this may be a sign of ECB mode being used.
Blackbox and Whitebox:
- Is encryption utilizing XOR encryption methods? Check the length of the encrypted data, if it does not increase by a defined block size, it may be a stream cipher. Stream ciphers generate cipher-text the same length as the plain-text message
- How sensitive is the data being encrypted?
- Is this cipher appropriate?
- What is the length of the plain-text message?
- What is the length of the keystream?
- How is the keystream being generated?
- Is the keystream implementing sufficient randomness?
- How is the keystream being distributed?
- Is the keystream being reused within a message? (keystream length < message length)
- Is the keystream being reused across messages?
- Is message integrity important? Is this being implemented? What method?
- Is a master key and IV being utilized? How are IVs being generated?
Common Stream Cipher attacks:
- Key reuse (within messages or across messages): Reuse of encryption keys, to include IVs, will compromise the confidentiality of the message
- Substitution attacks: stream cipher by themselves do not validate message integrity and are therefore vulnerable to substitution attacks
Additional Crypto Fuzzing Techniques:
- When the application leverages or compares an encrypted string or hash, look for variations which may indicate a collision between arbitrary text and valid text. Variations may include timing, error messages, and application behavior/output.
- When supplying input to an encryption function, attempt to input separators such as ;,|,:,_,-,and & to look for error messages indicating incorrect number of parameters.
Application should not utilize ECB mode encryption for data encrypted that is larger that a single block¶
Blackbox and Whitebox:
See above. Repeated data in ciphertext, block swapping, chosen plaintext attacks.
Block ciphers should operate in CBC mode¶
- Fuzz the input. By inputting the same character over and over, ECB will contain repetitions. CBC will not
- Encrypt the same value twice. Is the result the same? If so, the IV is likely to be static.
- Utilize the ECB tests. If it's not ECB it's likely to be CBC.
- If its CBC and you can run a dynamic test against it, try to run PadBuster against it to see if it's vulnerable to Padding Oracle.
Common Attacks:
1. Bit-Flipping Attacks
2. Padding Oracle: http://blog.gdssecurity.com/labs/2010/9/14/automated-padding-oracle-attacks-with-padbuster.html
- See slides for Proof of Concepts"
Initialization Vectors should be the size of an entire block and be cryptographically secure¶
TODO:
Initialization Vectors should never be reused to encrypt another message¶
TODO:
Encrypted data where data integrity is critical must have an HMAC¶
- If you identify an encrypted value, such as an encrypted parameter, cookie, header, etc,
attempt to fuzz it to determine how the application is handling incorrect crypto strings. - Perform the basic CBC, ECB, Stream Cipher attacks against it.
- If the application allows you to manipulate the encrypted value without failing and it doesn't look like a MAC is being passed in along with the encrypted value then it is probably vulnerable to this and should be logged, especially if you can successfully exploit one of the attacks above.
HMAC validation must be perform prior to decrypting cipher text¶
TODO:
Stream Ciphers¶
Cryptographically Secure Random Number Generator Used,¶
Keep a lookout for applications which use non SecureRandom output for creating auth tokens, crypto, passwords, etc)
Initialization Vectors used to create one time use keys for each message must be cryptographically secure and not be reused¶
TODO:
If message integrity is required, application should create and validate HMACs¶
Blackbox:
If you identify an encrypted value, such as an encrypted parameter, cookie, header, etc, attempt to fuzz it to determine how the application is handling incorrect crypto strings. Essentially attempt to perform the basic CBC, ECB, Stream Cipher attacks against it. If the application allows you to manipulate the encypted value without failing and it doesn't look like a MAC is being passed in along with the encrypted value then it is probably vulnerable to this and should be logged, especially if you can successfully exploit one of the attacks above.
Whitebox:
Look for use of HMAC when message integrity is required. If absent, this is an issue.
Asymmetric Cryptography¶
RSA Private Keys should be a minimum of 2048 bits¶
Blackbox and Whitebox:
Look for evidence of RSA key lengths and log if less than 2048 bits in length.
Key Management¶
Application encryption keys should be protected with Platform Data Protection APIs if available¶
Keys should be not be stored within deployed application code/configs or within code repositories¶
Keys should be securely generated from a RNG and not from a user defined value¶
Filesystem Access Control to the encryption keys should be restricted to the user running the application server¶
Application should have a strategy to perform Key Rotation¶
Symmetric Keys should be a minimum of 128 bits¶
If an encryption key is derived from user input, the key should be passed from a secure key derivation function¶
Key derivation function should contain an appropriate work factor to mitigate offline brute force attacks¶
Different Crypto keys should be generated between production and non-production environments¶
Certificate Validation¶
Certificates should not be signed with MD5¶
Ensure the certificate is properly validated prior to reading any fields in the certificate¶
Ensure that the hostname matches the CommonName or subjectAltName value in the certificate¶
Ensure the expiration data has not passed¶
Client side software should be digitally signed¶
Sensitive websites should consider Extended Validation Certificates¶
Side Channel & Timing Attacks¶
String comparisons on sensitive tokens should not susceptible to timing attacks¶
HMAC Signatures must be validated prior to decryption or handling of protected data¶
Application should not leak out error details or codes when handling the decryption or parsing of encrypted data¶
Compression ratios should not leak out information on the plaintext data¶
SSL Guidelines & Site Authenticity¶
Pages accepting or rendering sensitive data should be protected using SSL,¶
Identity any pages within the application's domain which are not returning data over HTTPS.
SSL protected pages should not be accessible over non-SSL connections,¶
Replay valid application requests over HTTP. Ensure that the application forces the user to redirect to the HTTPS
Authentication Tokens, Headers, and Credentials must only travel over SSL¶
Verify tokens are not set prior to redirection to HTTPS.
Pages should not allow framing by 3rd party websites¶
Create text.html, copy&paste the following into your new html file, replace TARGET with URL of the site and open in your browser.