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