Link to this headingRandomness

Link to this headingApplications 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.

Link to this headingApplication 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/

Link to this headingRNG only seeded during application startup

Whitebox:
Look for PRNG seeding only occurring during application startup.

Link to this headingDual 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

Link to this headingReview 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.

Link to this headingApplication’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/

Link to this headingHashing

Link to this headingUser 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.

Link to this headingAn 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”

Link to this headingPassword 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.

Link to this headingUser 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.

Link to this headingApplication 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)

Link to this headingSymmetric Cryptography

Link to this headingBlock Ciphers

Link to this headingOnly 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

2. 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:

1. 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
   1. How sensitive is the data being encrypted?
   2. Is this cipher appropriate?
   3. What is the length of the plain-text message?
   4. What is the length of the keystream?
   5. How is the keystream being generated?
   6. Is the keystream implementing sufficient randomness?
   7. How is the keystream being distributed?
   8. Is the keystream being reused within a message? (keystream length < message length)
   9. Is the keystream being reused across messages?
   10. Is message integrity important? Is this being implemented? What method?
   11. Is a master key and IV being utilized? How are IVs being generated?

Common Stream Cipher attacks:

1. Key reuse (within messages or across messages): Reuse of encryption keys, to include IVs, will compromise the confidentiality of the message
2. Substitution attacks: stream cipher by themselves do not validate message integrity and are therefore vulnerable to substitution attacks

Additional Crypto Fuzzing Techniques:

1. 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.
2. When supplying input to an encryption function, attempt to input separators such as ;,|,:,_,-,and & to look for error messages indicating incorrect number of parameters.

Link to this headingApplication 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.

Link to this headingBlock ciphers should operate in [CBC](/Crypto/Symmetric Encryption/Block Ciphers/CBC) mode

1. Fuzz the input. By inputting the same character over and over, ECB will contain repetitions. CBC will not
2. Encrypt the same value twice. Is the result the same? If so, the IV is likely to be static.
3. Utilize the ECB tests. If it’s not ECB it’s likely to be CBC.
4. 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”

Link to this headingInitialization Vectors should be the size of an entire block and be cryptographically secure

TODO:

Link to this headingInitialization Vectors should never be reused to encrypt another message

TODO:

Link to this headingEncrypted 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.

Link to this headingHMAC validation must be perform prior to decrypting cipher text

TODO:

Link to this headingStream Ciphers

Link to this headingCryptographically Secure Random Number Generator Used,

Keep a lookout for applications which use non SecureRandom output for creating auth tokens, crypto, passwords, etc)

Link to this headingInitialization Vectors used to create one time use keys for each message must be cryptographically secure and not be reused

TODO:

Link to this headingIf 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.

Link to this headingAsymmetric Cryptography

Link to this headingRSA 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.

Link to this headingKey Management

Link to this headingApplication encryption keys should be protected with Platform Data Protection APIs if available

Link to this headingKeys should be not be stored within deployed application code/configs or within code repositories

Link to this headingKeys should be securely generated from a RNG and not from a user defined value

Link to this headingFilesystem Access Control to the encryption keys should be restricted to the user running the application server

Link to this headingApplication should have a strategy to perform Key Rotation

Link to this headingSymmetric Keys should be a minimum of 128 bits

Link to this headingIf an encryption key is derived from user input, the key should be passed from a secure key derivation function

Link to this headingKey derivation function should contain an appropriate work factor to mitigate offline brute force attacks

Link to this headingDifferent Crypto keys should be generated between production and non-production environments

Link to this headingCertificate Validation

Link to this headingCertificates should not be signed with MD5

Link to this headingEnsure the certificate is properly validated prior to reading any fields in the certificate

Link to this headingEnsure that the hostname matches the CommonName or subjectAltName value in the certificate

Link to this headingEnsure the expiration data has not passed

Link to this headingClient side software should be digitally signed

Link to this headingSensitive websites should consider Extended Validation Certificates

Link to this headingSide Channel & Timing Attacks

Link to this headingString comparisons on sensitive tokens should not susceptible to timing attacks

Link to this headingHMAC Signatures must be validated prior to decryption or handling of protected data

Link to this headingApplication should not leak out error details or codes when handling the decryption or parsing of encrypted data

Link to this headingCompression ratios should not leak out information on the plaintext data

Link to this headingSSL Guidelines & Site Authenticity

Link to this headingPages 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.

Link to this headingSSL 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

Link to this headingAuthentication Tokens, Headers, and Credentials must only travel over SSL

Verify tokens are not set prior to redirection to HTTPS.

Link to this headingPages 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.

Link to this headingApplication should leverage HTTP Strict Transport Security

If the site does not set the “Strict-Transport-Security” header then it is not using it. I would consider logging this on bleededge companies that want to use some of the new security features available
“General SSL Testing Guidence:

• SSLyze will test for most of these conditions. SSLscan is another utility comparable to SSLyze.
• Use OpenSSL to manually verify and reduce false positives.
• More info is on Trac: https://trac.gdssecurity.net/wiki/Tutorials/TestingSSL”

