--------------------------------------------------------------------------------------- V. Something about WinNT Viperone --------------------------------------------------------------------------------------- +++++++++++++++++++++++++++++++++++ ++++ Fichier Joint : winnt.zip ++++ +++++++++++++++++++++++++++++++++++ [ Introducion ] Ceci est mon premier article pour IOC Magazine. J'espère qu'il vous plaira. Je vais vous apprendre comment exploiter une faille dans Windows NT qui nous permettra de devenir administrateur sur le réseau ou la machine simple. Je croit que je n'ai pas besoin de demander pourquoi devenir root ... I. Préliminaires : __________________ Tout d'abord, voici la liste des systèmes NT affectés par la faille. · Workstation 3.5, 3.51, 4.0, 4.0 SP1, 4.0 SP2, 4.0 SP3, 4.0 SP4 · Server 3.5, 3.51, 4.0, 4.0 SP1, 4.0 SP2, 4.0 SP3, 4.0 SP4 · Server 4.0, 4.0 SP4 , Enterprise Edition · Server 4.0, Terminal Server Edition Cet exploit peut être effectué à partir d'un compte invité et tout autres comptes (il faut avoir accès à la base de registre). II. Principe : ______________ Windows NT met en oeuvre un système de mémoire cache dans lequel il charge des librairies dynamiques (DLL) particulièrement importantes et surtout très fréquemment utilisées. Elles sont alors partagées entre tous les programmes. Cela évite des copies répétitives en mémoire de ces DLL, améliorant ainsi l'utilisation de la mémoire et les performances du système. À partir du moment où une de ces DLL a été placée dans le cache, elle n'est plus jamais rechargée depuis un fichier sur le disque (du moins tant et aussi longtemps que Windows n'est pas quitté). Le chargement de ces DLL est effectué au démarrage de Windows (avant ouverture d'une session), à partir d'une liste contenue dans la clef « KnowDLLs» Voici le lien dans la base de registre (Voir image1.gif) : HKEY_LOCAL_MACHINESystemCurrentControlSetControlSession ManagerKnownDLLs On y retrouve une vingtaine de DLL, dont "kernel32.dll", "user32.dll", "url.dll", "version.dll"... Ce système est (était?) censé accroître la sécurité, puisque le remplacement sur disque d'une de ces DLL par une autre (de même nom mais modifiée) st totalement vain. En effet, prenons l'exemple de "comdlg32.dll", qui sert à afficher les boites de dialogue standard. Si au cours d'une session on décide de remplacer cette librairie par une autre version, (en admettant qu'il n'y ait à cet instant aucune application y faisant appel), cette opération sera inopérante, puisque Windows continuera à utiliser la version initiale de comdlg32, placée dans le cache. Donc, il est tout à fait possible à un utilisateur n'ayant aucun privilège de vider, modifier, ajouter un objet, en particulier une librairie système comme "kernel32.dll". A l'aide de cette librairie modifiée, il va être possible d'effectuer n'importe quelle opération par la suite. II. Exploitation : __________________ L'idée de base mise en oeuvre par L0ph Heavy Industries pour mettre en évidence ce défaut a été la suivante : 1- Création d'une DLL "kernel32.dll" modifiée, différent sur un point par rapport à la version originale : Le point d'entrée (DLLMain), appelé systématiquement à chaque chargement de la DLL par n'importe quel processus, a été réécrit complètement. Toutes les autres API renvoient simplement à la DLL d'origine. DLLmain effectue une énumération des objets "Windows Station", puis pour chaque, énumération des "Windows Desktop", avec communication du nom du propriétaire de l'objet et interrogation de l'utilisateur s'il veut lancer ou non un "shell" pour cette station/desktop. Tant qu'il voit son nom comme propriétaire, l'utilisateur doit répondre "non", jusqu'à ce qu'apparaisse comme propriétaire : AUTORITE NT/SYSTEM. A ce moment là, la DLL modifiée kernel32 va ouvrir une fenêtre console de commandes (command.com de DOS), mais qui n'a rien d'anodine, puisque le propriétaire en est AUTORITE NT/SYSTEM. Donc tout processus exécuté depuis cette fenêtre va hériter des droits AUTORITE NT/SYSTEM, c'est à dire avec le plus haut niveau de privilèges ! Ainsi, l'utilisateur n'ayant aucun droit - en théorie - pourra donc exécuter le gestionnaire des utilisateurs, ouvrir son compte, et le modifier à sa guise, en s'octroyant par exemple le niveau administrateur. 2- Choix d'une tâche qui déclenche indirectement un processus ayant AUTORITE NT/SYSTEM comme propriétaire : Toute application "classique" lancée par l'utilisateur hérite des privilèges de l'utilisateur, mais il peut y avoir des processus intermédiaires, lancés alors par Windows, et ayant alors AUTORITE NT/SYSTEM comme propriétaire. Cela se produit quand on lance une application d'un autre sous-système. On rappelle à cet effet qu'il y a 3 sous-systèmes sous Windows NT, en mode "user" (mode protégé), situés au dessus du système de base, en mode "kernel" (non protégé) : · Win32 (Applications Windows 32 bits + NT Virtual DOS Machine, dans laquelle s'exécuteront les applications Windows 16 bits et les applications DOS) · POSIX (Applications en mode caractère, normalisées, portables sous d'autres systèmes d'exploitation telles que UNIX) · OS/2 (Applications en mode caractère du système d'exploitation d'IBM) Par défaut, une session Windows est dans le sous-système Win32. Les autres sous-systèmes (POSIX et OS/2) sont alors inactifs. Si, depuis une fenêtre de commandes (Win32) on lance une application POSIX, cela va se traduire par l'exécution première du processus Win32 psxss.exe (Application sous-système POSIX, qui va donner le contrôle ensuite à la DLL Client POSIX psxdll.dll). Or ce processus, qui nécessite temporairement le passage en mode kernel, a donc pour propriétaire AUTORITE NT/SYSTEM. Par ailleurs, psxss.exe fait appel à kernel32.dll (ne serait-ce que pour les API LoadLibrary et GetProcAddress). Donc il va provoquer à un certain moment l'exécution du point d'entrée modifié de kernel32.dll, et ainsi permettre le lancement d'un shell appartenant à AUTORITE NT/SYSTEM. III. Mode opératoire : ______________________ On utilise deux fichiers fournis par L0pht http://www.bellamyjc.net/download/failleNT4/hackdll.zip · eggdll.dll : version modifiée de kernel32.dll · hackdll.exe : exécutable permettant la suppression et le remplacement d'un objet dans le cache la syntaxe est très simple : - suppression d'un objet : hackdll -d - ajout d'un objet : hackdll -a Par ailleurs, on a créé un compte dans le groupe "invités" (aucun privilège) du nom de "DICK". On commence par recopier dans le répertoire c:temp la DLL originale kernel32.dll, renommée ici en realkern.dll. Ce répertoire et ce nouveau nom sont obligatoires, la nouvelle DLL eggdll.dll effectuant une redirection "en dur" (nom et chemin) vers elle. L0pht ayant fourni les sources http://www.bellamyjc.net/download/failleNT4/hackdllsrc.zip il est toutefois possible de recompiler cette librairie si on veut changer de nom et/ou de répertoire. Ensuite on lance une session sous le compte DICK. On ouvre une fenêtre de commandes, dans laquelle on vide du cache la DLL kernel32.Dll, puis on la remplace par eggdll.dll. Voir image : image2.gif Il ne faut plus toucher à cette fenêtre, toute action provoquant le retour à la situation initiale. Depuis une autre fenêtre de commandes, on lance une commande POSIX. Le Ressource KIT de NT en contient tout un répertoire (commandes "vi", "ls", "cat", "rmdir", "grep",...), mais on peut toujours se contenter de taper par exemple la commande posix /c calc (NB: le programme "calc" a été pris au hasard. Ce n'est pas un programme POSIX, donc il y aura à la fin un refus de la part du lanceur "posix" de l'exécuter, mais cela n'a pas d'importance, puisque ce que l'on désire seulement est le démarrage du processus psxss.exe) Une première boite de dialogue apparaît : image3.gif On répond ici "Non", car le propriétaire est pour l'instant "DICK" D'autres boites analogues vont se suivre, jusqu'a ce qu'apparaisse : image4.gif On répond alors "Oui" à cette question puis à celles qui suivent ( image5.gif ). Une fenêtre de commande nommée "System Console" apparaît alors : Fenêtre console créée par kernel32.dll Le propriétaire est AUTORITE NT Lancement du gestionnaire d'utilisateurs depuis cette fenêtre. On peut modifier totalement le compte "DICK" et les autres ! ( voir image6.gif ). Fenêtre console ouverte normalement par DICK. Le propriétaire est DICK Lancement du gestionnaire d'utilisateurs depuis cette fenêtre. On ne peut pas modifier le compte "DICK" ! On peut d'ailleurs vérifier cette "dualité" de comptes, en exécutant la commande whoami, soit depuis une fenêtre de commandes traditionnelle, soit depuis une fenêtre de commandes lancée depuis la fenêtre System Console. [ Conclusion ] Voila c'est la fin. Dans un prochain article peut être je vous démontrerai comment contrer cette faille. Mais rien n'est moins sur. D'ici la ne faites pas trop de bétises et rappelez vous que je ne suis en aucun cas responsables de vos actes. --------------------------------------------------------------------------------------- VI. Introducion au TUnneling ICMP MeiK --------------------------------------------------------------------------------------- [ Introduction ] Peut-être avez vous un jour été confronté au problème suivant : relier deux machines n'étant pas situées sur le même réseau avec un firewall au milieu. Peut-être aussi ne savez vous pas si vous devez bloquer le traffic ICMP du genre ICMP_ECHO...cet article vous aidera je l'espère à prendre votre décision assez vite, car vous allez voir qu'il est possible d'échanger des informations par le biais du protocole ICMP. [ Firewall ] Le but premier d'un firewall : défendre une machine / un réseau, d'une autre machine / un autre réseau. Tout le traffic provenant de l'extérieur du réseau protégé doit passer par le firewall, mais seul le traffic autorisé pourra passer de l'autre côté du firewall - le reste sera rejeté. Bien sur, cela est comme ça dans le meilleur des cas : lorsque le firewall est immunisé. [ ICMP_ECHO ] Je ne vais pas décrire en détail le protocole ICMP, il existe de très bons documents pour cela. Ce protocole sert surtout à détecter des erreurs sur un réseau. Les paquets ICMP, tout comme pour les paquets TCP et UDP, sont encapsulés dans un paquet IP. Il existe 15 types de paquets ICMP, mais nous allons nous pencher sur deux types de paquets particuliers : les types 0 et 8 (ICMP_ECHO_REPLY et ICMP_ECHO_REQUEST). Dans la théorie, une machine cliente envoie un paquet ICMP_ECHO_REQUEST à une machine qu'on qualifie de serveur, dans l'attente que cette dernière lui réponde par un ICMP_ECHO_REPLY. En fait, la machine serveur n'a pas de serveur à proprement parler écoutant au niveau du protocole ICMP. En fait c'est le Kernel du système qui répond. Bon, ça c'est la raison d'être du programme PING, et non, ce programme n'a à la base pas été fait pour trouver des adresses IP, ni pour flooder, il a été fait pour vérifier qu'une machine est bien accessible. [ Covert Channels ] En résumé, un covert channel est un "canal de communication" pouvant être utilisé afin d'échanger des données, mais pas un canal utilisé ordinairement pour ça justement. N'importe quel bit de donnée peut-être un covert channel en fait, ce qui fait qu'ils sont très difficiles à détecter et peuvent mettre grandement en danger la sécurité d'un système. Il suffit de savoir ce que l'on cherche en fait (o, quand, comment). Dans le cas d'un covert channel ICMP, ce qui peut vous mettre la puce à l'oreille serait un fort traffic ICMP justement. Bon, ceux qui ont le plus de méthodologie implanteraient directement le daemon directement dans le kernel et génèreraient le moins de traffic possible. [ Pourquoi ... ] Pourquoi avoir besoin de relier deux machines ne faisant pas partie du même réseau, ensemble ? cette question peut ammener plusieurs réponses. Vous pouvez très bien être chez vous et avoir besoin de documents qui sont sur votre machine sur votre lieu de travail, mais vu que cette machine faisant partie d'un réseau privé, vous n'avez aucun moyen d'y accéder directement. Il y a bien évidement la solution consistant à mettre vos documents sur un serveur ftp quelconque (je sais pas, prenez Multimania par exemple), mais il y a toujours le risque que quelqu'un découvre ces informations et les prenne, et voici votre travail confidentiel devenu connu de quelqu'un que vous ne connaissez pas. [ ...Comment] Il existe un programme de tunneling, dont je citerais le nom après cette explication, qui encapsule des données arbitraires dans des paquets ICMP_ECHO_* et par conséquent, exploite le covert channel existant à l'intérieur de ce traffic ICMP_ECHO. Comme le fait remarquer Route dans son article sur le tunneling ICMP, c'est une forme de stéganographie, car les données "secrètes" sont planquées dans un paquet "classique". Les données étant encapsulées et cryptées, cela est normal. [ Loki ] Loki est un programme de tunneling ICMP comme vous pouvez vous en douter, qui peut être utilisé pour contourner des firewalls (enfin, plutot passer au travers on va dire). Du moment que le traffic ICMP_ECHO est autorisé, le covert channel utilisé par Loki existe. Je suis également en train de (tenter de) coder un programme de tunneling ICMP. Vu que je m'y suis pris un peu tard (ce matin du 1er Novembre), il ne sera pas prêt pour ce numéro de IOC, mais peut-être pour le prochain (il y a intérêt !). [ La Solution Finale ] La seule solution à ce genre de tunneling serait d'interdire toute forme de traffic ICMP_ECHO sur votre réseau. Autoriser les paquets ICMP venant d'hotes de confiance ne résoudrait rien, parce que le spoofing ICMP est relativement aisé, car c'est un protocole qui ne se base pas sur une connexion comme TCP. Il existe aussi un moyen, utiliser une sorte de firewall qui regarderait le contenu des paquets, et s'il voit que ce n'est pas un paquet ICMP_ECHO classique, il agit selon ce que l'admin a défini. [ Bibliographie ] Covert Shells - J. Christian Smith Project Loki - Route