Recently, we read about lots of SSL/TLS-related vulnerabilities found in mobile apps, which should come as no surprise. We were warned about this back in 2012 (see my previous blog). More warnings came in 2014 from CERT and FireEye. The Open Web Application Security Project (OWASP) listed “insufficient transport layer protection” as number three in its top 10 list of mobile security problems of 2014.
One recent study found that thousands of mobile apps still used an old version of the OpenSSL library that was vulnerable to the FREAK attack. A similar problem was revealed by the creators of a popular mobile networking library called AFNetworking, when they disclosed a serious bug in their library that bypassed all SSL/TLS security checks. Although this bug and the one in OpenSSL were quickly corrected, thousands of mobile apps remain vulnerable until their developers recompile with the fixed version of AFNetworking or OpenSSL, and users upgrade to the fixed version of each app. Because these bugs were in application libraries and not in the operating system, phone vendors cannot automatically apply a patch. Given the slow rate at which users upgrade mobile apps, these vulnerable apps are likely to be with us for a long time.
Failure to properly write and test SSL/TLS-related code might be due to ignorance or an assumption that the platform or library will “get it right”. Sometimes SSL/TLS checks are disabled during development and debugging. App creators intend to re-enable the checks before the app is shipped, but they forget. That’s apparently what happened with Fandango and Credit Karma, who were cited last year by the FTC for SSL/TLS failures in their mobile apps.
Developers don’t have to use blind faith; some good tools are now available for testing how an app works in the presence of a Man-in-the-Middle (MITM) like CERT’s Tapioca.
In addition to the SSL/TLS certificate validation tests described in the white paper linked by my earlier blog, developers might also consider Public Key Pinning, defined in a relatively new RFC from the Web Security working group at the Internet Engineering Task Force (IETF). Developers need to apply caution, however, since one study pointed out the difficulty of building it correctly and the consequences of mistakes.