Many organisations have an over-reliance on open-sourced projects. What makes this interesting is that many of them are unaware of it. However, they are now starting to find out (the hard way).
First Published 14th February 2022
"Let's break the internet!"
4 min read | Reflare Research Team
A reason for much concern
On December 9, when the Apache Software Foundation disclosed a massive vulnerability in a Java logging library known as log4j creating mass panic amongst IT professionals who many at the time were already preparing to go on holiday.
This vulnerability is extremely critical due to the number of applications and devices that rely on the library which are estimated to be in the millions. It is widely used across consumer and enterprise systems, in everything from iCloud, Steam and Minecraft, to Fortinet, IBM, Microsoft, Red Hat, Salesforce, Siemens, and other vendors.
Wiz, a cloud security start-up, and Ernst & Young believe that 89% of enterprise cloud environments are affected by the vulnerability. In fact, if an organisation is running a java application that logs information somewhere, there is a very high chance that the application is using the logging library than it is not. According to the Wall Street Journal, a top U.S. cybersecurity official described the vulnerability as the worst she had ever seen.
While we won’t go into the technical details, one of the most interesting aspects of this vulnerability is how easily it can be exploited. Unlike memory corruption vulnerabilities – which often are difficult to find and even harder to create a reliable exploit — the exploit for the log4j vulnerability is extremely simple.
Another interesting aspect of this vulnerability is the fact that the library is normally used to keep track of an application behaviour including potential security issues, so it’s a huge problem when the one supposed to be watching out for problems is the one having a problem, and nothing is watching it.
How the event unfolded
The vulnerability was first disclosed to Apache by security researchers at Alibaba Cloud on November 24 and two days later was included in the CVE list. When the non-profit organisation made the information public around two weeks later, it didn’t take long before both hackers and security researchers came up with proof-of-concept exploits.
The media soon started reporting about the vulnerability after Minecraft servers and player computers running the Java edition of the game were compromised by hackers that exploited the vulnerability.
According to the cyber security group Check Point, more than 44 percent of companies globally have been targeted by hackers mass-exploiting the vulnerability since the information was made public, and at some points, the researchers at the company were seeing more than 100 hacks a minute.
Another security company, Sophos, said they “already detected hundreds of thousands of attempts since December 9 to remotely execute code using this vulnerability”. The researchers also said that log searches by other organisations such as Cloudflare suggest that the vulnerability may have been openly exploited for weeks.
Earlier, Cloudflare CEO Matthew Prince tweeted, “Earliest evidence we’ve found so far of #Log4J exploit is 2021-12-01 04:36:50 UTC,” and “that suggests it was in the wild at least nine days before publicly disclosed. However, don’t see evidence of mass exploitation until after public disclosure.”
Are we relying too much on open-source projects?
One thing that we find very interesting in this whole saga is the amount of reliance on open-source projects by big corporations.
While open-source projects can be more secure than closed-source projects, the very things that make them secure – such as the availability of the source code for independent researchers to look for and fix security bugs – can also give people a false sense of security.
The reason we say this is because the source codes for open-source projects are equally accessible to everyone including malicious threat actors and nothing prevents them from being the first to discover vulnerabilities in those projects before everyone else.
A lot of people also make the assumption that both researchers and developers are always tracking changes in open-source projects in case a vulnerability or something harmful is introduced. This is not only false but likely to be impossible considering there are thousands of open-source projects out there and even if we consider a hypothetical scenario where this is true – finding security bugs can be extremely difficult and time-consuming, and it could take months or even years before a vulnerability is uncovered.
As a matter of fact, we don’t have to look far to find the dangers of open-source overreliance.
It pays to not shit on developers
Just last week, thousands of software stopped working – potentially affecting millions of users – when the developer of two widely used open-source JavaScript libraries decided to sabotage his own code by introducing infinite loops that print political messages to protest against tech companies that use open-source code without paying the developers. The incident was initially thought to be a hack. However, only later did it come to light that it was the disgruntled open-source developer 'lashing-out' at a system he believed was unjust.
This is not the first incident of such kind. In 2016, another open-source developer based in Oakland, California literally broke the internet when he removed his 11-line JavaScript package from his online repository after a dispute with a tech company and their repository management team over the name of one of his packages.
Despite having only 11 lines of code, the package was a dependency to some of the most widely used open-source projects, and the removal of the package broke them all – causing big companies (and everyone else who relied on those projects) to go on panic mode.
Over the years, more and more open-source developers are publicly venting their discontent with tech companies taking advantage of open-source projects without giving back to the community that serves them. Many of these developers are feeling exploited, and unless they start seeing some love, they may just decide to stop contributing to the open-source community or start making their projects reassuringly expensive for the corporations who rely on them.
Do unto others...
But there are important lessons to be taken away from the open source community. Many developers who work within organisations are often the unsung workhorses whose output is the foundation on which many of our modern empires are built. Although they may not be getting as much of a raw deal as their counterparts in the open-source world, it pays well to look after your developers. Invest in their skills and capabilities, invite them into business-critical technology discussions early, and take them to lunch once in a while.
There is no need for disgruntled developers if you are treating them right. And as the war for top tech talent continues to increase in ferocity, showing a little bit of love is significantly cheaper than going back out to market to recruit a replacement, only to have them spend their days hunting for a deliberately hidden needle in your technological haystack.
To stay abreast of the latest IT security trends, developer shenanigans and data breaches, subscribe to our newsletter.