In this blog we are going to discuss Broken Cryptography in Android Applications. When application developers wish to use encryption in their apps, they have to be aware of broken cryptography attacks. This blog discusses how vulnerabilities caused by faulty encryption might be introduced into Android apps. We’ll also look at some of the ways an attacker might take advantage of these flaws.
We will be discussing these vulnerabilities.
Hash functions convert arbitrary input into fixed-length values in a predictable manner. It’s simple to compute the hash from the input, but determining the actual input from the hash is extremely difficult (if not impossible). Hash functions are used to verify integrity, but they do not ensure authenticity. For demonstration purposes, we are using a vulnerable application PIVAA application and for viewing the source code we are going to use Jadx tool.
The MD5 hashing method is included in the PIVAA application, which allows users to hash any string they enter.
Vulnerability: MD5 hashing shouldn’t be used for important data like passwords
This feature isn’t necessarily a vulnerability because of how it’s done in the PIVAA app, but it’s crucial to remember that weak hashing algorithms like MD5 and SHA-1 are vulnerable. The following problems plague MD5:
We can see how the hashing functionality is implemented by statically examining the application’s code.
The following is a breakdown of the hash function:
Let’s build an MD5 hash of a string input using the PIVAA application to highlight the MD5 hashing algorithm weakness:
We can carry out a dictionary attack on the hash a try to convert back to plan text by using crackstation.
The MD5 hash took 3 seconds to crack – “Test me.” There are various approaches, but this one demonstrates how simple it is to crack MD5 hashes that have not been salted.
Mitigation
Sensitive data exposure, key leakage, failed authentication, insecure sessions, and spoofing attacks can all come from weak encryption algorithm usage. MD5 and RC4 are two encryption or hash methods that are known to be weak and should not be used.
The appropriate usage of parameters, in addition to selecting safe encryption or hash techniques, is critical to the security level. The ECB (Electronic Code Book) mode, for example, is not recommended for use in asymmetric encryption.
The PIVAA application uses AES encryption in combination using ECB mode.
It’s vital to understand how AES-ECB works in order to understand why it’s unsafe. The following diagram shows how AES-ECB encryption works.
The following is an explanation of the diagram:
We can see the code used to conduct AES encryption using ECB mode by statically analyzing the PIVAA application’s source code.
Breaking down this method from top to bottom, it takes a single string parameter and then declares a “try catch” statement to handle any exceptions. The Java class “SecretKeySpec” creates a secret key from an array of bytes. Because a hardcoded key is supplied, the implementation of this class is likewise susceptible.
The “getInstance()” function of the “Cipher” Java class returns a cypher object that implements the provided transformation (i.e., “AES/ECB/PKCS5Padding”). Before the cypher object can be used, it must first be created by calling the “init()” function, which provides the mode (1) and secret key (skeySpec). After that, the plaintext is encrypted using the “doFinal()” function.
Finally, the method encodes the encrypted string in base64 and returns it. The “System.out.println()” function also prints this base64 encoded text to the standard output.
Using a hypothetical situation, we can show this problem with the PIVAA application. We obtained an encrypted ciphertext created by the application in this case, as seen below.
DMy2IlPGmV+cI1mpKZf+zg==
We can try a plaintext attack on this ciphertext. This effectively implies that we can estimate what the original content was by entering random characters and comparing the encrypted output to the ciphertext we were able to obtain.
Vulnerable Application
The last key was the same result as the ciphertext which we are looking for. The encrypted plaintext was the phrase “Test me” as we now know.
ECB mode should not be used for cryptographic operations. Instead, for cryptographic operations, use the code below:
Cipher cipher = Cipher.getInstance("AES/CFB/PKCS5Padding");
Even if ECB mode is not specified, the following code will default to it:
Cipher cipher = Cipher.getInstance("AES");
In cryptography, an initialization vector (IV) or starting variable (SV) is an input to a cryptographic primitive being used to provide the initial state. The IV is typically required to be random or pseudorandom, but sometimes an IV only needs to be unpredictable or unique. Randomization is crucial for some encryption schemes to achieve semantic security, a property whereby repeated usage of the scheme under the same key does not allow an attacker to infer relationships between (potentially similar) segments of the encrypted message. For block ciphers, the use of an IV is described by the modes of operation.
The PIVAA application uses AES encryption in CBC mode, but with a known initialization vector (IV). An initialization vector (IV) is required as an initial input to the cypher in the CBC, OFB, CFB, and PCBC modes.
Vulnerability: A plain text attack can be used to exploit predictable IVs.
To properly comprehend why a predictable IV renders an encrypted object vulnerable to crypto-analysis tools, it is necessary to have a broad understanding of how AES-CBC works (e.g., a Chosen-Plaintext Attack). The AES-CBC encryption is demonstrated in the image below.
The following is an explanation of the diagram:
We can examine the PIVAA application’s source code statically and see the function that performs AES encryption in Cipher Block Chaining (CBC) mode.
Breaking down this method (encryptAES_CBC_PKCS5Padding) from top to bottom, it takes a single string parameter and then declares a “try catch” statement to handle any exceptions. Each time the function is used, the “IvParameterSpec” Java class is used to define an Initialization Vector. We can see that a hardcoded value has been utilized in the Initialization Vector. +
The Java class “SecretKeySpec” creates a secret key from an array of bytes. Because a hardcoded key is supplied, the implementation of this class is likewise vulnerable.
The “getInstance()” function of the “Cipher” Java class returns a cypher object that implements the provided transformation (i.e., “AES/CBC/PKCS5Padding”). The “init()” method must be implemented before the cypher object can be used, and it specifies the mode (1), secret key (skeySpec), and Initialization Vector (IV). After that, the plaintext is encrypted using the “doFinal()” function.
Finally, the method encodes the encrypted string in base64 and returns it. The “System.out.println()” function also prints this base64 encoded text to the standard output.
We can now illustrate how to attack this vulnerability in the application since we have a better grasp of what the application’s code is doing. Let’s pretend we were able to obtain a string of ciphertext created by the PIVAA application, such as the following:
DMy2IlPGmV+cI1mpKZf+zg==
We don’t know what the encrypted content is, but we can try a selected plaintext attack based on what we know about how the application utilized a weak initialization vector. This effectively implies that we can estimate what the original content was by entering random characters and comparing the encrypted output to the ciphertext I was able to obtain.
Vulnerable Application
As can be seen above, we produced the same result as the ciphertext. The encrypted plaintext was the word “password,” as we now know.
In this blog, we’ve seen how attackers can use Android applications and take advantage of weak cryptography implementations. This isn’t a detailed list of potential encryption flaws in Android apps, but it does highlight some of the identifiable concerns. For more information refer OWASP_MSTG-v1.4.0 Cryptography . For learning more about Android pentesting, check out our Android Pentesting Methodology series. Don’t forget to stay connected with Redfox Security for more insights into Cybersecurity.
Redfox Security is a diverse network of expert security consultants with a global mindset and a collaborative culture. If you are looking to improve your organization’s security posture, contact us today to discuss your security testing needs. Our team of security professionals can help you identify vulnerabilities and weaknesses in your systems and provide recommendations to remediate them.
“Join us on our journey of growth and development by signing up for our comprehensive courses.“
Redfox Cyber Security Inc.
8 The Green, Ste. A, Dover,
Delaware 19901,
United States.
info@redfoxsec.com
©️2024 Redfox Cyber Security Inc. All rights reserved.
