

iOS apps can be hijacked to show fraudulent content and intercept data - trauco
http://arstechnica.com/security/2013/10/ios-apps-can-be-hijacked-to-show-fraudulent-content-and-intercept-data/

======
lstamour
Sooo... the news here is that Apple's caching framework works and apps that
don't care about connecting to the right remote service (aka apps that don't
use SSL) can be hijacked with MITM. This is ... news?

I mean, I'd love to see more apps capable not only of SSL but certificate
pinning, binary data transfer, and more.

Besides we all know in-app communication is low-hanging fruit for security
researchers, even with otherwise secure apps. Twitter's hard-coded OAuth token
with unlimited usage comes to mind, for example. It's not that the apps
themselves aren't "secure enough" but that once you remove the restrictive
nature of the browser as sandbox with an exposed address bar, apps can get up
to some funny business seemingly out of sight.

A useful reminder, to be sure, but it must be a slow news day for this to get
so many up votes.

~~~
lstamour
I am reminded also of Siri hacks from 2011:
[http://hackaday.com/2011/11/21/siri-proxy-adds-tons-of-
funct...](http://hackaday.com/2011/11/21/siri-proxy-adds-tons-of-
functionality-doesnt-require-a-jailbreak/)

Oh and the original article mentions creating a certificate profile to install
a custom SSL cert. That same technique can be used to MITM Apple's own
iMessage system, since iMessage doesn't use certificate pinning:
[http://www.tripwire.com/state-of-security/top-security-
stori...](http://www.tripwire.com/state-of-security/top-security-
stories/apple-imessage-vulnerable-eavesdropping-mitm-attacks/)

Though the more "iPhone security vulnerability" stories you hear, it just
comes down to fundamental principles. I'd be more worried from a security
perspective that jailbreakers still say iOS 7.0.3 is vulnerable.

~~~
jevinskie
Really interesting that iMessage doesn't use certificate pinning. Try as I
might, I was unable to MITM iTunes store connections thanks to certificate
pinning.

~~~
lstamour
Yes, I tried to use Charles Web Proxy to achieve a similar MITMing and was
unable to. Good job with the credit card data, Apple! :)

------
gfodor
"unencrypted TCP/IP connections are susceptible to man in the middle attacks"

there, I just saved you from reading the article, and you probably learned
more anyway.

~~~
cookingrobot
This is not a fair dismissal of the issue. This says that man-in-the-middle
attacks that occur on unsecured wifi networks will stay active after you move
to a trusted network. And the safeguard of an addressbar showing where content
is coming from isn't available when using apps.

------
valleyer
Man, what a spammy headline. This has very little to do with iOS in
particular.

I've seen this before from Goodin and Ars Technica. What a shame.

~~~
cookingrobot
It's a study of how many apps in the iTunes Store are probably vulnerable.
It's not a study of other app stores. That's why it's about iOS.

------
peter_l_downs

        > The weakness, dubbed HTTP request hijacking (HRH), is 
        > estimated to affect at least 10,000 titles in Apple's 
        > App Store.
    

I hate reading numbers like this. How did they arrive at 10,000? It's very
easy to "estimate" by making up a number.

~~~
sitharus
I assume it's a similar method to how I estimate project completion dates

------
yardie
Original headline: "Apps using unencrypted HTTP are insecure"

Editor meeting: "Can you spin this into an Apple story. It will be great for
clickthrough rates."

New headline: "iOS apps can be hijacked to show fraudulent content and
intercept data"

------
wallflower
The remediation points mentioned in the blog are interesting.

"Make sure the app interacts with its designated server(s) via an encrypted
protocol (e.g., HTTPS, instead of HTTP). As described earlier in the post,
this is an effective mitigation for HRH, but not a fix."

but not a fix?

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

~~~
bradleyland
Yeah, that bugged the hell out of me as well. I'm not sure what the authors
expect the iOS caching framework to do? It sounds like they would like to see
a different default, so that if someone does execute an HRH, it expires. That
seems silly though. IMO, a "fix" means not allowing the HRH to occur in the
first place, and the means used to accomplish the HRH is the MITM attack. No
MITM, no HRH.

------
tedunangst
Weird. I just read (or tried to read) this article over public wifi, but all
it says is "iOS is totally secure. You have nothing to worry about."

