Manual testing for cryptographic failures involves identifying weaknesses in encryption, key management, and cryptographic implementations. Below are detailed techniques, steps, and examples for uncovering cryptographic vulnerabilities.
Verify whether sensitive data is transmitted or stored without encryption.
- Use tools like Wireshark or Burp Suite to intercept traffic.
- Check for data transmitted over insecure channels, such as HTTP instead of HTTPS.
- Inspect storage mechanisms (e.g., files, databases) for plaintext sensitive data, such as passwords or session tokens.
Intercept a login request and inspect the payload. If the username and password are visible in plaintext, encryption is not applied.
Expected Behavior:
- All sensitive data must be encrypted in transit (HTTPS) and at rest (AES or similar).
Determine if outdated or weak cryptographic algorithms are in use.
- Analyze captured traffic or certificates using tools like SSL Labs or TestSSL.sh.
- Look for the use of deprecated algorithms such as MD5, SHA-1, or RC4.
- Review source code or configurations for insecure functions like
MD5() or sha1().
Run the following command to test SSL/TLS configurations:
openssl s_client -connect example.com:443
Expected Behavior:
Cryptographic keys should never be hardcoded and must be securely stored (e.g., in a key management system).
Identify cryptographic keys hardcoded in source code or configurations.
- Perform a manual code review and search for common key terms like
key, secret, or password.
- Use static analysis tools like SonarQube to locate hardcoded keys.
- Inspect client-side code (e.g., JavaScript or mobile apps) for embedded keys.
Find a hardcoded encryption key in source code:
const encryptionKey = "hardcoded_key_123";
Expected Behavior:
- Cryptographic keys should never be hardcoded and must be securely stored (e.g., in a key management system).
Ensure encryption keys are exchanged securely.
- Capture traffic during key exchange using Wireshark or Burp Suite.
- Look for keys transmitted over plaintext or insecure channels.
- Attempt to intercept the key during the exchange using Man-in-the-Middle (MITM) techniques.
If a symmetric encryption key is transmitted in plaintext during an HTTP session, it can be intercepted.
Expected Behavior:
- Keys must be exchanged securely using protocols like TLS 1.2+.
¶ 5. Testing for Insufficient Randomness
Verify that cryptographic operations use strong randomness.
- Analyze cryptographic operations such as token generation or IV (Initialization Vector) usage.
- Check for reused or predictable patterns in randomness.
- Review the source of randomness, ensuring secure methods like SecureRandom (Java) or secrets (Python) are used.
If an AES encryption IV is reused or predictable, attackers may exploit this to decrypt data.
Expected Behavior:
- Randomness must be generated using secure random number generators and never reused.
Ensure data integrity and authenticity through proper digital signatures.
- Intercept signed requests or files and attempt to modify the payload.
- Check if the application validates the signature correctly against a trusted public key.
- Test whether unsigned or improperly signed data is accepted.
Modify a software update package and observe if the application installs it without validating the signature.
Expected Behavior:
- All critical data and updates should be signed using secure algorithms like RSA or ECDSA and verified before processing.
Ensure the application properly validates SSL/TLS certificates.
- Perform a Man-in-the-Middle (MITM) attack using tools like Burp Suite or mitmproxy.
- Replace the legitimate SSL certificate with a forged one.
- Test for improper hostname validation by connecting with mismatched certificates.
Connect to a web application using a self-signed certificate and observe if the connection proceeds without warnings.
Expected Behavior:
- Applications should reject invalid certificates and enforce proper hostname matching.
- Wireshark: Monitor network traffic for unencrypted data and weak protocols.
- Burp Suite: Intercept and modify requests to test cryptographic implementations.
- SSL Labs: Analyze server SSL/TLS configurations.
- SonarQube: Detect insecure cryptographic practices in source code.
- TestSSL.sh: Test SSL/TLS configurations for security flaws.
- Ensure sensitive data is encrypted in transit (HTTPS) and at rest.
- Verify that only secure cryptographic algorithms are used.
- Check for securely generated and stored keys (no hardcoding).
¶ Randomness:
- Ensure secure random number generators are used.
- Validate certificates against trusted Certificate Authorities (CAs).
- Verify the integrity and authenticity of signed data or software.