🔒
There are new articles available, click to refresh the page.
Before yesterdayZero Day Initiative - Blog

CVE-2021-26084: Details on the Recently Exploited Atlassian Confluence OGNL Injection Bug

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Guy Lederfein and Yazhi Wang of the Trend Micro Research Team detail a recent code injection bug in the Atlassian Confluence server. Since the publication of the vendor advisory, U.S. Cybercom has reported that mass exploitation of this bug for crypto mining is ongoing and expected to accelerate. The following is a portion of their write-up covering the root cause CVE-2021-26084, with a few minimal modifications.


An Object-Graph Navigation Language (OGNL) injection has been reported in the Webwork module of Atlassian Confluence Server and Data Center. The vulnerability is due to insufficient input validation leading to OGNL evaluation of user-supplied input.

A remote, unauthenticated attacker could exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in arbitrary code execution in the security context of the affected server.

The Vulnerability

Atlassian Confluence is a collaboration platform written in Java. Users can create content using spaces, pages, and blogs that other users can comment on and edit. It is written primarily in Java and runs on a bundled Apache Tomcat application server. By default, Confluence is accessible via HTTP on port 8090/TCP.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF). SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like:

A corresponding HTTP request using the POST method might look as follows:

Confluence uses the Webwork web application framework to map URLs to Java classes, creating what is known as an “action”. Action URLs end with the “.action” suffix and are defined in the xwork.xml file in confluence- <version>.jar (where <version> is the Confluence version number) and in the atlassian-plugin.xml file in JAR files of included plugins. Each action entry contains at least a name attribute, defining the action name, a class attribute, defining the Java class implementing the action, and at least one result element which decides the Velocity template to render after the action is invoked based on the result of the action. Common return values from actions are “error”, “input”, and “success”, but any value may be used if there is a matching result element in the associated XWork XML. Action entries can contain a method attribute, which allows invocation of a specific method of the specified Java class. When no command is specified, the doDefault() method of the action class is called. The following is a sample action entry for the doenterpagevariables action:

In the above example, the doEnter() method of the com.atlassian.confluence.pages.actions.PageVariablesAction class handles requests to “doenterpagevariables.action” and will return values such as “success”, “input”, or “error”. This results in the appropriate Velocity template being rendered.

Confluence supports the use of Object Graph Navigational Language (OGNL) expressions to dynamically generate web page content from Velocity templates using the Webwork library. OGNL is a dynamic Expression Language (EL) with terse syntax for getting and setting properties of Java objects, list projections, lambda expressions, etc. OGNL expressions contain strings combined to form a navigation chain. The strings can be property names, method calls, array indices, and so on. OGNL expressions are evaluated against the initial, or root context object supplied to the evaluator in the form of OGNL Context.

Confluence uses a container object of class com.opensymphony.webwork.views.jsp.ui.template.TemplateRenderingContext to store objects needed to execute an Action. These objects include session identifiers, request parameters, spaceKey, etc. TemplateRenderingContext also contains a com.opensymphony.xwork.util.OgnlValueStack object to push and store objects against which dynamic Expression Languages (EL) are evaluated. When the EL compiler needs to resolve an expression, it searches down the stack starting with the latest object pushed into it. OGNL is the EL used by the Webwork library to render Velocity templates defined in Confluence, allowing access to Confluence objects exposed via the current context. For example, the $action variable returns the current Webwork action object.

