Estimated difficulty: šššš¤š¤
Welcome back to another MOBster post! It’s part three of our OWASP Mobile Top 10 series and in this post, we are covering M3: Insecure Communication! The previous MOBster post covered M2: Insecure Data Storage, and you can check that out here.
Like M2: Insecure Data Storage, this vulnerability is easy to exploit and has a severe impact if exploited. In theory, if insecure communication is a weakness of your application then an attacker may be able to listen or intercept your data transmitted over the wire. In this post, we are going to cover what insecure communication is and walk through how to set up your environment to intercept and inspect traffic coming from a mobile device.
What in the APK is it?
Insecure Communication in short covers any communication between your mobile and wherever the data is being sent. For example, this can encompass app-to-server communication, mobile to mobile communication and any other type of communication you can think of between mobile and endpoint.
There could be a serious impact on the organisation of the application if communications between the application
and the server is insecure.
The OWASP Mobile Top 10 explains the type of communications affected well:
This risk includes all communications technologies that a mobile device might use: TCP/IP, WiFi, Bluetooth/Bluetooth-LE, NFC, audio, infrared, GSM, 3G, SMS, etc. All the TLS communications issues go here. All the NFC, Bluetooth, and WiFi issues go here.
M3: Insecure Communication
The reputation of an organisation could be damaged if insecure communication is used. If used by an attacker data can be intercepted and potentially used to steal accounts or identities. Common issues of insecure communication are:
- Use of insecure ciphers.
- No secure channels implemented.
- No certificate inspection.
How it Works
We know if an application is vulnerable to insecure communication if the data can be intercepted or changed without detection. Eavesdropping using a tool such as Wireshark may highlight that an application is insecurely transmitting data if we can see data being transferred in cleartext.
There are multiple types of application for mobile devices – native, hybrid and web. Native applications are built for a specific platform, for example, an application developed specifically for the Android platform to be installed by a user would be considered a native app. These applications can make use of the device features, such as Bluetooth for communication. A hybrid application can use web services and native API’s to allow them to be installed like a native mobile application, yet still, perform and utilise features used by a web application. Finally, web applications are applications that are accessed via a mobile browser and do not need to be installed. They use web technologies, so can communicate over WiFi, however, can adapt to the mobile browser the application is being run on.
This “How it Works” section will attempt to explain Bluetooth and Wireless communication methods via a mobile application, at a high level. For the purpose of testing this out ourselves, we will focus on how insecure communication over Wireless (WiFi) to a router can be a problem.
Bluetooth
Similarly, Bluetooth and WiFi communicate through radio waves, however for Bluetooth both devices must have Bluetooth and two devices can communicate with each other. A Bluetooth connection is different to wireless or 4G / 5G connections as WiFi sends data to a router (where the WiFi comes from), rather than another device. An example of Bluetooth in use would be wireless earphones paired with your mobile phone, or smart scales sending data to an application on your device. The following video explains what Bluetooth is and how it works extremely well.
Wireless / 4G or 5G
An application may need to make use of the internet to send a message. This is extremely common in the connected world that we live in today, however, your device can make use of your home internet (e.g. your wireless router) or your mobile internet (e.g. a mobile tower). Mobile internet communications have been explained in one of my previous posts, so this will focus more on insecure communication to your home wireless router. Similar to testing web applications, for mobile applications we want to be checking for any data that is being sent in plaintext using HTTP or otherwise.
Case Study
Research was carried out by, Kaspersky, in 2018; where it was found that mobile applications were implementing an insecure third-party SDK (software development kit) that sent user data to servers unencrypted. HTTP was used other than HTTPS, which meant user data being sent over the wire to tailor ads could have been intercepted by an attacker sniffing the traffic.
“The scale of what we first thought was just specific cases of careless application design is overwhelming,” says Unuchek. “Millions of applications include third-party SDKs, exposing private data that can be easily intercepted and modified — leading to malware infections, blackmail and other highly effective attack vectors on your devices.”
Mobile Apps Transmit Unencrypted User Data.
Try it yourself!
What you will need:
- Install the Virtual Machine (VM) software Virtual Box to host your VM.
- Install Genymotion for an Android emulator.
- Add a virtual Android phone in Genymotion by clicking the plus button. This is so we have a device to carry out testing. Iām using the Google Nexus 5X.
- Burpsuite. Community edition would do fine here.
Note: The DIVA (Damn Insecure and Vulnerable Application) was tested, however no network traffic was picked up through Burp, so it appeared the application did not make use of WiFi. Instead example.com was navigated to, to generate traffic and analyse a web based mobile application.
1. Make sure your mobile device virtual machine and Burpsuite are running. Ensure Burpsuite is listening on all interfaces and that the mobile device is sending traffic through a proxy. We want to make sure that the certificate from Burp is generated and installed on the mobile device also. These steps have been detailed in this guide.
2. At this point your mobile device virtual machine should be successfully sending traffic through Burpsuite. You can drag and drop any applications you would like to analyse onto the mobile virtual machine to see what traffic is being sent back to the webserver. For the purpose of this walk through we will be going to example.com through the default mobile browser.
3. Navigate to example.com. Here we can see the request being made through the mobile device to the site.
GET / HTTP/1.1 Host: example.com Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Linux; Android 6.0; Genymotion Build/MRA58K; wv) AppleWebKit/537.36 (KHTML, like Gecko) Version/4.0 Chrome/74.0.3729.186 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,image/apng,/;q=0.8,application/signed-exchange;v=b3 Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 X-Requested-With: com.android.browser Connection: close
4. Analyse the requests and responses sent from the target application. If there was more to this website, since the communications are in HTTP, any attacker sniffing the traffic would be able to see data being passed.
5. Sniff the traffic to view data being passed. A tool called Wireshark is good for passively sniffing traffic.
6. And that is basically it! Make sure to passively and actively identify forms of potential insecure communications. This example of an application is small with limited functionality, however, it is worth testing all the functionality of an application and stepping through the requests to see how communications are working. Sensitive data should not be transmitted in plaintext or insecurely, so keep an eye out when testing!
What did we learn?
We learnt the dangers of applications that don’t make use of encryption and how we can test for such a thing. There are many different methods for communication and not all of them have been covered here; if there are any that peak your interest or take your fancy, then feel free to comment and I will see what I can do.
Thank you for reading this post! I hope you have a very Happy Easter and enjoy your bank holiday!
Sarah <3