Closed Bug 1021742 Opened 8 years ago Closed 8 years ago
Fennec manifest allows for ADB backup attack when USB debugging is enabled
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_9_3) AppleWebKit/537.76.4 (KHTML, like Gecko) Version/7.0.4 Safari/537.76.4 Steps to reproduce: i have a non rooted android device ( samsung galaxy tab 3 ) latest version and i installed firefox android app beta and firefox android app. i found that both apps ( firefox, firefox beta) are vulnerable to to ADB backup attack. It was found that if an attacker had access to an unlocked phone, they could take any data from the application's sandbox through ADB's backup feature. Normally ADB backup allows applications to be backed up to the cloud. This means that if a user replaces or wipes their phone, they can restore app settings. This feature is on by default and needs to be explicitly disabled in the manifest <application allowBackup="false" If enabled (or not explicitly disabled), then the backup feature can also be used over USB (details here:http://nelenkov.blogspot.co.uk/2012/06/unpacking-android-backups.html). This means that the shell user, which can not normally access files in the sandboxes of applications, can read and write to them. In the case of the Firefox + Beta Android app, it meant that if an attacker had access to an unlocked android device, then they could recover all the files from Firefox' sandbox to their PC. This includes the all cookies, password and token and other sensitive information just connect an unlocked android device with firefox app installed and enable usb debugging then go to your commend shell (ubuntu) and type these commands: adb backup org.mozilla.firefox_beta dd if=backup.ab bs=1 skip=24| openssl zlib -d > backup.tar tar -xaf backup.tar cd apps PROFIT :) NOTE: Firefox app (org.mozilla.firefox) is vulnerable to the same attack and should be fixed too NOTE 2: you just need unlocked android device and non rooted i made a quick demo video: http://youtu.be/Z6VxCdwXCCg Actual results: i extracted firefox protected/sandboxed files from a non rooted device using ADB backup attack Expected results: you need to add this line <application allowBackup="false" to your AndroidManifest.xml file in both firefox apps
More info: Vulnerability Type: Authentication Bypass Issues [CWE-592] Issue Severity: Important impact CVSSv2 Base Score: 6.6 (MEDIUM) (AV:L/AC:L/AU:N/C:C/I:C/A:N) Discovery: Mohamed Ramadan ( http://Attack-Secure.com ) References: http://www.securityfocus.com/archive/1/529783/30/210/threaded https://deepsec.net/docs/Slides/2013/DeepSec2013ChrisJohnRiley-AndroidSecureContainers.pdf http://blog.c22.cc/2013/08/01/bsideslv-android-backup-unpacker-release http://trotmaster.blogspot.com/2014/04/wickr-account-cloning-vulnerability.html http://blog.c22.cc/2013/09/05/a-sneak-peak-into-android-secure-containers-2/ http://seclists.org/bugtraq/2013/Nov/55 http://www.securiteam.com/securitynews/5KP3315C0W.html
Determined local attack. Requires user to set a non-standard and hidden pref in modern Android (usb debugging) or have access to an unlocked phone, thus the attacker could set the pref and perform the attack. We are not using the feature so setting 'application allowBackup="false"' seems sensible.
Status: UNCONFIRMED → NEW
tracking-fennec: --- → ?
Ever confirmed: true
OS: Mac OS X → Android
Hardware: x86 → All
Summary: Firefox android app (beta) is vulnerable to ADB backup attack → Firefox android app ( stable+beta) is vulnerable to ADB backup attack
Assignee: nobody → rnewman
Status: NEW → ASSIGNED
This should do the trick.
Attachment #8439355 - Flags: review?(mark.finkle)
Summary: Firefox android app ( stable+beta) is vulnerable to ADB backup attack → Fennec manifest allows for ADB backup attack when USB debugging is enabled
Comment on attachment 8439355 [details] [diff] [review] Add android:allowBackup="false" to AndroidManifest.xml.in. v1 I think we should continue to allow Nightly builds to "allowBackup" in the same way Nightly builds are "debuggable". Can you move the "allowBackup=false" line into the #else block with "debuggable=false", assuming my reading of the logic means that's the right spot to put it. Maybe even add "allowBackup=true" in the other block to make things more explicit.
Attachment #8439355 - Flags: review?(mark.finkle) → review+
The reason I suggest keeping allowBackup for Nightly is the value in being able to pull the data from the phone. If we feel this is better handled by "debuggable=true", which allows adb pulling data files, then just go with your original patch.
Sounds like a good idea to me.
I am not in favor of this patch. There is no privilege escalation here, and the allowBackup feature is working as designed in Android. All that's happening here is that someone who has already been authorized to use the device is accessing data stored on it. Nothing more. People should be allowed to back up their data, and if we set 'allowBackup=false' they will no longer be able to.
I agree. This isn't an attack at all. The phone owner is making an explicit security choice by having their phone unlocked.
Comment on attachment 8439355 [details] [diff] [review] Add android:allowBackup="false" to AndroidManifest.xml.in. v1 r- based on my last comment
Attachment #8439355 - Flags: review+ → review-
backed out of fx-team https://hg.mozilla.org/integration/fx-team/rev/e81fb1468aba
Are we saying that any "phone unlocked" attack vector is not a security concern?
(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #9) > I agree. This isn't an attack at all. The phone owner is making an explicit > security choice by having their phone unlocked. Agreed, this isn't an attack, it's a feature. I use this for debugging and (legitimately!) backing up my device.
(In reply to Mark Finkle (:mfinkle) from comment #12) > Are we saying that any "phone unlocked" attack vector is not a security > concern? I wouldn't, but this is an Android feature. You need to have a cable connected (I think?), and then you have to agree -- a dialog pops up on the device -- to backup. This is one of the few ways to get information off your phone. I claim that this feature (and it is a recent Android feature) helps our users truly own their data by making it possible to get off their device.
(In reply to Mark Finkle (:mfinkle) from comment #12) > Are we saying that any "phone unlocked" attack vector is not a security > concern? I would. If the reason the "attacker" can do something is the security/consent dialog is shown due to the phone being unlocked then this isn't a security flaw. As snorp pointed out on IRC, the difference between this and the attack on LastPass described here [http://www.securityfocus.com/archive/1/529783/30/210/threaded] is that this circumvented LastPass's own security (requesting a password to access data). The equivalent in Firefox's terms would be if this circumvented Master Password, which it doesn't.
OpenVPN fixed it: * Added app flag android:allowBackup="false" to prevent app data such as profiles and encrypted credentials from being backed up. This is seen as a security safeguard to prevent an attacker with physical access to the device from being able to easily extract profiles or encrypted credentials through Android's standard backup capabilities. http://openvpn.net/index.php/component/content/article/119-faq-openvpn-client/533-connect-android-release-notes.html Faceless fixed it: We have checked this issue and verified it as a valid bug which is in scope. The fix for this issue will be shipped with our next update to the app. This has been a very good find! Thank you! https://hackerone.com/reports/12617 courses fixed it: https://github.com/aporter/coursera-android/blob/master/Examples/DataManagementPreferenceActivity/AndroidManifest.xml wickr fixed it: http://trotmaster.blogspot.com/2014/04/wickr-account-cloning-vulnerability.html lastpass fixed it: http://blog.c22.cc/2013/09/05/a-sneak-peak-into-android-secure-containers-2/ i manually tested these apps and all of them fixed it: vine android app google wallet android app Coinbase wallet android app twitter android app - their reply to me was: jcollins closed the bug and changed the status to Duplicate. Thank you for the report. We are already aware of the issue. Thank you for thinking of Twitter security!
The previous comment suggests that the industry views Android's feature as a mistake. (Or as too coarse-grained.) As an in-between, how about we disable backup when we're not a debug build (like we do for android:debuggable?) Then you can install a debug from TPBL to get backup, but we stay in line with the industry.
(In reply to Nick Alexander :nalexander from comment #17) > The previous comment suggests that the industry views Android's feature as a > mistake. (Or as too coarse-grained.) As an in-between, how about we > disable backup when we're not a debug build (like we do for > android:debuggable?) Then you can install a debug from TPBL to get backup, > but we stay in line with the industry. That's what the landed (and backed out) patch did.
(In reply to Nick Alexander :nalexander from comment #17) > The previous comment suggests that the industry views Android's feature as a > mistake. (Or as too coarse-grained.) As an in-between, how about we > disable backup when we're not a debug build (like we do for > android:debuggable?) Then you can install a debug from TPBL to get backup, > but we stay in line with the industry. There are no release-signed debug builds, so you couldn't install over for beta or release
You can already perform this attack even with allowBackup=false: install the copy-to-sdcard add-on once you have control of the phone, copy the profile to external storage and upload it. This looks like total Security Theater to me.
Note that I do consider it an interesting question whether you can legitimately extract data out of the sandbox in other apps when you just have an unlocked phone. If this isn't generally possible, then our problem isn't (only!) allowBackup, but the entire idea that copy-to-sdcard is possible at all.
Although if I have your unlocked phone, I can see all your history and login to all your sites via login/pass autocomplete. I probably have access to your email as well, so I can start sending password reset requests for all your accounts even if the password isn't stored in the phone. Given that all your sensitive data can now be compromised even without extracting the actual profile, I'd love to see a good argument what extra protection disabling backups is supposed to give.
any updates? thanks best regards
I doubt we will take action here unless there's an actual argument what safety disabling backups would bring. If I get your unlocked phone, I can already get all the interesting information from your profile even without using the backup feature. IMHO we can make this bug public + WONTFIX.
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → WONTFIX
Resolution: WONTFIX → DUPLICATE
Duplicate of bug: 1190375
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.