News about a critical vulnerability in the Apache Log4j logging library broke last week when proof-of-concept exploits started to emerge on Thursday.
Log4j is an open-source Java logging framework part of the Apache Logging Services used at enterprise level in various applications from vendors across the world.
Apache released Log4j 2.15.0 to address the maximum severity vulnerability, currently tracked as CVE-2021-44228, also referred to as Log4Shell or LogJam.
While massive exploitation started only after exploit code became freely available, attacks have been detected since the beginning of the month, according to data from Cloudflare and Cisco Talos.
The Log4Shell flaw was reported by Alibaba’s Cloud security team on November 24 and it is unclear how some attackers were able to exploit it this soon.
In a statement on Saturday on the Log4Shell vulnerability, Jen Easterly, the director of the Cybersecurity and Infrastructure Security Agency (CISA), says that the agency is working with partners in the private and public sector to address the issue.
“We are taking urgent action to drive mitigation of this vulnerability and detect any associated threat activity. 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” – Jen Easterly, Director of CISA
Log4Shell is a Java Naming and Directory Interface (JNDI) injection that allows unauthenticated remote code execution. Adversaries can leverage it by changing the user-agent in their browser to a string in the following format:
The string will remain in the victim web server’s logs and will force a callback or request to the attacker’s URL when the Log4j library parses it. Attackers can use the string to pass encoded commands or Java classes to the vulnerable machine.
Advisories, notices, patches, or updates
Given the severity of the vulnerability and how easy it is to exploit it, CISA today released guidance for companies to set up defenses against Log4Shell attacks. The agency’s recommendation is to “apply available patches immediately” and to prioritize this process.
“Prioritize patching, starting with mission critical systems, internet-facing systems, and networked servers. Then prioritize patching other affected information technology and operational technology assets” – CISA
If patching is not possible, the agency recommends the following change:
log4j2.formatMsgNoLookups to true by adding the string
-Dlog4j2.formatMsgNoLookups=True to the Java Virtual Machine command for starting an application
This comes with the caveat that the system’s logging may be impacted if it relies on Lookups for message formatting. Also, the mitigation works only for versions 2.10 and later.
Immediately after details about Log4Shell became known, vendors started to investigate if their products are impacted and provided information about the results:
Amazon has updated several of its products to use a non-vulnerable version of the Log4j component and announced that it is either in the process of updating others or will release new versions in the near future.
The company has published details specific for affected services, among them being OpenSearch, AWS Glue, S3, CloudFront, AWS Greengrass, and API Gateway.
Based on its assessment, the company believes that no on-premise products are vulnerable to exploitation in their default configuration.
Modifying the default logging configuration (log4j.properties) to enable the JMS Appender functionality may bring the risk of remote code execution in some products, like Jira Server & Data Center, Confluence Server & Data Center, Bamboo Server & Data Center, Crowd Server & Data Center, Fisheye, and Crucible.
The company published mitigations and knowledgebase articles for several Symantec products affected by the Log4j vulnerability. These include CA Advanced Authentication, Symantec SiteMinder (CA Single Sign-on), VIP Authentication Hub, and Symantec Endpoint Protection Manager (SEPM).
Cisco has published a list of its products affected by Log4Shell along with a calendar for patching some of them starting December 14.
Affected products are from various categories, including the following:
While the investigation is still underway and the status may change for some of its products, Citrix has not listed any of its products as being vulnerable to Log4Shell.
The company’s cloud service, Perch, was found to rely on third-party components that were “potentially vulnerable,” reads an advisory from ConnectWise.
The vulnerable third-party was identified as FortiGuard’s FortiSIEM, which is used by ConnectWise’s StratoZen solution, prompting the company to temporarily restricting access to the hosted StratoZen servers. Access is now restored to most of the services.
A forum thread shows that only instances where the cPanel Solr plugin is present are affected and could be exploited, but only locally.
A staff member provided additional piece of mind announcing that an update with mitigation for Log4Shell is available to the cpanel-dovecot-solr package.
The patched Log4j package has been added to Debian 9 (Stretch), 10 (Buster), 11 (Bullseye), and 12 (Bookworm) as a security update, reads the advisory.
Docker says that it is “in the process of updating Log4j 2 in these images to the latest version available” and that the images may not be vulnerable for other reasons.
An advisory from the company lists almost a dozen of its products as being vulnerable, with fixes or mitigations already deployed for four of them.
FortiGuard announced that the advisory would be updated with the dates for applying fixes for other products, such as FortiSIEM, FortiInsight, FortiMonitor, FortiPortal, FortiPolicy, and ShieldX.
Both Windows and Linux versions of several F-Secure products are impacted by Log4Shell: Policy Manager (only the Policy Manager Server component), Policy Manager Proxy, Endpoint Proxy, and Elements Connector.
The company has created a security patch for administrators to correct the issue and provided step-by-step instructions to deploy it.
The open-source reverse engineering tool from the NSA received an update to version 10.1 that also upgrades the Log4j dependency to a non-vulnerable iteration.
IBM’s advisory for Log4Shell shows that only WebSphere Application Server versions 9.0 and 8.5 were affected by the vulnerability, via the Admin Console and the UDDI Registry Application components, and that the issue has been addressed.
The networking company disclosed that four of its products are impacted: Paragon Active Assurance, Paragon Insights, Paragon Pathfinder, and Paragon Planner.
While the assessment continues, at this stage another six products may be affected: JSA Series, Junos Space Management Applications, Junos Space Network Management Platform, Network Director, Secure Analytics, and Security Director (not Security Director Insights)
The company has yet to complete its assessment and has 12 products under review and will update the advisory with relevant information as it becomes available.
Only MongoDB Atlas Search needed to be patched against Log4Shell, the company notes in an advisory updated today
The developer adds that it found no evidence of exploitation or indicators of compromise before deploying the patch.
Okta released updates for Okta RADIUS Server Agent and Okta On-Prem MFA Agent to mitigate the risk from the Log4Shell vulnerability and strongly recommends customers to apply the fixes from the Admin Console.
Oracle said that “a number” of its products, without disclosing which ones or how many, are using a vulnerable version of the Log4j component.
The company referred its customers to the My Oracle Support Document and released a security alert with a strong recommendation to apply the provided updates “as soon as possible.”
An advisory on Friday revealed that versions of the Zed Attack Proxy (ZAP) web app scanner below 2.11.1 use a vulnerable Log4j component.
Components in multiple Red Hat products are affected by Log4Shell, the organization disclosed on Friday, strongly recommending customers to apply the updates as soon as they become available.
Among the products listed in the advisory are Red Hat OpenShift 4 and 3.11, OpenShift Logging, OpenStack Platform 13, CodeReady Studio 12, Data Grid 8, and Red Hat Fuse 7.
Two products from the company use a vulnerable version of Apache Log4j: Server & Application Monitor (SAM) and Database Performance Analyzer (DPA).
However, both products use a version of the Java Development Kit (JDK) that is either not susceptible to the Logj4 vulnerability or reduces the risk.
An investigation that is ongoing revealed that SonicWall’s Email Security version 10.x is impacted by the Log4Shell vulnerability. A fix is under development and should be released “shortly.”
Five other products from SonicWall are still under review and the rest of them have been found not to be impacted by the issue, according to an advisory from the company last updated on Saturday.
Core Splunk Enterprise is not affected unless Data Fabric Search is used. The company published a table with the versions of its products affected by Log4Shell both in the cloud and on-premise.
At the time of writing, the company has released fixes for some products and is currently working on rolling updates for at least seven of its products.
VMware has fixed several of its products vulnerable to Log4Shell attacks and is currently working to roll out patches for another 27 products.
In an advisory last updated today, the company lists nearly 40 of its products as impacted by the critical vulnerability. Many of them show a “Patch Pending” and mitigations are available in some cases.
The UniFi Network Application, which uses the Log4j library, has been updated to address the critical Log4Shell vulnerability.
The Log4j package has been patched upstream, reads the security advisory, and the update now has to trickle to Ubuntu 18.04 LTS (Bionic Beaver), 20.04 LTS (Focal Fossa), 21.04 (Hirsute Hippo), and 21.10 (Impish Indri).
The company found that the ADAudit Plus component for auditing Active Directory changes, which is part of the ManageEngine monitoring solution is vulnerable to Log4Shell attacks.
In a short post today, Zoho has provided instructions to mitigate the issue.
Zscaler has patched several of its products that used a vulnerable version of the Log4j library. After patching all of its Private Access (ZPA) services facing the public internet, Zscaler Mobile Admin, and Support Mobile Admin components, the company concluded that the issue has been fixed in all its products.
Some companies may choose not to take action against Log4Shell vulnerability believing that running certain Java versions diffuses any exploit attempt. This is not true, though, and they should update the Log4j library to its most recent iteration.
Márcio Almeida, senior security engineer at Canva graphic design platform warns that Log4Shell attacks work with any version of Java when adding support for LDAP serialized payloads in the JNDI exploit kit.
The researcher explains that for the attack to work with any version of Java the classes used in the serialized payload need to be in the application classpath.
This content was originally published here.