Android Application Security Testing Part-19: Insufficient Transport Layer Protection

Insufficient Transport Layer Protection

Insufficient transport layer protection allows communication to be exposed to untrusted third-parties, providing an attack vector to compromise a web application and/or steal sensitive information. Websites typically use Secure Sockets Layer / Transport Layer Security (SSL/TLS) to provide encryption at the transport layer. However, unless the website is configured to use SSL/TLS and configured to use SSL/TLS properly, the website may be vulnerable to traffic interception and modification.

·         Who are threat agents in this case?

o    Users local to your network (compromised or monitored Wi-Fi)

o    Carrier or network devices (routers, cell towers, proxy’s, etc)

o    Malware pre-existing on your phone

o    Hackers trying to attack you web services

·         To find out if an application has sufficient transport layer protection, look at the application traffic through a proxy. Answer the following questions:

o    Are all connections, not just ones to servers you own, properly encrypted?

o    Are the SSL certificates in date?

o    Are the SSL certificates self-signed?

o    Does the SSL use high enough cipher strengths?

o    Will your application accept user accepted certificates as authorities?

·         Common Scenarios

There are a few common scenarios that penetration testers frequently discover when inspecting a mobile app's transport layer security:  

·          

o    Lack of certificate inspection: The mobile app and an endpoint successfully connect and perform a TLS handshake to establish a secure channel. However, the mobile app fails to inspect the certificate offered by the server and the mobile app unconditionally accepts any certificate offered to it by the server. This destroys any mutual authentication capability between the mobile app and the endpoint. The mobile app is susceptible to man-in-the-middle attacks through a TLS proxy.

§  Android Application fails to verify the identity of the certificate presented to it. Most of the application ignore the warnings and accept any self-signed certificate presented. Some Application instead pass the traffic through an HTTP connection.

o    Weak Handshake Negotiation: Application and server perform an SSL/TLS handshake but use an insecure cipher suite which is vulnerable to MITM attacks. So any attacker can easily decrypt that connection.

o    Privacy Information Leakage:  The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. They may use SSL/TLS during authentication but rest all connection through non-secure channel. That doesn’t add to security of       application because rest sensitive data like session cookie or user data can be intercepted by an malicious user.

·         When communicating over public networks it is essential to send and receive information securely. The protocol widely used to secure these communications is SSL/TLS. (SSL/TLS refers to Secure Sockets Layer or to its successor, TLS, or Transport Layer Security.) SSL/TLS uses digital certificates to provide authentication and encryption. To trust that a certificate is genuine and valid, it is digitally signed by a root certificate belonging to a trusted certificate authority (CA). Operating systems and browsers maintain lists of trusted CA root certificates so that they can easily verify certificates that the CAs have issued and signed.

·         Protocols that rely on certificate chain verification, such as SSL/TLS, are vulnerable to a number of dangerous attacks, including man-in-the-middle attacks, which occur when an unauthorized party is able to view and modify all traffic passing between the mobile device and the backend

·         Android Application transmitted the data to a self-signed certificate which lead to interception of data, this is worst case scenario where an android application accepts all certificates presented to it.

·         Use certificate pinning to help prevent man-in-the-middle attacks.

How Do I Prevent Insufficient Transport Layer Protection?

General Best Practices:

·         Assume that the network layer is not secure and is susceptible to eavesdropping.

·         Apply SSL/TLS to transport channels that the mobile app will use to transmit sensitive information, session tokens, or other sensitive data to a backend API or web service.

·         Account for outside entities like third-party analytics companies, social networks, etc. by using their SSL versions when an application runs a routine via the browser/webkit. Avoid mixed SSL sessions as they may expose the user’s session ID.

·         Use strong, industry standard cipher suites with appropriate key lengths.

·         Use certificates signed by a trusted CA provider.

·         Never allow self-signed certificates, and consider certificate pinning for security conscious applications.

·         Always require SSL chain verification.

·         Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.

·         Alert users through the UI if the mobile app detects an invalid certificate.

·         Do not send sensitive data over alternate channels (e.g., SMS, MMS, or notifications).

·         If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel. In the event that future vulnerabilities are discovered in the SSL implementation, the encrypted data will provide a secondary defense against confidentiality violation.

Android Specific Best Practices

·         Remove all code after the development cycle that may allow the application to accept all certificates such as org.apache.http.conn.ssl.AllowAllHostnameVerifier or SSLSocketFactory.ALLOW_ALL_HOSTNAME_VERIFIER. These are equivalent to trusting all certificates.

·         If using a class which extends SSLSocketFactory, make sure checkServerTrusted method is properly implemented so that server certificate is correctly checked.

Useful links

http://projects.webappsec.org/w/page/13246945/Insufficient%20Transport%20Layer%20Protection