Millions of App Users Still Exposed to SSL Vulnerabilities

Here are some of the key highlights from the report:

• Poor programming practices expose users to SSL/TLS vulnerabilities.
• Months after app vendors were notified that their apps exposed users to SSL/TLS vulnerabilities, many of those apps still remain unsecure.
• The number of apps used by an average person in a month increased from 23 in 2011 to 27 in 2013. The amount of time spent using these apps increased from 18 hours per month in 2011 to more than 30 hours per month in 2013, according to a 2014 Nielsen study cited in the report.
• The Heartbleed vulnerability potentially impacted 17% (500,000) of the world’s secure Web servers.
• More than 20,000 mobile apps do not properly validate SSL certificates, leaving usernames and passwords exposed, according to a Vulnerability Note published in September 2014.
• Potentially Unwanted Programs (PUPs) were previously considered non-critical threats, but this is no longer true; PUPs have significantly enhanced their behavior.
• Macs are not immune as previously thought. The idea that attackers don’t pay attention to Apple operating systems is false; more than 70% of all malware found on Macs is classified as PUPs.
• Mobile malware grew from about 1.5 million instances in Q1 of 2013, to over 6 million instances in Q4 of 2014.

The significance of this report:

• These challenges impact all camps. For example, a challenge that impacts Microsoft and Google will translate to challenges for SharePoint, OneDrive, and Google Docs.
• Enterprise mobility that includes any BYOD adoptions without Mobile Device Management (MDM) and Mobile Content Management (MCM) is risky.
• Patch management is critical: The longer you wait, the more vulnerable you can become to exploits.
• User behavior remains targeted; as “Trust” and “Certificate” begin to lose value, confidence in security can quickly erode.
• Even top-rated apps cannot be assumed “safe”

I have  copied and pasted almost all of this from the McAfee Labs Threats report (direct link to the PDF). You can skip to the bottom to learn what the report has missed. I don’t think McAfee has purposely omitted anything. I just don’t think they, like other legacy security companies, have realized the full potential for cybercriminals to take advantage of the vulnerabilities of the WebView library/class.

For the purpose of highlighting what’s missing, I’ve pasted below, the most applicable sections of the report – related to apps, mobile malware and phishing attacks.

With the increasing use of mobile apps, the significant number of cryptographic vulnerabilities, and the impact those vulnerabilities have on trust in the Internet, application developers must to do all they can to ensure the security and privacy of their users, both mobile and nonmobile.

CERT, the first Computer Emergency Response Team at Carnegie Mellon University, announced in August 2014 the release of “CERT Tapioca” (Transparent Proxy Capture Appliance), a preconfigured virtual machine appliance that acts as a transparent network-layer proxy to perform MITM analysis of software. A couple of weeks later, CERT published a blog post about the automated discovery of SSL vulnerabilities in mobile apps using Tapioca.

The result of that investigation is the Vulnerability Note VU#582497, published in September 2014, which exposes the fact that more than 20,000 mobile applications fail to properly validate SSL certificates and thus are vulnerable to MITM attacks. All the tested applications and their details (tested versions, genre, number of downloads, CVE identifiers, and CERT VU# identifiers, among other information) are available in this public spreadsheet.

Recently, McAfee Labs decided to examine the most frequently downloaded mobile apps from that public spreadsheet to verify that they are no longer exposed to one of the most basic SSL vulnerabilities: improper digital certificate chain validation. Specifically, they dynamically tested the top 25 downloaded mobile apps that had been identified as vulnerable by CERT in September to ensure that usernames and passwords are no longer visible as a result of improper verification of SSL certificates. To our surprise, even though CERT notified the developers months ago, 18 of the 25 most downloaded vulnerable apps that send credentials via insecure connections are still vulnerable to MITM attacks.

The most downloaded vulnerable app in this group is a mobile photo editor with between 100 million and 500 million downloads. The app allows users to share photos on several social networks and cloud services. In late January, McAfee Labs tested the most current version of the app downloaded from Google Play using CERT Tapioca; they were able to intercept the app’s username and password credentials entered to log into the cloud service to share and publish photos:

x

