PCredz, récupérer des identifiants à partir d’une écoute réseau

I. Présentation

Je vous présente aujourd'hui un petit outil que j'ai l'habitude d'utiliser lors de scénarios de tests d'intrusion internes. Celui-ci permet de récupérer des identifiants à partir d'écoutes réseau.

PCredz est une petit outil assez simple écrit par Laurent Gaffié (Igandx, auteur de Responder), il s'agit simplement d'un parser en quête d'identifiant dans une suite de protocoles non sécurisés. Il peut être utilisé lors d'une écoute en live sur le réseau ou lire un fichier .pcap ou .pcapng (format produit par Wireshark ou TCPdump).

Il est en effet très fréquent que des protocoles non sécurisés soient utilisés au sein d'un réseau d'entreprise, cela car les utilisateurs et administrateurs se considèrent comme sécurisés lorsqu'ils sont "chez eux". Plus précisément car ils ne soupçonnent pas la facilité qu'un attaquant pourrait avoir à s'introduire logiquement dans leur réseau (en s'y connectant physiquement, en Wifi ou par la compromission d'un poste utilisateur), mais aussi car les menaces internes sont souvent oubliées des analyses de risques faites en internes.

II. PCCredz

L'outil peut être trouvé sur le dépôt de Laurent Gaffié : https://github.com/lgandx/PCredz

En date d'écriture de cet article, celui-ci gère déjà un bon nombre de protocoles :

• POP
• SMTP
• IMAP
• SNMP community string
• FTP
• HTTP
• NTLMv1/v2 (DCE-RPC,SMBv1/2,LDAP, MSSQL, HTTP, etc)
• Kerberos (AS-REQ Pre-Auth etype 23) hashes.

Tout ces protocoles, et bien d'autres d'ailleurs, sont en clair (sans aucun chiffrement), les phases authentification des utilisateurs et des systèmes font donc également passer ces informations là en clair, et n'importe qui en capacité d'intercepter ces flux peut les récupérer et les réutiliser.

Tous les hashs récupérés sont affichées selon le format hashcat afin qu'ils puissent être réutilisés rapidement et toutes les données récupérées sont stockées dans un fichier CredentialDump-Session.log.

Concernant l'utilisation, deux cas sont donc possibles. L'écoute en direct sur une interface, par exemple dans le cas d'une attaque par l'homme du milieu (MITM) menée en parallèle depuis le poste de l'attaquant :

./Pcredz -i eth0

Ou l'analyse "à froid" d'une fichier .pcap ou .pcapng, qui correspond aux scénarios d'écoutes menées sur une autre machine et dont les résultats ont ensuite été récupérés :

./Pcredz -f file-to-parse.pcap

On peut également indiquer un répertoire contenant plusieurs fichiers .pcap  avec l'option -d :

./Pcredz -d /tmp/pcap-directory-to-parse/

PCredz est écrit en python et se base essentiellement sur la librairie libpcap, il est donc possible d'étudier son fonctionnement et de le modifier (en ajoutant des protocoles par exemple). Voici par exemple la partie du code contenant les expressions régulières pour certains des protocoles pris en charge :

Voici un exemple de sortie sur plusieurs fichiers récupérés sur le site http://www.pcapr.net :

# ./Pcredz -d pcap/
Pcredz 1.0.0
Author: Laurent Gaffie
Please send bugs/comments/pcaps to: [email protected]
This script will extract NTLM (http,ldap,smb,sql,etc), Kerberos,
FTP, HTTP Basic and credit card data from a given pcap file or from a live interface.

CC number scanning activated

Parsing: pcap/POP3-NTLM-Authentication.CAP
Using TCPDump format
pcap/POP3-NTLM-Authentication.CAP parsed in: 0.0235 seconds (File size 0.00454 Mo).

Parsing: pcap/smtp-auth-login.pcap
Using TCPDump format
14 protocol: tcp 127.0.0.1:25915 > 127.0.0.1:25
SMTP decoded Base64 string: username
pcap/smtp-auth-login.pcap parsed in: 0.0157 seconds (File size 0.00162 Mo).

Parsing: pcap/SMTP-Login-Auth.Cap
Using TCPDump format
21 protocol: tcp 192.168.26.1:1698 > 192.168.26.130:25
SMTP decoded Base64 string: simon
pcap/SMTP-Login-Auth.Cap parsed in: 0.0238 seconds (File size 0.00463 Mo).

Parsing: pcap/krb5_pam_erebo_correct_login.pcap
Using TCPDump format
pcap/krb5_pam_erebo_correct_login.pcap parsed in: 0.00753 seconds (File size 0.00332 Mo).

Parsing: pcap/dump.pcap
Using TCPDump format
24 protocol: tcp 192.168.1.18:56380 > 88.190.19.182:80
Found possible HTTP authentication username=flag_x:password=flag%7Bi_should_add_ssl%7D
Host: ctf.bi.tk
Full path: POST /login HTTP/1.1

