iOS Apps With Broken Certificate Validation Put User Data at Risk.
A group of 76 iOS apps have been found to be vulnerable to a common SSL/TLS misconfiguration which would allow an attacker to steal user data if they were on same network. More than half of the vulnerable apps leaked user login data, 19 of which were apps for banks or financial and medical services.
Will Strafach, who works for verify.ly, found the vulnerable apps while developing his service. Verify.ly provides automated analysis of iOS binaries to find common problems.
This vulnerability is not new. In fact, it relies on a rather basic misconfiguration of SSL/TLS settings, and various apps and software have been previously found to have the same issue. But Strafach’s research showed that the problem still persists amongst a group of 76 iOS apps, which received a combined 18 million downloads, according to Apptopia, a company that provides data on the mobile app market.
The vulnerability works by using a man-in-the-middle attack and then providing a self-signed SSL certificate. This allows an attacker to pose as the server and receive data from the user’s app. It’s all possible because the affected apps do not properly implemented certificate validation, and accept certificates that should otherwise not be trusted.
This attack can only be executed by someone on the same network as you. This means public Wi-Fi networks are the most at risk, but just because your network has a password does not mean you are automatically protected. Strafach suggested turning off Wi-Fi and using your phone’s cell connection, as your providers network is significantly harder to attack.
Strafach classified vulnerable apps as a low, medium, or high risk, depending on the type of data that could be intercepted when using this attack. Low risk meant that the data was specific to the app, and low value personal information (like an email address). Medium risk classification meant the attack could be used to intercept login credentials and/or session tokens. When those credentials were for a financial or medical service, they fell into the high risk category.
The list of low risk apps has been released, but the medium and high risk apps have been withheld for at least 60 days to give developers time to fix the vulnerability.
The affected apps are misconfigured, with settings that break “the default validation that is in place so that instead of using the default store of trusted root [certificate authorities], the apps will accept any [certificate] signed by any [certificate authority],” Strafach told Motherboard.
It is possible that more apps have made the same mistake and are also vulnerable. However, by default apps should not be vulnerable. The vast majority of apps are likely not affected.
Apple has been one of the major companies pushing their ecosystem to HTTPS. Their App Transport Security (ATS) standard requires that apps use HTTPS connections to secure user data. However, ATS does not require certificate validation and cannot prevent this vulnerability.
This may seem like an oversight, but if Apple has strictly enforced certificate validation as part of ATS they would have made some apps and services that rely on intranet connections or private CAs unusable.
Over the last few years, Certificate Authorities have stopped issuing certificates for local hostnames and IP addresses, which has prevented certain type of attacks, but also eliminated the use of publicly-trusted certificates in these cases. Ironically, these restrictions make implementing SSL/TLS more difficult and lead some developers to adopting insecure practices, creating vulnerabilities like the one affecting these apps.