Slashdot Mirror
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."
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"
Are you sure about that? You can definitely pin certificates in iOS. The trustkit library provides an implementation, for example.
In addition it is fairly easy to implement pinning yourself. You can do this in case you don't want to include the certificate in the app bundle, or in cases where you don't know the certificate or even the issuing authority up front (like connecting to user-owned devices with self signed certs).
If construction was anything like programming, an incorrectly fitted lock would bring down the entire building...
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.
Yes, but then the story is going to be "76 apps vulnerable to SSL interception if running jailbreakable versions of iOS", because the attacker can trick the user into jailbreaking their device, installing SSLKillSwitch https://github.com/iSECPartner... before tricking them into installing and trusting a new cert. I find this scenario about as likely as the "install a fake cert and trust it, then please re-direct all your traffic to my nice little mitm proxy" scenario.
So only 76 third party applications use HTTPS on iOS? I don't think so. Rather, I think the blame lies with developers using self signed certs on their test servers, and tweaking the SSL options in their app so that works for them.
To be fair, TFS did sort of lay the blame where it belonged. But it sure as HELL didn't make a point of it.