Last week, a security alert was issued disclosing a critical buffer overflow vulnerability on Linux systems. The vulnerability known as GHOST (CVE-2015-0235) impacts applications running on Linux systems using glibc version 2. This is a serious vulnerability because it has a high impact when exploited, and the vulnerability is very widespread, due to the sheer number of public-facing Linux systems that are vulnerable and easily accessible by cyberattackers. For example, it could be used to remotely install cyber-espionage malware or turn machines into botnet "zombies" that execute DDoS attacks on-demand.
Due to the criticality of this vulnerability, we are recommending that all companies patch their internet-facing Linux servers as soon as possible. This could be a timely undertaking, but will be worth the time to avoid a costly breach.
This is yet another example, like Heartbleed and Shellshock, of a reusable open source component that is widely used and also quite vulnerable. In our research, we've found that open source components introduce an average of 24 known vulnerabilities into each web application. The GHOST vulnerability in glibc is a good example of an application inheriting a vulnerability because of its use of an open source component. Given the widespread nature of component use, it is important to test all applications in your software infrastructure, not just your mission-critical apps. The most effective way to accomplish this is typically with a combination of SAST, DAST, software composition analysis and web application perimeter monitoring.
Why have we heard more about vulnerabilities in components recently? Part of the reason is because, in the pursuit of rapid digital innovation, the use of components has become best practice in both traditional and agile development environments. In fact, according to industry analysts, 95 percent of all IT organizations currently leverage some element of open source software in their mission-critical IT solutions. In addition, FS-ISAC states that “the majority of internal software created by financial services involves acquiring open source components and libraries to augment custom-developed software.”
However, like any application, these components often contain vulnerabilities. But unlike internally developed code, the teams incorporating the components into their applications do not have visibility into vulnerabilities or when an update is made to fix a vulnerability. Basically, it is difficult for enterprises with multiple code repositories, and using multiple components in each application, to keep track of what version of a component is used in each application. As a result, countless web and mobile applications remain vulnerable, even when a vulnerability becomes known and the component is patched by the original developer. In the case of GHOST, the issue is exacerbated further because, like the Bash bug in Shellshock, glibc is a system component not typically installed by the application development team.
Because components are used in multiple applications, targeting and exploiting a single component can mean the ability to breach multiple companies. This means less effort for a larger outcome than targeting a single application; so cyberattackers are going to target vulnerabilities in components and third-party applications. What enterprises need to understand is that, once integrated into their environments, these components and third-party applications become theirs — and they will be held accountable for a breach. No one remembers the name of the HVAC company that caused Target to be breached — but they sure do remember that Target was breached.
It is time software composition analysis and third-party software security became a larger part of the security discussion. Without securing those attack vectors, a company can’t truly say it has a mature security program, or that it’s taken every reasonable step to secure its customers’ data.
Join us for a SANS Webinar, Wrapping Up The GHOST: Lessons Learned From The Ghost Vulnerability: register here.