By automating its app vulnerability testing, CERT (Computer Emergency Response Team), the US federally funded research centre originally set up to coordinate response to incidents threatening ARPANET, found that 2.4 percent of one million free Android apps tested had vulnerabilities.
And after notifying the authors just six percent responded – mostly not understanding there was a problem, or not concerned if there was, and only 0.1 percent subsequently said they fixed the vulnerability – so just 1,000 out of 24,000 insecure apps fixed.
Will Dormann, vulnerability analyst, CERT, told delegates at the RSA session, 'How we discovered thousands of vulnerable apps in one day', that using the Dranzer testing tool, plus Hijacklogs, and automation, he quickly found thousands of vulnerabilities – distinct ActiveX controls. Around 73 crashed in unique manner so CERT sent everything the vendor needed to fix it, but got the response that 73 was too many to handle.
The automated system, CERT Tapioca, is basically an MITM (man in the middle) kit, checking the traffic between the client and server, seeing it make a valid SSL handshake and identifying if the client has invalid SSL. It was initially scaled using emulation, enabling 20 scans to be run simultaneous, then further speeded up by using virtual machines. Companies can download CERT Tapioca for free, and test apps used by their organisation for SSL validation failure, including in non- fee apps and non-android apps, and can then report failures to CERT.
Assigning CVEs (Common Vulnerabilities and Exposures) is the de facto standard for tracking vulnerabilities in applications, and the official assigner of CVEs is an organisation called MITRE. But as Dormann explained, “MITRE does not attempt to track all applications with CVE. So no one has all vulnerabilities – MITRE is deciding which are important. But it's not clear what makes a CVE important.” Examples were given with Apps that are widely deployed, (10 million) with low impact, low deployment (single figures) with high impact like PayPal account details, as well as large scale deployment (five million) and significant impact such as loss of passwords, all of which had no CVE assigned.
Dormann added: “We forwarded 10,000, just testing Android – not others. They decided 'no', (the applications were not CVE worthy) and asked us to stop assigning CVEs because we were said to be finding too many. And so a lot of apps are vulnerable, but with no CVE – so people don't know.”
One site alone, AppsGeyser, which allows creation of an app for free, would need its apps to be regenerated to become secure – that's 1.4 million needing to be re-generated from one source but many diverse authors. The apps themselves were often highly questionable, including a Mobile Network Signal Booster, Cartoon Wars app with 10 million installs that requests root privileges, and the ‘brightest LED flashlight' that checks SSL.
Other platforms (iOS, Blackberry, Windows phone) are planned to be looked at next.
Lessons learned include: Vulnerability coordination does not scale easily; CVE doesn't scale easily; there are a lot of horrible apps; Authors often not responsive – and companies are advised to test the vulnerability of apps that they use.
This article originally appeared on SC Magazine UK.
