M3: Insufficient Transport Layer Protection

Overview

This JSON response provides information on the M3: Insufficient Transport Layer Protection vulnerability. It explains the threat agents, attack vectors, security weakness, technical impacts, and business impacts. It also includes steps to prevent this vulnerability and example attack scenarios.

Description

M3: Insufficient Transport Layer Protection is a vulnerability that occurs when a mobile application fails to adequately protect network traffic during data transmission. This can lead to the interception of sensitive data by threat agents, such as those on a compromised Wi-Fi network or malware on the mobile device. The lack of transport layer protection exposes users to the risk of data exposure, account theft, and potential phishing or MITM attacks. To prevent this vulnerability, it is recommended to apply SSL/TLS to transport channels, use strong cipher suites, and verify the authenticity of SSL certificates. Additionally, sensitivity data should not be sent over alternate channels and a secondary layer of encryption can be applied.

How to Prevent ?

To prevent 'Insufficient Transport Layer Protection', the following general best practices can be followed: 1. Assume that the network layer is not secure and is susceptible to eavesdropping. 2. 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. 3. 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. 4. Use strong, industry-standard cipher suites with appropriate key lengths. 5. Use certificates signed by a trusted CA provider. 6. Never allow self-signed certificates and consider certificate pinning for security-conscious applications. 7. Always require SSL chain verification. 8. Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain. 9. Alert users through the UI if the mobile app detects an invalid certificate. 10. Do not send sensitive data over alternate channels (e.g., SMS, MMS, or notifications). 11. If possible, apply a separate layer of encryption to any sensitive data before it is given to the SSL channel.

Example Attack Scenarios:

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

• Weak handshake negotiation:  The mobile app and an endpoint successfully connect and negotiate a weak cipher suite as part of the connection handshake. This results in weak encryption that can be easily decrypted by an adversary, jeopardizing the confidentiality of the channel.

• Privacy information leakage:  The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL. This exposes the confidentiality of any privacy-related data exchanged between the mobile app and the endpoint.