(Source: GeekFortune)
Alarming wealth of data remains in reset 'droid smartphones; for true security physical destruction post-reset is a solid solution

The good news is that your used smartphone may be worth some serious cash if you're one of millions of Americans who regularly buy and ditch the latest high-end flaghip smartphones.  The bad news, according to a new study from the University of Cambridge is that a wealth of data appears to remain even after a standard factory reset of your smartphone powered by Google Inc.'s (GOOG) Android operating system.

I. Tens, or Perhaps Hundreds of Millions of Devices are at Risk

Security researchers Laurent Simon and Ross Anderson exposed this troubling revelation by examining the common Factory Reset options found in 21 popular Android smartphones from the following top Android smartphone brands:
The devices were purchased from UK phone recycling firms.  Based on their findings on these devices, which had ostensibly undergone factory resets, the authors report:

We estimate that up to 500 million devices may not properly sanitise their data partition where credentials and other sensitive data are stored, and up to 630M may not properly sanitise the internal SD card where multimedia files are generally saved. We found we could recover Google credentials on all devices presenting a flawed Factory Reset.

That estimation may seem sensational, but recall that by 2012 (the era of Android v4.0 "Ice Cream Sandwich") global device population already stood at a half billion active smartphones, and since late 2013 (around the time of Android v4.4's ("KitKat") launch) Google has reported a pace of device activations well in excess of 1 billion units annually.

Factory Reset
One methods studied in the paper was the use of the Recovery Mode Factory Reset option in the bootloader of most Android devices. [Image Source: Jamie Wagner/YouTube]

Android in OS reset
Also studied was the in-OS Factory Data Reset option, accessible from the Android Settings app.
[Image Source: Wikihow]

There is a bit of a caveat.  The study only examined devices with Android v2.3 ("Gingerbread") through v4.3 ("Jelly Bean").  While that sample may be representative of the majority of the Android used smartphone market, some will inevitably question whether Android v5.0-5.1 ("Lollipop") fixes these flaws possibly through its decision to by default enable full device encryption (FDE).  

Android distribution
The authors show this table with various metrics indicating device version for Factory Reset models. [Image Source: Univ. of Cambridge]

The answer is "possibly", but the researchers suggest there's still cause for concern, writing, "Full-disk encryption has the potential to mitigate the problem, but we found that a flawed Factory Reset leaves behind enough data for the encryption key to be recovered."

(More specifics on the potential flaws in FDE protections are presented near the end of this piece.)

It's been known that flash memory can be vulnerable to snooping and other attacks via complex chip-level hacking.  But the Cambridge study goes a more pedestrian route focusing solely on "cheap data recovery attacks that require neither expensive equipment to physically extract data from the chip nor specific per-chip knowledge."

Android partitions
An Android device's internal storage is subdivided into three effective partitions in recent releases -- a small partition for the core OS functions including the bootloader, a user data partition (the "primary SD" eMMC storage), and an external SD storage partition (typically a mounted microSD card).  These partitions are further mapped to virtual partitions in the Android user-facing filesystem (seen above).
[Image Source: Addicting Info]

The paper first notes that care must be taken in the first place to sanitize the external SD storage, if an SD card was left in the device.  Failure to do so will automatically leave behind personal information, such as app logins.  If you had a Facebook, Inc. (FB) app stored on the SD card (due to limited device storage), for example, a malicious user might be able to purchase a device that a negligent dealer failed to fully flash and then access the former user's account.  But such exploits still come down to carrier negligence, and not an inherent OS flaw.

II. The Beginning of the Real Mess

The same can not be said about the Factory Reset.  The study found that the bootloader Factory Reset option (accessible via a hard reboot, not to be confused with the Factory Reset option in the settings of a running device) commonly only formats "a few hundred MB" a chunk of storage that "representing between 60% and 99.9% of the data partition depending on its size."

Android partitions
Android partitions as presented in the paper are shown up top.  The SDCard section (often referred to as the "Primary SD Card") is seen below detailed for an HTC device.  It is not a true SD card (unlike the external partition), but rather is an internal partition where various mounted user storage folders sit. [Image Source:TJWorld/Univ. of Cambridge]

The root cause of this lazy deletion is the use of the BLKDISCARD Linux command, which overwrites the memory block pointer in ext4 filesystems used in devices with embedded MultiMediaCard (eMMC) flash storage.  Crucially this command does not logically sanitize the data, but it's the one used to sanitize the DataPartition in older builds of the Android Open Source Project (AOSP) Factory Reset function found in the widely distributed bootloader found on most Android devices.

(The DataPartition is the partition on the device that stores most primary/internal app data, including login tokens, messages, and other sensitive data.)

The secure reset option is to use the BLKSECDISCARD instead, which properly digitally and logically sanitize the entirety of the targeted blocks.  But for unknown reasons -- perhaps the time a secure delete would take -- the bootloader Factory Reset option forgoes the more in-depth secure deletion command.
Android deletion
In the above figure the authors reveal the version history of sanitization commands by release and by the partition.  Note some section still don't use secure sanitization.  The bottom graph shows the percent of devices w/ failed sanitization for a given partition. [Image Source: Univ. of Cambridge]

The good news is that with the release of Android v4.0.1 ("Ice Cream Sandwich") the bootload Factory Reset was finally fixed to use the BLKSECDISCARD to sanitize the eMMC.  The bad news is that devices that originally had Gingerbread onboard were found to often not be properly updated by OEMs to contain this crucial security fix relating to the sanitization of the DataPartition.  The authors write:

[We] found that vendor upgrades likely omitted device drivers necessary to expose the logical sanitisation functionality from the underlying eMMC. In practice, this means that the secure command BLKSECDISCARD is not supported by ioctl, i.e. it returns errno 95 (EOPNOTSUPP).  It could be the case that the eMMC itself does not support secure deletion, but we think this is unlikely since the 2007’s 4.2 eMMC standard already provided the compulsory "ERASE" command for logical sanitisation.

Among the devices whose binaries were found not to properly receive the security firmware change include:
The Galaxy S II
The Samsung Galaxy SII is among the devices to fail implement the security fix to app data sanitization that Google delivered w/ Ice Cream Sandwich.

The authors note that of the devices that came with Gingerbread and were later upgraded to Ice Cream Sandwich "only the Google Nexus S in our sample properly sanitised its data partition after receiving upgrades to ICS."

That's not good.  Now Google's feature table claimed it was performing secure deletes, but that wasn't really happening in many cases.  

The failure lies partially with Google's reliance on OEMs to implement it nuanced OS updates, which typically contain a mix of firmware and software updates/bugfixes that OEMs attempt to merge into their personalized binaries.  It's hard to know for sure, but it's possible Google also failed to make clear to OEMs the change it has made (as OEMs have often barked back at complaints from Google suggesting its update guidance is poor at times).  However, Google only owns that small bit of the blame, as most of the onus lies with the OEMs themselves (HTC, Samsung, and possibly others) who botched the firmware updates.

Ice cream sandwich

Somewhat more bizarre the researchers found that some devices flashed with Android v4.0.x ("Ice Cream Sandwich") or Android v4.[1-3] ("Jelly Bean") either did not properly implement the finished firmware or seemed to implement it but suffer some indeterminate flaw when the commands tried to execute. 

Falling under the former category (improper firmware) was the LG Optimus L5, an ICS device that still used the BLKDISCARD command in its sanitization process.  Stranger still was the Motorola Razr i (a much buzzed about Jelly Bean device known for its Intel Corp. (INTC) Atom processor).  The authors report:

More intriguing, the Motorola Razr I, shipped with JB (v4.[1-3]), did not return any errors, but the secure deletion resulted in no block being deleted at all.

Uh oh, that's not good.

Motorola Razr i
An unknown flaw in the Motorola Razr i prevents it from properly sanitizing the data partition, although it does try to do so with the correct command.

Now all these issues have related solely to the /DataPartition/ section of the mounted flash memory.

III. Losing Your Media

When it comes to the /PrimarySD/ partition -- typically not an actual SD card, but the eMMC model of NAND flash memory chips inside your device -- the situation is even more troubling.  The Factory Reset in the bootload doesn't touch this portion of memory.  And when it comes to the in-oS version, as the AOSP does not mandate secure sanitization during the format process, you are ultimately left at the mercy of your OEM's implementation in terms of whether they use commands necessary to wipe the partition.
Android growth
Particularly bad was the SD sanitization.  These flaws potentially put images and other saved files of tens, if not hundreds of millions of Android users at risk. [Image Source: The Independent]

This puts your saved data, such as pictures, videos, music files, and audio recordings at risk of recovery by the device's new owner.  The authors write that this problem may still persist in Lollipop, although this time around it's actually the OEMs who have acted proactively in providing a fix.  The authors report:

The following Android version (JB, v4.[1-3]) marked the addition of insecure deletion via ioctl’s BLKDISCARD command. This confirms why 40% (≈150M) of devices still fail to logically sanitise their primary (internal or external) SD card. At the time of writing, we are not aware of any changes to the handling of the primary SD card, therefore we expect these results to hold on all other Android versions.

Logic would suggest that you should use the in-OS Factory Reset as it at least performs an insecure wipe of the primary SD partition -- enough perhaps to discourage casual malicious recovery attempts.  However, as the authors note, this often isn't possible due to the heavy OEM customization leads to a tendency for OEMs to inadvertently break or cripple Google's in-OS reset.  The paper describes:

For example, we mentioned that only the Factory Reset in Settings provides an option to sanitise the primary SD card (Section III-B1). Therefore one might advise users to use Settings rather than Recovery to sanitise devices. Unfortunately, vendor customisations sometimes make Recovery more reliable. For example, the two HTC One series phones in our sample properly sanitised their primary (internal) SD card in Recovery (contrary to AOSP), but not in Settings (as we would expect from the AOSP source code). It is likely that this result holds for many of the other HTC One-series devices. This also violates HTC guidelines: on its website, it suggests its users to first try Settings, and resort to Recovery only "if you can’t turn HTC One [X] on or access settings". HTC has put up a note to discharge itself of any responsibility: "A factory reset may not permanently erase all data from your phone, including personal information".

Turning finally to the external storage, things don't look very pretty their either.
No phone studied properly sanitized an onboard external memory card. [Image Source: Avisian]

The bootloader Factory Reset, and even the in-OS factory reset option also failed to securely wipe the external partition.  This means that even if you use the in-OS option that allows for the sanitization of a secondary SD card (i.e. a microSD card in your external slot), at best the card is wiped with insecure delete commands, allowing a savvy buyer to recover much or all of your data.

IV. A Danger Wealth of Recovered Data

Using these flaws, the researchers were able to recover:
  • User browsing history
  • Message contents ("SMSes, emails, and/or chats from messaging apps")
  • App credentials, including the Google master token 80 percent of the time (the master token secure access to the user's Google accounts, such as Gmail, Play, etc.)
  • Contacts lists
  • Multimedia (pictures, etc.)
(The master token recovery can at least be nullified by revoking former devices' access via the Google Account Manager tools online or on a capable smart device.)

Android peering
[Image Source: Greenbot]

Using these recovered details a malicious user could attempt to blackmail the former owner, or profit at their expense via selling the information online.  In recent years we've heard of a number of incidents of so-called "revenge pornographers" (most famously Hunter Moore) stealing photos and video of teens and young adults off their mobile devices.  

The methodology of this data recovery remains ambiguous, but it's possible that Android's failure to properly sanitize devices has allowed smut peddlers in the wild to troll bins of Factory Reset recycled Android smartphones, looking for juicy gems in the unsanitized partitions.

Revenge porn
The poor sanitization in Android may have helped some so-called "revenge pornographers" obtain their troves of stolen data. [Image Source: PA]

Of course, I'm not suggesting there's any hard evidence that is the case.  It may not be.  The reality is we will likely never know if this is indeed the case as it's hard to ascertain the source of stolen data in the aftermath.  Such ill-gotten private erotica could just as easily have been stolen by other means such as theft from a trusted source, phishing, malware infections, etc.  What I am saying is that if you read the Cambridge paper it's clear that someone like Moore could use simple recovery methods to find erotic private images in Factory Reset Android devices -- especially ones from the Gingerbread era when protections seemed to be the weakest.

V. The Workaround Until a True Fix Arrives

The authors do make it clear that they've shared these results with Google in hopes of promoting improvements/bugfixes.  And they also outline some options that will allow you to secure your device.

The simplest option, which the authors don't explicitly state, but which I will state here is for Android owners to hang onto their device or to physically destroy it when they're done with its use.  Physical destruction might not obstruct more extreme data recovery efforts, but a Factory Reset followed by physical destruction of the device hardware should do the trick nicely unless you have some truly determined enemies.  Just please, use a hammer or other blunt instrument, not your handgun.

physical destruction
Physical destruction following the Factory Reset is one of your best options, if resale is not a necessity. [Image Source: Mike Judge]

Alternatively, if you have root access (not an option to less technical users, perhaps), you can run third party apps post-Factory Reset to "bit-by-bit" overwrite all three partitions (the DataPartition, PrimarySD, and SecondarySD) rendering them unrecoverable.

Aside from the obvious solutions I outline above, that's the only way to secure a device in such a way that you can resell it.

Alternatively a less secure method is to enable full disk encryption (FDE) which was enabled in Android v4.0.x ("ICS"), and which became the default since Android v5.0 ("Lollipop").  

Don't count on Lollipop's default enabling of FDE to fix this mess in all cases.

The problem with this option is a familiar one found elsewhere in the paper -- you're relying on the hope that OEMs haven't compromised the encryption system.  HTC seems to be the worse offender in that regard.  The researchers write:

On one HTC phone running GB (v2.3.x), we found an encryption option, but it left all the data behind. We assume this was a vendor customisation and may only encrypt allocated space. FDE for the internal SD card is not supported on all phones, and not all v4.x devices support FDE on the data partition despite AOSP’s support. As a rule of thumb, only devices with an emulated internal SD card inherit the “encryption support” from the data partition when supported. On supported Android versions, the encryption key is stored encrypted with a key derived from a salt and a user-provided PIN (or password). This encrypted blob is referred to as the “crypto footer” in the AOSP source code.  An attacker who gains access to the crypto footer has enough information to brute-force the user’s PIN offline. The footer is stored in a dedicated partition or in the last 16KB of the data partition – the exact location is configured by vendors through the “encryptable=” option of the Android fstab file. In either case, we found that the footer was not erased after a flawed Factory Reset. Consequently, to logically sanitise a device with encryption, it is essential to select a strong password to thwart offline brute-force attacks. As most people just use a 4-6 digit PIN, it would usually be trivial to brute-force.

However, it's worth adding that the above outlined methodology to subvert the encryption is arguably of a greater degree of complexity versus simple file recovery utility use on unsanitized internal and external storage.  In that regard it may be worth the risk for some less tech savvy users.

Android malware
Don't less malicious buyers of used devices get their paws on your data by trusting the built in methods or using the wrong workarounds. [Image Source: Sin Amigos]

One potential route that the authors recommend not to take is to try to use the remote wipe functionality implemented by various OEMs as a means to sanitize the device.  Typically, the authors note, this will simply use some sort of Factory Reset or worse.  It is unlikely to increase your data security, they note.

VI. The Eternal Debate

Again, it's worth noting that while the paper does draw conclusions relating to Android v4.4 ("KitKat") it doesn't specifically mention Android v5.0 ("Lollipop").  But by the sound of it it's reasonable to expect some of the serious data exposures showcased in the work remain in the latest builds of Android, at least for some devices from some OEMs.

Inevitably this raises a couple of points.  First it raises the perpetual criticism over Google's decision to give OEMs (and phone carriers) the freedom to modify the firmware and core binaries for the smartphone and tablet distributions of Android.  That's a philosophical debate that could go on till the end of time, but suffice it to say that the approach does have some merits.

used smartphones
Data theft is a serious concern for Android users who sell their devices, the paper illustrates.  Users must go to great extremes to guard their legacy data. [Image Source: Blancco]

And it's worth noting that Google has moved to directly take on the ability to update core parts of its operating system, including core apps.  It's unclear whether this will include updating the Factory Reset (at least in the in-OS Setting menu launcher).  But if that's not the case in Lollipop, already, it's very probable that Google may eventually take direct control and ownership of this functionality to protect users.

Google has also been putting pressure on OEMs to release updates in a more timely manner.  The study suggests, though, that Google needs to focus equally on pressuring OEMs to properly and fully merge in the changes from updates, given the numerous botched updates the study dug up.

Ultimately a final, even more thorny and esoteric debate can be found in the fact that security researchers had such ready access to the low-level workings of the Android filesystem.  While some such details are known regarding rival operating systems such as Apple, Inc.'s (AAPL) iOS, information on the low level firmware, including the filesystem implementation nuances, tends to be more outdated and only known among the elite ranks of firmware hackers, such as the jailbreak/unlocking community.

Android OSP

To that end, the foundation of Android -- open source software -- may in some ways have made discovering these serious flaws much easier.  Or to put it differently, similar flaws likely exist in the Factory Reset procedures for Apple's iOS and Microsoft Corp.'s (MSFT) Windows Phone -- we just don't known about them and they're a bit harder to discover, should they lurk in wait in devices given the relative lack of access to root-level data recovery tools for the average iOS or Windows Phone user.

For better or worse there is a certain degree of security through closedness, when it comes to users selling Factory Reset personal devices.  We've seen this trend before when it comes to malware in the real world affecting smartphone users, and we're seeing it again when it comes to the discovery of exploitable data sanitization flaws.

iOS, Android, and Windows Phone
[Image Source:]

On the flip side, Android can take advantage of this opennness and discourse to eliminate these kinds of bugs.  While it's disturbing that potentially hundreds of millions of devices worldwide are now at risk of data theft due to these discoveries, that serious concern should ultimately drive a more proactive and thorough approach to data sanitization during Factory Resets, both at the OEM and the OS provider levels.

In the end, the fruit of Android openness may be an OS that's ultimately better secured and employs better data protection procedures than either Apple or Windows Phone.  But it'll be a somewhat more painful and bumpy road in the months or years to come before that outcome is reached, as this work demonstrates glaringly.

Source: Univ. of Cambridge [PDF]

"We don't know how to make a $500 computer that's not a piece of junk." -- Apple CEO Steve Jobs

Latest Blog Posts

Copyright 2017 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki