News recently broke of a vulnerability affecting digital systems across the internet, leaving them exposed to account takeover by hackers. In fact, threat actors are already attempting to exploit the vulnerability and researchers are warning of serious repercussions worldwide. The problem lies in Log4j, a ubiquitous, open-source Apache logging framework that developers use to keep a record of activity within an application. The list of services with Internet-facing infrastructure that is vulnerable to a critical zero-day vulnerability in the open-source Log4j logging utility is immense and includes some of the biggest names on the Internet, including Apple, Amazon, Cloudflare, Steam, Tesla, Twitter, and Baidu.
<p>Are we witnessing a match made in heaven? Apparently, a ransomware attack is currently exploiting the Log4Shell vulnerability. It\’s the Khonsari ransomware gang who has built an attack using C# and the .NET framework. </p>
<p>After execution, the malware enumerates all mounted drives (other than C:/) and targets user directories including Documents, Videos, Pictures, Downloads, and Desktop. An AES 128 CBC algorithm is used for encryption, and the files are saved with a .khonsari extension.</p>
<p>There are no signs that the Log4Shell vulnerability is slowing down, in fact a second CVE (CVE-2021-45046) just got announced. In the second and third stages, threat actors are aggressively deploying malware families. Among them are Kinsing, XMR, and Mirai. Additionally, some coin-miners and CobaltStrike beacons have been observed in the wild. Nearly 2000 malicious IOCs have been observed so far, which require immediate attention.</p>
<p>The Log4Shell data breach is making a considerable industry impact as the attack opens doors to every other type of possible cyber threat. If the attack isn’t contained as soon as possible, there is a risk of wider implications. We therefore need to be prepared for multiple waves of attacks. </p>
<p>To exploit Log4shell, you only need a basic understanding of Java technology. So, in theory, there are seven million people capable of performing such an attack. The scale of this attack is also unpredictable as the effort-to-benefits ratio of Log4shell is unprecedented. We could safely assume that many organisations already have their systems compromised by malware or attacks that are yet to be identified. </p>
<p>What this attack does highlight is the industry’s demand for new AI-driven ways to fight against cyberattacks by bringing machine learning to Web application firewalls. One of the scenarios commonly worked on is anomaly detection on logs at scale. However, even the companies that invested in modernising their log analytics still have a way to go in battling such sophisticated attacks. </p>
<p>Any breach stemming from Log4shell (or similar) will still require teams to reprovision and reinstall every affected environment, and to drive a full investigation into all affected systems. At present, the method to contain such an attack requires a high level of tools and automation that are typically reserved for cyber defence pure players. Companies need to level up and engage with sophisticated AI tools to bolster their cybersecurity defences.</p>
<ol>
<li><strong>Make sure that your security operations center is actioning every single alert on the devices that fall into the category above:</strong> “There are a wide range of methods hackers can use to access personal information through Log4j’s vulnerability. The human effort required to detect and action each event is simply unrealistic.”</li>
<li><strong>Install a web application firewall (WAF) with rules that automatically update, so that your SOC can concentrate on fewer alerts:</strong> “Firewalls aren’t going to stop hackers. They still have plenty of other ways to break into organizations’ systems through Log4j, which are undetectable by the firewall. This includes malicious code embedded into JSON, XML, and other common data structures that power nearly every website and application.”</li>
<li><strong>Enumerate any external facing devices that have Log4j installed:</strong> “The focus on ‘external facing’ devices is a mistake, as many internal systems also log data that originated from an untrusted source.”</li>
</ol>
<p>Log4j is a library that is built into the logging functionality of a very large part of the internet. It is embedded/used by a ton of software that run websites, clouds, security services, games, etc… Because logs are important for security, debugging, and audit trails, it is very common for some part of user controlled data to go directly into log files. Those two aspects, coupled by the trivial nature of exploitation of this vulnerability make it very serious.</p>
<p>Attackers only need to find a vector by which they can cause a crafted string to be inserted into a logfile of a vulnerable system. Once they have achieved that, the impacts to an enterprise can be wide. Obviously they could gain a foothold on the victim’s network; that foothold may be privileged if the product that was compromised was an administrative or security component. They can also leak environment variables from the compromised systems which can lead credentials being leaked (if they are stored in an environment variable). Additionally, because of the embedded nature of this library into other software, as a consumer, it is very difficult to tell what products you have in your environment that might be using it. If you can’t do that first task quickly or completely, mitigation becomes very difficult.</p>
<p><span style=\"font-family: Arial;\">CVE-2021-44228 is one of the most pervasive security vulnerabilities that organizations have had to deal with over the past decade. Organizations are challenged with identifying all of the vulnerable Log4j instances across their enterprise. Patching isn\’t trivial. Many vendors are still determining whether their software uses Log4j, as organizations eagerly wait to know if they should apply emergency patches. Closed box systems, vendor-managed systems, and software that\’s no longer maintained (but still running in test or even production environments) adds to the complexity and pain.<br /><br />Organizations need to think about several key things as they work to tackle this problem:<br />1. They need to discover the systems and applications that use Log4j (which may include secondary and tertiary systems that data is passed to).<br />2. They need to apply patches where they can. <br />3. They need to anticipate that they may never find all vulnerable instances, so they should apply mitigations across the enterprise to reduce the exploitability and impact of attempts.<br />4. They need to assess/manage the risk of their vendors and partners.<br />5. They need to determine if instances have already been exploited and then investigate it accordingly.<br /><br />The slightly positive news is that most exploitation observed so far is automated in nature, which means responses and investigations will be relatively easier. But there\’s so much noise right now – and separating the noise from the deliberate and targeted intrusions can be difficult.</span></p>