While developing a tool for evaluating mobile application security, researchers at Sudo Security Group Inc. found out something unexpected. Seventy-six popular applications in Apple's iOS App Store, they discovered, 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. 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.

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.

Ars independently verified that several applications discovered by Strafach were vulnerable. These sorts of vulnerabilities are nothing new; thousands of applications have had incorporated bugs that caused TLS to become vulnerable to attack, both on iOS and Android. But the fact that they persist even as Apple tries to push developers toward greater security is disconcerting, to say the least—especially in applications that could expose financial or health data along with user credentials.

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 names of these apps are not currently being published. "Currently, this list is only available to limited parties due to sensitivity," Strafach wrote. "I have been in touch with MITRE and will follow up later with a listing of the CVE IDs for affected iOS applications of which data interception would be considered medium risk or high risk."

The same old story

Until recently, many mobile applications didn't protect much of the data sent to their back-end interfaces. When we looked at passive monitoring of mobile applications in 2014, we discovered many applications that were passing session tokens and other sensitive data in the clear. And for some developers that have moved to secure connections, poor verification of TLS certificates has continued to be problem.

Even security-focused applications have run into trouble with TLS validation, including the two-factor authentication provider Duo. In 2015, Duo issued a security advisory warning that one version of their iOS application had left open a TLS vulnerability. Many secure applications avoid the issue by using "pinned" certificates hard-coded into applications, which allows them to avoid interception of the certificate hand-shake at the beginning of a TLS session. But that may not be practical for other applications.

Apple has been pushing iOS developers to use App Transport Security (ATS) to secure data transmitted by applications sold through the App Store. In December, Apple extended the deadline for application developers to implement ATS. ATS uses TLS v. 1.2 and requires stronger cryptography (AES and SHA-2), as well as "forward secrecy" to protect past transactions if a certificate is compromised. But ATS doesn't ensure that applications properly verify the certificate—just that the developer uses TLS to begin with.

ATS does allow for use of Certificate Transparency—a public "log" of verified certificates. Google is also pushing the service and is planning to use Certificate Transparency to enforce validation of trusted web sites by October 2017. But not all certificate authorities (let alone site and app operators) have signed off on implementing CT, so its adoption by app developer is still in its infancy. And if Apple tries to enforce Certificate Transparency now, it could actually cause some applications to become less secure, Strafach said. Developers "would not be able to utilize certificate pinning for their connections, and they could not trust otherwise untrusted certificates which may be required for intranet connections within an enterprise using an in-house PKI."

The one ray of sunshine for end-users is that man-in-the-middle attacks (other than those by state actors) are possible only when connected to the Internet via an untrusted Wi-Fi connection. If you're connected using cellular broadband or a trusted wireless network, man-in-the-middle attacks are highly unlikely—though attackers can use Wi-Fi network spoofing to fool a device into connecting to a malicious network, as Ars has demonstrated in the lab in the past.

With links: https://arstechnica.com/security/2017/02/dozens-of-popular-ios-apps-vulnerable-to-intercept-of-tls-protected-data/