One Identity Offers Free Security Risk Assessment to SolarWinds Customers and Free Safeguard for Proactive Privilege Defense

Comments: Protect Yourself Against the Apache Log4j Vulnerability

Comments by: Lotem Finkelstein, Director, Threat Intelligence and Research for Check Point Software Technologies 

I cannot overstate the seriousness of this threat. On the face of it, this is aimed at crypto miners but we believe this creates just the sort of background noise that serious threat actors will try to exploit in order to attack a whole range of high value targets such as banks, state security and critical infrastructure.

Since Friday, CPR witnessed what appears to be an evolutionary repression, with new variations of the original exploit being introduced rapidly — over 60 in less than 24 hours. It looks almost limitless. For example, it can be exploited either over HTTP or HTTPS (the encrypted version of browsing). The number of combinations of how to exploit it gives the attacker many alternatives to bypass newly introduced protections. It means that one layer of protection is not enough, and only multi layered security posture would provide a resilient protection.

Unlike other major cyber-attacks that involve one or limited number of software, Log4j is basically embedded in every Java based product or web service. It is very difficult to manually remediate it . Once an exploration was published (on Friday), scans of the internet ensued (to allocate surfaces which are vulnerable due to this incident). Those who won’t implement a protection are probably already scanned by malicious actors. We already saw over 470,000 attempts to scan networks of around a third of all enterprises globally. Most worrying is the fact that almost half of those attempts were made by known malicious groups.

This vulnerability, because of the complexity in patching it and easiness to exploit, will stay with us for years to come, unless companies and services take immediate action to prevent the attacks on their products by implementing a protection. Now is the time to act. Security teams need to jump on this with utmost urgency as the potential for damage is incalculable. The need for a rapid response is highlighted by the fact that this was discovered at the end of the working week in the run up to the holiday season when security teams may be slower to implement protective measures.  

At Check Point Software we have, for several months, been sounding the alarm about a ‘cyber pandemic’ and this is exactly what we are referring to. It’s highly contagious and spreads rapidly, so constant vigilance and a robust prevention strategy are essential.

Comments by: Tim Mackey, principal security strategist, Synopsys Cybersecurity Research Center

Apache log4j is the de-facto way Java applications write their log information. This means that a very large number of applications are potentially impacted by CVE-2021-44228, and we’ve already seen reports of just how easy it is to trigger the exploit. That’s the worrisome aspect of most zero-day vulnerabilities – that it’s easy to trigger and impacts a ubiquitous piece of software. In this case, exploit of CVE-2021-44228 can allow remote code to be executed, and while that’s problematic enough, the reality is there are likely other potential outcomes from an exploit – we just haven’t seen them or heard them reported. That’s because vulnerability disclosure isn’t a point in time activity. Instead, the disclosure serves as a trigger for security researchers and attackers alike to identify what other potential weaknesses the impacted code might have.

Protecting against exposure to CVE-2021-44228 starts with a basic element of software supply chain risk management – know the code that powers your business. If you don’t know which applications run Java and have a vulnerable version of log4j, then you can’t guarantee you’ve patched everything. If you’re relying on periodic scans of software or configurations to determine whether you’re exposed to something, then it’s time to start looking at continuous monitoring for software supply chain issues and possibly implementing automated pen-testing capabilities. After all, it’s always possible for a vulnerable version of something that should’ve been patched to be used elsewhere or by a different supplier. 

This site uses Akismet to reduce spam. Learn how your comment data is processed.