1021742 - Fennec manifest allows for ADB backup attack when USB debugging is enabled

Status: RESOLVED DUPLICATE of bug 1190375

(Firefox for Android Graveyard :: General, defect)

Description

[u401878]

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

Comment 1

[u401878]

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

Comment 2

[Kevin Brosnan [Ex-Mozilla]]

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.

Comment 3

[Richard Newman [:rnewman]]

Attachment: Add android:allowBackup="false" to AndroidManifest.xml.in. v1

This should do the trick.

Comment 4

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 5

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 6

[Richard Newman [:rnewman]]

Sounds like a good idea to me.

Comment 7

[Richard Newman [:rnewman]]

https://hg.mozilla.org/integration/fx-team/rev/889e19a5e9cc

Comment 8

[James Willcox (:snorp) ([e-mail]) (he/him)]

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.

Comment 9

[Brad Lassey [:blassey] (use needinfo?)]

I agree. This isn't an attack at all. The phone owner is making an explicit security choice by having their phone unlocked.

Comment 10

[James Willcox (:snorp) ([e-mail]) (he/him)]

Comment on attachment 8439355 [details] [diff] [review]
Add android:allowBackup="false" to AndroidManifest.xml.in. v1

r- based on my last comment

Comment 11

[Brad Lassey [:blassey] (use needinfo?)]

backed out of fx-team https://hg.mozilla.org/integration/fx-team/rev/e81fb1468aba

Comment 12

[Mark Finkle (:mfinkle) (use needinfo?)]

Are we saying that any "phone unlocked" attack vector is not a security concern?

Comment 13

[Nick Alexander :nalexander [he/him]]

(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.

Comment 14

[Nick Alexander :nalexander [he/him]]

(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.

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

(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.

Comment 16

[u401878]

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!

Comment 17

[Nick Alexander :nalexander [he/him]]

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.

Comment 18

[Richard Newman [:rnewman]]

(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.

Comment 19

[Brad Lassey [:blassey] (use needinfo?)]

(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

Comment 20

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 21

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 22

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 23

[u401878]

any updates?

thanks

best regards

Comment 24

[Gian-Carlo Pascutto [:gcp]]

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.

Comment 26

[morrison_constable]

This is unbelievable stupid. I have to switch from an old device to a newer one and have some 40 tabs open in Firefox I DON'T want to have to reopen with all their history. Months of history in closed tabs, and yes, probably some passwords stored. In order to get other app's data off the old phone I had to:

1) Turn on developer mode.
2) Find and install the USB drivers on the PC (granted, there may be those out there with a full assortment of drivers installed just for a time when they have access to an UNLOCKED(!) device.
3) Plugin phone and allow MTP access, WHILE UNLOCKED.
4) Initiate a ADB transaction, WHICH THE PHONE PROMPTED ME TO ALLOW, ONLY WHILE UNLOCKED.

3 WHOLE OPERATIONS that are required before one can access ANY DATA via adb, and as other commenters have mentioned, if the bloody phone is unlocked than someone can access most of the data ANYWAYS!!!!! 

All this change does is prevent legitimate users from backing up their own f**** data. And of course I would need to root the device or reinstall a recompiled version of Firefox to get this data off, oh wait, BEFORE I KNEW OF THIS STUPID DECISION. I am a long time Firefox user, but seriously this is reasons I have switched in the past. Where is the pref to disable this behavior, aye? There has to be a way to store encrypted/password/cookies/etc in a separate app with the android:allowbackups set to false, that the main Firefox process can access to store/retrieve these.

Comment 27

[Gian-Carlo Pascutto [:gcp]]

You're commenting in a bug where it was decided *NOT* to disable the backup feature because of a purported attack. It got disabled later on for a different reason, see bug 1190375 and bug 1185920.