Those clauses are to prevent the application from downloading code that is not reviewed. Blocking HTTP requests and requiring HTTPS requests would block several categories of legit applications but it would be nice to have them explained.
This is just a little enhancement for the the usual non-tls http mitm on shared media. They use a 301 moved permanently code, making some http clients cache the new attacker-controllled url for a little longer after the active attack stops.
That is a very nice little enhancement though. If the app trusts the cache headers, this widens the scope from "your use of this app is compromised while on the rogue AP" to "your use of this app is compromised wherever you connect from once you've used it on this rogue AP". That's a non-trivial difference!
I agree it sounds like a non-trivial difference. An app could present new information over time, to fool the user into clicking on an external link in the app. The victim is now on the attacker's website, which suits the attacker more than trying to manipulate the app.
facepalm Security company learns that HTTP MITM + cache poisoning is a thing that exists. (Edit: If it wasn't obvious, 301's are a common and well known form of cache poisoning in this scenario)
Next I bet they will discover that you can pretend to be anyone you want in e-mail!
Yeah, I does sound like that but it also says persistently DNS poisoning or ARP poisoning isn't very persistent. So there COULD be something here...but I don't think so
In my experience, most mobile apps use cert pinning or regular ol https. Only a few that I have seen actually use http.
The biggest thing mobile apps do is client-side checks instead of server-side, since an assumption of network connectivity can't be made. It's pretty funny the types of things you'll find. Anyways...
edit: Oh wow. I watched the video. That's embarrassing. "We haven't done a responsible disclosure because everyone knows HTTP is just like that"
> On Tuesday, mobile security researchers will demonstrate a simple attack that exploits a vulnerability in the code within apps that run on Apple’s iOS operating system.
This vulnerability is pretty much OS-independent, and also ancient. Summary: "We have discovered that HTTP is insecure, also, we have discovered the 301 redirect; for this, we are expecting a nomination for the Nobel Prize, at the very least."
It might be. This is a compound attack. The attack makes a couple of assumptions that are dangerous for both iOS and Android:
1) The app communication is using HTTP.
2) The attacker has some means of executing a MITM (man-in-the-middle) attack.
The portion that appears to be unique to iOS (maybe it's not), is the default cache policy for 301 redirects. Specifically, once the attacker has targeted some HTTP traffic, they use the MITM attack to redirect iOS to the attacker's server instead of the intended one. The default cache policy on iOS makes this redirect more or less permanent. That's bad because once you leave the compromised network, your phone will continue to talk to the attacker's server instead of the intended one.
The reason this exploit is seeing such an apathetic response is because the cache poisoning is pretty lame in comparison to having executed a MITM scenario. Once you have MITM, you have complete control over the traffic a device receives. For HTTP communications, this is not specific to iOS devices.
The best mitigation for MITM attacks is to simply use HTTPS instead of HTTP. Unfortunately, it's not easy for iOS users to see whether an app is using secure back-end communications.
I'm fairly certain without doing any research whatsoever, that most every browser on most every platform is vulnerable to this attack. It is literally a DNS cache poisoning and MITM. Nothing more. The difference with a mobile platform is you're dealing with apps that don't have a URL bar to tell you that you've actually on qwerty.info/paypal instead of paypal.com, which is an indicator of an attack.
However, this is a good opportunity to point out that if you're building an iOS or Android app, you should not only use TLS for all your connections, but also pin your certificates and only confirm a connection after validating that certificate.
There aren't many good reasons why a mobile app should need to depend on the CA system for security. In fact, in a mobile setting, if you're willing to create a separate API endpoint for your app, you can replace the CA system entirely; just create your own CA, sign your own certs, and ship your app with your own root certificate.
I was at their presentation earlier today. Maybe not a big thing, but I liked their conclusion. they demonstrated a mitm-proxy that gave 301s so that ignorant native apps loaded and cached external trusted resources. They also mentioned using malicious iphone profiles with new certificates or configured proxy. Demoed also using faked captive network, maybe also with pineapple/wifigate
Thy also claimed many apps had this vulnerability. They also said it was easy to fix. Think about caching in native clients, and ignore 301s in native apps. They didn't mention 302s
reply