In first part of this article, I described how do we analyze protocols during mobile applications testing.

During this analysis, I noticed that the Diffie–Hellman protocol is used to exchange encryption keys. The protocol implementation was audited, and I discovered that it is prone to two attacks: Man-in-the-Middle and brute-force. Each of these attacks compromise the security of the protocol, allowing attackers to view and modify the data sent between the mobile applications and the servers.
The attacker must have access to the application's network traffic (e.g., to the router through which the phone connects to the Internet). Introduction The application uses the Diffie–Hellman protocol to exchange encryption keys between the server and the mobile application. At the beginning of the connection, plaintext RPC messages are exchanged for this purpose. An example of an RPC message sent from the server to the application is shown below:
The RPC message sent from the application to the server: For simplicity, only the process of exchanging an encryption key to encrypt data in the application-to-server direction will be described. The exchange of the encryption key for encrypting data in the server-to-application direction is implemented in a similar way.
Diffie–Hellman protocol The protocol is implemented in the following way:
1) The server generates a prime number p (yellow) and a base g (green).
2) The server generates a secret value a.
3) The server calculates A (blue) = pow(g, a) mod p.
4) The server sends the values p, g and A to the mobile application:
5) The mobile application generates a secret value b.
6) The mobile application calculates encryption key = pow(A, b) mod p.
7) The mobile application calculates B (pink) = pow(g, b) mod p.
8) The mobile application sends the value B to the server:
9) The server calculates encryption key = pow(B, a) mod p.
10) At this point, the server and the application have exchanged the encryption key, which is used to encrypt rest of the communication in the application-to-server direction.
11) The exchange an encryption key for the server-to-application direction is performed in a similar way. Man-in-the-Middle attack The Diffie-Hellman protocol does not provide authentication, making it prone to Man-in-the-Middle attacks. An attacker can act as a network traffic forwarder between the server and the application. During the key exchange phase, the attacker exchanges separate keys for both connections: one between the server and the attacker, and another between the attacker and the application. After that, the attacker can decrypt the data using the first key, display and/or modify it, re-encrypt it using the second key, and then forward it.
It is worth noting that there is also a simpler variant of this attack that allows the attacker to force the server and the application to use an encryption key chosen by the attacker. During the key exchange phase, the attacker changes the g and A values to zero:
In this scenario, the application calculates encryption key as pow(0, b) mod p. Regardless of the secret value b, the encryption keys will always be zero. Then, the application calculates B value as pow(0, b) mod p, which will also always be zero regardless of the secret value b. The B value is then sent to the server:
The server calculates the encryption key = pow(0, a) mod p. Regardless of the secret value a, the encryption key will always be zero. As a result, the attacker can force the server and the application to use an encryption key consisting entirely of zeros.

I was able to perform this attack during the tests. An example usage of the exploit, displaying decrypted RPC messages for both directions – application to server (in green) and server to application (in blue):
Brute-force attack During the analysis of the Diffie–Hellman protocol implementation, it was noticed that it is prone to a brute-force attack. The mobile application generates a secret value b (in red) that is 4 bytes long (it should be at least 16 bytes long). This secret value is used to calculate B = pow(g, b) mod p. Since the attacker knows B, g and p, it is possible to iterate through all possible values of the b (only pow(2, 32) = 4 294 967 296 possible values) and check if any of them produce the expected B value. If so, the secret value b is found. The attacker can then use it to calculate the encryption key = pow(A, b) mod p.
Update version 1.2: It is important to add that a secure source of random values (such as /dev/urandom) should be used to generate the entire key, not just a seed value to initialize the PRNG, as is currently done:
It is also important to note that if the server generates a weak secret value, the protocol also becomes vulnerable to brute-force attacks. Summary It is important to remember to not implement a custom, proprietary encryption protocol, as it is a difficult task prone to mistakes that can compromise the security of the solution. Instead, it is advised to use widely adopted, proven secure solutions, such as WebSocket Secure (WSS), which can be used to transport the current RPC messages.


#CyberSecurity #PenetrationTesting #InfoSec #DataProtection #VulnerabilityManagement