M5: Insecure Communication (2024)

Unencrypted network traffic, weak TLS configurations, and missing certificate validation. Attackers intercept data via man-in-the-middle attacks on mobile networks.

Risk Assessment

Am I Vulnerable?

• Sensitive Data in Transit: The prominent characteristics include packaging up some kind of sensitive data and transmitting it into or out of the device. Some examples of sensitive data include encryption keys, passwords, private user information, account details, session tokens, documents, metadata, and binaries.
• Data Integrity Risks: If the data can be changed while in transit, without the change being detectable (e.g., via a man-in-the-middle attack), that is a good example of this risk.
• Data Confidentiality Risks: If confidential data can be exposed, learned, or derived by observing the communications as it happens (eavesdropping) or by recording the conversation as it happens and attacking it later (offline attack), that's also an insecure communication problem.
• TLS Configuration Problems: Failing to properly setup and validate a TLS connection (e.g., certificate checking, weak ciphers, other TLS configuration problems) are all here in insecure communication.

How Do I Prevent It?

• Assume Insecure Network: Assume that the network layer is not secure and is susceptible to eavesdropping.
• Apply SSL/TLS: Apply SSL/TLS to transport channels that the mobile app will use to transmit data to a backend API or web service.
• Third-Party SSL: 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.
• Strong Cipher Suites: Use strong, industry standard cipher suites with appropriate key lengths.
• Trusted CA Certificates: Use certificates signed by a trusted CA provider.
• Reject Bad Certificates: Never allow bad certificates (self-signed, expired, untrusted root, revoked, wrong host). Consider certificate pinning.
• SSL Chain Verification: Always require SSL chain verification.
• Endpoint Verification: Only establish a secure connection after verifying the identity of the endpoint server using trusted certificates in the key chain.
• Invalid Certificate Alerts: Alert users through the UI if the mobile app detects an invalid certificate.
• No Sensitive Data on Alternate Channels: Do not send sensitive data over alternate channels (e.g., SMS, MMS, or notifications).
• Secondary Encryption Layer: 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.

Example Attack Scenarios

• Lack of Certificate Inspection: The mobile app and endpoint successfully establish a TLS connection. However, the mobile app fails to inspect the certificate offered by the server and unconditionally accepts any certificate offered to it. 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.
• Weak Handshake Negotiation: The mobile app and an endpoint successfully negotiate a TLS handshake. However, the mobile app and server successfully negotiate with the server to use a weak cipher suite that results in weak encryption that can be easily deciphered by the adversary. This compromises the confidentiality of the channel between the mobile app and the endpoint.
• Privacy Information Leakage: The mobile app transmits personally identifiable information to an endpoint via non-secure channels instead of over SSL/TLS. This compromises the confidentiality of any privacy-related data between the mobile app and the endpoint.
• Credential Information Leakage: The mobile app transmits user credentials to an endpoint via non-secure channels instead of over SSL/TLS. This allows an adversary to intercept user credentials in cleartext.
• Two-Factor Authentication Bypass: The mobile app receives session identifiers via non-secure channels instead of over SSL/TLS. This allows an adversary to intercept session information, which can then be used to bypass two-factor authentication protections.