Always enjoy reading articles like this that describe the process of reverse engineering a particular technology or device.
Also appreciated the mention of the rageagainstthecage exploit which looks like it could be used to enable a "full user data" backup to be made of a device. One of my complaints about Android is that even the "owner" of the device (without rooting & therefore warranty voiding) can't access all their own data files if an application provides no way of doing so.
Of course not. Obfuscation gets you something (it takes few minutes of work to get the key for new Blu Ray releases), but the only secure solution is hardware that melts itself when you give it the wrong password. Even then, things like this have been broken in the past. Given infinite time with access to a device, anything that it is securing will be stolen. (The same goes for physical systems. No safe is completely secure. They even got the gold out of storage in Cryptonomicon eventually!)
The real solution is, "if you have data that's so secure that stealing the phone and running the software on a virtual machine threatens your security, maybe the data should not be on a fucking cell phone".
The main issue I have with this article is that it describes a very implausible circumstance in my opinion. If you have an application with such sensitive information on the phone to warrant this kind of testing, why would you not take advantage of the device administration policies to enforce a password policy and a password timeout policy?
There doesn't seem to be a policy in the current API docs to prevent a user from enabling USB debugging, but there is a rather large warning when that option is selected.
Without USB debugging and using a password policy, the author's strategy would not have worked. With the current strategy, this has nothing to do with Android, and everything to do with having poorly designed and poorly implemented security on the part of the application author.
The software under test is designed to allow employees to use their personal phones for corporate use. Being a personal phone, corporate policies are irrelevant because we cannot apply or enforce them. The software is in use by some very large companies and being evaluated by others therefore it is far from implausible that some of those personal phones haven't got a device lock code set.
I agree it is not an Android issue though, it is the poor design of the app.
A more common policy in my experience is that any phone that has any company data on it must be company-managed. In other words, you pay for it but the company really owns it.
@Thomas, thanks for the clarification, I guess I'm just used to companies with more authoritarian policies. Something along the lines of: "If it connects to our infrastructure, it gets policies enforced" (similar to what WMF said).
Yes that is my experience as well and is the case where I work. This seems to be changing as more tech-savvy staff with highly capable devices push their companies to "get with the times". So I guess that is why we're there to point out the risks in doing so. Doing this was partly fun, and partly so we could backup any statements we made about the risks of doing it.
Anyway, glad people enjoyed it. It's good to get some discussion going too. Thanks =D
Very interesting and in depth article, thank you very much for posting it.
Does anyone know why android chose not to use LSM or other kernel based capability enforcement? It would seem like such a hands off platform would be ideal for fine grained enforcement - allowing some amount of security to be maintained even in light of a privilege escalation exploit.
Also appreciated the mention of the rageagainstthecage exploit which looks like it could be used to enable a "full user data" backup to be made of a device. One of my complaints about Android is that even the "owner" of the device (without rooting & therefore warranty voiding) can't access all their own data files if an application provides no way of doing so.