Threats / 05 Network communications interception

Unless they have compromised the backend services themselves, there are three main points at which attackers can take control of data being transmitted over the network:

Only the first of these access points can be fully controlled by developers. But it’s crucial to be aware of the threats to the others. And there are mitigations and prevention mechanisms that we can take from inside the app against all of them.

There are two main protocols used for managing communication of data via the network: HTTP (Hypertext Transfer Protocol) and HTTPS (HTTP over Transport Layer Security (TLS)). HTTPS is more secure, since it’s designed to guarantee both the authenticity of the server and confidentiality through encryption of the data transmitted to it.

Ordinarily, with every connection governed by the HTTPS protocol, the client - in this case the mobile app - requests a certificate from the server. The operating system then checks that certificate against the certificate authority (CA) to confirm that the server is authentic. If the certificate is validated, the app is allowed to use the server’s public key to encrypt data before transmission, which the server can then decrypt on arrival.

This combination of authentication and encryption is important, because network communications are inherently exposed. Data communicated over the network can be intercepted by anyone who controls a node on that network.

In attacks such as these, therefore, adversaries take control of data as it’s being transmitted over the network. Network sniffing tools (such as Wireshark and tcpdump), for example, allow attackers to capture network traffic by intercepting data packets being sent from the device to a local router. And proxy servers can also be used to stand as a Man-in-the-Middle (MitM), receiving all data between the mobile device and the servers it connects to.

If the data is encrypted with the legitimate server’s public key, such interception is less valuable to the attacker. This is why attackers target either unencrypted data or look for ways to manipulate the client (the mobile device or mobile app) into communicating with a proxy server. Ordinarily, this proxy server would not be able to provide a certificate that can be validated by the operating system’s pre-installed certificate authority. That means the system would block the connection. The attacker must therefore manipulate the system (in most cases by manipulating the user) to accept the proxy server’s certificate. There are several ways that attackers can achieve this, but more than not it will involve some form of social engineering.

An attacker might, for example, develop and distribute a malicious VPN app and advertise it as highly secure and effective. When your legitimate app’s end users download this malicious VPN app and install it on their devices, the rogue VPN app will ask them to install a custom certificate authority. This custom certificate authority validates the fraudulent server’s certificate, meaning the app will encrypt data using the fraudulent server’s public key. And the attacker can receive and decrypt as they please.

As we explore in the Virtualized Environments section of this guide, app wrappers are applications that are designed to execute other apps within their own sandbox. They have full control over the wrapped app’s processes, including how it manages network communications.

This means that if an end user runs your legitimate mobile application inside a malicious app wrapper, the attacker can hook various high and low level network communication APIs used by your mobile app to perform network communications. And they can then forward every bit of information to their Command & Control (C&C) server.

Almost all mobile apps use third-party libraries, either open source or licensed. And it’s a challenge for developers to have full knowledge and understanding of the logic inside them.

This opens up an attack vector for attackers: developers may unknowingly incorporate malicious libraries into their apps, which they then distribute, unaware that they’re rotten on the inside. And at runtime, because the malicious library is part and parcel with your application, fundamentally it is allowed access to all other parts of it. The library can influence how it interacts with the operating system, with other applications, and with the network.

This type of malicious library would therefore allow attackers to take control of sensitive data immediately, as soon as it is processed within the application’s context itself, essentially by hooking any high & low level network communication API calls.

Intercepting network communications may also give an attacker insights into your server-side architecture and backend APIs. This could enable them to identify and exploit vulnerabilities, perform session replay attacks, and even flood your API or backend infrastructure with massive traffic to cause denial of service (DoS).

It’s worth bearing in mind the vast amount of sensitive data that may flow between an app and remote endpoints.

All of this might be a target for attackers, for any number of reasons.

Before distributing any new app or update, perform Software Composition Analysis to ensure that the app is free from vulnerable or malicious dependencies that attackers might use to intercept data in transit.

To protect against malicious app wrappers, your app can try to check if it’s actually installed or present on the device. It can also check for any signs of anomalies in system libraries or platform APIs used by your mobile application

The two priorities in mitigating and preventing network sniffing and man-in-the-middle attacks are (1) encrypting the data for transit; and (2) ensuring that the data can only be decrypted at the legitimate, intended endpoints.

It’s standard practice to use HTTPS to ensure encryption, and the shoe on the other foot is certificate validation checks: checking with every request to the backend that the server can provide a legitimate and expected certificate.

Both Android and iOS systems can perform such checks, validating server certificates according to whether they correspond to root certificates pre-installed on devices.

However, the system cannot truly be relied on to perform these checks. If an attacker or malware has escalated privileges, it remains possible to override the system checks, and/or to install fraudulent root certificates.

It’s therefore crucial to perform such checks from within the mobile app itself. The authentic certificates against which every request must be compared can either be pinned - fixed - at the point of building the app, as in the case of Public Key Pinning, or they can be validated by comparison with distributed public logs of authorized certificates, according to the Certificate Transparency framework. In either case, it’s important to use a protection mechanism that can block the connection and prevent the transmission of data if a valid certificate isn’t provided.