Software is consuming the world. These days, everyone is using applications to do everything from paying their bills, finding the love of their life, or even just working out the fastest way to get to work. In order to keep up with the demand for constant releases and new applications, developers depend on open source software components to give their products powerful and important features without the need to write new code on their own; this includes open source security code.
These components are written and maintained by the open source community, receiving support from a wide base of caring contributors who are dedicated to creating better code. Use of open source components is rising to meet the need for more software, now comprising between 60-80 percent of the code base in most modern applications today. However, not everyone out there seems to have joined in with the spirit of collaborating for the good of the community.
As we saw in the Equifax hack back in September of 2017, when hackers exploited a vulnerable version of the Apache Struts 2 component in the company’s web application to steal the personally identifiable information belonging to over 145.9 million people, open source can have certain risks if it is not used responsibly.
The primary threat is when an open source component is found to have a vulnerability (commonly referred to as a CVE), it is published for all to see so that they can perform the necessary fixes. Unfortunately, hackers can also view this information that tells them — with no need for effort on their part — which components are vulnerable and how to carry out the exploit. They can then use this information to ping organizations to find out who has been too slow to patch, making their breach into their systems.
For their part, far too many organizations are not checking to see if the open source components that they are using for their products contain any of these known vulnerabilities, and are generally unaware of which open source components are in their products; meaning that they do not know that they have a potential emergency on their hands when new vulnerabilities are published.
“You Have to Look Gift Code in the Mouth”
In the vast majority of cases, these vulnerabilities in the components are simply mistakes by the coders where hackers have found a hole or secondary function that can be exploited for ill-gotten gain. Then there are the cases where hackers will use otherwise innocent open source components as trojan horses, inserting malicious code into the components that they know will be used by organizations in their applications. This essentially gives them a backdoor into the applications that they can then go and target later at will, knowing already which versions have the built-in weaknesses.
A number of companies have reported finding cases where some of the open source components that they use in their products were found to have code that could be used for ransomware attacks, wherein hackers could encrypt their data, holding them hostage until they received payment.
Content from our partners
Keeping open source projects secure from malicious injections like these means depending on the community to be constantly reviewing the code with their “thousand eyes” in the words of Linux’s Linus Torvalds.
Security researchers are constantly sifting through the code, finding vulnerabilities, and reporting them to a range of security databases and advisories. It is a tough job staying on top of all of these resources as they are widely distributed, and need to be continuously monitored in order to help organizations stay ahead of the hackers.
When it comes to keeping your products secure, sometimes you have to look the gift code in the mouth, checking for potential vulnerabilities.
Open Sourcing Hacking Tools
A popular tactic among many hackers is to create a piece of malware or hacking tool, and then make it open source, essentially putting their dangerous toys out there for the masses to use. We see this in the posting of the source code for the tools or malware on sites like GitHub or n0where.net. Why hackers choose to do this can range between a couple of different reasons.
On the more sinister side, some hackers will choose to open source their malware because it allows them to hide in plain sight. By putting the code out there for theoretically anyone to see and use, it becomes nearly impossible for law enforcement or others to trace the malware back to them without some next level forensics.
We saw a textbook case of this method with the WannaCry ransomware attacks when the code, which was based on stolen NSA hacking tools, was posted to GitHub, spawning a litteny of copycats and obfuscating the real team behind the malicious code. Many indicators point to North Korean state-backed hackers having played a role in this story, but good luck proving it. Then some are simply old school hackers who believe in creating something powerful and want to share it with the world. This is one parts narcissism, and another part 10 year-old boy who figured out how to build a small explosive with his chemistry set and wants to show off for the neighbors.
In many cases, these hacking tools, which can be used for security researchers to find vulnerabilities, can be abused when they fall into the wrong hands.
The Dumbing Down of Hacking
The issue of open sourcing hacking tools is similar to the evolution of exploit kit markets, wherein hackers develop malware for use in hacks and sell it to other hackers who may lack the talent to write their own effective code. Many have commented that this results to a lowering of the bar of entry necessary to carry out destructive attacks, and is essentially a “dumbing down” of hacking.
One interesting case of a tool that was developed by a security researcher and then open sourced on GitHub is the case of AutoSploit. Last February, a security researcher using the Twitter handle VectorSEC combined two tools, the pentesting tool Metasploit and the connected device IP address search tool Shodan. This tool that he (we assume) called AutoSploit, allowed users to search for targets based on a term, and assault the targets with a massive barrage of pentesting exploits.
Some of VectorSEC’s critics likened the move to basically fully automate the targeting and hacking of connected systems (like IoT and servers) to giving a child a machine gun, noting that it gave outsized power to inexperienced hackers who had no real idea of how to control it.
Using Open Source Securely and Responsibly
There is no denying that open source is an essential element of application development, and ignoring the risks is not an option. Developers love using the open source components that they take from GitHub and elsewhere, and rightly so. By not having to reinvent the wheel every time they need a new feature, they are able to work faster and give more of their focus to the special sauce that makes their product shine.
However, working with open source securely and taking your user’s data protection seriously depends on taking responsibility for your code. First and foremost it means avoiding open source components with known vulnerabilities, and utilising automated tools that allow you to manage your open source usage at scale.
Second, despite the efforts of a few bad apples, we need to continue to depend on the open source community to keep us safe. These researchers are doing an incredible job in finding the vulnerabilities and reporting them for our benefit. It is then up to us to actually listen to them and keep our applications protected.
