Oast.pro Log4j

[Lutgarda Briseno]

Manyapplication frameworks in the Java ecosystem use this logging framework by default. For instance, Apache Struts 2, Apache Solr, and Apache Druid are all affected. Aside from those, Apache Log4j is also used in many Spring and Spring Boot applications, so we suggest you check your applications and update them to the latest version.

An attacker can leverage the weakness discovered in log4j to attack an application in what is commonly referred to as Remote Code Execution (RCE). Essentially, an attacker can trick a vulnerable application into running commands passed by the threat actor. In this particular case, the attack vector is using LDAP services to deliver malicious code back to the server running the vulnerable library. This could result in placement of remote access tools or discovery of other services / secrets within the application running environment.

There are many ways to find vulnerable versions of Log4j in use. One of the most effective ways to detect these vulnerable versions is with Software Composition Analysis (SCA) tools. These tools can point out where your applications are pulling in vulnerable versions of open source dependencies and suggest how to update to non-vulnerable versions. This does mean you have to compile and deploy your applications to have protection from the updated library. StackHawk has some great partners to use for SCA detection of the vulnerable Log4j library:

In addition to SCA tooling, the RCE vulnerability found in Log4j may be detected in running applications with a testing method referred to as Out of Band Application Security Testing (OAST). This is a third service that an affected client would reach out to indicating that it is vulnerable as described in the image below.

You can also use ZAP to check running applications for the presence of the Log4J vulnerability using the newly released Log4J Test Plugin and setting up OAST services with ZAP as per the ZAP blog post.

On Dec. 9, 2021, a remote code execution (RCE) vulnerability in Apache Log4j 2 was identified being exploited in the wild. Public proof of concept (PoC) code was released and subsequent investigation revealed that exploitation was incredibly easy to perform. By submitting a specially crafted request to a vulnerable system, depending on how the system is configured, an attacker is able to instruct that system to download and subsequently execute a malicious payload. Due to the discovery of this exploit being so recent, there are still many servers, both on-premises and within cloud environments, that have yet to be patched. Like many high severity RCE exploits, thus far, massive scanning activity for CVE-2021-44228 has begun on the internet with the intent of seeking out and exploiting unpatched systems. We highly recommend that organizations upgrade to the latest version (2.17.1) of Apache Log4j 2 for all systems. This version also patches the additional vulnerabilities CVE-2021-45046, found on Dec. 14; CVE-2021-45105, found on Dec. 17; and CVE-2021-44832, found on Dec. 28.

On Dec. 22, we updated this blog to include statistics on Log4j exploitation attempts that we identified by analyzing hits on the Apache Log4j Remote Code Execution Vulnerability threat prevention signature for the Palo Alto Networks Next-Generation Firewall. We describe a range of examples of activities that could be attempted in the event exploitation is successful, including mass scanning, vulnerable server discovery, information stealing, possible delivery of CobaltStrike and coinmining. We also include a timeline of recent events relating to Log4j vulnerabilities.

On Dec. 28, we updated this blog to include information about CVE-2021-44832, which is an RCE vulnerability affecting instances of Log4j 2 in instances where an attacker has permission to modify the logging configuration file and can in turn construct a malicious configuration using a JDBC Appender. This JDBC Appender in turn references a JDNI URI that can execute remote code on the affected device.

Palo Alto Networks customers are protected via Next-Generation Firewalls (PA-Series, VM-Series and CN-Series) or Prisma Access with a Threat Prevention security subscription and protected by Cortex XDR using exploit protection on Linux endpoints and Behavioral Threat Protection across Windows, Mac and Linux endpoints. Prisma Cloud can detect continuous integration (CI), container images and host systems which maintain vulnerable instances of log4j. You can also automate incident response with Cortex XSOAR.

Apache log4j 2 is an open source Java-based logging framework, which is leveraged within numerous Java applications around the world. Compared with the original log4j 1.X release, log4j 2 addressed issues with the previous release and offered a plugin architecture for users. On Aug. 5, 2015, log4j 2 became the mainstream version and all of the previous version log4j users were recommended to upgrade to log4j 2. Apache log4j 2 is widely used in many popular software applications, such as Apache Struts, ElasticSearch, Redis, Kafka and others.