OGNL expressions in Velocity templates are parsed using the ognl.OgnlParser.expression() method. The expression is parsed into a series of tokens based on the input string. The ognl.JavaCharStream.readChar() method, called by the OGNL parser, evaluates Unicode escape characters in the form of “\uXXXX” where “XXXX” is the hexadecimal code of the Unicode character represented. Therefore, if an expression includes the character “\u0027”, the character is evaluated as a closing quote character ('), escaping the context of evaluation as a string literal, allowing to append an arbitrary OGNL expression. If an OGNL expression is parsed in a Velocity template within single quotes and the expression’s value is obtained from user input without any sanitization, an arbitrary OGNL expression can be injected.

An OGNL injection vulnerability exists in Atlassian Confluence. The vulnerability is due to insufficient validation of user input used to set variables evaluated in Velocity templates within single quotes. By including the “\u0027” character in user input, an attacker can escape the string literal and append an arbitrary OGNL expression.

Before OGNL expressions are evaluated by Webwork, they are compared against a list of unsafe node types, property names, method names, and variables names in the com.opensymphony.webwork.util.SafeExpressionUtil.containsUnsafeExpression() method. However, this list is not exhaustive, and arbitrary Java objects can be instantiated without using any of the unsafe elements listed. For example, the following expression, executing an OS command, would be accepted as a safe expression by this method:

A remote attacker can exploit this vulnerability by sending a crafted HTTP request containing a malicious parameter to a vulnerable server. Successful exploitation can result in the execution of arbitrary code with the privileges of the server.

Remote Detection of Generic Attacks

To detect this attack, you should monitor all HTTP traffic requests where the path component of the request-URI contains one of the strings in the “URI path” column of the following table:

If such a request is found, you should inspect the HTTP request method. If the request method is POST, look for the respective vulnerable parameters from the table above in the body of the HTTP request, and if the request method is GET, you should look for the parameters in the request-URI of the HTTP request. Check to see if the value of any of the vulnerable parameters contains the string "\u0027" or its URL-encoded form. If so, the traffic should be considered malicious and an attack exploiting this vulnerability is likely underway.

Conclusion

Atlassian patched this vulnerability on August 25, 2021. Since the initial publication of their advisory, they have updated it multiple times to note the active attacks and to add clarification on how customers can identify if they are using Confluence Cloud. They do list some mitigations, but considering how widespread this bug is currently being exploited, the best course of action is to apply the patch and enhance system monitoring.

Special thanks to Guy Lederfein and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-26084: Details on the Recently Exploited Atlassian Confluence OGNL Injection Bug

CVE-2021-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Kc Udonsi and Yazhi Wang of the Trend Micro Research Team detail a recent code execution vulnerability in the Cisco HyperFlex HX Data Platform. The bug was originally discovered by Nikita Abramov and Mikhail Klyuchnikov of Positive Technologies. The following is a portion of their write-up covering CVE-2021-1497, with a few minimal modifications.


Cisco HyperFlex HX Data Platform is a high-performance, extensible distributed file system that supports multiple hypervisors with a wide range of enterprise-grade data management and optimization services. A remote code execution vulnerability has been reported in the product due to improper input sanitization.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the web-based management interface of the target server. Successful exploitation could lead to the execution of arbitrary code in the context of the root user. Cisco patched this vulnerability in May 2021.

The Vulnerability

Cisco HyperFlex HX Data Platform Installer uses an HTTP-based web console. It is accessible through the following address:

         https://<server_name>

Where <server_name> is the name of the machine on which Cisco HyperFlex HX is installed. HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the line terminator sequence consisting of a Carriage Return (CR) character followed by a Line Feed (LF) character, and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the GET method might look like this:

A similar request using the POST method might look like this:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

        var1=value1&var2=value2&var3=value3...

Remote users can submit a request to the /auth/ endpoint of the Cisco HyperFlex HX server to authenticate themselves before installation operations. Below is an example of a request submitted to /auth/ to perform a system restore-and-reboot operation:

The frontend NGINX server will forward the HTTP request to the backend HTTP server listening on TCP/8082:

The HTTP server is implemented in an ELF executable file /opt/springpath/auth/auth. When it receives an HTTP request sent to the /auth/ endpoint, it will call the function main_loginHandler() to handle the request. The function will first extract the salt value from the line of /etc/shadow file using the provided username value from the HTTP request. Then it will call the function main_validatePassword() to validate the user-supplied password. This function finally calls main_checkHash() function. To calculate the hash value of the supplied password, this function uses generated Python code as follows:

        python -c 'import crypt; print crypt.crypt("<somePass>", "<salt>")'

Here <somePass> is the password supplied in the HTTP request and <salt> is the value extracted from the /etc/shadow file.

A Python code injection vulnerability exists here. The code fails to correctly validate the value of password before using it to generate the Python code string. An attacker can include Python command injection characters in the value of the password parameter to inject arbitrary Python code. For example, a value like the following:

implies the generated Python code will be like:

Therefore, the OS command COMMAND will be executed when the generated Python code is called.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted request to the target server. Successful exploitation can result in the execution of arbitrary commands in the security context of the root user.

Conclusion

Cisco patched this vulnerability in May 2021. In their advisory, they mention there are no workarounds. Affected customers should apply the vendor patch to ensure they are protected from this vulnerability.

Special thanks to Kc Udonsi and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-1497: Cisco HyperFlex HX Auth Handling Remote Command Execution

CVE-2021-31166: A Wormable Code Execution Bug in HTTP.sys

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Kc Udonsi and Yazhi Wang of the Trend Micro Research Team detail a recent code execution vulnerability in the Microsoft Internet Information Services (IIS) for Windows. The bug was originally discovered by the Microsoft Platform Security & Vulnerability Research team. The following is a portion of their write-up covering CVE-2021-31166, with a few minimal modifications.


The Internet Information Services (IIS) for Windows Server is a flexible, scalable, secure, and manageable web server for hosting static as well as dynamic content on the web. IIS supports various web technologies including HTML, ASP, ASP.NET, JSP, PHP, and CGI. IIS features an HTTP listener as part of the networking subsystem of Windows. This functionality is implemented as a kernel-mode device driver called the HTTP Protocol Stack (HTTP.sys). This driver is responsible for parsing HTTP requests and crafting responses to the clients.

Note that the driver http.sys is a mature technology that provides the robustness, security, and scalability of a full-featured web server. It is also used by Windows Remote Management WS-Management (WinRM) and Web Services for Devices (WSD) associated with Network Discovery. It could also be used by any other web servers that need to be exposed to the internet without using IIS. Therefore this vulnerability is reachable via any system utilizing http.sys.

HTTP is a request/response protocol described in RFCs 7230 - 7237 and other RFCs. A request is sent by a client to a server, which in turn sends a response back to the client. An HTTP request consists of a request line, various headers, an empty line, and an optional message body:

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and Content-Type header. For example, a simple HTTP request passing a parameter named “param” with value “1”, using the POST method might look like this:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

Of relevance to this vulnerability is the HTTP request header “Accept-Encoding”. This header advertises to a web server compression algorithm it can understand. The server selects a proposal from advertised choices, uses it, and informs the client of its decision using the HTTP response header “Content-Encoding”.

The advertised compression algorithms are known as content-coding. The content-codings could be specified in the order of preference with qvalue weighting which describes the order of priority of values in a comma-separated list.

The “Accept-Encoding” HTTP header Field-Value has the following format:

Example "Accept-Encoding" headers are as follows:

where the Field-Value strings are gzip, identity, *, deflate, gzip;q=1.0, *;q=0.5
In HTTP.sys the routines HTTP!UlAcceptEncodingHeaderHandler, HTTP!UlpParseAcceptEncoding and HTTP!

UlpParseContentCoding are responsible for parsing the "Accept-Encoding" HTTP request header.

Upon receiving an HTTP request, the routine HTTP!UlAcceptEncodingHeaderHandler is invoked for each “Accept-Encoding” header present in the request headers. This routine then invokes HTTP!UlpParseAcceptEncoding on the “Accept-Encoding” HTTP header Field-Value.

The HTTP!UlpParseAcceptEncoding routine walks the Field-Value string by invoking HTTP! UlpParseContentCoding. The HTTP!UlpParseContentCoding routine, among other functionalities, returns a reference to the next content-coding string within the Field-Value for the next iteration and determines if the current reference into the Field-Value string is either an unknown, a supported, or an invalid content-coding string.

A valid content-coding string is a well-formatted string according to the “Accept-Encoding” HTTP header Field- Value format illustrated above. It can either be unknown or supported. A supported content-coding string is a valid content-coding string specifying a compression algorithm supported by IIS.

In the following “Accept-Encoding” HTTP request header example:

       Accept-Encoding: gzip, aaaa, bbbb;

“gzip” is a supported content-coding string, “aaaa” is an unknown content-coding string, and finally “bbbb;” is an invalid content-coding string because it is improperly formatted.

During the processing of the Field-Value string, the routine HTTP!UlpParseAcceptEncoding maintains a circular doubly linked list of unknown content-codings. However, the presence of an invalid content-coding string will result in an HTTP Bad Request server response.

A circular doubly linked list is a data structure that exhibits properties of both doubly linked lists and circular linked lists. In a circular doubly linked list, two consecutive nodes are connected by previous and next links. Distinctively, the last node connects to the first node by its next link and the first node connects to the last node by its previous link. If the circular doubly linked list contains only one node, the next and previous links connect to itself.

A remote code execution vulnerability exists in the HTTP Protocol Stack for Microsoft Internet Information Services implemented in http.sys. The vulnerability is due to a design flaw in the maintenance of a circular doubly linked list in UlpParseAcceptEncoding.

In the routine HTTP!UlpParseAcceptEncoding, the list of unknown content-codings is initialized to contain just a root node. This root node resides in the function's stack memory region. While processing the Field-Value string, subsequent nodes are allocated for unknown content-codings in the paged memory pool (i.e virtual memory addresses that can be paged in and out of the system). In the event that HTTP!UlpParseAcceptEncoding failed to acquire memory within the paged pool or that HTTP!UlpParseContentCoding determined that a content-coding string is invalid, nodes allocated within the paged pool will be freed and in all but one case, immediately by the routine HTTP!UlFreeUnknownCodingList via the root node residing on the function's stack memory region (original root node).

The routine HTTP!UlFreeUnknownCodingList unlinks and frees nodes in the order they were added to the circular doubly linked list. It begins with the first non-root node and will perform various integrity checks on the node to be deleted effectively in a bid to determine if the circular doubly linked list has been corrupted. If the checks succeed, the node will be freed otherwise the routine aborts with __fastfail leading to a kernel crash.

After fully parsing all content-codings specified in the Field-Value string, if the list of unknown content-codings contains additional nodes, the additional nodes are unlinked from the root node that resides on the function's stack memory region and relinked to a root node in an internal structure. During unlinking, HTTP! UlpParseAcceptEncoding failed to reset the next and previous links of the initial root node such that they connect to itself. Hence, the next and previous links of the original root node still connected to the now migrated nodes.

An attacker could craft an “Accept-Encoding” HTTP request header such that the unknown content-coding list is migrated to the internal structure but also passed to HTTP!UlFreeUnknownCodingList via the original root node as a result of an invalid content-coding string passed to HTTP!UlpParseContentCoding. This scenario occurs because a special error code 0x0c0000225 is returned by HTTP!UlpParseContentCoding when the only non-tab, non-space character in the content-coding string currently being processed is the comma character (,). This error code does not result in the immediate freeing of the unknown content-coding list in HTTP!UlpParseAcceptEncoding. The unknown content-coding list will still be migrated to the internal structure before the error is handled.

Since the original root node's next and previous links still connect to the migrated nodes, the free operation will be performed for the first added node connected by the original root's next link because the integrity checks performed on the node will succeed. However, since the first node is connected to the internal structure’s root node via its previous link, the routine HTTP!UlFreeUnknownCodingList unlinks this node from the internal structure root node instead of the passed in the original root node. On the next iteration, the same node is to be freed again since the routine parses the passed-in initial root node. This time, a non-crashing use-after-free occurs, the integrity checks are performed again on the node but this time they fail. This is because when the routine checks the node connected to the previous link of the already deleted and unlinked node, it finds the internal structure's root node. However, when it checks the node connected to the internal structure root node's next link, it finds a node different from the one specified for freeing. The routine HTTP!UlFreeUnknownCodingList aborts via __fastfail with FAST_FAIL_CORRUPT_LIST_ENTRY. This results in a blue screen of death (BSOD) with stopcode KERNEL SECURITY CHECK FAILURE.

A remote, unauthenticated attacker can exploit this vulnerability by sending a crafted Accept-Encoding HTTP header in a web request to the target system. Successful exploitation of this vulnerability can result in denial-of-service conditions or code execution with kernel privileges in the worst case.

Conclusion

Microsoft addressed this vulnerability in the May patch release cycle. They recommend prioritizing the patching of affected servers.

Special thanks to Kc Udonsi and Yazhi Wang of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-31166: A Wormable Code Execution Bug in HTTP.sys

CVE-2021-25646: Getting Code Execution on Apache Druid

In this excerpt of a Trend Micro Vulnerability Research Service vulnerability report, Pengsu Cheng and Prosenjit Sinha of the Trend Micro Research Team detail a recent code execution vulnerability in the Apache Druid database. The bug was originally discovered and reported by Litch1 from the Security Team of Alibaba Cloud. The following is a portion of their write-up covering CVE-2021-25646, with a few minimal modifications.


Apache Druid is a high-performance, modern, real-time analytic database. Druid is designed for workflows where fast ad-hoc analytics, instant data visibility, or high concurrency are required. Druid streams data from applications like Kafka and Amazon Kinesis, and batch-loads files from data lakes such as HDFS and Amazon S3. Druid supports most popular file formats for structured and semi-structured data. Some common application areas for Druid include clickstream analytics (web and mobile analytics), network telemetry analytics (network performance monitoring), server metrics storage, supply chain analytics, (manufacturing metrics), application performance metrics, digital marketing/advertising analytics, and business intelligence. 

Apache Druid provides a rich set of APIs via HTTP and JDBC for loading, managing and querying data. Users can also interact with Druid via its built-in console interface. The Apache Druid console can be accessed via HTTP. An HTTP request consists of a request line, various headers, an empty line, and an optional message body: 

where CRLF represents the new line sequence Carriage Return (CR) followed by Line Feed (LF) and SP represents a space character. Parameters can be passed from the client to the server as name-value pairs in either the Request-URI or in the message-body, depending on the Method used and the Content-Type header. For example, a simple HTTP request using the GET method and passing a parameter named param with value 1 would look like this:

A corresponding HTTP request using the POST method might look like:

If there is more than one parameter/value pair, they are encoded as &-delimited name=value pairs:

         var1=value1&var2=value2...

The Vulnerability

Druid offers the ability to execute JavaScript at the server without restrictions. Out of concern for security, JavaScript is disabled by default.

Druid uses Jackson to parse the JSON data. When Druid receives JSON data of type “javascript” it uses JavaScriptDimFilter as the corresponding entity class. The constructor of JavaScriptDimFilter is decorated with @JasonCreator:

The @JsonCreator annotation signifies that when the JavaScriptDimFilter class is deserialized, Jackson will call this constructor. The parameters of the constructor dimension, function, extractionFn, and filterTuning all have @JasonProperty annotation modification; as a result, Jackson will be encapsulated a com.fasterxml.jackson.databind.deser.CreatorProperty type when deserializing and parsing to JavaScriptDimFilter. In the case of config parameters that are not marked @JasonProperty, a com.fasterxml.jackson.databind.deser.CreatorProperty named "" will be created.

According to the Druid documentation, JavaScript execution can be enabled via the flag druid.javascript.config in the configuration, and is disabled by default. org.apache.druid.js.JavaScriptConfig contains JavaScript-related configuration. Druid uses the Jersey framework, and all its configuration information, including JavaScriptConfig, is provided by the Guice framework. In order to execute JavaScript on the Druid server, an attacker would need to enable JavaScript in the JavaScriptDimFilter configuration.

Apache Druid has a remote code execution vulnerability while parsing JSON data of type JavaScript. This vulnerability is mainly based on the Jackson parsing feature. When the name property of the JSON data is resolved to "", the value of that empty key is bound to the corresponding parameter (config) of the object (JavaScriptDimFilter, specified when the type is JavaScript). As a result, an attacker can enable the JavaScript execution settings, resulting in the execution of user-supplied JavaScript using the function key.

In the com.fasterxml.jackson.databind.deser.BeanDeserializer#_deserializeUsingPropertyBased method, the “key name” in the parsed JSON string is used to find the corresponding CreatorProperty in the current parsed object. This functionality of looking at the CreatorProperty is implemented in the findCreatorProperty method. The findCreatorProperty method looks for the property in the _propertyLookup HashMap for the corresponding “key name”. In _propertyLookup, the key of JavaScriptConfig is set to "" as it is not decorated with a @JsonProperty annotation. If the attacker supplies a key in the JSON string as "", findCreatorProperty will match that key and it will select the CreatorProperty corresponding to JavaScriptConfig. For example, an attacker can supply the corresponding segment of the JSON to inject configuration settings into JavaScriptConfig:

Jackson is responsible for injecting org.apache.druid.js.JavaScriptConfig into _propertyLookup. The _deserializeUsingPropertyBased method mentioned earlier is called by deserializeFromObjectUsingNonDefault method from the BeanDeserializerBase class, where the _propertyLookup is stored in _propertyBasedCreator HashMap. The BeanDeserializerBase#deserializeFromObjectUsingNonDefault method gets called from BeanDeserializer#deserializeFromObject, where the HashMap is stored in _propertyBasedCreator. Ultimately in the SettableBeanPropery class, the _propertyBasedCreator is assigned to the _valueTypeDeserializer HashMap. According to Jackson documentation, the _valueTypeDeserializer hashmap contains type information and this is the type deserializer used to handle type resolution.

After extracting the corresponding CreatorProperty of the JavascriptConfig, JavaScriptDimFilter checks if the JavaScript execution is enabled. Finally, it executes the JavaScript. The following code shows JavaScriptDimFilter checking if the JavaScript is enabled or not:

         Preconditions.checkState(this.config.isEnabled(), "JavaScript is disabled");

Therefore, an attacker is able to set the JavaScriptConfig to enable JavaScript execution by sending an empty ("") name when the type is set to JavaScript. The value of the empty name is then parsed and applied to the configuration of JavaScriptDimFilter class. The attacker can then send arbitrary JavaScript as the value of the function key.

A remote attacker can exploit this vulnerability by sending an HTTP request containing crafted JSON data in the request body. Successful exploitation can result in the execution of arbitrary code with the privileges of the vulnerable server.

Source Code Walkthrough

The following code snippet was taken from Apache Druid version 0.19.0. Comments added by Trend Micro have been highlighted.

From org.apache.druid.query.filter.JavaScriptDimFilter:

From com.fasterxml.jackson.databind.deser.BeanDeserializer:

From com.fasterxml.jackson.databind.deser.impl.PropertyBasedCreator:

From com.fasterxml.jackson.databind.deser.BeanDeserializerBase:

From com.fasterxml.jackson.databind.jsontype.impl.AsPropertyTypeDeserializer:

Conclusion

The Apache Druid team has addressed this vulnerability and recommends users update to version 0.20.1. They also recommend network access to cluster machines be restricted to trusted hosts only. Publicly available proof-of-concept code has been released for this bug, so administrators should upgrade to a non-affected version of Druid as soon as possible.

Special thanks to Pengsu Cheng and Prosenjit Sinha of the Trend Micro Research Team for providing such a thorough analysis of this vulnerability. For an overview of Trend Micro Research services please visit http://go.trendmicro.com/tis/.

The threat research team will be back with other great vulnerability analysis reports in the future. Until then, follow the ZDI team for the latest in exploit techniques and security patches.

CVE-2021-25646: Getting Code Execution on Apache Druid

  • There are no more articles
❌