Uncovering Android Master Key That Makes 99% of Devices Vulnerable
bluebox.com
bluebox.com
* The zip format doesn't structurally guarantee uniqueness of names in file entries. If the APK signature verification chooses the first matching file entry for a given name, and unpacking chooses the last then you're screwed in the way described.
* The JAR signing scheme signs a file containing hashes of file name/data hash pairs. However, there seems no part of the verification steps (in the JAR specification) where extra files not mentioned in the signed data cause signature rejection. This seems like a bad idea.
From the description, though, it sounds like a key management problem. Anyway, this talk is definitely on my Blackhat schedule!
I was approached about buying two different Android 0days related to APK signing about 3 months ago, so definitely some issues to be found. The seller wanted unrealistic terms, so I never got full details.
As far as I can tell, these concerns shouldn't be the cause. It enumerates through all entries in the jar, regardless of duplicate names.
To me, it seems like someone would have to side-load an application. Anything coming from the Play store should be safe?
Then I go to paypal, forgot password, get email, gain account access, ruin your life.
Not sure how plausible any of this is, I'd have to be a really dedicated hacker to set all that up. But it's all possible.
Also, never ever ever EVER connect to open wi-fi.
Pfff. I could get mugged walking down the street too, but I still carry my wallet and keys around. And yes, I have been the target of some robbery attempts in the past.
Protip: I've had my paypal account hijacked before, that isn't very fun to deal with
I'm happy enough using open wifi to read the news or check train times. I kinda rely on gmail "getting SSL right" so that if my mail checks while I'm doing that I'm still OK. I wouldn't log in to my internet banking or PayPal on open wifi. I know I'm leaving myself open to "forgetting" and accidentally using and open wifi connection for a sensitive transaction/login, but for me the probability of me forgetting multiplied by the probability of any particular open wifi being malicious is "low enough" that I'm happy to accept the consequences.
Be aware the open wifi has risks. Take suitable precautions. Use them if it's useful - but modify your behaviour to minimise the risks. But if you just want to check the news or the weather or the bus schedule, someone saying "never connect to open wifi" is probably not giving or taking into account appropriate context.
This is why you secure your damn wifi. Even if the password and user are on the wall, the traffic is still encrypted!
So just because its WPA2 doesnt make it magically safe from tampering.
And usually a coffeshop that has WPA2 will still have admin/admin as their router credentials, if you are lucky they have Linux and from there you have # and can use iptables to divert traffic to your device as you wish.
I believe there is ample opportunity to sell a "secure wifi box" with some kind of fanless linux/*bsd-box with a (more) secure access point in it than what most ISPs currently deliver. Throw in a caching, ad-blocking proxy... (Alternative business plan: give the boxes away, sell ads based on location -- (re)placing ads in web content...).
I'm kind-of forced to use a WEP connection right now, which is pretty much equivalent to open wi-fi since is can be cracked in a matter of minutes.
However I use HTTPS-Everywhere, and GMail & other websites run on https by default. So my question is: is HTTPS over open wi-fi trustworthy?
Also, don't underestimate the power of e.g. sslstrip. Most users enter "google.com", not "https://google.com". If you're not careful, somebody will just remove all the SSL links on your pages, or lead you to another domain with a valid one, via DNS or HTTP redirects.
I wonder if that's true?
At a high enough stakes game - one would have to assume that state level actors have already trivially compromised both - the NSA clearly has pretty much 100% compliance from Verizon, and I don't think its going out on a limb to assume they've got similar compliance from at least one of (and possibly all of) the US based CAs. Egypt at a state level have been seen using fraudulent SSL certs - and you'd be foolish to assume there isn't equivalent CA access available to any government who has a root CA authority under their jurisdiction.
But that's kind of a moot point - if the NSA is targeting me individually, I have to assume they'll gain access to pretty much everything - even if I strongly encrypt everything (and don't ever make a mistake doing so), many of the intended recipients of my communication are in jurisdictions where they've got enough power that wouldn't be able to resist the NSA's demands to reveal the unencrypted contents. (If they can ground head-of-states private planes in various European countries, there are probably very few places they cant "lean on" someone strongly enough to make it a not-very-difficult question about whether to give up my personal data.) "Lesser" state level actors - GCHQ, or ASIO here in .au for example - might not have quite such god-like global power, but I'm under no delusion about the privacy protection I've got against the "feeble compared to the NSA" local government intelligence organisation of whatever country I happen to be in, if it takes a personal interest in me.
At the attack levels lower down though - carders, identity thieves, the generic "internet fraud" level attacker - I suspect ISPs are significantly more likely to be compromised than CAs - or at least the important part of the CA infrastructure that holds the root signing keys. I'd guess typical ISP infrastructure is not as well secured as typical CA root keys - and that zerodays, unpatched known vulnerabilities, and rogue/disgruntled/underpaid sysadmins in small (and perhaps even large) ISPs represent a much higher risk than non-state-level attacks via stolen CA keys.
HTTPS is only good when you know what you're connecting to.
"This is probably not the site you are looking for!"
London Underground have partnered with a variety of commercial providers to offer free wifi at Underground and Overground stations. At least one of those providers forcibly redirects all traffic to plain http to show some "welcome" page, and won't let you use ssl at all.
So users might get surprised once, see that the page they get finally get to is an official looking page, and then just shrug and continue.
(which in this specific situation also creates the perfect setup for MITM'ing people without even have to go through the trouble of a cert: A portable base station, a higher powered antenna, a little setup to fake the same setup with a copy of their page, and voila you have a bunch of commuters happily tolerating surfing without SSL to get their free wifi while you intercept all their traffic)
Is there any semi-standard way to do pinning? That is/will be supported by at least the next (preferably current) version of the major browsers?
Or do you mean "manual" pinning (eg: convergence et al)?
I'm no aware of anything a site administrator can do to unilaterally enable/force certificate pinning?
The best I could find was:
https://www.owasp.org/index.php/Certificate_and_Public_Key_Pinning
https://tools.ietf.org/html/draft-ietf-websec-key-pinning-06...
1.) Not vulnerable to any CSRF flaws
2.) Uses Strict-Transport-Security
3.) Uses cookies with the "secure" flag set
So it's best to use a trusted network if the HTTPS site you're accessing has CSRF flaws. That was my point.
As trustworthy as it is otherwise, so generally yes.
Since Android supported arbitrary VPNs (as of ICS) I use OpenVPN to home on my tablet (as I always did with my netbook) - that way I should be no more unsafe, even for unencrypted protocols, than if I were sat at my desk. It does add latency of course, which in less than ideal conditions (an iffy 3G/GPRS connection) affects throughput too (on top of the small amount of packed wrapping overhead in the VPN protocol itself), but I've not found that to be noticeable for my use pattern.
However, to your ending comment, some time back I asked whether passwords actually gave you security from other people who know the same password (e.g. a coffee shop that has a big sign telling you the WPA password). While I have zero knowledge to confirm or deny this, someone in the know claimed that no, given that the wifi password is used for the initial key exchange, it offers superficial interception/monitoring protection against someone malicious who knows the same password. Take that with a grain of salt, but I never could find other resources on that.
The password is your access to the network, not the encryption key for your messages.
The second responded to the comment about never using open wifi networks, where I took open to mean unencrypted. My comment is that open and encrypted networks are synonymous (or so I have been told) if the person who wants to capture your traffic knows the network password.
Which loops back to the first point, that you should only use encrypted services on networks you don't have full faith in.
It is "safe" to not use transport security for the actual file download since the signatures are verified before install.
Edit: the hash checking is done in addition to the APK signature verification, i.e. you can not replace the APK with a different APK signed with the same developer key.
Apparently the Play store has hosted malware apps in the past...
Does this mean that if I don't install any rogue app store, that I'm safe against the attack which allows forging signatures?
android.permission.INSTALL_PACKAGES controls which of the in-flash applications may install stuff: it's not available to non-built-in applications at all, and the Amazon store doesn't have (or need) it.
Presumably it is easy for any individual app store to filter for apps with duplicate cryptographic signatures but different content. But if someone could find an app and a spoofable signer that is present on one store but not another, they could submit an altered app under a spoofed name on the store that lacks the app. Spoofing privileged signers would hopefully be difficult on the Play store, but might be possible elsewhere.
This is one reason why you'd have to be crazy to pirate a keyboard app for instance.
(It doesn't sound too far fetched to me, since we know that the NSA has even installed hardware at companies like Google.)
where did you find that? I thought all the big companies say they don't have anything installed by NSA, but that NSA can ask for data
http://gigaom.com/2013/06/29/new-prism-slides-say-the-progra...
I think about how manufacturers drag their feet on normal updates and can't imagine what heaven and earth movement would be required to patch this industry wide.
Then again, maybe the attack surface for this is small enough that it's manageable.
http://www.darkreading.com/vulnerability/google-sets-new-agg...
They do release security updates. (Or at least used to -- I haven't paid attention lately.)
The major upgrades change and break lots of shit for them. A backported security update generally does not.
The story also says that this hack could be used to send text messages and other communications. In the wrong hands this could be a devastating financial and social exploit.
This is a major blow to essential system of Android security system, the core functionality is broken the consequences can be massive not to mention it will never be fixed on old devices.
In the PC world, authenticode on executables does not really offer that much security: Any malware can be signed and you normally don't verify the signature of applications.
And with Android: Just because APKs could be forged, what exactly is the attack vector? If sideloading is not enabled, and the play store uses HTTPS, how would such an forged APK with an stolen signature get placed on your device? Could other apps modify the APK of another app? Doesn't each app have it's own Linux userid and aren't there access restrictions? How would some random game go and write into the APK of an app with high privileges in order to inject code? If that were possible, there would already be DOS like attacks: One game destroying the APK of a competing game, etc.
I'd really like to know the attack vector!
No, you can't actually go poking into other apps' apks but how many people would press "update" if they see the package manager's "Installing Gallery update, no permissions required" dialog?
The user has to install a pirated APK. Also Play store is SSL secured. Just use common sense.
The more interesting question is when / how will Amazon (and other reputable app stores) deal with the issue.
1. Apps like Skype already allow themselves access to so much sensitive and private information and things like the Motorola spyware uncovered recently (https://news.ycombinator.com/item?id=5973282 ) are so bad that I find the extra evilness possible with root access not so significant. What amount of additional harm would it really be? Intercepting network traffic? Better hidden rootkit that even hides from the few users who have jailbroken their phone?
2. The Linux kernel regularly has security bugs and we know that Android phone manufactures don't update devices timely or at all. Wouldn't every Android phone not have at least one exploit for the kernel itself at any given point in time? Where are the apps that just use this to gain root access? Or has Google hardened the kernel well enough that there are no known exploits by which an APK with native code doing syscalls can increase it's privileges?
And at what point do we stop calling these sorts of problems "vulnerabilities" and start calling them surrepitious "back doors"?
If it's possible use this vulnerability to arbitrarily rewrite the contents of any or all of the APKs loaded onto a given phone, then this flaw allows for the ability to engage in a key behavior that makes rooting Android popular: Disabling all of the unwanted bloatware that device manufacturers usually prevent you from deleting.
"Installation of a Trojan application from the device manufacturer"
Ok, so the manufacturer of the device is shipping a trojan on my device. Isn't there a bigger problem in this situation?
Then after a week or so, it wakes up and downloads its payload which with it can modify itself, transforming itself to seemingly be the Gmail app you are so often using, while moving the real gmail away. Then you continue using and updating "gmail" like you normally would, except you know, its now using a proxy and no ssl.