Add a Vulnerability for Cryptographic failures

[preetkaran20]

Is your feature request related to a problem? Please describe.
As OWASP Top 10 gave a lot of emphasis on Cryptographic failures so we should have such vulnerability as part of VulnerableApp

Describe the solution you'd like
Look at other VulnerableApplications and see if they have any vulnerability for cryptographic failures and if we found something then implement something similar to the the project as well.
If we don't found then we can look at the below reference link and there is a lot of great information and vulnerabilities so we can include them
Reference link: https://owasp.org/Top10/A02_2021-Cryptographic_Failures/

** Acceptance criteria **
If we can even start discussion and thought process towards this vulnerability and how we can implement it would be a great thing. and If we can add 3-4 levels then it is amazing.

[Zgzorx]

Hi !

With @AlexisOsmont we had a few ideas of some cryptographic failures levels:

1. Hardcoded login and password
2. Using plaintext password over HTTP
3. Using plaintext password over HTTPS
4. Using poorly hashed password (MD5 / SH1)

What are your thoughts about this ?

Regards

[preetkaran20]

Hi @Zgzorx @AlexisOsmont

Thanks for taking time for reviewing this issue.
My thoughts on the above levels:

1. These levels are difficult to make as a challenge, for example, if we start storing plaintext passwords, how does user who is trying to learn from the level will be able to break it?
2. with Poorly hashed password, yes that can be converted to a breakable levels like we start storing some passwords in the database with poor hash functions or encryption functions( say rc4 etc) and at each level we show a hashed password/encrypted password string in the screen and let the user try and guess it and if he guesses the correct password and submit on the screen, we will say "success" else "failure".

With the above hashed password logic, we do break one of the usecase of application which is Scanners but that can be tackled separately.

please let me know your thoughts and in case you want to jump over a call to discuss, let me know, I would be happy to connect. I work in PT timezone.

thanks,
Karan

[Zgzorx]

About the plaintext password, we could use a tool like Wireshark to observe the http request cointaining the password.

We could use the same technique to recover a poorly hashed password but HTTPS might complicate too much.

Sadly we are in CE timezone, making a call difficult.

Regards

[preetkaran20]

@Zgzorx no issues regarding the timezone issue.

Yes, Https is tough and therefore, I would suggest to create vulnerability levels as something like take a broken encryption algorithm, encrypt whatever string is provided by the user and show it in the screen, then ask user to retrieve the key for the encryption algorithm and validate if the provided string is actually right.

you can think of some more levels like this.

Let me know your thoughts.

[RengarajR404]

1. Weak Encryption Algorithm:
   Scenario: The application uses the outdated and insecure DES encryption algorithm to protect user data. Users can attempt to decrypt the encrypted data by exploiting the weak algorithm.
   Learning Objective: Understand the importance of using strong encryption algorithms like AES and the risks of weak encryption.

2. Insecure Key Storage:
   Scenario: The application stores encryption keys in plain text files on the server. Users can access and use these keys to decrypt sensitive information.
   Learning Objective: Highlight the importance of securely storing encryption keys, such as using hardware security modules (HSMs) or secure key management practices.

3. Inadequate Data Encryption:
   Scenario: The application only encrypts user passwords but leaves other sensitive data, like credit card numbers, unencrypted in the database. Users can exploit this to access and steal sensitive information.
   Learning Objective: Emphasize the need for comprehensive data encryption practices, including data classification and encryption of all sensitive data.

4. Misconfigured SSL/TLS:
   Scenario: The application uses SSL/TLS for secure communication, but it's vulnerable to common misconfigurations, such as weak cipher suites or expired certificates. Users can intercept and decrypt communication between the client and server.
   Learning Objective: Demonstrate the importance of properly configuring SSL/TLS to ensure secure data transmission.

5. Insecure Random Number Generation:
   Scenario: The application relies on insecure random number generation for cryptographic operations. Users can predict or manipulate the random numbers to compromise security.
   Learning Objective: Highlight the significance of using secure random number generation methods for cryptographic purposes.

6. Cross-Site Scripting (XSS) & Cryptographic Flaws:
   Scenario: An XSS vulnerability exists in the application, allowing attackers to inject malicious scripts. Users can exploit this vulnerability to steal cryptographic keys or manipulate encryption processes.
   Learning Objective: Showcase how multiple vulnerabilities can interact and compound the overall security risk.

7. Insecure Password Storage:
   Scenario: The application stores user passwords using weak hashing algorithms (e.g., MD5) without salting. Users can crack hashed passwords and gain unauthorized access to accounts.
   Learning Objective: Teach the importance of strong password hashing, salting, and proper password storage practices.

8. Cryptographic Padding Oracle:
   Scenario: The application is vulnerable to a cryptographic padding oracle attack. Users can exploit this vulnerability to decrypt encrypted messages.
   Learning Objective: Introduce users to the concept of padding oracle attacks and the need for secure cryptographic implementations.

Each of these scenarios presents a different cryptographic vulnerability that users can explore and learn from.