Zombies: Top 5 Open Source Vulnerabilities That Refuse To Die
Table of Contents
Open source components provide the building blocks for most of the technologies that we depend on, comprising between 60-80% of the code base for most modern applications available today. So when one of them is compromised with a reported known vulnerability, it can have a massive impact on a multitude of applications.
No matter how much time has passed, the story remains the same. Open source vulnerabilities are one of the biggest threats for organizations big and small. The major issue at hand is despite knowing about the different vulnerabilities and their available fixes, people aren’t taking the time to understand the open source software they are using. Plenty more are simply failing to patch the vulnerable components in their software.
In recent years as the rate of software development has exploded, the reach of vulnerabilities in popular open source projects have had a major impact on the the public at large. What is surprising though, is that even after having wrecked so much damage on the technology industry, so many of these vulnerabilities continue to haunt developers in many of the products that we know and love.
In late 2017 we highlighted some the major breaches that rocked the headlines over the past ten years. However this time around we are putting together the more well known open source vulnerabilities into the spotlight. Here are the top 5 open source vulnerabilities that shocked the open source community and could still be affecting us as we speak.
HeartBleed
One of the most famous open source vulnerabilities till today, Heartbleed was brought to light in April of 2014. This vulnerability allowed attackers remarkable access to different kinds of sensitive information.
Heartbleed was caused by a flaw in OpenSSL, an open source code library that implemented the Transport Layer Security (TLS) and Secure Sockets Layer (SSL) protocols. In short, a malicious user could easily trick a vulnerable web server into sending sensitive information, including usernames and passwords. Heartbleed was linked to an attack where hackers managed to steal 4.5 million healthcare records.
More than fours years have passed but this vulnerability is still alive as it appears that many organizations did not remediate this serious security glitch properly. As of 2017, Heartbleed was still affecting more than 199,500 systems, which is hard to reconcile considering the time that has passed and the press surrounding its patchability.
ShellShock
Adding to the pain of Heartbleed, Shellshock joined the party to make 2014 an even tougher year for open source vulnerabilities. This exploit of the code allowed hackers to use Bash to remotely execute commands from environment variables. Even though Bash is not an internet-facing service, many different internet and network services such as web servers use environment variables to communicate with the server’s operating system.
Since the environment variables are not guarded properly by Bash before being executed, the attackers could send commands to the server through HTTP requests and get them executed by the web server operating system.
So after all this fanfare, is Shellshock still affecting us? The answer is yes, despite having four years to patch this vulnerability, large numbers of servers are still affected by Shellshock.
Drown Attack
The CVSS score for this severity wasn’t considered to be that serious, yet with Drown affecting HTTPS, as well as other services relying on SSL and TLS, the sheer scope of this vulnerability helped force it into the headlines
At Drown’s height, 33% of all HTTPS websites were affected by this vulnerability That’s about 11 million websites just in case you’re counting.
The whole point of the HTTPS web protocol is to make the internet more secure, right? So what happened?
When Drown burst onto the scene, HTTPS may have given users a false sense of security. The vulnerability exploited a flaw in SSL v2, allowing attackers to break HTTPS’ encryption, and consequently steal sensitive communications such as usernames, passwords, credit card numbers, sensitive documents, etc.
Thankfully, fixing this open source security vulnerability was fairly straightforward. All you needed to do was disable SSL v2 on all your servers and applications.
Glibc Vulnerability
One of the most talked about open source security vulnerabilities in recent years is Glibc. This GNU C library was at the heart of 2015’s Ghost vulnerability, which was found to be vulnerable to yet another critical flaw.
This open source security vulnerability affected all Linux servers and web frameworks such as Python, PHP, Ruby on Rails as well as API web services which use the GNU C library. The vulnerability enabled hackers to compromise apps via a man-in-the-middle attack, with the possibility of taking control of a user’s system, which accessed a hacker-controlled DNS host.
What made this vulnerability particularly unique was that we were introduced to Glibc 2.9 way back in 2008. This meant that the vulnerability was around for eight years before it finally popped up our radars! Luckily, RedHat moved fast and issued a patch within a few days of Glibc’s disclosure.
Apache Struts 2
On Sept. 7, 2017, consumer credit reporting agency Equifax reported a security breach that occurred between mid-May and July.
The breach, involving over 145.9 million people, is considered the biggest breach to date. Hackers acquired access to a massive cluster of names, social security numbers, birth dates, street addresses and, in some instances, driver’s license numbers and credit cards. With those sets of data, criminals can steal identities to set up credit cards, mortgages, loans and more.
The vulnerability that attackers exploited to access Equifax’s system was in the Apache Struts 2 open source software framework, a widely used platform. Despite knowing about the breach in mid-March 2017 and receiving an open source patch for the vulnerable leak, why didn’t Equifax patch it? Straight up negligence, right? Perhaps.
Most reports indicate that they were simply unaware that they were using it in their customer complaint portal, so they did not know that they needed to patch it when the warnings were issued.
Aim for the head
Open source security is still a challenge for many organizations. The ghosts of vulnerabilities past have a way of coming back to haunt us – and if we don’t start investing in ghost patching, it probably won’t be the last.
As we have seen over the past five years, open source vulnerabilities are nothing to take too lightly. Open source components are constantly being audited by members of the amazing open source community to help keep us safe. But still , they need to be monitored and updated to avoid such vulnerability and hacks as seen above. Always update your components with the most updated version which you can find easily with the help of the open source community.
And remember, if the open source community knows about an open source security vulnerability, so do hackers. Constantly remediating the issue sooner rather than later is always the best idea.
