Third-party application vulnerabilities more concerning than NSA “backdoors”
Last week the New York Times broke a story regarding the ability of the NSA to foil basic privacy safeguards. What seemed to catch the most attention from other media outlets, as well as political and technology pundits was the fact the NSA had asked some software vendors to insert backdoors into their code so that the NSA can easily “hack” into systems running these applications.
The coercion of private enterprises by government agencies is disquieting, and backdoors make it possible for cybercriminals as well as the NSA to hack these systems. However, inserting backdoors into systems requires quite a bit of fore-thought and planning. It is far easier for anyone, from the NSA to the cybercriminal to simply hack into a system through the insecurities prevalent in third-party software used by every enterprise.
Every time an enterprise integrates a third-party application into their systems they are introducing new vulnerabilities to the enterprise. Unlike backdoors, these vulnerabilities are the result of innocent flaws rather than intentionally nefarious code; however the impact is the same. Cybercriminals or even government agencies can exploit these inadvertent vulnerabilities as easily as they can exploit a “backdoor”. Both avenues of attack result in the same compromised data which so alarmed to the media last week.
Some may say a vulnerability is different from a true backdoor, such as secret series of events that causes elevated access, because a vulnerability will eventually be discovered and remediated. History shows us however that the density of defects in common software is such that there is likely always another vulnerability, and if there isn’t attackers can always move to the next running application. Furthermore it is very likely that any planted backdoor will take the form of a well known vulnerability type to provide plausible deniability. Therefore the inspection for innocent flaws is by far the most likely way to protect from both criminal or state sponsored intrusion.
At Veracode we perform code scanning on the binaries of tens of thousands of applications a year. We find many, many vulnerabilities but true backdoors are almost non-existent. We have a set of scans for these backdoors which you can read about in our paper on scanning for backdoors in binaries. Our data shows they are either impossible to find or don’t exist. On the other hand the vulnerability density of the average application is high.
The NSA’s actions are troublesome to anyone concerned about privacy, but the NSA is not out to steal personal data for financial gain, or take down the United States’ critical infrastructure, and that is where third-party application vulnerabilities are more disturbing. These are the vulnerabilities that hacktivists, terrorist groups and “ordinary” cybercriminals will – and already have – exploited. One can simply look to the Syrian Electronic Army’s recent breach of the Washington Post, CNN and Time for an example of this. The SEA took advantage of the trust they placed in a third-party web application component used at all three sites. By exploiting this vulnerability they were able to breach all three organizations. Had each organization included security posture testing in their procurement processes, they would have been aware of the vulnerability and could have asked the vendor to put in processes to mitigate against this angle of attack. This is why enterprises must focus on addressing third party vulnerabilities, rather than worrying about whether there is an NSA backdoor in their system.
The NSA needs to be held accountable for their actions, but enterprises and the general public shouldn’t allow this information distract us from the larger issue of security – especially when it comes to the security of third-party applications and application components. Doing so would be akin to putting our heads in the sand and pretending these risks don’t exist.