Open-source software (OSS) is now so widely used that it is incredibly difficult to find an organisation that doesn’t incorporate OSS in some form or another – whether that be in a standalone open-source product, or more commonly, in the form of OSS packages. Though its usefulness cannot be doubted, the prevalence of this software is exactly what makes it a major target for cyber-attacks.
A prime example of this is Log4j, a popular logging utility used by scores of organisations for recording events such as status reports and errors. In a situation which came to be known as ‘Log4shell’, a zero-day vulnerability allowed threat actors to compromise systems using malicious code and take control all while remaining undetected. At the time, its impact was described as “enormous” and the implications of its implementation into countless commercial products underlined the inherent vulnerabilities of some open-source technologies when weak points are exposed.
While these packages serve as invaluable tools for developers, saving countless development hours, there are a range of risks to address. Even when leveraging established OSS solutions to speed up a design, their inclusion within a product leaves end users unaware of the potential threats they are exposed to in these integrations, unknowingly presenting significant risk factors for anyone who then uses the resulting software.
In addition, public OSS repositories, the primary sources from which developers source these packages, are typically inundated with new third-party software and application updates on a daily basis. While these repositories offer the prospect of accelerated development, the sheer volume on offer makes security vetting a huge undertaking. As a result, responsibility for winnowing out malicious or unsuitable software predominantly falls upon security researchers and firms, rather than being managed by a structured, mandated system.
Threat actors look to capitalise on these vetting shortfalls by manipulating legitimate packages with malicious insertions, which they then re-upload onto public repositories under similar names and wait for their victims to download them. Another common method hackers use is to develop something new to upload to the sites, embedding secondary malicious code in otherwise useful open-source packages. Some of these cyber criminals have honed this approach to such an extent that they have established fake social media profiles, positioning themselves as credible developers within well-known companies to present a more convincing persona.
While numerous malicious security problems within OSS packages have been flagged because they predominantly cater to larger audiences, by the time these vulnerabilities surface, they are often too entrenched within developed software to be isolated and removed effectively.
Although OSS attacks can occur in software used across any industry, those which often rely on and reuse predictable applications are the most at risk. Take the banking sector, for example, whose well-established and formulaic software landscape offers an enticing option for open-source-focused attackers. Here, hackers can almost anticipate the software that will be run by any given bank and look to infect it with malicious code accordingly. Attackers can also be highly pragmatic in their approach, assessing the potential return of tactics which provide more in terms of efficiency and reliability rather than attacking a higher volume of random targets with more unpredictable infrastructures.
However, no industry is invulnerable, not least because the development ecosystem is geared towards optimising the use of open-source technologies. Modern work environments in particular usually operate using a significant amount of ‘off the shelf’ software – many with some form of OSS package built in. Developers sharing packages throughout their community is not a new concept – after all, why spend the time developing something new when you can readily access tried and tested programmes? But the problem today is that external awareness of these ecosystems has increased so attackers have now turned their attention to how they can capitalise on the tradition of community trust that has been cultivated over many years.
Navigating the OSS Threat Landscape
In the case of the Log4j incident, the impact of the attack was largely exacerbated by widespread ignorance about the software integrations involved. To protect against future attacks of the same nature, there’s also a need for an accessible software directory that facilitates rapid vulnerability assessments.
Organisations must have an in-depth understanding of every piece of software they deploy. In this context, comprehensive documentation detailing OSS integrations can be invaluable. Though, if this is not available, tools that analyse and identify packages within software can effectively see organisations through should the worst occur.
To a large extent, protection from OSS attacks hinges on awareness and knowledge. Although open-source software has been proven to be immensely beneficial over a long period of time, showcased by its widespread adoption, it is not without its vulnerabilities. By definition, as OSS becomes universally incorporated, the vulnerabilities it can contain are likely to be magnified. In this context, greater levels of vigilance, knowledge and proactive measures are the best defence in this evolving and crucial sector of the technology industry.
About the Author
The opinions expressed in this post belongs to the individual contributors and do not necessarily reflect the views of Information Security Buzz.
