The IBM X-Force Application Security Research Team has discovered a vulnerability in the Dropbox SDK for Android (CVE-2014-8889) which allows attackers to connect applications on mobile devices to a Dropbox account controlled by the attacker without the victim’s knowledge or authorization. This is a serious flaw in the authentication mechanism within any Android app using a Dropbox SDK Version 1.5.4 through 1.6.1 (note: this vulnerability was resolved in Dropbox SDK for Android v1.6.2). The vulnerability can be exploited in two ways, using a malicious app installed on the user’s device or remotely using drive-by techniques. It cannot, however, be exploited if the Dropbox app is installed on the device (it does not even need to be configured, just installed).
Upon discovery of the vulnerability, the IBM team privately disclosed the issue to Dropbox. The response from Dropbox to this security threat was particularly noteworthy as they acknowledged receipt of the disclosure within a mere six minutes, confirmed the vulnerability within 24 hours, and released a patch within just four days. This undoubtedly shows the company’s commitment to security, this was one of the fastest response times the IBM Security team has seen in its long history of vulnerability research.
With a patch solution available, it is highly recommended that developers update their Dropbox SDK library. Additionally, end users (device owners) must update their apps that rely on the SDK and are also encouraged to install the Dropbox app, which makes it impossible to exploit the vulnerability; this is because the vulnerable SDK code is not invoked when the local Dropbox app is installed.
The following blog post gives a high-level overview of the vulnerability leveraging a proof-of-concept exploit the IBM X-Force team developed. The full details of CVE-2014-8889 and the DroppedIn exploit are available via this white paper.
Background
It is no secret that the world is now storing private personal and business data in the cloud. In order to access this data, providers such as photo-sharing services or general-purpose storage services, are expected to be accessible not only by the user, but also by apps that leverage that data to enhance the user experience. In an effort to ease the development lifecycle and encourage an ecosystem of reliant solutions, cloud services often provide a framework, or rather a Software Development Kit (SDK) that apps can utilize. The Dropbox SDK for Android is such a framework, providing Android apps with a simple way to interface with Dropbox.
These frameworks can be very appealing for app developers since they provide a simple client-side Application Programming Interface (API). From a security perspective, however, the frameworks themselves provide an extremely attractive attack surface since the vulnerability of the framework could potentially affect numerous applications that use it.
According to AppBrain, which provides statistics about the prevalence of Dropbox SDK use for Android, 0.31 percent of all applications use the Dropbox SDK. Of the top 500 apps, the prevalence is higher, at 1.4 percent.
Out of the 41 apps we examined as part of our initial research that use the Dropbox SDK for Android, 31 apps (76 percent) used a vulnerable version of the SDK. It is worth noting that 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 SDK version 1.5.4, this older attack vector was notable in that it could not be prevented by installing the Dropbox app.
This app falls under the category of password management apps, and uses the Dropbox SDK to synchronize the user’s vault (key store) with Dropbox. This attack let us leak the victim’s vault to the attacker’s account, which could then crack its master password offline (if it were weak enough) or steal it using other techniques, such as a phishing attack. In order to prevent exploitation 1Password users should download the latest 1Password app, which contains a fixed Dropbox SDK.
It should be noted that this attack technique does not put data saved to Dropbox from other solutions at risk to prying eyes.
This blog post gives a high-level overview of the vulnerability and the attack we developed. The full details of DroppedIn are available in this white paper.
Understanding the Vulnerability: Dropbox and OAuth
Apps need to be authorized on the user’s Dropbox account in order to access data. A naïve solution would be to provide apps with the user’s credentials. Dropbox avoids this bad practice by leveraging the OAuth protocol, which does not disclose the credentials.
This process begins with a single out-of-band registration of an app on the Dropbox website. As a result of this registration, the app developer receives an app and secret key from Dropbox, which are saved (hard-coded) in the application code.
The OAuth ‘dance’ starts by the app calling the Dropbox SDK, requesting to authenticate the user and authorize the app. After receiving the request, the Dropbox SDK generates a cryptographic nonce — a very large, random number — helps in securing this process. The Dropbox SDK either invokes the browser or the Dropbox app (if it is installed), which presents the following familiar screens to Dropbox users:
The nonce is saved locally and is sent to Dropbox. The user next authenticates and authorizes the app to access Dropbox data using the API, which returns an access token and the nonce to the application. The returned nonce is compared with the locally saved one, and if they match, the access token, which allows the app to access the Dropbox data, is accepted and later consumed by the app.
Since the nonce is a random number attackers cannot guess, it helps prevent a simple attack in which the attacker injects an access token pertaining to his or her account (instead of the victim’s).
The goal of the attack is to link the app with the attacker’s account instead of the victim’s to either have the victim upload sensitive information or download malicious, attacker-controlled data that may be used as part of other attacks.
Adding the nonce parameter, since the attacker cannot predict it, should have mitigated the threat. However, an implementation-specific vulnerability exists that lets attackers force the Dropbox SDK to leak that nonce to the attacker’s server, rendering the secrecy of the nonce useless.
Vulnerability
The CVE-2014-8889 vulnerability lets adversaries insert an arbitrary access token into the Dropbox SDK, completely bypassing the nonce protection.
The code belongs to the Activity that is responsible for the Dropbox authentication. It consumes various Intent extra parameters. Since the browser can invoke this Activity, it can be launched by both malware and malicious websites with an arbitrary Intent payload. Therefore, special care must be taken when consuming this Intent’s payload.
Consumption of a particular Intent extra parameter, named INTERNAL_WEB_HOST, has devastating results. When the browser is used (i.e., the Dropbox app is not installed) to authenticate the user and authorize the app to access the user’s Dropbox account, this parameter eventually controls the host that the browser surfs to. If the attacker can generate an Intent targeting the activity, with INTERNAL_WEB_HOST pointing to his or her server, the authentication process will take place with the nonce sent to the attacker.
The DroppedIn Attack for Dropbox SDK
The IBM X-Force Research Team developed a working proof of concept exploit, dubbed “DroppedIn” to test this vulnerability. This proof of concept allows the attacker to link a target app with the attacker’s Dropbox account instead of the victim’s without the victim’s knowledge.
We created both local and remote (drive-by) end-to-end versions of the “DroppedIn” proof-of-concept attack. Both local and remote attacks fail if the Dropbox app is installed on the targeted device. In order to exploit the DroppedIn vulnerability, a couple of things need to happen, the following figure provides an overview of the remote attack:
Step 1: The attack begins with a preliminary, out-of-band step. The attackers obtain an access token associated with their account and the attacked app. This is especially easy because attackers can simply download the app to their device, authorize it on their Dropbox account and record the returned access token pair.
Step 2: The victim is lured to surf to an attacker’s controlled website or some page that the attacker has injected malicious data into.
Step 3: Attackers cause the Dropbox SDK within the app to leak the nonce to their server. This is done by exploiting the aforementioned vulnerability, using a simple HTTP redirect.
The HTTP redirect causes the vulnerable Dropbox SDK Activity to be invoked with the attack payload.
The Intent will eventually trick the vulnerable Dropbox SDK Activity to request (using the browser) https://attacker:443/1/connect (with the nonce as a GET parameter). This implies that succeeding in the last step requires that the attacker owned a Secure Socket Layer certificate of his or her own domain, but this is rather easy.
Step 4: The attackers now know the session’s nonce, so they can impersonate to Dropbox and inject their pregenerated access token from Step 1 into the app by another HTTP redirect.
Step 5: At this point, the attacker’s token has been successfully injected into the target app. The missing piece of the puzzle is how the app consumes this data, which is up to the developer. More details about this step are available in the white paper.
Case Studies
The first case study uses DBRoulette, which is an app bundled with the Dropbox SDK. This app randomly fetches and displays images from the linked Dropbox account. While this is a sample app, we believe many lazy developers simply copy the Dropbox SDK calls and paste them into their own code. Exploiting this app lets attackers override the currently saved access token with their injected one, completely relinking the app with their account. The following image depicts a successful attack, with one of the author’s thumbs fetched from the attacker’s Dropbox account instead of the victim’s. This has been fixed with the current release of the Dropbox SDK.
The second case study was identified using Microsoft Office Mobile. This app uploads the user’s documents to the cloud and supports multiple Dropbox accounts. The exploitation would occur before the user adds a new Dropbox account in order to be successful. According to the app’s logic, the user will be asked to enter his or her Dropbox credentials in the browser window. However, the app will still be linked — in the background and without the user’s consent — to the adversary’s account. This would put all future documents the user saves using Microsoft Office Mobile at risk. Microsoft and Agilebits have updated their apps in the Google Play store to the new SDK that Dropbox has issued to address the vulnerability and to protect their customers. Dropbox has also updated the DBRoulette sample code which is bundled with the SDK. Users still are required to update their apps to ensure they are secure.
The third case study was conducted using 1Password, which supports a single Dropbox account. The exploitation would once again occur before the user configures 1Password to use his or her Dropbox account. Again, according to the app’s logic, the user will be asked to enter his or her Dropbox credentials and the app will still be linked to the adversary’s. The current version of the app uses the newest SDK, and is not vulnerable.
One way to quickly determine if you have been attacked by this vulnerability is to, from your PC, login in to Dropbox.com and look at your files using the browser window to identify if there are files you are archiving on your mobile device using Dropbox that are not present when you log in via a web browser on your computer.
Note: Microsoft and Agilebits have updated their apps in the Google Play store to the new SDK that Dropbox has issued to address the vulnerability and to help protect their customers. Dropbox has also updated the DBRoulette sample code which is bundled with the SDK. Users still are required to update their apps to help ensure they are secure.
Mitigation
Dropbox SDK for Android Version 1.6.2 and later incorporates a fix for this security vulnerability. The vulnerable Dropbox SDK Activity no longer accepts input parameters from the incoming Intent’s extras. This makes it impossible for the attacker to control the host with which the Dropbox SDK communicates in order to leak the nonce.
Developers are strongly encouraged to update their SDK to the latest version. In order to avoid exploitation of slowly updating apps, end users should update their apps to the latest versions and install the Dropbox app, which makes exploitation impossible.
Hi. I’m Designer of Blog Magic. I’m CEO/Founder of ThemeXpose. I’m Creative Art Director, Web Designer, UI/UX Designer, Interaction Designer, Industrial Designer, Web Developer, Business Enthusiast, StartUp Enthusiast, Speaker, Writer and Photographer. Inspired to make things looks better.
0 comments:
Post a Comment