We didn’t need the Black Hat and DEFCON hacker conferences to make us aware that vulnerabilities in third-party software were a major security concern – for software vendors and their customers. The “Heartbleed” vulnerability in OpenSSL did a great job of driving that point home.
But this month’s twin security conferences in Las Vegas will amplify what has already become a high-decibel conversation about the role that (unaudited) third-party components play in successful attacks against otherwise robust platforms these days.
In just one example, Jeff Forristal, the CTO at mobile security firm Bluebox Security will unveil a critical security hole that affects almost every Android phone in circulation.
The vulnerability, which Forristal is calling “FakeID” is linked to a third-party software component that has been bundled with Android since 2010. Due to a flaw in Android application handling, malicious applications can use the vulnerability to escape the restrictions of the Android application sandbox and get special security privileges without any user notification or interaction.
In a conversation I had with Forristal, he said the code in question was an open source component that was “sucked into” the original version of Android in 2008. Even though the component in question has since been “deprecated” (discontinued), it has persisted in Android – the world’s most widely used mobile operating system.
This is no ‘theoretic’ attack. The vulnerability could be used by attackers to sneak malicious applications onto Android devices by making them appear to come from legitimate publishers. That could lead to a malicious application having the ability to steal user data, recover passwords and secrets or otherwise compromise the Android device, he said.
In another presentation, Kymberlee Price, director of ecosystem strategy at Synack, and Jake Kouns, CEO of the Open Security Foundation will use epidemiologic models to explain the spread of vulnerabilities through an IT ecosystem by way of third-party code, Price recently told Dark Reading.
The data the two have collected provide proof that vulnerabilities flow throughout IT environments with the code they’re contained in (no surprise there). But they will also argue that current rankings of “severity” don’t take into account the pervasiveness of the vulnerable code and the context (how that third-party code is deployed). OpenSSL, for example, had a CVSS severity rating of “5” out of “10.” However, its widespread use and re-use within third-party applications made its actual impact much higher. More than 200 advisories linked to products using OpenSSL were issued in the wake of the revelation about the “Heartbleed” vulnerability.
“Once you start looking at what's being accessed in some of these products it starts looking significantly more impactful. It may not be a 10.0, but it's incredibly damaging," Price told Dark Reading.
Forristal says that business dynamics often drive decisions to integrate third-party components. “They cut your time to market but, as OpenSSL shows us, you can pay the price.” He said he can’t explain why organizations don’t do thorough audits of third-party code they use, but suspects that human failings play a big role.
“People decide ‘we’ll just trust this thing,’ or ‘it seems good,’ or ‘other people use it,’” he said. While no piece of software is perfectly secure, companies owe it to themselves to do audits that can detect glaring vulnerabilities or flaws in code they use, he said.