Nyhet -
Critical Vulnerability in Apache Log4J. This affects you.
A new Remote Code Execution (RCE) vulnerability (identified as CVE-2021-44228) has been discovered in the Apache module, log4j. Without wishing to sound alarmist, this may be the most serious vulnerability we’ve faced in the last decade. Once the dust has settled, it may be the most serious vulnerability in the history of modern cyber security.
If you’re reading this, it almost certainly impacts you.
What it means
Apache log4j is a Java-based logging framework that is used in a multitude of custom applications, off-the-shelf software, and cloud applications like Steam and Apple iCloud.
The list of applications impacted by this vulnerability is vast and growing hourly as our understanding of the problem develops. The log4j component is the defacto logging library for Java and is widely used within Java environments.
The security community has been working non-stop since Friday to get a handle on the extent of the problem, and there is some emerging understanding of what technologies are affected, but this is only the start of a very long story and we should anticipate that more affected systems will be revealed for several weeks to come.
The vulnerability is triggered via a variety of programmatic paths to the vulnerable log4j component, as the Minecraft component below illustrates. The attacker only needs an interface that accepts string input from outside, and somehow forwards that string to the underlying log4j component.
In one instance, the vulnerability has been exploited on the popular Minecraft gaming platform simply by typing a specially crafted message into the game’s chat window.
Log4 fun and profit
The exploit for this vulnerability is being referred to as ‘log4shell’ and involves creating a carefully crafted text string that finds its way through to the log4j logging component, where it causes the specified command to be executed on the underlying operating system.
The string that triggers the exploit can be crafted in a variety of different formats – a technique known as obfuscation. This makes detecting an attack via logs or on the network a significant challenge.
The exploit is what’s known as ‘blind’, meaning that the attacker doesn’t receive direct feedback on whether it succeeded. A typical approach would therefore be to attempt to trigger a ‘reverse’ connection from the exploited component to a server the attacker controls on the internet from which remote command and control can be established. Preventing outbound connections from internet-facing servers would help to mitigate this approach, but it is by no means the only option the attacker has. There are many avenues open to an attacker that don’t require real-time command and control, so this challenge really shouldn’t feature in your risk calculus. One popular vector so far has surprisingly been to deploy crypto coin mining malware.
We shouldn’t make the mistake of underestimating the creativity of our adversaries or the level of mayhem that this vulnerability will enable.
Attack activity
News of the vulnerability became publicly known on Friday, December 10th. However, there is evidence to suggest that there have been attempts to exploit the issue since at least December 1st, suggesting the exploit has been in the wild for at least 9 days before it was publicly disclosed. We may yet discover that the exploit is even older than that.
Since being publicly disclosed on the 10th, several exploits have been developed and published, and there are widespread reports of generic scans and targeted attacks.
The bottom line for you is simple: Firstly, you may already have been targeted using this vulnerability sometime in the past. Secondly, your internet-facing systems will certainly be facing scans for generic manifestations of the vulnerability and will be compromised if possible, even for something as banal as a botnet or a cryptocurrency miner. Finally, you should anticipate that the vulnerability will be exploited in more sophisticated, targeted attacks in the near future, and for lateral movement across your networks once an initial compromise has been accomplished in some other way.
What we know about the impact
As we mentioned before, our understanding of the scale of the problem is still in its early stages. Steele yourself for a long, ongoing struggle as the scope continues to expand.
Here’s what our Computer Emergency Response Team (CERT) has discovered to date (12 December):
Not-impacted products:
Palo Alto Networks will publish updates on a dedicated web page, but they have asserted that no product is affected, although this library is listed in their license documentation. F5, Pulse Secure, Check Point also confirmed they are not vulnerable.
Under investigation:
Among the vendors that are still investigating their products. For example:
Confirmed impacted products:
The following vendors already confirmed that some of their products are vulnerable:
As the vendors are still in the process of investigating this vulnerability, our CERT is engaged to continuously update our Vulnerability Intelligence Database (here). We will update you here on this blog, via our Managed Vulnerability Intelligence Watch service, or directly via the services you engage us for.
What we are doing
Our multi-disciplinary crisis management team has been engaged with this issue since we published our first World Watch advisory on Friday. We have been meeting regularly to communicate updates and track progress regularly all weekend. Our team includes:
- CERT
- Research
- The Office of the CISO
- Internal cybersecurity
- Internal IT
- Global operations – Managed Detection and Response and Vulnerability Management
- Penetration Testing
- Computer Security Incident Response Team (CSIRT)
Our efforts have focused on the following:
- Tracking the scope and the scale of the issue, variations, attack vectors, affected products, and potential mitigations;
- Engaging with our vendors and partners;
- Updating our customers via our World Watch advisory service;
- Updating our detection capabilities across our worldwide SOCs and CyberSOC;
- Updating our vulnerability scanning platform with the most current detections available;
- Triaging our own perimeter and internal systems to gauge the potential impact on our environment and ensure the safety and reliability of our customer services.
We will continue to work tirelessly to ensure the safety of our systems, and the integrity of our services, and to keep you, our customers, informed, updated, and supported as we work together to tackle this challenge and ensure there are no serious incidents.
What you should do
We can’t emphasize enough how urgent this issue is, and how vital it is that you take urgent action.
Given that this vulnerability has been actively exploited for several days now, however, rash and panicked responses probably won’t serve us either.
We advise our clients to prepare for a long process as new versions of the vulnerability emerge, more vendors publish details, and attackers continue to innovate and adapt.
Every environment is different, and businesses will have to conceive their own response based on their unique environments. We would propose the following priorities be considered:
- Focus on the internet and mitigate. Your first step should be to identify vulnerable internet-facing systems. A vulnerability scanner can be deployed for this purpose, and most have already been updated with appropriate signatures. However, the vulnerability is nuanced, and scanners will likely only identify the most basic cases. A better approach may be to engage a penetration testing team to manually search for vulnerable instances. You’ll want to equip the team with login credentials to any internet-facing web applications. Ultimately, however, you’ll want to identify any systems that use log4j, manually if necessary. If that’s not clear, identify any systems that use Java in some form and assume they are vulnerable. Patching log4j is the ideal course of action, but there are other workarounds that reduce the risk if patching is not possible.
- Limit outbound internet connections. As we mentioned already, a popular and dangerous technique used by attackers is to establish an outbound connection from a compromised system to their command-and-control server. You want to prevent this. Blocking outbound connections won’t prevent systems from getting compromised, but it will complicate the attacker’s ability to verify their exploit or leverage a compromise in a useful way.
- Communicate with your vendors. Many of the systems you own or use will be vulnerable. Unless you have a clear view of what software components they use, you will have to depend on them to advise you on the risk and potential mitigations. Your focus is to inventory your estate and establish a channel to your vendors.
- Patch log4j everywhere. Once you’ve controlled the risk of attack from the internet, you’ll want to thoroughly inventory every technology you have to identify all the systems that may be vulnerable. As we previously mentioned, an internal vulnerability scan is a good start, but the nature of the problem really requires that you find log4j wherever it may be hiding. Speak to your vendors, and assume that anything running Java needs to be examined closely.
- Detect attacks and limit the impact. Detection is certain to be a constant game of cat and mouse for several weeks to come. Our initial efforts are likely to be naïve, but our capabilities will improve over time. Set yourself up to implement detections on your firewalls, web servers, proxies, Web Application Firewalls, and servers. Expect to have to deal with a high level of false positives and to have to adapt and test repeatedly.
- Defense in depth. The threat of an 0day exploit is not new and we’ve long understood that we need to engineer our controls on the assumption that some systems will be compromised. Our response has always been ‘defense in depth’, which means we patch everything we can, deploy endpoint protection, enforce strong authentication and limit user privileges, limit network traffic in, out, and across your network, and search for anomalous behaviors wherever you can. Deception, for example via Thinks ‘Canaries’, will improve your ability to detect and respond to the worst case. And speaking of the ‘worst case’, consider establishing a relationship with a professional CSIRT that you can access if you detect signs of compromise.
The terrifying scope and scale of this issue is a ‘first’ for the industry. But like other security threat firsts in our space, our collective efforts will allow us to tackle the threat, manage it, and emerge wiser and stronger on the other end.
