Insecure communication. This is the third article of the OWASP Mobile Top 10 Risks series and it is, more or less, how far I covered during research for my master’s degree theses in Cybersecurity. The third most relevant risk affecting mobile applications is, M3-Insecure Communication, and it mainly covers poor handshaking, incorrect SSL versions, weak negotiation, clear text communication, etc. [1]
Securing the communication between client and server has (and will) always be paramount in this model to provide clients with secure implementations that ensure the security of their private data. The methods used to protect the communication, sent to or received from the server, are mostly based on the use of a strong public key infrastructure implementation which, at the same time, uses certificates to ensure the integrity and confidentiality of data and communication.
Securing the communication is paramount. Using a strong PKI implementation greatly improves the security of the communication.
In general, certificates must be using a long enough private key (2048 bits at minimum), they must be valid (not expired), issued by a trusted certification authority and must be correctly configured at server level to work with secure protocols (TLS v1.2 is preferred) and cipher-suites (RSA/AES256/SHA2 algorithms should be favored).
Intercepting traffic
Intercepting the traffic for a mobile application is not straightforward, there are certain significant conditions that needs to be met in order to successfully execute this attack and compromise the communication between an Android application and the backend server it connects to. These conditions include:
- Ability to install the proxy’s CA certificate on the device.
- The application trusts the user installed certificate.
- Configuring the workstation as a router.
- Ability to change the device’s Wi-Fi configuration.
- Bypassing SSL pinning (if present).
Intercepting the traffic is not that easy, you need to meet a few conditions to successfully carry out this attack, known as man-in-the-middle.
Here you can find more information on how to intercept traffic for an android application, you should also take look at how to trust user installed certificates on Android devices for applications targeting API 24 and above, since API 23 and below trusts these kind of certificates by default.
Poor Handshaking
Similar to how the three way handshake establishes the rules of engagement during a TCP connection. Every TLS/SSL connection begins with a handshake; which sets the rules of communication for a secure connection, meaning that it determines what cipher suite will be used to encrypt the communication, verifies the service and establishes that a secure connection is in place before beginning the actual transfer of data, as stated here on ssl.com
It is particularly important to pay attention to the TLS/SSL configuration made at server level and make sure that it meets a few requirements for establishing a secure connection. There are basic things that you can, and should, check on every SSL/TLS connection handling sensitive data, to ensure the communication is secure:
- Certificate is preferably not for a wildcard domain (*.domain.com)
- Key length is at least 2048 bits in length.
- Allows only secure protocols (TLS v1.2 is the current recommendation).
- Accepts only secure ciphersuites (favor AES256 and SHA2 algorithms).
- Secure renegotiation is available.
Most relevant to handshaking are number 3 and 4 which ensures that the communication is carried out using secure means (protocols and ciphersuites). Beside this, as we will see below, there might be a problem in how negotiation/renegotiation is handled.
Weak Re-negotiation
Renegotiation is basically making a new handshake while in the middle of a TLS/SSL connection and the problem, as described here, is related to how renegotiations are not cryptographically tied to the TLS/SSL connection they are being performed over and how an attacker can leverage this to form a TLS connection with the target server, inject content of his choice, and then splice in a new TLS connection from a client. The server treats this as a renegotiation and therefore “believes” that data transmitted by the attacker is coming the client.
There are four types of renegotiation:
- Client-initiated secure renegotiation.
- Client-initiated insecure renegotiation.
- Server-initiated secure renegotiation.
- Server-initiated insecure renegotiation.
And there are two main problems with renegotiation: a possible man-in-the-middle attack described here and a DoS attack caused by sending lots of handshakings to exhaust the server’s resources.
You can do a couple of checks here using openssl, as shown below, but there are tools like sslyze, sslscan, sslabs, etc, that can fetch you a lot of interesting information about the health of an SSL/TLS connection (we’ll see them afterwards).
openssl s_client -connect host:port
Secure Result: Secure Renegotiation IS supportedopenssl s_client -connect host:port
HEAD / HTTP/1.1
R
[CRLF]
Secure Result: Renegotiation fails
sslyze and sslscan
Both great tools, as mentioned before, they can be used to evaluate the health of an SSL/TLS connection, a good amount of data, to validate some of the checks mentioned above, can be obtained by using these tools. For instance, if you want to do a “regular” scan on a specific host, you do something like this:
sslyze --regular domain.com
There is a ton of possible switches you can play with on sslyze, go ahead and check the help with the –help flag. An usual output of this tool shows something like this:
Do note the results under Session Renegotiation, the information about the certificate used for PKI, OCSP configuration and Downgrade attacks. However, a vital part of the output you need to check is the one referring to protocols and ciphers:
As mentioned above, the recommendation here for servers handling sensitive data, is to enable TLS v1.2 only and making sure that secure ciphersuites are used, always favoring RSA for asymmetric encryption , AES256 for symmetric encryption and SHA2 for hashing.
On the other hand, sslscan is similar in usage, but it’s always good to cross-check using two or three of these kind of tools, for sslscan you’d do something like this:
sslscan domain.com
Both examples shown above assumes that TLS/SSL communication is done through port 443, if you need to use a different port, use domain:port in both cases.
Conclusion
Securing the communication between client and server is paramount for applications handling sensitive data under this model. There are a series of configurations and conditions that needs to be met in order to successfully ensure the confidentiality and integrity of the information flowing in the communication. Manual testing skills and tools like sslyze and sslscan are needed to provide an objective risk evaluation.
[1]https://www.owasp.org/index.php/Mobile_Top_10_2016-M3-Insecure_Communication
Recent Comments