The infection rate for mobile malware varies significantly over time but is nonetheless quite striking, with at least 8% of all systems reporting an infection since Q4 2013. Most of the rise and subsequent fall since Q4 2013 is caused by the detection of a single ad network—AirPush— which is considered a PUP, as are many ad networks.

The number of new suspect URLs skyrocketed in Q3 due to a doubling in the number of new short URLs, which often hide malicious websites, and a sharp increase in the number of phishing URLs. In Q4, the pace of new suspect URLs returned to a typical amount.

McAfee primarily attribute the immense leap in new phishing URLs in Q3 to a single Russian pill-spam phishing campaign that created a separate subdomain for every recipient. The campaign was not renewed in Q4.

What’s missing from the report

The report talks about mobile malware, spyware and ransomware as if it were separate to phishing attacks from malicious URLs. This is because legacy security companies see phishing URLs only as a threat for consumers who visit links via email on their desktop computer. Most desktop email clients offer zero protection against potential phishing attacks. That said, most mainstream desktop browsers do offer protection against phishing attacks. Chrome and Firefox use the Google Safe Browser API to do a quick URL lookup to see if a given URL is labeled as ‘malware & phishing’ before allowing the webpage to load. This is good news if you only read email on your desktop however. Bad news if you use your mobile to read email. According to some reports, 65% of email is read first on mobile.

Your exposure to potential phishing attacks isn’t limited to when you read email on your mobile either. You’re potentially exposed every time you visit a website inside any app on your mobile. Not every app has the ability to display websites. But most do.

• No mobile email app offers any kind of anti-phishing protection
• No message/chat app offers any kind of anti-phishing protection.
• No mobile browser will protect you from a known phishing site – including Chrome and Firefox
• No app on your phone will protect you from known phishing sites – unless it’s protected by the MetaCert Security API or the Google Safe Browser API that is.

At the time of writing this post, AppMakr.com is the only platform that offers app publishers an option to protect consumers from phishing attacks. Appery.io is integrating MetaCert into the platform as I type this post with more platform integrations on the way.

In March 2015, 44% of all apps built on AppMakr signed up for at least one of MetaCert’s monthly security services. Of those, 74% signed up for both ‘malware & phishing’ protection and XXX-blocking. These numbers lead us to believe that ‘mom and pop’ DIY app publishers want better protection for their end-users. So as an industry, we need to make it easy for them to do so as these apps make up for the vast majority of apps on the market today. It’s also a massive market opportunity for security companies trying to navigate the mobile landscape.

Legacy security companies haven’t yet realized how the insecurities of WebView have weakened the TCB of the Web infrastructure so McAfee can’t be blamed for omitting this important layer in the mobile ecosystem from their report. Even the most legitimate apps with perfectly implemented SSL certificates; providing secure connections between the app and a web server, are still potentially exposing consumers to phishing attacks.

I haven’t yet read a single report from any security company that details the potential risks facing consumers who use apps – whether they’re simple consumer apps, or app used by enterprises. While legacy companies are busy building anti-virus apps and network-based filtering, they’re missing the opportunity to build security at the app-layer – helping developers to add security to their apps. By adding a layer of security to apps, you stop more attacks from hitting the OS – allowing anti-virus apps to provide a backup or second layer of security.

For a detailed insight into how WebView exposes consumers and enterprises to potential threats, read the post I wrote entitled “How WebView has weakened the TCB of the Web infrastructure“.

How do you make WebView more secure?

At the time of writing this post, there are currently only two companies that offer a security service on the app-layer – MetaCert and Google.

At MetaCert we built a Security API that makes it easy for developers to protect consumers from phishing attacks – protecting them from mobile malware, spyware and ransomware. With our Security API, developers can also block websites based on their classification. For example, educational, faith based apps and organizations with content compliance considerations, may want to block pornography from loading inside their apps. Some developers may wish to block the entire Internet, while only permitting access to websites that fit a specific category. Although we have limited access to a few categories, we do provide access to more than 30 additional categories for developers who request it.

MetaCert is the only company in the world to classify URLs and folders without having to classify their associated domains or sub-domains. This allows developers to block, or permit access to certain content with precision-like accuracy when compared with legacy classification systems. We were also the first in the world to provide a Security API for looking up the classification of URLs for apps. Google recently announced their Safe Browsing API for apps. So we should expect to see more security companies add this offering in the near future.