During the recent years, mobile application security has been in a constantly evolving state where hackers come up with new ways to attack applications, while the mobile developers are constantly enhancing the platform’s security. Thus, security of mobile applications is becoming more and more important for companies as well as the information security industry in general.
Our white hat hacker Mikael has been studying and researching mobile application security and wanted to share some of his findings as well as the issues that he sees in mobile application development, security and what companies can do to ensure better mobile application security. So if you wish to know more how to prevent mobile application vulnerabilities, read on!
The purpose of this blog is to demonstrate how a Cross-App Scripting vulnerability, a form of XSS, could be exploited in a mobile application and to show, what can be done to prevent these vulnerabilities. The aim is to provide more insight and understanding in preventing vulnerabilities for people working in mobile application security. It’s also worth to mention that the information in this blog post is known to mobile application hackers. We also want to remind the reader that attacking is only allowed when one has a permission for the attack from the target and hacking is always illegal without the permission from the target.
The example study in the blog post is based on a finding Mikael did while he was researching a mobile application. To understand this blog post you need to understand the Android interprocess communication (IPC) and WebViews. Going in-depth to these topics is out of scope of this blog post, but a short, basic explanation is crucial to understand what’s happening.
The Android IPC is designed to give mobile applications a way to communicate with each other, for example:
You’ve designed an application that allows the user to login with their Facebook or Google credentials to enhance the user experience. In theory the application can receive an intent from these application’s allowing the user to authenticate with their respective account credentials.
A WebView are views in an application that replicates the experience of a web browser on the device, so a WebView can render HTML and JavaScript code inside the application. Using a WebView is particularly useful to utilize and use an existing web application that you’re developing.
One big part of my personal methodology during mobile application audits is to look for WebViews and if they have JavaScript enabled in them, and usually, they do.
The vulnerability
I’ve replicated the most important parts of my finding as a half pseudocode to avoid exposing the application in question. Note that I’ve removed most of the code to highlight the most important parts, which led to the discovery of vulnerability.
The AndroidManifest.xml defined the following intent filter:
The intent filter led to broadcast receiver handler, that forwarded the received data to this vulnerable code in the main activity:
Notice how there isn’t really any good validation done on the received data. The code only checks if the input is not empty and continues execution. I’ve noticed that most mobile applications that I’ve had the opportunity to audit does this type of validation, which is risky when a user has some level of control over the input.
Effectively what the code did was receive data from an intent and try to pass that data into loadUrl function, which is the same as opening a URL in a web browser in view (WebView). Additionally, the WebView function had the ”evaluate Javascript” function set to ”true”. Most security aware developers and web application hackers by now would figure out that we could exploit this in a few ways:
- Access arbitrary files with the file protocol
- Load arbitrary websites
- Execute code with the JavaScript protocol
I found the ability to execute JavaScript in the context of the web service to be particularly devastating, because I was able to steal the user’s cookies with ease and send them to my server.
Even though there are cases where a mobile application vulnerability could be exploited by a remote server, this particular vulnerability can be exploited only by a malicious application on the user’s device. The likelihood of a malicious app existing to exploit this vulnerability is uncommon, but if we consider the target application to be a financing (e.g Banking, investment or other financing related applications) the risk goes up.
Proof of concept
We can deliver two separate proof of concepts on this vulnerability. We can easily test the application with android development bridge (adb) to validate the finding. After validation we can actually build a malicious application to exploit the vulnerability.
Adb command:
Turning that adb command into a malicious application would use something like the following code to exploit the vulnerability:
Here we first create a new intent, we set the target application and target application’s broadcast receiver, the action and the data which contains our payload, and finally we send our payload.
When our malicious application has been built and installed on the device, we can test our proof of concept by navigating to the application and executing our malicious intent. The result leads to an alert dialog opening within the target application and domain name as it’s text, which proves that we have successfully executed an attack on the service providers application.
Conclusion
Due to an exposed component and weak validation, we were able to exploit a rather trivial vulnerability. The takeaway here would be to check if your application has any exported functionality that could be exploited in an unintended way. The second thing to do would be to improve validation where necessary. If I’d get paid for each time, I’ve seen the validation being only if data is not null, well let’s just say that I would be quite wealthy.
Mikael Amose
Mikael is a web and mobile application specialist at 2NS.