Flaw in Log4j needs immmediate remediation

After nearly two years of adopting major network and security changes wrought by COVID-19 and hybrid work, weary IT network and security teams didn’t need another big issue to take care of, but they have one: Stemming potential damage from the recently disclosed vulnerability in open source Java-logging Apache Log4j software.  

Log4j or Log4Shell has been around a long time—it was released in January, 2001—and is widely used in all manner of enterprise and consumer services, websites, and applications. Experts describe the system as an easy-to-use common utility to support client/server application development.

The Log4j weakness, defined in CVE-2021-44228  and CVE-2021-45046 in the National Vulnerability Database, basically lets an unauthenticated remote actor take control of an affected server system and gain access to company information or unleash a denial of service attack.

There is a remedy to the problem, so organizations should immedialty upgrade to Log4j 2.16.0 to be protected against both CVEs, experts say.

Still, the impact of the vulnerability could be extensive because it has been in the wild so long and becaise Log4j is so widely used. The Log4j library is embedded in almost every internet service and application including Twitter, Amazon and Microsoft, according to Check Point. 

“Log4j worms could damage critical infrastructure, and it is a national security threat already,” said Tom Kellermann, head of Cybersecurity Strategy for VMware. “Bad nation state actors are already exploiting it as we speak.”

For example, Check Point says it has seen over 2.8 million attempts to exploit the vulnerability and over 46% of them were made by known malicious groups as of Dec. 16. “We have so far seen an attempted exploit of over 47% of corporate networks globally,” Check Point stated.

Cisco’s Talos security research unit stated that it has seen attempts to place the Log4j Java Naming and Directory Interface (JNDI) attack string in email. “At this time we have not identified widespread email campaigns attempting to use email messages to trigger the vulnerability. It is potentially recon as many threat actors and researchers are essentially trying everything in an attempt to find something that eventually hits log4j,” the group stated.

“The biggest issue for enterprise customers is the amount of systems that could be impacted because logging systems are so widespread and while Internet facing servers might be highly vulnerable, it’s the downstream servers linked to them that are also problematic,” said Nick Biasini, head of outreach with Cisco Talos. “In addition organizations batch process logs that may not be processed for weeks so the exploit effects will be felt a long time out.”

“The Log4j vulnerability is extremely widespread and can affect enterprise applications, embedded systems and their sub-components,” Jonathan Care a research director at Gartner Research said in a statement. “Java-based applications including Cisco Webex, Minecraft, and FileSilla FTP are all examples of affected programs, but this is by no means an exhaustive list. The vulnerability even affects the Mars 2020 helicopter mission, Ingenuity, which makes use of Apache Log4j for event logging.” 

Care noted that the security community has created lists cataloging vulnerable systems and it includes major network players such as Cisco, Juniper, Arista, Palo Alto, and VMware as well as other big industry players such as IBM, AWS, and Google.

“However, it’s important to note that these lists are constantly changing, so if a particular application or system is not included, don’t take it as assurance that it isn’t impacted,” Care stated.  “Exposure to this vulnerability is highly likely, and even if a particular tech stack does not use Java, security leaders should anticipate that key supplier systems—SaaS vendors, cloud hosting providers and web server providers— do,” Care stated.

Remediation

There are a number of things enterprises can do to respond to the Log4j vulnerability, experts said.

“Enterprise users should deploy the Log4j 2.16 patch immediately, but they can also microsegment outbound traffic to prohibit new connections,” said Kellermann.  “They also need to monitor for abnormal traffic flows in those environments and expand their threat-hunting capacity.”

VMware said that it has responded to the Log4j situation in a number of its products. For example NSX Distributed IDS/IPS and NSX Network Detection and Response (NDR) signatures have been released that detect Log4J exploit attempts, including obfuscation methods seen in the wild. These signatures will detect and prevent attempts to exploit vulnerabilities regardless of origination, VMware stated.

Cisco, Palo Alto, AWS and others have also responded to the vulnerability.

Gartner’s Care said cybersecurity leaders need to make identification and remediation of this vulnerability an absolute and immediate priority.

“Start with a detailed audit of every application, website and system within your domain of responsibility that is internet-connected or can be considered public-facing. This includes self-hosted installations of vendor products and cloud-based services,” Care stated. “Pay particular attention to systems that contain sensitive operational data, such as customer details and access credentials.”

Once this audit is complete, turn your attention to remote employees, and ensure that they update their personal devices and routers, which form a vital link in the security chain, Care stated.

“This will likely require a proactive, involved approach, as it is not sufficient to simply issue a list of instructions, given vulnerable routers provide a potential entry point into key enterprise applications and data repositories,” Care stated.  “You’ll need the support and cooperation of the broader IT team.”

The US Cybersecurity and Infrastructure Security Agency (CISA) recommends organizations take three additional, immediate steps regarding this vulnerability: “Itemize 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; and Install a web application firewall (WAF) with rules that automatically update so that your SOC is able to concentrate on fewer alerts.”

Other Log4j activities

• IBM’s X-Force created a scan tool to detect Log4Shell. You can access it, at no cost, here: https://github.com/xforcered/scan4log4shell.
• Microsoft stated that because this vulnerability is in a Java library, the cross-platform nature of Java means the vulnerability is exploitable on many platforms, including Windows, macOS, and Linux. As many Java-based applications can leverage Log4j 2 directly or indirectly, organizations should contact application vendors or ensure their Java applications are running the latest up-to-date version. Developers using Log4j 2 should ensure that they are incorporating the latest version of Log4j into their applications as soon as possible to protect users and organizations.
• Microsoft also stated that Azure App Service and Functions does not distribute Log4J in the managed runtimes such as Tomcat, Java SE, JBoss EAP, or the Functions Runtime. However, applications may use Log4J and be susceptible to this vulnerability. Customers are recommended to apply the latest Log4j security updates and re-deploy applications.
• Cisco Talos has released seven new ClamAV signatures for CVE-2021-44228 and CVE-2021-45046. A new Snort Signature ID, 58795, has also been released.