Classification

Overview

The verify() method defined in a class that implements the HostnameVerifier interface always returns true. When establishing a secure connection the application does not check the authenticity of the domain. This can lead to a loss of data confidentiality.

Within the establishing of a protected connection (handshake) server sends its public key and certificate, which are a cryptographic proof that the public key belongs to the owner of the server, to the client. The authenticity of certificates is provided by Certification Authority.

The correspondence between the certificate and the public key transferred to the client within the handshake does not guarantee the security of the connection. The client must make sure that the public key and the certificate come from the domain to which the connection is requested. Such check is not provided at the level of SSL / TLS protocol . In its absence at the application level, the attacker can violate the connection confidentiality by redirecting the user traffic through the attacker’s server and presenting a certificate that is valid for the attacker’s domain.

To check whether the requested domain matches the certificate received in response Android applications have the HostnameVerifier interface. The developer can use one of the existing implementations of this interface (StrictHostnameVerifier, X509HostnameVerifier) or create his/her own. It is assumed that the verify() method of the class that implements HostnameVerifier returns true if the connection to this host is allowed within the current connection and return false otherwise. The verify() method always returning true means that the application trusts all owners of all valid certificates, regardless of the domain for which they were obtained.

A possible attack scenario:

1. The attacker enters the user’s WLAN and redirects user’s traffic through the attacker’s server (for example, via a DNS cache poisoning attack).
2. The user initiates a connection to https://safeserver.example.com.via an SSL / TLS protocol.
3. Instead of the https://safeserver.example.com.public key an attacker sends the application his/her own public key and a valid certificate issued by the certification authority for the https://hackedserver.example.com.domain.
4. The app makes sure that the resulting certificate is valid (for https://hackedserver.example.com., ignoring the fact that the certificate has been issued not for the resulting domain for which the connection was originally requested.

Insecure Communication vulnerabilities take the third place in the “OWASP Mobile Top 10 2016” mobile application vulnerabilities ranking.

References

1. Security with HTTPS and SSL - developer.android.com
2. OWASP Mobile Top 10 2014: Insufficient Transport Layer Protection
3. OWASP Mobile Top 10 2016-M3-Insecure Communication
4. CWE-297: Improper Validation of Certificate with Host Mismatch
5. Fixing Hostname Verification - Will Sargent / tersesystems.com
6. CWE-295