

New Vulnerability Found in Apps Using Wi-Fi - mweider
http://bits.blogs.nytimes.com/2013/10/29/new-vulnerability-found-in-apps-using-wi-fi/?hp&_r=0&gwh=C271E3989891B58B303031189CCA2D3F

======
tptacek
No comment on the actual announcement.

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.

------
dsl
_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!

~~~
theboss
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"

------
fulafel
The original article is at [http://www.skycure.com/blog/http-request-
hijacking/](http://www.skycure.com/blog/http-request-hijacking/)

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.

~~~
ZoFreX
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!

~~~
exodust
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.

------
mike-cardwell
Sounds like a plain old fashioned MITM attack to me. Nothing new here.

~~~
bladedtoys
Indeed. And Apple my have been trying prevent apps from being overly
vulnerable from the start: the approval process will reject:

2.7 "Apps that download code in any way or form will be rejected"

2.8 "Apps that install or launch other executable code will be rejected"

~~~
cmgreen
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.

------
gorm
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

More info here [http://www.skycure.com/blog/http-request-
hijacking/](http://www.skycure.com/blog/http-request-hijacking/)

------
deelowe
Is this really worthy of a HN post? This is a pretty basic attack.

------
vaadu
Is this Apple only? The articles do not mention Android.

~~~
bradleyland
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.

~~~
uxp
_The portion that appears to be unique to iOS (maybe it 's not), is the
default cache policy for 301 redirects._

Its in the HTTP spec:

> This response is cacheable unless indicated otherwise.

\-
[http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10...](http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.3.2)

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.

