Dozens of iOS mobile banking, medical and other applications handling sensitive user information are vulnerable to man-in-the-middle attacks where TLS traffic can be intercepted.
Of the 76 apps analyzed by Sudo Security Group, 19 are considered high-risk where financial or medical credentials, or authentication tokens, could be siphoned off by an attacker on the local network.
Those applications were not named by the researchers, who this weekend began notifying the affected developers. CEO Will Strafach told Threatpost that the apps contain networking code that accepts self-signed certificates, a feature likely left in by developers for debugging. The apps, in turn, will accept any self-signed cert and allow an attacker to present their own cert into a traffic stream and redirect supposedly secure data their way. He has named all of the low-risk apps affected in a report published yesterday; those considered at medium- and high-risk will have between 60 and 90 days to remediate before they are publicly identified, Strafach said.
“An attacker can self-sign their own cert, set up a man-in-the-middle proxy tool and have it present their custom cert and man-in-the-middle any connection nearby,” Strafach said. “The best theory I have is that app developers put in the code so they can internally test apps on staging servers. Internal servers are not on the public network, so they need to use a self-signed cert and I guess they didn’t remove the code.”
Strafach stressed that this isn’t something Apple can fix without breaking the security already present in a lot of the apps. For example, some custom apps work behind the firewall and use self-signed certs that are pinned to a trusted internal set of certificates or public keys. Apple’s App Transport Security feature, introduced in iOS 9 and forces apps to connect over HTTPS, would be ineffective against this misconfiguration, Strafach said. ATS would see the TLS certificate, consider these connections as valid TLS connections, and put certificate validation in the app’s hands.
Of the 76 apps analyzed (a combined 18 million downloads), 33 are considered low risk, Strafach said, because most of the data at risk is device data or a limited set of personal information. Two-dozen others are a medium risk and 19 are high risk, he said, personally confirming the ability to intercept credentials or session tokens for authenticated users.
“This is really a thing developers need to make sure they get right. If Apple blocks this, it would cause more problems and leave apps less secure,” Strafach said. “Developers need to be careful with the level of code they’re putting in apps. If they’re using self-signed certificates to test apps, if they’re not careful to remove this code it poses a great risk to users.”
Users can avoid compromise by switching off Wi-Fi in situations where sensitive information is being sent over a public network since most of these attacks would happen over Wi-Fi, he said. Strafach said the vulnerability is still present over a cellular network, but attacks are much more complicated and expensive than over Wi-Fi, lessening the risk.
“The fix might be just changing one line, or few lines of code,” Strafach said. “Overall it boils down to making sure you don’t have debug code working in a production app.”