Link to this headingSSLv2 must not be enabled

Black Box Testing:
Most tools will test for this. Verify with OpenSSL:
openssl s_client -connect example.com:443 -ssl2

Link to this headingSSLv3 must not be enabled

Poodle Vulnerability

Black Box Testing:
Most tools will test for this. Verify with OpenSSL:
openssl s_client -connect example.com:443 -ssl3”

Link to this headingTLS 1.0 should be enabled

Black Box Testing:
Most tools will test for this. Verify with OpenSSL:
openssl s_client -connect example.com:443 -tls1

Link to this headingTLS 1.1 should be enabled

Black Box Testing:
Most tools will test for this. Verify with OpenSSL:
openssl s_client -connect example.com:443 -tls1_1

Link to this headingTLS 1.2 should be enabled

Black Box Testing:
Most tools will test for this. Verify with OpenSSL:
openssl s_client -connect example.com:443 -tls1_2

Link to this headingProduction SSL enabled servers must require 128-bit cipher strength

Black Box Testing:
Most tools will display the keep length next to ciphers that are tested.
example: sslyze.py –regular google.com
…
Accepted Cipher Suite(s):
ECDHE-RSA-AES256-SHA 256 bits HTTP 200 OK
AES256-SHA 256 bits HTTP 200 OK
ECDHE-RSA-DES-CBC3-SHA 168 bits HTTP 200 OK

Link to this headingNo NULL cipher cipher suites (No confidentiality)

Verify with OpenSSL to prevent false positives.
Black Box Testing:
Tools will display NULL-SHA or NULL-MD5 in the accepted cipher list. However, some servers will technically accept the SSL connection, but then immediately respond with an http page which asks the user to upgrade their browser. This isn’t too common these days, but it happens. Verify this with the following OpenSSL command:
openssl s_client -connect example.com:443 -cipher NULL-SHA <<< “GET / HTTP/1.1”

If the connection allows you to type a GET / HTTP/1.1 and returns the standard page, it’s vuln. If it displays an error and then terminates the connection, it is a false positive and should not be reported.

Link to this headingNo ADH ciphers (No authentication)

Black Box Testing:
Tools will display ciphersuites starting with ADH, EXP-ADH, or SSL_DH_anon.

Link to this headingDepricate RC4 (ASAP)

Black Box Testing:
Tools will display ciphersuites including RC4 in their name.

Link to this headingDepricate 3DES (ASAP)

Black Box Testing:
Tools will display ciphersuites including DES-CBC3 or 3DES in their name. (if it’s just DES, then it’s a more serious issue due to the 56 bit key length, and should fit under require 128-bit cipher strength instead)

Meet in the middle attack: ““3DES provides only 108 bits of security (or 112, depending on the source), which is below the recommended minimum of 128 bits

Link to this headingDHE or ECDHE ciphersuites should be supported

Black Box Testing:
Tools will display ciphersuites starting with DHE, TLS_DHE, ECDHE, TLS_ECDHE.

Forward Secrecy: https://www.eff.org/deeplinks/2013/08/pushing-perfect-forward-secrecy-important-web-privacy-protection”

Link to this headingNo 1024 bit keys. 2048 recommended.

Larger keys than 2048 bits may be a waste of resources.
Use a tool, or view the cert in a browser.

Black Box Testing:
Open the cern in the browser. OpenSSL and most SSL testing tools will also report the key length.

Link to this headingCert should be valid for all hostnames which use it.

Avoid wildcards if possible.
Check Subject AND Subject Alternative Name

Black Box Testing:
Open the cert in the browser. Be sure to check the Subject Alternative Names, too. OpenSSL and most SSL testing tools will also report host names

Link to this headingCert should not use MD5 for sigining

Black Box Testing:
Open the cert in the browser and check the signature algorithm. OpenSSL and most SSL testing tools will also report the signature algorithm.

Link to this headingAvoid using production private keys/certs on test, staging, and other non-production systems.

May not be an issue if test and prod are behind a prod SSL gateway.

Black Box Testing:
Open the cert in the browser and be sure to check the Subject Alternative Names, too. OpenSSL and most SSL testing tools will also report host names. If the cert contains both production and test environment domains, this may indicate that the prod private is hosted on test or development environments. However, some environments put both test and production behind a single SSL gateway. Be sure to verify the setup in the client’s environment.

Also, if there is a domain name mismatch due to a test server using a prod certificate, this issue exists.

Link to this headingCompression should be disabled

Black Box Testing:
Most SSL testing tools will show if compression is enabled. OpenSSL will also show compression settings when the connection is started.

Link to this headingClient-Initiated Renegotiation should be disabled

Black Box Testing:

Most SSL testing tools will show if Client-Initiated Renegotiation is enabled. To test with OpenSSL:

If the connection is terminated with a handshake failure, the server does not allow Client-Initiated Renegotiation.

Link to this headingInsecure Renegotiation

Black Box Testing:
Most SSL testing tools will show if secure renegotiation is enabled. OpenSSL will also show secure renegotiation settings when the connection is started. Ex: “Secure Renegotiation IS supported”