Threats / 05 Network communications interception

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.

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.