Africa teaching

1 - Introduction
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.

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.

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 :

suite: http://www.authsecu.com/honeypots-honeynet/honeypots-honeynet.php