Researchers warn that attackers are actively exploiting the newly announced unauthenticated remote code execution vulnerability in Log4j (Apache’s Java-based logging tool). Although most of the work of mitigating CVE-2021-44228 is undertaken by application owners and software developers, corporate security teams must also do their part to ensure the security of their organizations.
This technical tip provides short-term mitigation measures for affected enterprise security teams who have no updates available yet, for any reason, cannot install the update immediately, or will not receive the update at all.
Consider the following scenario: The vendor has a financial application that uses Java and a vulnerable version of Log4j. Any organization that uses a client application to access the Java application is also vulnerable to remote code execution, because the client may also use Log4j. In this case, the organization is in a more difficult situation because it must wait for the supplier to update the main application and client. For legacy applications, this will never be possible.
Karl Sigler, senior security research manager at Trustwave SpiderLabs, said: “Any Java application that uses the affected log4j version and is accessible via the network can be exploited. Many of these applications may be third-party applications and are beyond the user’s management. Control range.”
Step 1: Determine exposure
potential Attack surface Luke Richards, head of threat intelligence at Vectra, said it is huge. Randori has an app This helps to check whether the log4j instance is vulnerable.You can search for the existence of JAR files log4j-core-*.jar Determine if log4j is being used.
The security vulnerability (CVE 2021 44228) exists in Log4j versions prior to 2.14.1, so any Java application that uses a vulnerable version is at risk. Many Apache tools have vulnerabilities — Struts 2, Solr, Druid, and Fink — but the problems are far beyond this list because Java is so widely used in enterprises.
The total number of scans for Log4j vulnerabilities has tripled in one day, BitDefender Lab Say. These figures are based on telemetry data from Bitdefender’s global honeypot network. The team stated that most of the scans came from Russian IP addresses.
Richards said that the initial vector is also difficult to detect because it needs to look at a specific string in the log. Richards said that analysts can view the raw input of the log4j server and alert on all LDAP external connections, or look for external connections from the log server to Java class files.The pattern in the text field, for example User agent: /${jndi:.*/ It was “a clear sign of an attempt to sabotage the server,” Richards said.
Avi Shua, co-founder and CEO of Orca Security, said that organizations need to determine which applications are using vulnerable components. One way is to use continuous scanning tools. Externally facing assets should be blocked. “We recommend blocking external-facing applications that use vulnerable libraries unless it can be determined that this vulnerability is not exploitable or an updated version has been released,” Shua said.
Yarra Rules
Attempts to find potential compromises have also been published.
Richards recommends finding hosts that might run log4j (such as Apache Tomcat and Struts) and moving them to a group for easy monitoring and follow-up.
In the initial scenario, the organization blocked LDAP, and possibly RMI and CORBA. Sigler said that end users can update with others in the group. The organization should block LDAP traffic (and possibly RMI and CORBA, depending on future variants) and monitor the traffic.
Step 2: Apply mitigation measures
Update to the latest version of Java because it will prevent the use of LDAP to load remote code libraries, said Bojan Zdrnja, senior lecturer at the SANS Institute and chief technology officer of INFIGO. “The current exploit mechanism is blocked by the latest version of Java. It sets com.sun.jndi.object.trustURLCodebase It’s true,” Zdrnja said.
if Log4j cannot be updated,set up log4j2.formatMsgNoLookups Set the parameter to true when starting the Java virtual machine to make the vulnerability unexploitable, Apache said in its consultation. The command line options are -Dlog4j.formatMsgNoLookups=true . Set the JVM flag (log4j2.formatMsgNoLookups=true) In the component.properties file on the classpath can also prevent searching in log event messages.
Apache also recommends Classpath
(zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class) arrive Prevent remote code execution. Deleting the Jndi Manager class from it will cause JndiContextSelector and JMSAppender to no longer work.
Specify %m{no search} Prevent searching in log event messages in the PatternLayout configuration.
Zdrnja said that if possible, another option for organizations is to control outbound traffic from the periphery and block LDAP and RMI traffic.
Step 3: Use existing protection measures
The above method assumes that updates will eventually become common. For legacy applications, there will be no updates, security or other aspects. Traditional tools “must use some other runtime protection,” said co-founder and chief scientist Arshan Dabirsiaghi. Comparative safety. Application-level RASP is probably the most robust.
WAF is not so effective here, because in modern architectures the input may not come from HTTP, the exploit path contains out-of-band elements, and blocking such attacks at the periphery may also eventually trigger false positives and disrupt normal traffic, Dabirsiaghi said.
In other words, Cloudflare has already released New signature of its firewall Prevent malicious activity at the application level. This rule prevents jndi lookups in common locations in HTTP requests. It is expected that other web application firewall vendors will soon follow suit.
Step 4: Update
There is only one thing in this step: patch and update as soon as possible.
