Android allows developers to configure network security settings to have their apps transmit unencrypted data over the insecure HTTP rather than the default secure HTTPS that implements encryption through TLS protocol. What a developer needs is to have a line like this: android:networkSecurityConfig=”@xml/network_security_config“ in the app’s AndroidManifest.xml file that specifies the location of the network security configuration file.

Investigation of the Use of Both HTTP and HTTPS in Android

In the network security configuration file, the developer needs to explicitly declare the IP addresses that the app can access over the insecure HTTP. This flexibility, to be able to transmit data over HTTP, is crucial at the development stage when the developer may need to use the localhost to host databases and server-side code when developing an app. Since localhost (127.0.0.1) does not implement TLS, a developer will just need to configure the network security file in the app to use the localhost. Below is the code for network_security_config.xml file:

<?xml version=”1.0″ encoding=”utf-8″?> 
<network-security-config> 
<domain-config cleartextTrafficPermitted=”true”> 
<domain includeSubdomains=”true”>192.168.10.63</domain> 
</domain-config> 
</network-security-config> 

The downside of this is that a developer can deploy an app that transmits data over HTTP. There is no restriction provided by the Android Studio or Android OS to ensure developers do not compile the release APK and ship their apps to consumers with HTTP enabled. 

This loophole leaves Android apps exposed to eavesdropping and man-in-the-middle attacks. These attacks threaten the user’s data confidentiality, integrity, and authenticity. 

Confidentiality: A Demonstration of an Eavesdropping Attack 

When data is transmitted over HTTP, it flows through the network as plaintext. Therefore, anyone who has access to the network channel can intercept the data packets and view the data. If an attacker hooks Wireshark network traffic analyzer onto the network channel, they will be able to intercept data packets flowing between the Android app and the server. See below: 

Figure 1. Analysis of HTTP packets intercepted using Wireshark 

The above figure shows the analysis of a Wireshark file filtered to only display the TCP packets transmitted over the HTTP. The packets are in plain text, therefore are readable. The TrojanHorse app is transmitting data from the infected device (IP: 192.168.10.62) to a remote server (IP: 192.168.10.63). The first TCP-HTTP transmitted packet contains the details about the victim device (shown in the figure above). The rest of the packets contain user data. 

To seal this loophole, Android should have a mechanism to prevent apps from being compiled for release with network configurations that allow an app to transmit data over HTTP. When generating an APK in Android Studio, there are two options to choose from; debug or release. The release option generates an APK for distribution to be installed on users’ phones. Android Studio should be able to enforce HTTPS at this stage by requiring developers to revert network configuration settings to default. 

Android Network Security 

The convenience that Android ecosystem offers developers to be able to configure network security settings to allow their apps to transmit data over insecure HTTP is a security flaw. This is because Android does not provide a mechanism to ensure that developers do not compile apps for release to consumers with HTTP enabled. This leaves a chance for security compromise where a developer could potentially ship an app to consumers without proper network security configuration. This can expose users to eavesdropping and man-in-the-middle attacks as demonstrated below.  

Figure 2. Analysis of plain text HTTP packets intercepted using Wireshark  

Therefore, this security flaw violates confidentiality and threatens the integrity and authenticity of app data. 

According to the study carried out by Possemato and Fratantonio in 2019 and again in 2020 [1], Android developers do distribute apps to users with weak network configurations even when Google requires all developers to implement HTTPS in their apps for secure data transmission. In 2019, the pair found out that out of the 125,419 applications they crawled, only 16,332 implemented HTTPS. When they repeated the study again in 2020 for the same applications after Google started enforcing HTTPS by setting it as the default protocol for Android apps, they found that majority of the developers had not adopted the secure HTTPS. In this study we go further to practically demonstrate the risk developers put their app users in when they implement weak security configurations allowing their apps to transmit data over the insecure HTTP. 

References

[1] A. Possemato and Y. Fratantonio. “Towards {HTTPS} everywhere on android: We are not there yet,” In 29th USENIX Security Symposium (USENIX Security 20), pp. 343-360. 2020.