By Bruce Kang, Associate Security Operations Engineer
Introduction
In the 2021 iteration of the OWASP Top 10, Cryptographic Failures moved up one ranking to take the No. 2 spot. Its name also changed from “Sensitive Data Exposure” to “Cryptographic Failures” to more accurately describe the vulnerability. In this article, we will take a deep dive into this vulnerability and explain how and why it exists, and also how to prevent them from being exploited.
A Brief Explanation of Cryptography
To understand what falls under the broad category of Cryptographic Failures, it’s important to first understand what cryptography is exactly. To keep things simple, cryptography can be thought of as a way of secure communication so that sensitive information can only be viewed by authorized parties. The process for this usually involves having an original “plaintext” message, which is then put through some sort of encryption algorithm, which turns it into unreadable “ciphertext.” This ciphertext is then only able to be decrypted back to its original plaintext by the intended recipient(s), usually by using a cryptographic key that only the intended recipient(s) have access to.
Implementations of Cryptography
Cryptography is ubiquitous in today’s computing world. It is implemented in technologies like:
- Protocols: HTTPS, FTPS, SFTP, SSH, SMTPS, etc. to ensure that all communication between two endpoints are encrypted.
- Hashing (one way encryption): passwords, authentication, file integrity verification, etc.
- Website certificates to verify authenticity.
Explanation of Cryptographic Failures
Since cryptography is used so widely and has many different implementations, there are several ways for vulnerabilities to occur. This could be through implementation errors, using weak encryption methods, not encrypting data at all, and much more. Therefore, a Cryptographic Failure vulnerability is a broad vulnerability category that encompasses all types of attacks that are related to anything cryptography related. As one could imagine, a vulnerability of this type could lead to serious consequences, as cryptography is meant to secure sensitive information. Thus, if there is a failure at any point in this process, this information could be exposed to any number of malicious attackers.
Simple Example with Man in the Middle Attacks
For our first example of a Cryptographic Failure, imagine if a banking website did not use HTTPS. To give some context, HTTPS encrypts traffic being sent between the user and the website, as opposed to HTTP which sends everything “in the clear”. This is very important considering things like passwords, social security numbers, etc. could be communicated between the user and website. Using HTTPS means an attacker would not be able to view the information being exchanged if they were to intercept the traffic. Therefore, failure to use HTTPS would make users vulnerable to what would be called a “Man in the Middle” attack. As the name suggests, this type of attack happens when an attacker is able to intercept traffic between two nodes and view the information being exchanged, usually possible by being on the same network. This attack would look something like this:
Here the attacker is able to view all the information the user is sending to the website, possibly including things like the credentials for their bank account. This is all because the website failed to implement the necessary cryptographic controls for preventing this attack.
Real World Example #1: Weak Ciphers
Usually, a Man in the Middle attack can prove to be pointless if the data is encrypted, as the collected data will be impossible to read without the decryption key. However, there are ways to bypass this. A real example of this attack vector was found by one of our Synack researchers (sensitive information redacted). They found that the application they were testing was using weak, outdated block ciphers for encrypting communication being sent back and forth between the users and the application. It is important to remember that block ciphers encrypt data in “blocks” of data. The larger the blocks, the more layers of complexity are added to the encryption, in turn making the data harder to decrypt without the key.
However, the application was found to be using only 64 bit block ciphers, an outdated method of block cipher encryption due to it being vulnerable to the “Sweet32” vulnerability (CVE-2016-2183, CVE-2016-6329). Without getting into the mathematics behind this vulnerability, it can essentially be understood as being used to crack any encryption that uses 64 bit block ciphers. Because of this, it has been advised to use encryption algorithms that use block sizes of at least 128 bits, such as AES.
What this means is that attackers could potentially conduct a Man in the Middle attack (as described earlier) to capture encrypted traffic between the user and the application, then crack the encryption easily due to the weak cipher.
This vulnerability was found by the researcher utilizing a tool called testssl.sh (https://github.com/drwetter/testssl.sh). This tool was run against the target website like so:
After identifying that the website uses weak ciphers, testssl.sh can be used again to find that this causes it to be exploitable via Sweet32.
With this information, an attacker now knows that a Man in the Middle attack could be used to capture sensitive data, then easily be cracked using the Sweet32 vulnerability.
This vulnerability showcases how important it is to ensure that the strongest, most up to date encryption algorithms be used whenever possible, especially considering that encryption algorithms are constantly evolving.
Real World Example #2: Unencrypted Admin Credentials
In our second real world example showcasing Cryptographic Failures, one of our own Synack researchers managed to find hard-coded admin credentials for an application through source code review (sensitive information changed or redacted). The researcher found that the target was running “Manage Engine Service Desk Analytics Plus Application.” Upon finding this, the researcher was able to request for the source code of this application from the vendor.
The researcher then found that the source code contained hard-coded credentials
public static final String DEFAULT_USER = “admin@website.com”;
public static final String DEFAULT_USER_PWD = “admin123”;
public static final String PARTNER_ADMIN = “partner+admin@website.com”;
public static final String PARTNER_ADMIN_PWD = “Password123”;
These credentials were then able to be used on the target that was running this application, thereby granting administrative access to the hosting server. This is a very clear and simple example of a Cryptographic Failure, as these credentials should have been encrypted or stored in a key vault, instead of being hard-coded into the source code.
Real World Example #3: Unencrypted file backups in Microsoft Azure
This third example of Cryptographic Failures also shows an example of an organization not encrypting all of their data. A Synack researcher managed to find a client’s file backups that were not completely encrypted. Specifically, the vulnerable application backed up Office 365 mailboxes in a Microsoft Azure storage account, and claimed that these files were in fact encrypted with the key being stored in Azure Key Vault. However, the researcher discovered that the data was only encrypted server-side. This meant that the encryption would only protect the backups if an attacker were able to gain physical access to the hard disk on the host server, which would be incredibly difficult to do considering Microsoft Azure is a major cloud provider.
Instead, the researcher found that any user who had access to the Microsoft Azure storage account would be able to view every mailbox that was backed up to it, without even needing the key. This vulnerability was found by first creating the backup via the vulnerable website:
After the backup is created, a blob storage folder is created in the Azure storage account called “o365-backups”, which contains all backed up mailboxes and attachments. One could then view the location of any user’s attachments folder by logging into the storage account and accessing this URL:
https://storage_account.blob.core.windows.net/o365-backups/<mailbox_user>/attachments/
From here all the researcher had to do was generate a download URL for any of the attachments found. After downloading the file, a Hex Editor can then be used to change the file from its original custom file format to a PNG, making it viewable. This would work for any attachments for other users on the application as well, potentially exposing sensitive information stored in user’s mailboxes.
What was probably intended here was for the storage account to be used to manage the mailbox backups without actually being able to read what was in them. Thus cryptography was not properly implemented and allowed the Azure storage account to view more information than was necessary, violating the principle of least privilege and potentially exposing sensitive information to unwanted eyes.
Real World Example #4: GitHub Exposes JWT Encryption Key
This next example is very similar to the second one that was shown, as it involves the hardcoding of sensitive cryptographic information. This information was found through source code review on a client’s GitHub repository. One of our Synack researchers reviewed the publicly available code and found that it exposed a JWT private signing key.
JWT stands for “JSON Web Token,” which is usually used for authentication. These tokens contain various data in JSON format about a user, and also must be signed by a private signing key in order to be used for authenticating into a specific application. If an attacker knows the fields needed for a valid JWT, and has the private signing key, it is possible for them to create their own valid JWT to impersonate other users. In turn, they would have full access to all that user’s data.
The researcher was first able to find this private key in the client’s GitHub repository
- Private static string privateKey = <KEY>
Using this private key, they then could generate a public key using openssl. Then, by using information found from the GitHub repository, the researcher was able to find the other fields used in the JWT. The resulting JWT was this. Note: the username of the user being impersonated must be known beforehand, likely through some type of user enumeration.
{
“sub”: “1234567890”,
“name”: “USER2”,
“iat”: 1516239022
}
The header was also found to be using HS256
{
“alg”: “HS256”,
“typ”: “JWT
}
Then, a JWT generator website like https://jwt.io/#debugger-io could be used to combine all this information to create a valid JWT token that could be used. The payload, header, private key, and public key were all used to create the encoded JWT, as shown below.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IlVTRVIxIiwiaWF0IjoxNTE2MjM5MDIyfQ.MlOB8X3VEZgAuD_Q7odNy_TEXbv5gSeXb3vHd538BKE
This was then used to authenticate the application as “USER2” by changing the attacker’s cookie. The researcher then had access to all of USER2’s data.
Thus, it is important to remember that hardcoding sensitive information into viewable source code is almost always bad practice.
Real World Example #5: Crackable Password Hash Retrieval
Cryptographic Failure vulnerabilities can also arise when the original plaintext itself is not following best practices. This mostly applies to the encryption of passwords, as having weak passwords can often lead to them being compromised, even if proper encryption is used to hash them.
Offline password cracking usually involves having a set of compromised passwords that are still hashed, then using some kind of cracking tool to decrypt them. These include tools like hashcat, John the Ripper, THC Hydra, and more. The basis of all these tools is that they will go through each hashed password and attempt to guess the plaintext using a wordlist of common passwords, or use a rainbow table of pre-calculated hashes for common passwords.
An example of this involves another one of our Synack researchers, who cracked an administrator’s password for a server management application running on a client’s network. The researcher was first able to find that the vulnerable host was running HP Integrated Lights-Out (iLO), which uses the IPMI v2 authentication protocol. The problem is that IPMI v2 has a design flaw that could be used to dump the password hash of the requested user, before even authenticating. The only requirement is that a valid username be known. The following Metasploit module can be used to dump these hashes.
auxiliary/scanner/ipmi/ipmi_dumphashes
After the password hashes are retrieved, they can then be cracked offline. Normally, strong passwords that are salted are extremely hard to crack. This is because 1) a unique, complex password will generate an equally unique hash that is not part of any existing rainbow tables, and the password itself will not be in any common brute force wordlists. 2) Salting the password adds more complexity to the hash, as it will add a unique, random string of characters to each password before it is hashed, which is then only known by the application.
However, the researcher found that this application was not following either of these practices for their administrator passwords, and thus was able to crack them very easily. All the researcher had to do was run hashcat on a text file containing the dumped hashes, along with another text file containing common administrator usernames (admin, administrator, root, etc.).
hashcat –username -a 3 -m 7300 hashes.txt
These credentials could then be used to gain administrative access to iLO, in turn allowing the attacker to have a shell environment on the host. This vulnerability has even been reported as being used in ransomware attacks: https://www.bleepingcomputer.com/news/security/ransomware-hits-hpe-ilo-remote-management-interfaces.
This is why it is of the utmost importance to ensure that strong password policies are enforced to ensure that they cannot easily be cracked. Best practices include having policies around password length, complexity, or just using a password management solution.
Final Thoughts
Ensuring that cryptography is properly implemented is critical. Understanding why cryptography is important and how it works is paramount to using it correctly. To find out more about preventing these vulnerabilities, The OWASP guide can be found here.
It is clear why the OWASP Top 10 has put Cryptographic Failures so high up on its list, as the prevalence and consequences of these vulnerabilities are enormous. Learn more about how Synack can help prevent these and other vulnerabilities in your systems here.
The post Preventing Cryptographic Failures: The No. 2 Vulnerability in the OWASP Top 10 appeared first on Synack.
Login
