On Friday 9 December, the information security world was rocked by the disclosure of Log4j (CVE-2021-44228), a zero-day vulnerability in the widely used Java logging library Apache Log4j, which allows attackers to remotely execute code and gain access to machines. Not only is the vulnerability relatively simple to take advantage of, the ubiquitous nature of Log4j means that it’s embedded in a vast array of applications, services and enterprise software tools that are written in Java – and used by organisations and individuals around the world.

LOG4J FLAW COVERAGE - WHAT YOU NEED TO KNOW NOW 

US warns Log4j flaw puts hundreds of millions of devices at riskLog4j flaw: Attackers are making thousands of attempts to exploit this severe vulnerability Log4j RCE activity began on December 1 as botnets start using vulnerability

That means after a long and exhausting year, tech staff find themselves scrambling to fix yet another critical vulnerability. Even worse, in the case of Log4j, it may be extremely hard for even security professionals to understand whether this code is part of their applications and thus a potential risk. Like much open-source software, it is built-in down the supply chain. Many vendors are still attempting to find out if their products are affected. That’s why some have likened Log4j to Heartbleed, a vulnerability in SSL that affected many major websites and services, but was also difficult to detect and manage. Like Heartbleed, the consequences of which have continued to unfurl for years, there’s already the fear that Log4j vulnerabilities could be a long-term problem. Not that hackers have waited a moment before attempting to take advantage of a newly disclosed vulnerability, of course. Within just a few hours, there were already a vast number of attempts at exploiting Log4j vulnerabilities. What’s more, the malicious activity being tracked has only continued to rise – one cybersecurity company says it took just days for attackers to target almost half of corporate networks.
Some of the first payloads dropped were cryptominers – malware that uses the processing power of the infected device to mine for cryptocurrency.  But much more dangerous threats soon followed. These included instances of penetration-testing tool Cobalt Strike being installed – something commonly used by attackers to steal usernames and passwords that are necessary to move around networks. That was followed by reports of ransomware that is exploiting Log4j. Take Khonsari, which is an incredibly basic form of ransomware, but ransomware groups are quick to adopt any techniques that increase the chances of compromising networks and successfully demanding a ransom, meaning more ransomware attacks leveraging Log4j are likely to follow. Then came the nation state-backed hacking groups looking to exploit the vulnerability – like they had with SolarWinds and Microsoft Exchange. Hacking operations working out of China, Iran, North Korea and Turkey were spotted attempting to leverage Log4j – and they’ll continue to make these moves for as long as they can. Work has already begun to repair the damage. CISA has mandated that federal agencies must patch the Log4j vulnerability within days. But for everyone else, the process could take years and there will be plenty of instances where, despite the critical vulnerabilities, some systems will never get the patch. Just look at EternalBlue, the catalyst behind WannaCry and NotPetya in 2017, which still regularly features among the most commonly exploited vulnerabilities and, years later, is still used by cyber criminals to launch attacks. Ultimately, as long as there are systems that are at risk from the Log4j vulnerability, there will be cyber criminals or nation state-backed hackers out there who will look to take advantage. And even if a high-profile organisation is under the impression that it’s protected against the vulnerability, there’s the possibility that attackers could compromise a supplier that doesn’t manage its IT as thoroughly. Criminals could then exploit that gap as a gateway to the larger, more lucrative target.

LOG4J FLAW COVERAGE - HOW TO KEEP YOUR COMPANY SAFE 

Log4j zero-day flaw: What you need to know and how to protect yourself Security warning: New zero-day in the Log4j Java library is already being exploited Log4j flaw could be a problem for industrial networks ‘for years to come’ 

It’s ultimately a quirk of how the internet works that so much harm could potentially come from an open-source project, operated and managed on a voluntary basis. The internet is a crucial part of our everyday lives, but instances like this Log4j vulnerability demonstrate how vulnerable it can be. Some experts will call for more rules and regulations over how the internet and computers ultimately work and fit together. That would be a difficult conversation, particularly given how so much of the infrastructure that helped make the internet what it is today is ultimately built from passion projects and volunteer schemes. Cybersecurity professionals were already burned out after a difficult few years. Another major cybersecurity event in the run up to Christmas won’t have helped anything. Unfortunately, Log4j will likely remain an issue through 2022 and beyond – we’re probably only scratching the surface of the risk and the hacking campaigns that will attempt to exploit this vulnerability. The best thing organisations can do, for now, is to follow the expert advice and apply updates to mitigate the potential damage – and then hope that similar vulnerabilities don’t emerge elsewhere any time soon to cause more damage and more burnout.