Publikációk:
Statement from CISA Director Easterly on “Log4j” Vulnerability | CISA
Patch Now Apache Log4j Vulnerability Called Log4Shell Actively Exploited (trendmicro.com)
Blogposztok:
Webinar-ok:
Dragos: Thursday, December 16.
Recorded Future: December 15 at 11:00 AM ET
Update 1.
CISA Adds Log4J to Catalog of Known Exploited Vulnerabilities*
(December 10, 11, & 13, 2021)
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.
Editor’s Note
[Ullrich]
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…
[Neely]
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.
[Spitzner]
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. www.youtube.com: What do you need to know about the log4j (Log4Shell) vulnerability?
Read more in:
– www.cisa.gov: Statement From CISA Director Easterly on “Log4j” Vulnerability
– www.scmagazine.com: CISA adds Log4j to critical vulnerabilities list, warns industry to follow similar guidelines
– arstechnica.com: The Internet’s biggest players are all affected by critical Log4Shell 0-day
– gist.github.com: SwitHak/20211210-TLP-WHITE_LOG4J.md
Log4Shell Exploit is Going to be Around for a Long Time*
(December 13, 2021)
The US Cybersecurity and Infrastructure Security Agency (CISA) estimates that there are hundreds of millions of devices that are vulnerable to Log4Shell. Rob Joyce said that “The log4j vulnerability is a significant threat for exploitation due to the widespread inclusion in software frameworks, even NSA’s GHIDRA. This is a case study in why the software bill of material (SBOM) concepts are so important to understand exposure.” Jake Williams said that “if you’re patching #log4j today on an Internet facing service, you need to be doing an incident response too. The reality is that someone else almost certainly beat you to it. Patching doesn’t remove the existing compromise.”
Editor’s Note
[Neely]
When Log4j was introduced, it provided visibility and logging capabilities to our Java applications and services which we all leveraged and it is now included in many packages and distributions, meaning you’re going to have to work to make sure that it’s updated everywhere, particularly where embedded and you’re reliant on a third-party update. You need to take active steps to monitor and protect yourself, as well as verify you’re not already compromised. When you’re done updating, don’t turn off the monitoring.
[Honan]
It’s also important to note that if you scan for this vulnerability and discover your system is patched, make sure it was you who applied that patch. Criminals are known to patch systems they compromise to prevent others from doing the same.
Read more in:
– www.govinfosecurity.com: Already Compromised by Apache Log4j? Check Before You Patch
– www.cyberscoop.com: CISA warns ‘most serious’ Log4j vulnerability likely to affect hundreds of millions of devices
– www.scmagazine.com: Log4j vulnerability cleanup expected to take months or years
– www.wired.com: The Log4J Vulnerability Will Haunt the Internet for Years
– twitter.com: Jake Williams
– twitter.com: Rob Joyce
* Forrás: SANS NewsBites