pcap/dump.pcap parsed in: 0.0364 seconds (File size 0.0425 Mo).
Parsing: pcap/ftp-login.pcap
Using TCPDump format

9 protocol: tcp 192.168.1.7:50885 > 192.168.1.3:21
FTP User: alex
FTP Pass: alex

pcap/ftp-login.pcap parsed in: 0.00617 seconds (File size 0.00143 Mo).

III. Scénarios d'utilisation

Plusieurs moments clés dans le déroulement d'une intrusion peuvent conduire à l'utilisation de cet outil afin de faciliter le travail de l'attaquant au sein du réseau.

L'une des premières étapes d'une intrusion reste l'écoute passive, l'attaquant qui parvient à accéder au réseau interne d'une entreprise se met simplement en écoute sur le réseau afin d'étudier ses composants et son comportement sans lever d'alerte (en envoyant par exemple des identifiants incorrectes ou en faisant des scans réseau).

Cette première écoute n'est pas la propice à l'utilisation de PCredz, car les requêtes contenant des identifiants sont généralement dédiées à un serveur précis et donc ciblées.

Au fur et à mesure des compromissions et de ses avancées, un attaquant peut exécuter des écoutes réseaux sur les machines compromises afin de voir ce qui entre et sort de leur interface réseau. Ce type d'écoute est déjà bien plus intéressante pour l'utilisation de PCredz car l'utilisateur va forcément s'authentifier sur différents services au cours de sa journée. Egalement lors de la compromission d'un serveur, l'attaquant qui parvient à exécuter une écoute réseau va pouvoir récupérer les identifiants des utilisateurs qui se connectent aux services hébergés par le serveur.

Finalement, les cas d'interception réseaux, tels que l'ARP Spoofing , sont les plus intéressants car l'attaquant essaie de récupérer le plus de trafic possible afin d'y récupérer des informations, ou simplement de détourner/modifier le trafic intercepté pour des attaques massives ou ciblées.

Bref, nombreux sont les cas où une interception réseau est possible et l'utilisation de PCredz retourne souvent des résultats intéressants.

IV. Protections

Différents bonnes pratiques de sécurité peuvent ralentir l'attaquant lors d'une compromission interne du réseau et rendre inutile des outils tels que PCredz :

Au niveau architecture, les bonnes pratiquent générales de sécurité vont dans le sens du cloisonnement des systèmes et des utilisateurs par niveau de sensibilité ou criticité. Il est par exemple possible de positionner les administrateurs sur un réseau différent des utilisateurs. Ainsi, même en cas de compromission d'un poste utilisateur, le trafic réseau depuis et vers les postes des administrateurs sera plus difficile à intercepter (par ARP spoofing par exemple). Voir la règle 19 du Guide d'hygiène informatique de l'ANSSI "Segmenter le réseau et mettre en place un cloisonnement entre ces zone" : https://www.ssi.gouv.fr/uploads/2017/01/guide_hygiene_informatique_anssi.pdf

Concernant les configurations des services proposés aux utilisateurs, l'utilisation de protocoles sécurisés doit être systématique afin de réduire autant que possible la transmission d'identifiants en clair sur le réseau. Quasiment tous les protocoles proposent aujourd'hui une version chiffrée (HTTP -> HTTPS, FTP -> FTPS/SFTP, telnet -> SSH, etc.). Voir la règle 21 du Guide d'hygiène informatique de l'ANSSI "Utiliser des protocoles réseaux sécurisés dès qu’ils existent".

Egalement, les postes utilisateurs comme les serveurs doivent faire l'objet d'un durcissement qui vise à n'installer que les outils nécessaires à leur besoin métier et à interdire l'installation d'outils par des utilisateurs non privilégiés. Par exemple, les distributions Linux possèdent presque toutes nativement les paquets tcpdump ou nmap d'installés, et il est très fréquent que ces outils soient réutilisés lors d'une intrusion. L'attaquant n'a alors pas à installer ses propres outils, actions qui pourrait trahir sa présence (connexion à Internet, installation de nouveaux paquets, modification des droits ou permissions, etc.). Tous les logiciels permettant une écoute réseau doivent donc être désinstallés (et plus largement ceux qui ne répondent pas à un besoin métier ou technique justifié). Cela fait notamment partie des recommandations de la règle 14 du Guide d'hygiène de l'ANSSI : "Mettre en place un niveau de sécurité minimal sur l’ensemble du parc informatique".

Enfin, des outils de détection d'intrusion peuvent également être utilisés afin de trahir, non par une écoute réseau, mais une attaque par l'homme du milieu. Une attaque de type ARP spoofing est par exemple très visible sur le réseau. L'article suivant détaille le pourquoi et le comment de cette attaque et les protections possibles : Comprendre les attaques via ARP spoofing (MITM, DOS)

Bref, ce petit outil est très pratique car il automatise une bonne partie du travail de recherche d'identifiants. Mais l'application des bonnes pratiques générales de sécurité permettent tout de même de se protéger, non pas de son utilisation directe, mais des vulnérabilités ou faiblesses qu'il exploite.