Dropbox Patches Remotely Exploitable Vulnerability in SDK

Developers at Dropbox recently fixed a remotely exploitable vulnerability in the Android SDK version of the app that enabled attackers to connect applications on some devices to a Dropbox account without the user’s consent.

Developers at Dropbox recently fixed a remotely exploitable vulnerability in the Android SDK version of the storage app that enabled attackers to connect applications to a Dropbox account without the user’s consent. This could have opened users up to the theft of information from any app that used a faulty version of Dropbox, either via malware or drive-by exploitation.

The issue stemmed from what researchers at IBM – who found the vulnerability – called a “serious flaw” in the SDK’s authentication mechanism. An attacker could have dropped an arbitrary access token into the SDK’s code, which would have bypassed its nonce protection.

In a blog entry this morning, Roee Hay, a team leader for IBM’s X-Force Application Security Research team, dug deeper into the flaw.

In his writeup Hay technically refers to the flaw as an “implementation-specific vulnerability” (CVE-2014-8889) that granted attackers the ability to force the SDK to leak the nonce to the attacker’s server, thus “rendering the secrecy of the nonce useless.”

With the nonce the attacker could link the app with their own account, instead of the victim’s, and trick them into either uploading sensitive information or into downloading malicious data.

Dropbox authenticates apps via OAuth calls and in response the SDK spits out a lengthy, complex cryptographic number, or nonce. As long as the nonce the SDK generates matches the nonce returned via API from the other app, both apps can access each other.

In a proof-of-concept for the vulnerability, which IBM has coined the DroppedIn vulnerability, an attacker has to 1) Obtain an access token 2) Lure the victim to a malicious site 3) Leak the victim’s nonce to their server 4) Impersonate the nonce to Dropbox and 5) Inject their token into a targeted app.

In a video posted alongside their research today both Hay and Or Peles, another IBM security researcher, describe how they were able to use the vulnerability as a vector to attack one of the apps that connected to the Dropbox SDK, an older version of 1Password. As the video shows, once a user stumbles upon a website controlled by an attacker, the Dropbox SDK code in 1Password can be exploited and the attacker can gain access to the victim’s vault. Many 1Password users share log-ins across multiple platforms via vaults that are usually synced by a cloud service like iCloud or Dropbox.

Since the vulnerability was present in the app’s SDK library, many apps that use it, like 1Password and Microsoft Office Mobile, were using a vulnerable version of it. 1Password and Microsoft have of course updated their apps in Google Play since IBM reported the vulnerability but users are still encouraged to make sure they’re running the latest version, which includes a fixed version of Dropbox’s SDK.

Hay points out after privately reporting the issue, Dropbox’s security team expedited the fix, acknowledging the flaw in six minutes, confirming it in 24 hours and releasing a fix in only four days.

As this was an SDK-only issue, users that ran the standalone Android version of the Dropbox app were never affected but the problem did affect Dropbox SDK versions 1.5.4 through 1.6.1. Dropbox addressed the vulnerability by making it so the SDK refuses input parameters in 1.6.2 and on.

“This makes it impossible for the attacker to control the host with which the Dropbox SDK communicates in order to leak the nonce,” Hay writes.

The most recent build of Dropbox SDK for Android, 1.6.3, was pushed live on January 9.

Suggested articles