When news broke of the Log4J vulnerability, IT administrators were desperate to find solutions to protect against it. The vulnerability is exposing thousands of applications all around the world to a very simple attack. Amazon Web Services, Microsoft, Cisco, Google Cloud and IBM have all discovered that at least some of their services were vulnerable to the attack.
In this Spotlight, we approach Log4J from two perspectives. First, we look at the materiality of the exploit and what this means for companies in the long-term. Second, we provide pointers on what organisations can do now to prevent threat actors from leveraging Log4J.
The Log4J Vulnerability Will Haunt the Internet for Years (Wired.com)
The materiality of the attack comes from at least two things. First, the vulnerability is very easy to exploit. All attackers have to do is log a strategically crafted string into a targeted server, for instance, by sending an email, setting the string as a username, or sending it in the chat function. Second, the vulnerability has a long tail, meaning its full impacts have yet to materialise. Attackers can use Log4J as an initial infection vector and then spend weeks or months moving across corporate networks before taking any action, such as detonating ransomware or exfiltrating intellectual property.
Evidence suggests that nation-state attackers are already exploiting the vulnerability. Former NSA hacker Jake Williams commented on this: “If you have an internet-facing server vulnerable to Log4Shell that you haven't patched yet, you almost certainly have an incident response on your hands.”
All of this means that the impacts of Log4J will slowly trickle in over the coming weeks and months when attackers come out of their stealth mode and unleash payloads.
What can companies do to evade Log4J? Sygnia’s advisory: Log4Shell remote code execution
Cybersecurity company Sygnia has published actionable step-by-step guidance on what companies can do to evade Log4J.
Sygnia’s advice is based on four workstreams:
- Identify vulnerable assets – one of the main challenges in addressing Log4Shell is figuring out which applications are vulnerable. Mapping the Log4Shell attack surface is key to correctly prioritising mitigation activities.
- Remediate vulnerable applications – patching vulnerable applications or specifically blocking vulnerable features in the log4j library.
- Reduce the attack surface – blocking attackers’ ability to exploit the vulnerability reliably, even if it still exists in the environment.
- Enhance visibility – it’s possible to identify attackers exploiting Log4Shell in your environment. However, some configuration changes may be required to facilitate the detection and investigation of such attempts.
Sygnia’s report provides step-by-step guidance on the technical steps required within each workstream.
