Lesson learned, and what we can expect going forward
Photo by Math on Unsplash
By now you’ve probably already heard of the name “Log4j”.
What happened
Late November this year, a Chinese researcher named Chen Zhaojun privately disclosed to Log4j maintainers that version 2 of Log4j contains a critical vulnerability that allows unauthenticated remote code execution (RCE) in applications that utilize the library. On December 9th, the vulnerability was disclosed to the public.
This vulnerability has also been dubbed “log4shell” and has been assigned the CVSS score of10.0, which is the highest possible score for a vulnerability. The vulnerability’s CVSS score is maxed out because of its potential impact and how easy it is to exploit. Log4shell allows attackers to execute arbitrary code on the target machine and does not require authentication, network access, or any user interaction to exploit. You can find a technical deep dive into what makes the Log4j vulnerability possible here.
This vulnerability is especially severe because of how ubiquitous the Log4j library is. Applications that are using Log4j < 2.15.0 are affected, and any application whose dependencies use the vulnerable libraries could be affected too. Companies like Apple, Cisco, Microsoft, have all confirmed that their product was impacted. Many open-source projects such as Apache Struts are affected too.
You can find a guide on how to determine if your application is vulnerable and how you can mitigate the vulnerability here.
“Long” Log4j
The full extent of the vulnerability and its damages are still being investigated. But a vulnerability with Log4shell’s reach and impact would probably be a part of our lives for quite some time. You can find a list of vendors that are found to be vulnerable to the issue here. Many vendors have started to patch or have fixed the issue, but many are still lagging behind. We can expect Log4j issues to be continuously identified or exploited in the next few months, or even years from now.
Organizations that have been monitoring their systems have discovered that Log4shell was exploited in the wild even before a public POC became available on Dec 9th (a report by Cisco Talos here). Currently, Log4shell is mostly being used to deploy crypto miners on target machines. There has also been attempted data theft and lateral movement into organization networks. State-sponsored attacker groups have also been detected trying to exploit the vulnerability.
To buy time for organizations racing to fix the bug, vendors like Cloudflare and ExpressVPN have rolled out temporary protection against Log4j. These protection mechanisms work by blocking suspicious requests and outgoing traffic and do not fix the fundamental vulnerability.
Given how easy it is to exploit Log4shell, it is very likely that some organizations have already been compromised before a fix or mitigation can be deployed. Attackers who gain access to the system via Log4shell can establish persistence on the system and wait for a convenient time to strike. So it’s important to continue monitoring your systems for suspicious activity lookout for indicators of compromise far into the future.
Lessons learned
This is not the first time the industry has had to respond to a widespread vulnerability. Still, a vulnerability like this one often points out the shortcomings of our current security processes and where we can improve.
You can’t secure what you don’t know about
While organizations scramble to respond to the disclosure, it’s not always clear where Log4j is used in an organization or even if it is used. And you can’t secure what you don’t know about.
Dependency management remains one of the most essential yet difficult tasks for security teams. You need up-to-date information about all the dependencies that are used in your systems to keep components updated and respond to new vulnerabilities in time.
One way to gain control over your application dependencies is to use a software composition analysis (SCA) tool to identify your application’s dependencies and scan them for vulnerabilities.
You are using other people’s code
We rely on code written by other people.
Open Source Software (OSS) is at the core of today’s information technology. About 80% of companies run their operations on OSS and 96% of applications are built using open source components. Most of today’s commercial products are shipped with some OSS libraries. We don’t write every single line of code that goes into our applications anymore. This means that securing open source dependencies and fixing open source vulnerabilities became an important part of software security.
We collectively rely on a number of open-source projects that are maintained by volunteers in their free time. Log4j highlights the need for the software world to put more effort into funding and supporting open source libraries that are critical to the modern digital infrastructure.
Taken from xkcd: https://xkcd.com/2347/
As individuals, there are ways to contribute to the security of open-source projects. You can either help maintain open-source projects or participate in initiatives like the Internet Bug Bounty program and work to identify vulnerabilities in popular libraries.
As developers, you should use popular and well-known open-source libraries whenever possible. This might seem contradictory since Log4j is a very popular library and made many applications vulnerable, but the library being large and popular is the reason the bug was found and quickly fixed. Vulnerabilities will happen, and popular libraries have more people looking at them. So use popular libraries and keep them up to date.
Defense-in-depth
Even if an application uses Log4j does not mean that the vulnerability is exploitable. The same vulnerability can manifest in different ways in different applications, and other protections built into the application can determine if the vulnerability is actually triggerable by attackers. Typically, less than 10% of CVEs are actually “attackable” to attackers. Use our tool to determine if the Log4j vulnerability is indeed attackable in your application’s context.
The difference between an attackable and a harmless open source vulnerability is often defense-in-depth techniques, or the practice of implementing several defenses for a potential vulnerability.
A defense-in-depth technique you can implement against injection issues like Log4shell is to sanitize user input the application receives. You can also deploy a WAF (web application firewall) to help filter out suspicious user input.
You should also run your application with only the privileges it needs to complete its tasks. For example, when an application requires only read access to a file, it shouldn’t be granted any writing or execution permissions. This is called the “principle of least privilege”. This practice will lower your risk of system compromise during an attack because attackers won’t be able to gain access to sensitive files and operations even if they gain command injection on the application.
No one can predict which open source libraries will be found vulnerable in the future, but you can make sure that the impact of future zero-days is minimized using defense-in-depth techniques.
Protect from future attackability
ShiftLeft’s CORE is an application security platform built over the foundational Code Property Graph that is uniquely positioned to deliver a specification model to query for unknown vulnerable conditions, business logic flaws, and insider attacks that might exist in your application’s codebase.
With ShiftLeft CORE, teams are able to focus on known and unknown issues that can be detected and reached by attackers from outside the application.
To get a free ShiftLeft CORE account, visit https://www.shiftleft.io/register.
To try Intelligent SCA, sign up for a premium trial within ShiftLeft CORE.
Top comments (0)