The remotely exploitable Log4j vulnerability, mentioned in an earlier post, is still a hot topic and still represents a critical flaw in many systems. As Liam Tung notes, the vulnerability is “being attacked by multiple actors and likely will remain so for many more months.”
The bug is being tracked as CVE 2021-44228 and has been partially fixed in the Apache Foundation's recent updates, the most current of which is Log4j version 2.16.0. “Most efforts are now focused on vendors updating Log4j in their products and end-user organisations applying updates as they become available,” says Tung.
Still, the situation remains complicated, and, as Matt Asay notes, the various hot takes about the root cause of the vulnerability are not helpful. He quotes Matt Klein, of the open source Envoy project, who says “complaining about the villain of the day ([open source] funding, memory safety, etc.) is a red herring, and over-focusing on one cause leads to no real improvement. We are all human and juggling a mountain of constraints; it's a miracle that tech works 1% as well as it does."
As is the case with other major vulnerabilities, Log4j exploits are likely to continue for months, if not years, which means mitigation efforts must continue as well. Steve Povolny, head of advanced threat research for McAfee Enterprise and FireEye, told ZDNet that Log4Shell "now firmly belongs in the same conversation as Shellshock, Heartbleed, and EternalBlue."
"Attackers began by almost immediately leveraging the bug for illegal crypto mining, or using legitimate computing resources on the Internet to generate cryptocurrency for financial profit... Further exploitation appears to have pivoted towards theft of private information," Povolny said.
Cybersecurity and Infrastructure Security Agency (CISA) Director Jen Easterly, in a statement, urges all organizations to upgrade to the latest version of Log4j or apply vendor-recommended mitigations immediately. Organizations should also:
- Enumerate any external facing devices that have log4j installed.
- Make sure that your security operations center is actioning every single alert on the devices that fall into the category above.
- Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts.
Easterly adds that “this effort also underscores the urgency of building software securely from the start and more widespread use of Software Bill of Materials (SBOM)” as directed by President Biden earlier this year. An SBOM, Easterly says, “would provide end users with the transparency they require to know if their products rely on vulnerable software libraries.”
Looking for a job?
Check out the latest job listings at Open Source JobHub.