CISA Adds Log4J to Catalog of Known Exploited Vulnerabilities
In a statement over the weekend, Cybersecurity and Infrastructure Security Agency (CISA) director Jen Easterly said, “We have added this vulnerability to our catalog of known exploited vulnerabilities, which compels federal civilian agencies -- and signals to non-federal partners -- to urgently patch or remediate this vulnerability.” GitHub’s list includes hundreds of affected services with links to each service’s security advisory.
CVE-2021-44228, or log4shell as the vulnerability has been named, has kept us all pretty busy this weekend. We have only seen the beginning of what will be a vast effort to protect from this vulnerability. Most attacks are currently attempting to very simply “spray” the exploit string into frequently logged fields. Over time, attackers will get better at targeting specific software packages. We have seen a bit of this with VMware vCenter. Affected security tools present a huge target attackers will not miss to exploit. Dealing with log4shell, make sure to preserve your notes. History has shown that once a high profile vulnerability like this is found, people will look for similar issues in other tools, and also take a deeper look at the affected library. JNDI is not unique to log4j and a well-known issue. Another "lesson learned" of this still evolving incident: Secure configurations matter. The vulnerability may be mitigated by disabling the risky JNDI feature, and it looks like log4j will start shipping with it disabled by default. But for now: patch... patch... patch...
If you’re using Log4J 1.x, it is no longer supported, and you need to move to Log4j 2. Update to at least Log4J 2.16. Even so, you need to take actions to ensure you’re secure. Enumerate your externally facing devices with log4j installed, make sure your SOC is monitoring all the alerts from them and configure a WAF to reduce the attack surface and volume of alerts. If you have applications developed in Java and you have been contemplating migrating them to another technology you may want to execute that plan, particularly if you no longer have your Java expertise.
What makes this vulnerability so unique is just how ubiquitous it is (if your system, application or device is logging it could be vulnerable) but what is also unique is the attack surface. For this attack you are not remotely connecting to a specific port for a specific application, instead you are attacking any input that logs that input, such as connections to a Webserver, email filtering, etc. For an excellent overview of the attack and defenses, check out the webcast by SANS and instructors. https://www.youtube.com/watch?v=oC2PZB5D3Ys