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."
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.