This actually applies to most HTC handsets, heck, maybe most phones, but this is the Dream forum and I wanted to talk about the Dream (since I own one). I actually had realized this the day I first rooted my phone, but it had been on the back of my mind until today when I ported MCR 2.6 for the Dream and saw the laughable WaveSecure app. I then thought about posting this general warning for Dream users and hopefully we can brainstorm and bring this big security hole to an end.
WaveSecure is an app that runs as a high priority process in your phone and it can do silly things such as disallow the usage of the device or access to the data on it by placing a locking screen on your phone. To enable your phone back, you enter a pin. Does that sound familiar? Ofcourse, your phone already has a lockscreen. The app also has a few backup and restore features, but nothing that hasn't been done before. Probably the only worthwhile feature is the ability to lock your phone remotely (but then the lockscreen was already active anyway).
Our rooted phones are different than stock ones, though. If you lose your phone and a knowledgeable person gets a hold of it, all they have to do is reset the phone, hold Home and Red, and voila, they have access to ALL your personal data inside your phone. I'm not only talking about the SDCard here, because accessing that data is so stupidly simple, but your phone writes enormous amounts of personal data to /data. There you can find account logins for all your installed apps, contacts info, you can find browser cache info and if you do your banking on your phone's Browser and have cookies set, well, they're all there. I've looked through several of the files in /data and most things there are dumped in human readable format, so a crook wouldn't even have to try very hard. I found my home's wifi hidden SSID AND 22 character lenght alphanumerical WAP2 encryption key in a file, and both were labeled as such .
One solution I see is easy, modify recovery to give you an option to prompt for password on start. But there's still the fact that, with the device on, we can still adb remount and then adb pull /data, so the adb binary would also have to be re-written for this purpose.
There's still yet another problem, though. Fastboot... Most of us are running a flavor of an Engineering SPL (either Death SPL or Hard SPL), and even if we block /recovery and /system, a crook can still fastboot flash boot and fastboot flash system and with a minimal booting image (no android runtime, only enough in /bin to boot a linux system) he can still get adb pull /data access.
That's where I'm at a loss, though. How do we patch SPL to prevent unauthorized usage? Are there any other security gaps I might have missed?
Comment, discuss, develop.
I'm confused. Wiping clears out the /data partition. Where are you getting all this data from post-wipe?
And that's exactly why I carry my important data safely with me. Wipe clears out the /data partition as much as "Emptying the Recycle Bin" erases deleted data in Windows.... meaning, it's still there. Although flash memory is better at deleting data, it can still be easily recovered, but then again, how are you supposed to wipe if you don't have the phone with you. I didn't see anything about remote wipe. Also, any person with two neurons firing would think right away about removing the battery and SIM before attempting anything.
Also, so let's say a wipe did clear /data entirely and you were able to remotely wipe EVERY SINGLE TIME the phone was lost or stolen (I once went a week without realizing I had lost my phone, paying that kind of bill and talking to Customer Service for hours on end is no fun), it still doesn't mean that the security gaps are not there. I still think they should be fixed, even if to foil people not interested in the data at all but on using the phone for their own. Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?
Oh, I see what you meant XD. Edited my post.
I've noticed this too, but the safest way to secure it is to have android encrypt the files as they are put on the data partition. Even then, that data is still unsecure. We should file an issue with the google code page for android and have them worry about it
Well, this has actually been considered...
For 'droid 1.6: From the home screen, Menu --> Settings --> Security --> "Use secure credentials". It is, of course, up to the application to make use of secure credentials. This is something that you should question the developers of secure applications about.
Other times, you may note that applications like "Password safe" will password protect and encrypt their data sets.
So it is definitely up to you to ensure that the applications that you use are written with security in mind.
Now for your home wifi password... does that really matter that much? They have to actually be IN (or very near to) your home to make use of it.
B-man007 said:
I've noticed this too, but the safest way to secure it is to have android encrypt the files as they are put on the data partition. Even then, that data is still unsecure. We should file an issue with the google code page for android and have them worry about it
Click to expand...
Click to collapse
No device can be more secure than being encrypted (assuming use of strong encryption). There is most definitely NO WAY EXCEPT encryption to secure your data.
I guarantee that EVEN WITH a no-root recovery partition and a no-fastboot bootloader that enforces system image signatures, that the data on the device *CAN STILL* be read off it.
It is definitely impossible to secure these devices against being read through something like jtag. And if it is read through jtag, the only thing that can possibly protect your data is encryption.
is it possible to do a complete wipe of the device? i know its not permanent but i figure if i quit banking online after i wipe the phone then i am no longer succeptible to that form of theft
I bet this is making some people that sold their rooted G1's nervous right now lol
this is the same issue blackberry users have, , even with a remote wipe ,there was concern that data can still be retrieved. That's also why the secret service is so concerned about the president having and using one daily, if its ever lost or stolen, ,,well you know, ,,
So rooted or not android is not the only platform with this issue. .
I would like to address this
"Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?"
Did you know if you called any cellphone carrier that you have and told them your phone was lost/stolen they will put the IMEI or ESN on the lost/stolen list, and then it can no longer be active on their network and from what I hear any other networks.
card13 said:
I would like to address this
"Don't you hate it when people find phones on the street, and instead of trying to return it they take it to their nearest mom & pop phone shop and have it unlocked, etc?"
Did you know if you called any cellphone carrier that you have and told them your phone was lost/stolen they will put the IMEI or ESN on the lost/stolen list, and then it can no longer be active on their network and from what I hear any other networks.
Click to expand...
Click to collapse
Depends on where you are, here in Canada, if it gets blacklisted by Rogers, it will still work on Fido (which happens to be owned by rogers).
There is also the possibility of rewriting the IMEI. Not exactly a major difficulty.
I have an idea. Since that, if someone gets hold of your phone physically, there's no way that he/she will be restricted from accessing the data, unless it's encrypted properly.
Therefore, to enhance the security, the data (or at least, /data) should be encrypted all time. I'm not familiar with Linux so I have no idea if it's doable or not, but that's a start.
That way, even if someone gets hold of your phone, and flash/hack/cheat all kinds of things, fastboot, recovery, adb... He/she will still be unable to access your data.
To do this, the bootloader (or the init script?) needs to implement a way to unlock the data.
To further increase the security, remote shutdown and wipe should be implemented as well.
Remote lock will NOT work because, while a phone is locked, it means it's running, and the data is already unencrypted at that point, and while I don't have much knowledge in hacking. I think a serious-enough person can hack the phone and get the data.
Of course, this still doesn't solve the problem that, if you, or your family member, is being held at gunpoint.
Just my 2 cents.
1) No changes to bootloader. Bootloader is not relevant to encrypted /data. The changes would be to add in the appropriate encryption scheme to the kernel. Also, to mount the /data partition using the selected encryption method, and to prompt at the appropriate time (mount time) for password. This would be DURING BOOT.
2) The reason you don't want to do this is that d/encryption eats CPU and memory.
bug666 said:
I have an idea. Since that, if someone gets hold of your phone physically, there's no way that he/she will be restricted from accessing the data, unless it's encrypted properly.
Therefore, to enhance the security, the data (or at least, /data) should be encrypted all time. I'm not familiar with Linux so I have no idea if it's doable or not, but that's a start.
That way, even if someone gets hold of your phone, and flash/hack/cheat all kinds of things, fastboot, recovery, adb... He/she will still be unable to access your data.
To do this, the bootloader (or the init script?) needs to implement a way to unlock the data.
To further increase the security, remote shutdown and wipe should be implemented as well.
Remote lock will NOT work because, while a phone is locked, it means it's running, and the data is already unencrypted at that point, and while I don't have much knowledge in hacking. I think a serious-enough person can hack the phone and get the data.
Of course, this still doesn't solve the problem that, if you, or your family member, is being held at gunpoint.
Just my 2 cents.
Click to expand...
Click to collapse
lbcoder said:
1) No changes to bootloader. Bootloader is not relevant to encrypted /data. The changes would be to add in the appropriate encryption scheme to the kernel. Also, to mount the /data partition using the selected encryption method, and to prompt at the appropriate time (mount time) for password. This would be DURING BOOT.
Click to expand...
Click to collapse
So that's the init scripts?
lbcoder said:
2) The reason you don't want to do this is that d/encryption eats CPU and memory.
Click to expand...
Click to collapse
And battery, may I add?
To what extent is the question, I don't think it's a must-have feature for everybody, but think some may be willing to put up with the trade off...?
bug666 said:
So that's the init scripts?
Click to expand...
Click to collapse
Mainly kernel, but yes, some adjustment would have to be made to the init.
And battery, may I add?
Click to expand...
Click to collapse
Certainly. Anything that eats CPU eats batter.
To what extent is the question, I don't think it's a must-have feature for everybody, but think some may be willing to put up with the trade off...?
Click to expand...
Click to collapse
A better implementation would be to encrypt *some* data, i.e. application home directories, but specifically NOT the ~/lib directory. Because really, do you CARE if your APK's or dalvik cache are encrypted or not? This would minimize the performance impact (to negligible) while providing the desired data security.
Also, encryption on a per-application basis would allow this to be done withOUT having to pause bootup to ask for a password... it could be done more intelligently on first-access-attempt.
Anybody tried using Walkie Vault (http://www.walkie-vault.com/)...? Can it encrypt the data/home folder...?
A system-wide usable encryption system that different apps may make use of is a good idea, but is it on Android's agenda yet...?
It hasn't quite entered the collective consciousness that the connected smartphone, as configured today and if logged into online services, is the ultimate personal identity device. Unlike other personal effects we keep on us at all times (id cards, keys), a Google login gives a thief potentially a treasure trove of data to exploit without requiring any further identification to the phone other than the lock screen (assuming the user has set one). Once it becomes a big enough issue we may see solutions such as:
- Built in biometric identification (fingerprint scan, iris scan) replaces lock screen.
- OS framework requires apps storing sensitive user data to store into encrypted databases, authenticated from above biometric keys.
- Carriers, digital identity providers (e.g. Google, MSN) providing remote wipe as free standard services and accessible over the phone, not just a web page.
No computer is 100% secure.
Biometrics are often easy to fool.
3 of the fingerprint scanners I have encountered were easily by-passed with a pencil, and a rubber glove. Not to say they are all like that, but some are super simple to get around. Myth busters bypassed one with a photo copier and a sharpie. My buddy bought one super cheap, and put it on his wife's computer to make her feel safer. We bypassed it by breathing on it. (it was super cheap)
The current "Lock" on the G1 is like that super cheap biometric scanner. Your fingers leave behind oils. Oils are what leave the marks on the screen. Breathe hot air on the screen and you can see the pattern of the lock sequence. Some lock.
Note to self: remember to wipe off screen everytime you unlock phone.
I think that the best way around this is to remove all the data from the phone in the first place. For several years now I have been telling my friends that google's ultimate goal will be server side data storage that you log into to use.
The world of cell phones is headed this direction as well.
Google voice, Google Chrome, Google Docs, Cloud....all operate under the idea that you connect to the data, manipulate it, save it, then (ideally) your device forgets it was there.
If you want to stop cell phone theft, you have to hard code the phone to accept only one set of data, and any attempt to change that data in a way not prescribed by the phone will result in the destruction of the data and the usability of the phone. Not real cost effective for a device that lasts on the average of 18 months.
Another option is to make a daily use phone. Only good for 24 hours. Then you have to get a new one. Make them cheap, and disposable.
Common users would freak out over having to back up the data all the time, or you would need a uplink storage location like...oh say Google voice, Google Chrome, Google Docs, Cloud.
The average consumer has no clue what that thing in their hand is capable of doing, storing, or tracking. The techno geek is the problem and much like ROM's, what stops a Techno geek today, won't necessarily stop him tomorrow.
In the mean time, wave secure at least offers you the satisfaction of telling you when someone has put a different sim in your phone.
And it will scare the crap out of someone when they pull out the sim card. it is very loud!
But I agree the android system needs a better lock.
Maybe a mod could be prepared to separate /data into a cryptfs system, only trouble is that to make it secure a start/unlock password would need to be entered.
In light of the recent kerfuffle between the government and Apple, I have a purely technical question (not looking for opinions) on 6P/Marshmallow encryption.
1) How does the actual encryption compare to Apple's (latest)?
2) Is it possible (within reason and with current technology) to be broken? (I know that theoretically ANYTHING can be broken, just asking if it would be practical (e.g. not take 100 years).
3) In there anything either Google or Huawei could do to assist the government in hacking a 6P/Marshmallow?
4) Is there any addon that would give the capability of n-wrong attempts/erase as in Apple. If so, would it require root?
Apple is being asked to provide a method to allow a brute force attack. Having a really strong password is a good way to prevent such an attack. And the 6P's fingerprint scanner makes a strong password doable, without the inconvenience usually associated with it.
After 10 incorrect entries, Android will make you wait 30 seconds after each attempt, which makes it a slow, arduous process. I don't have the patience to determine if there is a point in this process where data is automatically wiped from the phone.
Of course you can always use ADM to wipe your phone remotely if your phone is still connected.
Actually, (and I'm just speaking technically, not making political/moral judgements), fingerprint encryption does NOT stop the government from decrypting your phone. You can be legally compelled to swipe your finger (but NOT to provide your own password), and your fingerprint can be used even if you're dead.
Solutions Etcetera said:
Apple is being asked to provide a method to allow a brute force attack. Having a really strong password is a good way to prevent such an attack. And the 6P's fingerprint scanner makes a strong password doable, without the inconvenience usually associated with it.
After 10 incorrect entries, Android will make you wait 30 seconds after each attempt, which makes it a slow, arduous process. I don't have the patience to determine if there is a point in this process where data is automatically wiped from the phone.
Of course you can always use ADM to wipe your phone remotely if your phone is still connected.
Click to expand...
Click to collapse
l_stevens said:
Actually, (and I'm just speaking technically, not making political/moral judgements), fingerprint encryption does NOT stop the government from decrypting your phone. You can be legally compelled to swipe your finger (but NOT to provide your own password), and your fingerprint can be used even if you're dead.
Click to expand...
Click to collapse
Assuming they have your finger, that's all true. But turning the phone off will still require your pin/pattern/password to decrypt it.
IIRC, Android does not automatically wipe your phone, but enough attempts will put it into a state where no more attempts can be made. At that point, additional account credentials are required, or an FDR is necessary.
I also know first hand, that resetting a phone from recovery will not allow a phone to be used without account credentials.
Great information. Big thanks given!
Since Android is "Open Source", would it be feasible for someone to remove the delay to enable a brute force attack? In any case, Google could do it if ordered.
So, assuming a brute force attack occurs (delay removed), how easy to break the encryption set by a pattern (and is there anything else Google to do in addition to removing the delay to help decrypt)?
Solutions Etcetera said:
Assuming they have your finger, that's all true. But turning the phone off will still require your pin/pattern/password to decrypt it.
IIRC, Android does not automatically wipe your phone, but enough attempts will put it into a state where no more attempts can be made. At that point, additional account credentials are required, or an FDR is necessary.
I also know first hand, that resetting a phone from recovery will not allow a phone to be used without account credentials.
Click to expand...
Click to collapse
l_stevens said:
Great information. Big thanks given!
Since Android is "Open Source", would it be feasible for someone to remove the delay to enable a brute force attack? In any case, Google could do it if ordered.
So, assuming a brute force attack occurs (delay removed), how easy to break the encryption set by a pattern (and is there anything else Google to do in addition to removing the delay to help decrypt)?
Click to expand...
Click to collapse
On an unrooted phone with a locked bootloader, the only way to modify the system would be to unlock and root, which would wipe the phone.
Does Marshmallow use 256-bit AES encryption?
That about pattern lock? Is it the equivalent of a 4 digit passcode (or 6 or 8...)?
l_stevens said:
Does Marshmallow use 256-bit AES encryption?
That about pattern lock? Is it the equivalent of a 4 digit passcode (or 6 or 8...)?
Click to expand...
Click to collapse
https://source.android.com/security/encryption/
128 bit.
Sent from my Nexus 5X using Tapatalk
Solutions Etcetera said:
On an unrooted phone with a locked bootloader, the only way to modify the system would be to unlock and root, which would wipe the phone.
Click to expand...
Click to collapse
Google could create an special signed OTA update zip file and side load it to the device in Recovery without having to oem unlock the bootloader. This special OTA would allow for brute force unlocks.
SpookyTunes said:
Google could create an special signed OTA update
Click to expand...
Click to collapse
I suppose. But given Google's stance on the issue, I doubt that is any more likely to happen than with Apple.
SpookyTunes said:
Google could create an special signed OTA update zip file and side load it to the device in Recovery without having to oem unlock the bootloader. This special OTA would allow for brute force unlocks.
Click to expand...
Click to collapse
You have to unlock the phone to authorize the computer you're using to be able to connect to adb, correct? I could have sworn this needed to be done before you could adb sideload. Perhaps I'm incorrect.
At any rate, this is a fantastic reason why you should never leave your bootloader unlocked, unless you don't care if someone can have an easier time stealing your data.
Sent from a 128th Legion Stormtrooper 6P