IBM discloses vulnerability in Dropbox's Android SDK

The flaw allegedly affects popular Android apps like Microsoft Office Mobile, but Dropbox maintains its scope is limited

Unlocked circuit board / security threat
Credit: Thinkstock

Security researchers at IBM have found a vulnerability in Dropbox's Android SDK, versions 1.5.4 through 1.6.1, which allows attackers to connect applications on mobile devices to the Dropbox accounts they control.

IBM and Dropbox have been working together since December to verify and patch the vulnerability. But Dropbox remains adamant that the problem is of extremely limited scope and most Android users -- especially at this point -- are not vulnerable.

Rapid response

Originally discovered by IBM Security's X-Force Application Security Research Team, the vulnerability -- classified as CVE-2014-8889 -- allows an attacker to link an app that uses the vulnerable version of the SDK to a Dropbox account of their choosing. The user's own Dropbox account is not accessible through this vulnerability.

"This may allow the attacker to steal sensitive information and inject malicious data into apps," IBM's Roee Hay stated in a high-level overview of the issue provided in advance of its public announcement.

According to IBM, Dropbox responded very quickly when contacted. "This may have been the most rapid response from any vendor we disclosed a vulnerability to," said Erin Lehr, of External Communications and Media Relations at IBM Security, in a phone conversation. "Within four days, they had a patch."

That said, IBM agreed to give Dropbox at least 90 days to verify the vulnerability -- enough time for Dropbox to ensure that those using its SDK had patched their products.

While only a small percentage of all Android apps use the SDK -- 0.29 percent, according to research provided by AppBrain -- IBM claims the vulnerability is more common among some of the more popular Android applications and cited Microsoft Office Mobile as one example. Out of 41 apps it examined that used the Dropbox SDK, IBM claims 31 apps were vulnerable.

"The rest of the apps were vulnerable to a much simpler attack that has the same consequences but had been fixed by Dropbox in the 1.5.4 version of the SDK, which the apps' developers did not upgrade to," Hay said.

A closed window of opportunity

Dropbox, however, maintains that the scope of the vulnerability is extremely limited -- and far more so now that app developers have had time to patch their applications.

"There are no reports or evidence to indicate the vulnerability was ever used to access user data," said Devdatta Akhawe of Dropbox in a blog post about the issue.

Dropbox also insists that exploiting the vulnerability would not have been easy to do and would have required all of the following conditions be fulfilled:

  1. The victim would have to be using an application on Android with the affected version of the SDK.
  2. The victim would have to visit "a specially crafted malicious page with their Android Web browser targeting that app, or have a malicious app installed on their phone," said Akhawe.
  3. The Dropbox client for Android would have to not be installed on the device.

This last point is crucial for two reasons:

  1. The Dropbox client -- as opposed to apps developed with the vulnerable version of the SDK -- is itself not currently vulnerable.
  2. Once the client is installed, all interaction with Dropbox through third-party apps is conducted through the client, rather than via the functionality provided in the SDK.

Most Android malware isn't due to vulnerabilities in the operating system itself, but rather because incautious users install applications not provided from the Google Play store, which is scanned regularly. That said, this vulnerability affected legitimate, fully vetted applications. Future vulnerabilities of the same ilk will require as much early warning and remediation as possible.

From CIO: 8 Free Online Courses to Grow Your Tech Skills
Notice to our Readers
We're now using social media to take your comments and feedback. Learn more about this here.