Code disaster - learn how old code can destroy your business
Old open source code from 3rd party library code and outdated repositories is increasingly a major source of application vulnerabilities, but tracking it down isn’t quite as simple as you might expect...
Do you know where your code is from? It could have a major impact on the security of your enterprise applications, without raising any red flags at all during the development stage. Your developers may have perfectly legitimately incorporated flaws into the very start of the build process by using a vulnerable component from a third party library code or outdated code repository.
That may sound alarmist, and it’s certainly tempting to respond with a ‘not-in-my-backyard’ knee jerk, but this is exactly what has happened with the Heartbleed vulnerability in OpenSSL and Shellshock in GNU Bash, to name but two well publicised examples from recent years, where developers reuse libraries and frameworks that contain unpatched flaws in production applications. Incidentally, you can test your SSL/TLS implementation here for free to make sure Heartbleed is not present. High-Tech Bridge’s research in early 2016 found that 10 per cent of SSL VPN servers that rely on OpenSSL, were still vulnerable to Heartbleed…
In a recent analysis of 25,000 applications, Sonatype found that seven per cent of components had at least one security defect tied to the use of an insecure software component. Repositories such as GitHub, Bitbucket, and Python Package Index are all designed to help developers out with pre-written code, allowing them to add functionality without coding each and every one from scratch, but this sensible strategy can introduce vulnerabilities.
According to an analysis of Sonatype’s own Central Repository in 2015, developers had made 31 billion download requests of open source and third-party software components, up from 17 billion requests the year before. The company found that 6.1 per cent of code downloaded from its Central Repository had a known security defect.
It’s when insecure code is used to build a component within a software program, which is in turn used inside other larger components, that problems really start to multiply. One example of vulnerable third-party code that is regularly reused is a deserialization flaw in Apache Commons Collections (commons-collections-3.2.1.jar) – first reported in 2015 and patched in November of the same year. An investigation by Veracode found that there are still 1,300 instances of the old vulnerable version still available inside Java applications using Spring and Hibernate libraries and hosted across multiple open source code repositories. According to Veracode, Apache Commons Collections is the sixth-most common component used in Java applications. It found that the unpatched version of the software was in a whopping 25 per cent of 300,000 Java applications scanned.
Of course, the issue isn’t restricted to outdated library code and apparently lazy developers, it’s also down to managing patching and updates effectively, so new vulnerabilities are patched in a timely manner. Security researchers at Veracode recently estimated that 97 per cent of Java applications it tested included at least one component with at least one known software vulnerability.
This research gels with new figures from High-Tech Bridge researchers, who found that more than 90 per cent of in-house developed web applications designed to handle medical, financial or other sensitive data were vulnerable to a high-risk improper access control or other application logic flaws not related to the sanitization of user-supplied input (like in XSS or SQL injections for example).
One thing is clear, and that is that application security is still one of the major causes of corporate compromise out there, as Ilia Kolochenko, CEO, High-Tech Bridge summarised: “In 2012, High-Tech Bridge and Frost & Sullivan released a White Paper saying 4/5 network intrusions start directly, or involve, insecure or outdated corporate web applications. However, since then, not many companies changed web application security priority in their risk strategies.
“People prefer to spend on mysterious APTs and other highly exaggerated threats, leaving the main doors to their companies (web apps) open to everyone. We need to understand that modern web application is not just a website, but a direct access to internal and highly sensitive infrastructure.”