LOG4SHELL BRIEFING SERIES

Threat Intelligence Briefing: Log4Shell

December 17th

How Serious is the Log4j Vulnerability?

There is currently a lot of news around the latest global cyber vulnerability, Log4Shell. But what does it all actually mean? Do we believe the hype, or is it just that – ‘hype’?

Well, yes, Log4Shell (the name given to the vulnerability that is used to hack the Apache Log4j[1] software library) is a bad one. Over the first 10 days since the issue became public there hasn’t just been one update and patch but rather a series of patches released for this small innocuous piece of software. Open-source software is created and updated by unpaid volunteers and the unexpected global focus by security researchers and malicious threat actors has put it under the spotlight like never before. And it’s almost certainly not over yet in terms of even finding all the issues – let alone having our systems secured.

The Cybersecurity and Infrastructure Security Agency (CISS) in the US issued an emergency directive that ordered federal civilian executive branch agencies to address the issue by requiring agencies to check whether software that accepts “data input from the internet” are affected by the Log4j vulnerability. The agencies are instructed to patch or remove affected software by 5 p.m. ET on Dec. 23 and report the steps taken by Dec. 28: Shape Emergency Directive 22-02 | CISA

The combination of 3 factors has sent this to the top of people’s inboxes and to-do lists within IT and security departments around the globe.

• First, Log4shell is a very simple vulnerability to exploit. It only takes a line of code for an attacker to trigger this attack. This can be run by anyone, anywhere, within seconds and without deep technical skills – just a quick internet search.
• Secondly, it’s one of the worst types of vulnerabilities. It gives the attacker the ability to remotely execute arbitrary code. This means the attacker can run any commands or code on the target system. The vulnerability has been scored using an industry scoring methodology called CVSS[2] which assigns this the highest level of impact you can get; a full house at 10, out of a maximum score of 10. The power this attack yields is clearly linked to the systems and data that sit around the vulnerable system, which could then be compromised.
• Thirdly, the final contributing factor is that this piece of software (Apache’s Log4j) is very widely used. It’s open-source software, which means it’s free to access and use. It’s a library that is used to enable logging within software systems and is used by millions of devices. Many large vendors of software products appear to be using this[3] somewhere within their product set because it’s been so well known and trusted. It appears in places that may not be expected, too. For example, most corporate networks are likely to host software that uses this library. To put it in perspective, it’s been reported that there have been over 28 million downloads[4] in the last 4 months alone.

This all means that the very tool which many products use to log bugs and errors now has its own serious bug!

Typically, vulnerabilities relate to one vendor and one or two products. The challenge with Log4Shell is that it’s vendor agnostic. Any software which uses the Apache Log4j library is now a vulnerable product, and the race is on the get systems patched and remediated.

Following an initial few days of internet-wide remediation, the issue was compounded on December 15th, when it was discovered that the patch that had been released[5] (v2.15.0) didn’t fully remediate the Log4j vulnerability. A lower severity vulnerability was still present, in the form of a Denial-of-Service weakness. A patch for this was quickly released (v2.16.0) and the global race to fix began again. Since then, a further issue has also been found and the latest advice is to move to v2.17.0. And since then, another patch has been released of a further lower level vulnerability resulting in 2.17.1 being released.

Keep an open eye as we may not be at the end of this yet either!

The cybersecurity response to the Log4j vulnerability

The good news is that, although on a global scale, attackers from one-man-bands through to state-sponsored threat actors know about this and can target anyone who is still vulnerable, vendors are on the case and are working at pace to get patches out for their systems. However, history tells us that there is a long tail for organisations to close these gaps and there will be many people who still are not fully aware of the issue, their exposure, or the urgency with which they need to act. Locking down your internet-facing systems must be a priority but the vulnerabilities inside networks will take longer to identify and remediate, especially in large complex organisations.

There is a lot of talk about the Log4j vulnerability being used by self-propagating ‘worm like’ malware. Right now, there are so many vulnerable systems for attackers to go after it can be argued that there isn’t much need. But time will tell how this exploit gets used in future malware, ransomware, crypto-mining attacks, and botnets – as well as targeted attacks.

LRQA Nettitude have been investigating this since the issue was first announced in mid-December 2021 to the wider community. Our threat intelligence teams have created a set of briefings and information about this which you can find on our site here.

Please contact us if you have any questions or if you need help with testing or detecting this vulnerability within your organisation or if you are worried that you may have been compromised.

[1] https://logging.apache.org/log4j/2.x/security.html

[2] https://nvd.nist.gov/vuln/detail/CVE-2021-44228

[3 https://blog.sonatype.com/why-did-log4shell-set-the-internet-on-fire

[4] https://logging.apache.org/log4j/2.x/security.html