While supplying an easy and flexible user experience, Apache log4j 2 has historically been vulnerable to process and deserialize user inputs. Two previous deserialization vulnerabilities, CVE-2017-5645 and CVE-2019-17571, were previously discovered, resulting in code injection and further RCE due to a lack of necessary processing against provided user input data.

The Apache log4j library allows for developers to log various data within their application. In certain circumstances, the data being logged originates from user input. Should this user input contain special characters and be subsequently logged within the context of log4j, the Java method lookup will finally be called to execute the user-defined remote Java class in the LDAP server. This will in turn lead to RCE on the victim server that uses the vulnerable log4j 2 instance.

If we take a closer look, we discover that log4j 2.x supports a mechanism called lookups, which is usually used to set up the log4j config flexibly for users. The official introduction about Lookups is as follows:

The normal user can conveniently and flexibly add values to the configuration at arbitrary places with the predesigned format by using this feature. In detail, when calling the log method in the application, log4j 2.x will call the format method to check the specific characters ${ in each log.

There are several types of lookup supported by the feature lookups, such as Jndi Lookup, JVM Input Arguments Lookup (JMX), and Web Lookup. The Jndi lookup allows variables to be retrieved by JNDI. In the Jndi Lookup, several protocols are supported to make the remote lookup, such as LDAP and RMI. If the log includes the strings shown in Figure 2, the Java method lookup will be called to find the string jndi:logging/context-name.

Considering the log content is usually exposed to users and can be easily controlled by the attacker in many applications, once the attacker controls the string as shown in Figure 3 and sets a malicious Java class on an attacker-controlled LDAP server, the lookup method will be used to execute the malicious Java class on the remote LDAP server.

The log4j library is a powerful log framework with very flexible features supported. However, convenient features often involve potential security issues at the same time. Without careful user input filtering and strict input data sanitization, a blind trust of user input may lead to severe security issues.

Exploit code for the CVE-2021-44228 vulnerability has been made publicly available. Any user input hosted by a Java application using the vulnerable version of log4j 2.x may be exposed to this attack, depending on how logging is implemented within the Java application.

Thus far, widespread scanning is taking place on the internet with the intention of identifying vulnerable instances of log4j. These scans are being made via HTTP and do not appear to be targeting any specific applications. Many of these requests are leveraging the User-Agent field in hopes of identifying and subsequently exploiting systems on the internet. One such example of these requests is as follows:

To better understand the impact of the recent vulnerabilities in Log4j facing our customers, we analyzed the hits on the Apache Log4j Remote Code Execution Vulnerability threat prevention signature Dec. 10, 2021-Feb. 2, 2022. Based on our telemetry, we observed 125,894,944 hits that had the associated packet capture that triggered the signature. Figure 7 shows the hits per day, including a large spike in activity Dec. 12-16, followed by a tapering off of activity from Dec. 16-21 and another large spike on Jan. 1, 2022. After the spike in the new year, the signature hits results in a jagged line with counts differing day to day, but with the spikes being dramatically smaller than those previously seen.

We analyzed the packet captures that triggered the signature Dec. 10-31 and found the exploitation attempts appear in various places within the HTTP requests, primarily the URL and fields within the HTTP request header. We extracted 70,577,055 exploit strings from the packet captures and found that over 49% were within the top six fields of the HTTP request, as seen in Table 1. It should also be noted that many of the packet captures showed exploit strings within multiple fields within the HTTP request, each of which were counted in these figures.

Our analysis of the activity involving the Apache Log4j Remote Code Execution Vulnerability signature showed most of the Log4j exploit attempts were related to mass vulnerability scanning. Table 2 shows the top domains and IP addresses seen in the callback URLs within the Log4j exploit string, which account for just over 80% of signature hits Dec. 10-31. We clustered all RFC1918 IP addresses seen in these callback URLs into their respective ranges (10/8, 172.16/12 and 192.168/16) and found that 54% of the signature hits in this time frame were generated by internal scanning. Additionally, several well-known vulnerability scanning services are represented in this list, such as nessus[.]org as the top callback involving a remote location.

3a8082e126