Dozens of Popular iOS Apps Vulnerable To Intercept of TLS-Protected Data (arstechnica.com)
Researchers at Sudo Security Group Inc. discovered seventy-six popular applications in Apple's iOS App Store that had implemented encrypted communications with their back-end services in such a way that user information could be intercepted by a man-in-the-middle attack. According to Ars Technica, the applications could be fooled by a forged certificate sent back by a proxy, allowing their Transport Layer Security to be unencrypted and examined as it is passed over the internet. From their report: The discovery was initially the result of bulk analysis done by Sudo's verify.ly, a service that performs bulk static analysis of application binaries from Apple's App Store. Will Strafach, president of Sudo, verified the applications discovered by the system were vulnerable in the lab, using a network proxy configured with its own Secure Socket Layer certificate. In the post about his findings being published today, Strafach wrote: "During the testing process, I was able to confirm 76 popular iOS applications allow a silent man-in-the-middle attack to be performed on connections which should be protected by TLS (HTTPS), allowing interception and/or manipulation of data in motion. According to Apptopia estimates, there has been a combined total of more than 18,000,000 (Eighteen Million) downloads of app versions which are confirmed to be affected by this vulnerability."
The data exposed by the vulnerability in each of the applications varied in sensitivity. For just less than half -- 33 of the applications -- the risk was relatively low, as most of the data was "partially sensitive analytics data," Strafach said. These apps included a number of third-party "uploader" apps for Snapchat (which exposed Snapchat usernames and passwords) and the Vice News app, among others. In 24 cases, the exposed data included login credentials or session tokens that would allow an attacker to hijack the account associated with the application, though those accounts were not tied to highly sensitive data. However, the remaining 19 applications left sensitive data exposed to attack. In these cases, Strafach "confirmed ability to intercept financial or medical service login credentials and/or session authentication tokens for logged in users."
The data exposed by the vulnerability in each of the applications varied in sensitivity. For just less than half -- 33 of the applications -- the risk was relatively low, as most of the data was "partially sensitive analytics data," Strafach said. These apps included a number of third-party "uploader" apps for Snapchat (which exposed Snapchat usernames and passwords) and the Vice News app, among others. In 24 cases, the exposed data included login credentials or session tokens that would allow an attacker to hijack the account associated with the application, though those accounts were not tied to highly sensitive data. However, the remaining 19 applications left sensitive data exposed to attack. In these cases, Strafach "confirmed ability to intercept financial or medical service login credentials and/or session authentication tokens for logged in users."
We wanted to verify that the certificate we get from our service is issued by the CA we actually get our certificate from (sometimes called certificate pinning), but Apple only allows this for their own apps. Us third-party, second-class developers have to trust whatever bogus certificate comes over the network. Blame Apple.
Something new and internal to iOS between the user and app seller?
A totally new network to Apple, the user and back to the app server/services?
Make apps buy any trusted certificate they want and then be required use it?
Anyone have any news on the cellular interception side in the wild? Thanks.
Can a desktop computer do better? Has this all been fixed on most desktop OS?
Domestic spying is now "Benign Information Gathering"
They should use something like DANE to prevent man the middle
https://en.m.wikipedia.org/wiki/DNS-based_Authentication_of_Named_Entities
I wish apple libraries supported this transparently it would solve a lot of MITM issues
76 apps missing cert pinning, how is that a story?
So the attack is this then:
1) Find user with non-certpinning app installed
2) Trick user into installing a cert
3) Trick the user into trusting the newly installed cert
4) Modify the network settings on the users device to re-direct traffic via mitm proxy, or attack network such that traffic is re-directed via mitm proxy.
5) How is this a story worth posting?
I have no problems using apps without certpinning, any successfully attack requires, at the very least, two stupid decisions on part of the user.
Also, not using certpinning != vulnerability.
I saw your post, as well as your subject. What utter incomprehensible nonsense. Have a nice day now.
It bugs me that at every place I've worked at, dev environments always use self signed certs.
This may be OK for pure web stacks but not if you have your own clients like phone apps or IOT devices.
Developers will immediately code for trusting any cert. If they are aware of the issue, they then add conditional code to check the environment and if it's not test then enable validation.
So, you devops need to install proper certs in all environments.
Why does arstechnica always publish articles trashing android, apple or linux, but never microsoft?
I always test against a server that I've set up with a legit CA cert, and NEVER (even for testing) allow self-signed.
It makes testing a bit more annoying; but only a bit.
In fact, I'm working on an app right now that does this.
Via ADB one can use a custom hosts file on a droid that's rooted, easily (Apple devs get "GodMode" rooted phones they SSH into to alter hosts, you don't & yes, jail breaking is possible (iirc, go up > 1024 folders & it's useless)).
What's Apple Desktop Bus got to do with this?
And oh, look! ANOTHER Unverifiable, specious Apple-Hating comment from yet ANOTHER Anonymous Coward!
Amazing!
Sucks to be a faggat or a hispter.
WOW!
TWO Spelling errors in EIGHT words! That has to be some kind of record!
Well done, you illiterate, homophobic, luddite moron!
I thought the security of DANE relied on that of DNSSEC, and the security of DNSSEC was limited by the 1024-bit RSA zone signing key on the root zone until October of last year. The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.
Does this luddite need an appboard app to app his spelling?
Android Debugging Bridge [...] Via ADB one can use a custom hosts file
What's Apple Desktop Bus got to do with this?
Nothing, which is why he spelled it out. What's next, a claim that the fellow's initials can only stand for Android Package?
See my subject: The fool you replied to is some butthurt jackass sockpuppeteer/multiple acct user w/ 'assburger brain' who I've torn up before is all, obviously!
* So he makes fake accounts/sockpuppets & trolls me all day long vs. doing anything constructive of worth...
(I pity dolts like him - I truly honestly do - they're wasting their lives (but when their life IS a waste of time, oxygen & food? Perhaps I don't blame them but I DO blame them for letting it become that, trolling others spreading their own misery they project...))
APK
P.S.=> They do it to themselves... apk
>What's Apple Desktop Bus got to do with this?
That's what my brain parses ADB to every time.
It must be a function of age.
I should use this sig to advertise my book ISBN-13 : 978-1501515132.
Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example.
poÅYet baskı
The deprecation of 1024-bit RSA is why, for example, web browser publishers haven't added support for DANE.
Trust me, that's about the least of the reasons why browsers are ignoring DANE.
>What's Apple Desktop Bus got to do with this?
That's what my brain parses ADB to every time.
It must be a function of age.
Glad I'm not the only one... ;-)