Il n'y a pas si longtemps, je suis dans l'informatique, mais récemment, je me suis laissé emporter par le sujet de la cybersécurité. Le métier de pentester est particulièrement intéressant. En surfant, j'ai vu un article sympa "Comment une base de données mal configurée nous a permis de posséder un cloud entier de plus de 25K hôtes" par Security Shenanigans. Traduction des deux parties et porter à votre attention.
introduction
Dans cet article, vous apprendrez comment nous avons réussi à effectuer une connexion sqlmap directe à la base de données à l'aide de BMC / IPMI pour compromettre un gros client.
Contexte
Il y a quelques années, notre équipe a reçu une mission: effectuer un test de pénétration de l'infrastructure sur le réseau Openstack. Il se composait d'environ 2 000 serveurs physiques hébergeant plus de 25 000 machines virtuelles. Nous avons commencé notre travail sur un petit sous-réseau, dans lequel il y avait une limite sur la quantité de trafic sortant. Après une analyse rapide, Nmap n'a pas pu trouver de vulnérabilités évidentes susceptibles d'être exploitées. Par conséquent, nous avons commencé à étudier les services qui nous sont offerts. Parmi eux, nous avons trouvé un serveur PostgreSQL sans défense hébergé sur un serveur de développement. Après avoir créé une liste de mots personnalisée avec plusieurs dérivés du nom de l'entreprise, nous avons pu nous faufiler dans le système en utilisant des données relativement simples du compte. Le nom d'utilisateur était Postgres et le mot de passe était "admin".
Ensuite, nous avons décidé d'utilisersqlmap . Cet outil a été conçu pour utiliser l'injection SQL, mais il peut également vous offrir plusieurs options lors de l'établissement d'une connexion directe à la base de données (lorsque vous avez vos informations d'identification). L'une de ces options consiste à lancer un shell de commande sur la base de données en production.
Après avoir testé le shell, nous avons décidé de créer une charge utile personnalisée (payload) afin d'obtenir une connexion inverse. Cela permettrait de travailler plus confortablement.
Nous avons construit la charge utile en utilisant msfvenom. La charge utile dans ce cas était un shell TCP inversé pour une machine Linux x64. Dans l'image précédente, vous pouvez voir que nous devions choisir l'architecture de la base de données.
Collecter la charge utile avec msfvenom
L'avantage de cette charge utile est qu'elle peut être utilisée pour se reconnecter en utilisant un simple Netcat. La plupart des autres charges utiles nécessitent quelque chose comme Metasploit (choisissez exploit / multi / handler) pour les mêmes tâches.
Après avoir exécuté la charge utile avec le wrapper sqlmap, nous avons obtenu notre connexion au serveur.
Lancement de la charge utile Se reconnecter
et tester l'accès
Utilisation de périphériques BMC
Chaque fois que vous exécutez un test de pénétration d'infrastructure et que vous compromettez une machine sur un nouveau segment de réseau, vous devez effectuer une nouvelle analyse pour voir si quelque chose de nouveau émerge. Cette base de données nous a permis de nous connecter au réseau cloud de l'entreprise, y compris la plupart des machines virtuelles et des hôtes. Nous avons été très satisfaits des résultats de la nouvelle analyse car nous avons trouvé plusieurs périphériques BMC.
L'un des trois périphériques BMC
Le BMC (Baseboard Management Controller, processeur de service) est un périphérique intégré préférentiel connecté au serveur principal qui fournit une surveillance et un contrôle hors bande. Il fonctionne indépendamment du processeur, du BIOS et du système d'exploitation. Les erreurs survenant dans l'un de ces éléments ne sont pas susceptibles d'affecter son fonctionnement. Le microcontrôleur a son propre processeur, sa mémoire et son interface réseau, il est donc disponible même si le serveur lui-même est éteint. Tous les grands équipementiers ont des BMC spécifiques pour leurs produits:
- Dell DRAC
- IBM IMM
- HP iLO
- Supermicro IPMI
Un autre terme avec lequel vous devez vous familiariser, IPMI (Intelligent Platform Management Interface) est essentiellement le protocole que vous utilisez pour communiquer avec ces périphériques. Son objectif est de surveiller et de gérer le matériel du serveur, quel que soit le système d'exploitation, même lorsque le serveur est éteint, mais connecté à une source d'alimentation.
Disons simplement qu'IPMI est de loin l'un des protocoles les moins sûrs que vous puissiez trouver. Pour vous donner une idée, IPMI 2.0 est conçu de telle manière que vous pouvez directement demander un hachage personnalisé au serveur lors de l'étape d'authentification. Une autre vulnérabilité existe lorsque vous demandez une autorisation en mode "chiffrement 0", ce qui vous permettra de vous connecter avec n'importe quel mot de passe.
Architecture par blocs IPMI Les
périphériques BMC que vous pouvez trouver sont généralement mal protégés, car il s'agit d'un type de périphérique configuré une seule fois, pendant la phase d'assemblage du centre de données, puis utilisé uniquement lorsque le serveur n'est pas disponible par des moyens conventionnels.
Nous avons pu facilement nous authentifier sur certains appareils sur lesquels le chiffrement 0 était activé .
Ici, vous pouvez voir comment nous sommes connectés avec un mot de passe aléatoire. Faites attention à la partie "-C 0".
Connexion réussie à l'appareil avec un mot de passe aléatoire
Informations réseau pour l'appareil
Même si le chiffrement 0 n'est pas activé sur certains appareils, vous avez encore d'autres façons de vous connecter. Les deux plus connus sont soit l'utilisation des informations d'identification par défaut (que les administrateurs système n'essaient généralement pas de changer) ou l'exploitation d'une vulnérabilité de divulgation de hachage (puis le craquage des hachages). Ce dernier devait être fait pour la plupart des appareils.
Paires nom d'utilisateur / mot de passe par défaut banales pour la plupart des utilisateurs
Une liste de mots contenant des hachages d'utilisateurs que nous demandons au serveur
Extension des hachages personnalisés à l'aide de metasploit
Nous obtenons immédiatement des données sur les hachages typiques
Après avoir parcouru tous les hachages, nous avons commencé à les casser.
Piratage des premiers hachages
En quelques minutes, nous avons eu accès à environ 600 BMC.
609 hachages réussis
Il y avait quelques périphériques HP ILO que nous n'avons pas pu déchiffrer. Heureusement pour nous, HP iLO 4 1.00 à 2.50 dispose également d'un contournement d'authentification. Cela vous permet de créer un compte administrateur via un buffer overflow dans l'en-tête de connexion HTTP traité par le serveur Web. L'exploit l' utilise pour obtenir un accès privilégié au reste de l'API, qui à son tour vous donne la permission de créer des comptes.
Utilisation de CVE-2017-12542
Après ces étapes, nous avons obtenu le contrôle total de 90% des appareils BMC de l'entreprise. Si vous avez lu sur les périphériques BMC, vous savez maintenant qu'ils vous permettent de:
- Moniteur
- Redémarrer
- Réinstaller
- KVM (virtualiser)
des appareils connectés. C'est génial et tout, mais ils ne simulent que l'accès physique au serveur, vous devez toujours y entrer. Oui, vous pouvez vous amuser en éteignant les appareils, mais nous avons pensé que ce n'était pas suffisant, alors nous avons continué à creuser.
L'un des moyens les plus courants de pirater du matériel possédant une adresse physique consiste à le redémarrer et à contrôler l'exécution automatique du shell racine. Vous pouvez le faire sur Unix, Mac et Windows.
La difficulté avec cette approche est que chaque serveur héberge généralement environ 2000 hôtes virtuels. Nous devions donc trouver un serveur inutilisé. Le plan était de le désactiver (ou simplement de le démarrer s'il était déjà désactivé) et de modifier l'exécution automatique pour nous donner un accès root. Après cela, nous avons voulu examiner la configuration pour trouver les bogues / charges utiles qui nous permettraient de compromettre également d'autres serveurs.
Openstack vous permet d'interroger l'infrastructure locale et d'interroger des paramètres spécifiques. L'un d'eux est l'état de la machine virtuelle, qui dans le cas de cette société locale a été défini comme la disponibilité de la VM (liste blanche / noire pour la réception du trafic) + état opérationnel (démarré / désactivé).
Nous devions trouver un serveur sur liste noire (l'état de fonctionnement n'avait pas d'importance) et nous en avons trouvé un qui ne fonctionnait pas en raison de problèmes de disque. Heureusement, nous avons pu démarrer, mais certaines parties du système de fichiers se sont retrouvées en mode lecture seule.
Demande Openstack pour un serveur approprié à pirater
Une fois que nous l'avons trouvé, nous nous sommes connectés avec les informations d'identification que nous avons trouvées précédemment.
Utilisation des accès obtenus précédemment
Accès à l'interface KVM L'interface KVM
simule une connexion directe au serveur via le BMC. Au démarrage, vous devez modifier le chargement automatique de Grub et l'ajouter
ro init = / bin / bashà la ligne appropriée pour démarrer dans le shell racine... Habituellement, l'indicateur de lecture / écriture (rw) est utilisé, mais nous avons dû utiliser l'indicateur de lecture seule (ro) pour éviter tout problème avec le disque défaillant.
Modification du menu grub
Après la connexion, nous avons examiné les interfaces réseau pour tester la connectivité au serveur. Comme vous pouvez le voir, ifconfig montre plus de 10 interfaces actives.
Après avoir pris le temps d'analyser la structure du réseau et de comprendre où nous en sommes, nous avons commencé à étudier le serveur.
En quelques minutes, nous avons trouvé un terrain d'entente avec bash_history (l'une des meilleures sources d'informations précieuses que vous pouvez trouver sur une machine Linux) les
informations d'identification novadb dans bash_history
Pour ceux qui ne connaissent pas l'architecture Openstack, Nova est une base de données de gestion qui stocke des informations administratives pour l'ensemble du cloud, telles que des certificats, des quotas, des noms d'instance, des métadonnées et des informations bien plus importantes .
Vérification des informations d'identification
Après la connexion, nous avons vérifié l'accès administrateur à l'aide de grant_MySQL.
Cela fait, nous pouvons voir la structure interne de NovaDB.
Tables dans la base de données Novadb
En regardant les informations sur la VM, nous avons pu voir environ 34 000 appareils. Cependant, environ un tiers d'entre eux n'étaient pas disponibles / ne fonctionnaient pas. Le montant exact peut être vu dans l'entrée de ligne float_ips.
Laissez-moi vous expliquer pourquoi ces données de la base de données sont si importantes.
Si vous souhaitez fermer toute l'entreprise, vous pouvez arrêter chaque serveur virtuel via l'interface BMC. Ils ne fonctionneront pas tant que les administrateurs système ne réactiveront pas les choses.
Vous pouvez écrire votre propre malware pour infecter tous les serveurs, mais le déploiement de masse sur les canaux BMC n'est pas facile (rappelez-vous que nous avons dû démarrer un serveur inutilisé pour modifier l'exécution automatique de Grub avant d'y accéder).
Cependant, avec l'accès à NovaDB, vous pouvez simplement corrompre la base de données et tout l'environnement cloud cessera de fonctionner. Même en supposant que l'administrateur système était suffisamment intelligent pour jeter un coup d'œil rapide à la base de données, il est beaucoup plus difficile de dépanner une base de données corrompue qu'une base manquante.
En outre, l'administrateur système peut comprendre que quelque chose ne va pas et écraser tout simplement avec la sauvegarde la plus récente, n'est-ce pas? Nous y avons également pensé. C'est pourquoi nous sommes allés de l'avant et avons compromis les sauvegardes.
Au début, nous avons essayé d'interroger la base de données principale avec quelque chose comme
SELECT * FROM information_schema.PROCESSLIST AS p WHERE p.COMMAND = 'Binlog Dump'; , mais la société a utilisé sa propre solution de sauvegarde qui fonctionnait de manière irrégulière et n'utilisait pas de schéma maître / esclave. Nous avons donc continué à analyser les sous-réseaux voisins juste pour trouver les bases de données de sauvegarde fonctionnant sur le même port que le principal.
Comment nous avons réussi à trouver les sauvegardes
Nous avons vérifié la possibilité d'utiliser les informations d'identification existantes et, bien sûr, elles sont apparues.
Vérifier l'accès à une sauvegarde
Avec nos propres sauvegardes, nous avons pu prouver le compromis complet de l'infrastructure de virtualisation, ainsi qu'un moyen de finaliser les opérations en quelques minutes.
J'aime toujours terminer un examen / rapport en écrivant des correctifs possibles pour les problèmes rencontrés. De plus, ils étaient nombreux, par exemple:
- Réutilisation des informations d'identification
- Il n'y a pas de segmentation du réseau
- Mots de passe banals
- Structure de sauvegarde non sécurisée
- Micrologiciel obsolète
Un problème critique qui n'a pas été facile à résoudre était les failles du protocole IPMI.
La solution la plus efficace serait de placer les serveurs compatibles BMC sur un segment de réseau différent avec une liste limitée et contrôlée d'adresses IP. C'est ce que cette entreprise a finalement fait.
J'espère que vous avez apprécié notre histoire. Autant nous nous sommes amusés à apprendre ce sujet.