Unintended Data Leakage - Application Backgrounding

Application Backgrounding iOS

If an application is open, it is possible that it can be sent in to the background by a change in state, such as the user pressing the Home button or from an incoming call. 

When an application is suspended in the background, iOS will take a “snapshot” of the app and store it in the application caches directory. 

If any sensitive information is open in the application when it enters the background, the snapshot is written to the filesystem in clear text. This can then be accessed by a malicious user.

iGoat Example

iGoat has an example of this type of vulnerability under Data Protection (Rest) > Backgrounding. Just click on Start to begin the exercise.

Enter any answers in the security question text fields and tap on the home button on your device to take the application in the background. iOS will take a screenshot of the application before it goes in the background.

If you navigate to the /Library/Caches/Snapshots/ folder you will find the snapshot containing the information you entered.

In order to prevent this kind of a vulnerability, these text fields can be set with the hidden attribute.

Example

The UIApplication delegate method applicationDidEnterBackground can be used to detect when an application is entering the background and modify the display accordingly.

- (void)applicationDidEnterBackground:(UIApplication *)application {

viewController.creditcardNumber.hidden = YES;

}

Insecure Local Data Storage iOS

iGoat

iGoat is a deliberately vulnerable mobile application that allows developers and testers to learn about common security issues that are often seen in iOS. If you want to find out more about the project then you can click on this link.

Setup

In order to run this application via a simulator you will need xcode installed from the app store. The next step is to download the latest version of iGoat here. You should be able to open the project file iGoat.xcodeproj with xcode, when you run the application you should see the simulator on the screen.

Optional: Inside the iGoat folder there is a ruby server igoat_server.rb. We do not need it for this tutorial but we will need it later on, you will need to install some necessary ruby gems - this can be done by running the command 'sudo gem install sinatra json'. To start the server you can run the command below

Insecure Data Storage 

Insecure data storage vulnerabilities occurs when development teams assume that users or malware will not have access to a mobile device's filesystem and subsequent sensitive information in data-stores on the device. Filesystems are easily accessible. Organizations should expect a malicious user or malware to inspect sensitive data stores. Rooting or jailbreaking a mobile device circumvents any encryption protections. When data is not protected properly, specialized tools are all that is needed to view application data.

In the iGoat mobile application we will exploit sensitive data stored locally on the device. In the simulator navigate to Data Protection (Rest) > Local Data Storage.

Once you click on the 'Start' link you will see a login page similar to below. All you have to do is enter a username and password pair then login.

 Now we can try and via the insecure data. Finding the correct directory can be tricky when using a simulator. First you need to locate your device, an easy way to do this is to go to Finder and enter the path below.

 

Then you can sort the directory by Date Modified to determine your current device.

Once inside the device you can navigate to /Containers/Data/Application/<UUID>/ . Next navigate into the Documents directory - you will see a sqlite file called credentials.sqlite. Use the command sqlite3 credentials.sqlite to enter the sqlite3 interpreter with the database file. 

To view the tables type '.tables', you will see a table called creds. We can dump all of the information from the table by entering the command 'select * from creds;' 

Recommendations 

It is important for developers to note that the data stored in Sqlite files is saved unencrypted in the application sandbox on the device.For databases consider using SQLcipher for Sqlite data encryption.

References: https://www.owasp.org/index.php/Mobile_Top_10_2014-M2

Intercepting Android Applications With Burp Suite

Burp Suite

Burp Suite is a very useful platform for application security analysis. Burp is written in Java and can be run on most platforms, it includes both a free and commercial version. It includes a proxy server that allows you to configure your browser or mobile application for traffic interception.

In this post we will go through the steps for configuring burp to intercept traffic on a mobile device.

Configure Burp Proxy Listener

Once you open Burp - go to the Proxy tab and the Options. Click on the add button and set the 'Bind to port' to 8080. Then select All interfaces.

Configure Mobile Device/ Emulator

In your Android device or emulator go to 'Settings' and Wi-Fi (ensuring that you are connected).

Next hold down on the network button until you see a menu with either 'Forget network' or 'Modify network'. 

When you select 'Modify network' the menu below will open , check the 'Show advanced options' checkbox. Change the Proxy settings to 'Manual' and enter the IP address in the Proxy hostname field of the computer that is running burp. In the 'Proxy port' field enter the port that burp is listening on e.g. 8080.

Intercept Traffic

To test that we can intercept the traffic, open up a mobile application and perform an action. In the screenshot below we are logging into the Insecure Bank app.

Before hitting the Login button go to the 'Proxy Intercept' tab in burp and ensure that intercept is on.

Once you submit the request you should see the traffic in the intercept pane.

Installing Burp CA Certificate

In this example the mobile application is sending traffic over HTTP - if the application is using SSL/TLS the you will have to install the burp CA certificate on the device.

On the emulator open a browser and naviagte to http://burp. Then click on CA Certificate to install.

If you open the file manager you will see the cert under 'Downloads'.

Once you double click on the cert you will be prompted to name it. You can enter any name here and click Ok.

In Settings click on the the 'Security' tab, then  and then 'Credential Storage'. You should then see the cert under User

You should now be able to intercept any traffic being transmitted over HTTPS without getting any security warnings..

References: https://support.portswigger.net/customer/portal/articles/1841102-installing-burp-s-ca-certificate-in-an-android-device

Debugging Android Applications

Debug Flag

In Android you can set a flag in the manifest file to tell the OS whether or not an application can be debugged. This flag is commonly set to true during the development process, if the flag is still set to true in production then this can be dangerous and can lead to insecurities such as sensitive file exposure 

 The attribute in the <application> element in the manifest file will look like this  -    

 android:debuggable["true"|"false"]

Checking Application Debug Flag

During a security review it is important to check if the application has debuggable="true". Fortunately, there is a module in drozer that will do the work for us. In order to check all the application packages on the device run the command below. As you can see the insecure bank application has debuggable on.

To see which applications are active and connected to the debugging socket (@jdwp-control) you can run the 'adb jdwp' command below.

The jdwp command gives us a list of PIDs of processes that can be debugged. We can find out what packages the PIDs are mapped to by using ps and grep commands. You can see below that we can debug the insecure bank application.

Exploiting Debuggable Applications

So what can we do now? We know that the application is debuggable but we don't have root on the device. You may or may not know that if the device is not rooted then you cannot access the private data of the application. If you do try and root the device and it has an MDM policy applied preventing root exploitation then the device may get quarantined.

 No problem ;). We can use run-as, this binary allows you to execute commands in the shell with the same permissions  owned by the app, basically you are placed inside the applications private data directory.

It is now possible to run any command to view or query the data. The command below shows the databases in insecure bank.

So lets pull back some data from the insecure bank application. Using run-as and sqlite3 we can query the applications database. We can use .tables to list all of the available tables 

Now lets dump the data in the names table, you can use .dump. You can also use "select * from names" instead of .dump to query the table.

Hopefully this demonstrates why it is important to set debuggable="false" before deploying to production.