[collaboratif] Les Botnets

[InstinctHack]

1. Définition

Un botnet (de l'anglais, contraction de « robot » et « réseau ») est un réseau de bots informatiques, des programmes connectés à Internet qui communiquent avec d'autres programmes similaires pour l'exécution de certaines tâches.

On peut pas faire plus clair

2. Fonctionnement d'un botnet malveillant

2.1 Les étapes

Etape n°1 : Infection de la victime (possibilité d'exécuter un binaire à nous sur la machine distante). Ceci est possible grâce au social-engineering (plugin à "installer" pour voir la vidéo) ou en exploitant les failles du navigateur ou des plugins installés dessus (Flash, Java, adobe reader) par le biais d'exploit kits vendus au marché noir.
Etape n°2 : Exécution du malware.
Etape n°3 : récupération des ordres via le C&C ou via le réseau P2P créé par le bot, et action du bot en conséquence.
Etape n°4 : revenir à l'étape N°2 :>
Le botnet peut également être codé de façon à se dupliquer, scanner le réseau local à la recherche de failles, afin de s'étendre à d'autres machines.
On peux imaginer qu'il transporte aussi l'exploitkit qui l'as fait venir sur la machine, ainsi que d'autres afin d'exploiter d'autres failles.

2.2 Les modèles de botnets

2.2.1. Le botnet centralisé
Tous les machines infectées se connectent à un centre de contrôle (C&C dans le jargon) pour récuperer les ordres et envoyer les données récoltées par le bot.
avantages :

• facile à comprendre (!= facile à mettre en place, donc d'autres modèles sont pas forcément plus difficiles à faire)
  
• toutes les données sont disponibles sur un même serveur (éventuellement 2 ou 3).
  
• On peut protéger le botnet soit en ajoutant plusieurs C&C (si un dns se fait désactiver, on peut toujours se connecter aux C&C de secours, cette approche est utilisée par Andromeda et Smoke Loader), soit en générant des noms de domaine via un algorithme connu de l'attaquant, permettant de mettre en place un C&C temporaire sur le domaine pendant une durée limitée.
  

défaults :

• Toutes les infos sont disponibles sur un même serveur, ce qui rend le botnet vulnérable si le centre de contrôle est débranché par les autorités.
  
• Si le botnet devient trop grand, le serveur sature (DDoS involontaire du serveur).
  

conclusion : pas top.

2.2.2. Le botnet hiérarchisé.
(imaginez une pyramide)
Il existe un ou plusieurs serveurs en haut, ils contrôlent des serveurs un peu plus bas qui eux-mêmes contrôlent des machines un peu plus bas.
avantages :

• Moins de staturation du serveur par-rapport au centralisé.
  

défaults :

• Le rajout d'un ou plusieurs noeuds est problématique (doit-on rajouter le noeud en "bas", au niveau "intermédiaire" ?.
  
• Ne semble pas adapté pour un botnet (de type maître/esclave)
  

conclusion : brainfuck useless.

2.2.3. Le botnet p2p.
(imaginez une toile d'araignée)
aucune machine n'est au-dessus de l'autre, chacune des machines envoit des informations à ses pairs.
avantages :

• pour détruire le botnet, il faut déconnecter toutes les machines (via un sinkhole, c'est-à-dire envoyer les connexions des noeuds dans un "trou noir")
  

défaults :

• Pour donner des ordres, comment on fait ? c'est plus complexe à gérer que dans les cas précédents, mais très abordable avec du chiffrement. / chiffrage asymétrique dans l'ensemble.
  
• Doit être capable de résister à une attaque lancée par un noeud "malveillant" pour perturber le fonctionnement du botnet
  

conclusion : doit être plus réfléchi que les autres, mais le botnet est nettement plus solide.

2.3 Les canaux de communication

Un réseau communique, et pour cela il existe de nombreuses méthodes :

• requête http/https ; avantages : difficile à différencier de requête "légitime"
  
• canal irc ; avantages : on peut utiliser un serveur tiers pour communiquer
  
• un enregistrement TXT d'un DNS avec un ttl assez court; avantage : c'est L337 =] ; défault les DNS sont en géréral faciles à détourner par les autorités ou même les FAI et puis la masse d'informations est assez faible.
  
• des photos stéganographiées ; avantage : on peut poster les images sur des serveurs d'hébergements "gratuits" (mais ici comment récupérer les images envoyées par un noeud ? Par des comptes ouverts par des bots et "suivre" les publications du bot, enfin cette technique n'est qu'une idée )
  
• On peut aussi utiliser un protocole homemade (ce qui est généralement le cas, le protocole est souvent basé sur UDP) ; avantages : plus flexible ?
  

2.4 La phase de bootstrap

Dès lors qu'une machine est infectée, la première question qui se pose est : comment le bot va-t-il pouvoir rejoindre le réseau P2P si celui-ci ne possède pas de serveur central, il n'a aucune informations concernant les autres noeuds du réseau.
En réalité celui-ci va se connecter à un serveur de bootstrap pour récupérer ces informations, mais qui n'impactera pas la "survivabilité" du réseau si celui-ci venait à être coupé ou saturer.
On peut par exemple citer l'exemple du protocole P2P Gnutella qui possède des serveurs indépendants listant les noeuds par ordre de dernière activité.
Il peut toutefois exister une autre manière, le bot peut créer un exécutable d'infection qui contiendra une liste de noeuds dans la section .rsrc de l'exécutable, sous forme XML par exemple, ou également brute.
Dès lors, le bot n'aura qu'à utiliser cet exécutable pour infecter d'autres machines, et les nouvelles machines infectées n'auront absolument pas besoin de se connecter à un serveur de bootstrap, quelle aubaine pour ces vilains tipiaks !
Une fois la liste des noeuds récupérée, le bot peut ensuite se connecter au réseau, et attendre passivement les commandes.

2.5 Réseau P2P et bouclage infini

Imaginez le cas suivant : le bot A fait passer une commande aux bots B, C et D, mais comme ceux-ci ont le bot A dans leur liste de noeuds et qu'il est facile de trouver un autre chemin dans un réseau P2P, le bot A finira par reçevoir la commande qu'il a déjà reçu et la fera à nouveau véhiculer dans le réseau : il en résultera un bouclage infini et une congestion du réseau.
La méthode pour contourner ce problème est assez enfantine :
1) Ne pas renvoyer bêtement un paquet à son envoyeur, mais cela ne suffit pas.
2) Générer un jeton unique pour chaque requête, ainsi le bot n'aura qu'à stocker ce jeton en mémoire et saura si il a déjà reçu la requête. Si il l'a déjà reçu, il pourra l'ignorer et se contenter de faire sa vie. On peut aussi rajouter un TTL au paquet (ce qui permet aussi de nettoyer la liste des jetons obsolètes, sinon le bot risque de consommer beaucoup de mémoire)

2.6 Empoisonnement de la liste des noeuds

Le problème de l'architecture P2P est qu'il n'existe pas de moyen sûr d'identifier les données qui y véhiculent, et un algorithme de chiffrement asymétrique ne permet d'identifier que l'administrateur, mais pas si un bot est en réalité un humain qui voudra espionner le réseau et le corrompre afin de l'éteindre.
Pour palier ce problème il n'existe pas vraiment de solution ultime, il n'y a que comme possibilité de vérifier un minimum les informations reçues, et ne changer uniquement que les adresses des noeuds "morts" :
- est-ce que les noeuds que j'ai reçus sont-ils valides, puis-je me connecter dessus ?
- l'adresse IP de tel bot est-elle particulière ? est-ce l'adresse d'un VPN, d'un proxy ou d'un organisme dont les adresses sont connues (éditeur antivirus, FBI et compagnie ?) ?
Cela permet d'obtenir un niveau de confiance légèrement plus élevé même s'il n'est pas optimal.
A partir de là il est possible de prendre des actions automatiques contre les noeuds de faible confiance : les ignorer, simuler des réponses positives pour faire perdre du temps à l'intrus, lancer une attaque DDoS comme le fait le botnet Storm etc...

3. Contrôle

Désormais, vous devez vous demander : si il n'y a pas de serveur central, comment reconnaître si une commande vient de l'administrateur, ou d'un méchant fouineur qui veut faire tomber le botnet ou s'en servir pour son compte ?
La réponse est tout aussi simple : il faut utiliser un algorithme de condensat (SHA-512) et un algorithme de chiffrement asymétrique (RSA-4096). (http://fr.wikipedia.org/wiki/Rivest_Shamir_Adleman) La plus grosse clé déjà cassée était long de 768 bits (Le 12 décembre 2009) avec un système de calcul distribué. en 2010, des chercheurs de l'université du Michigan ont réussi à casser une clé RSA de 1024 bits en provoquant des erreurs au niveau du microprocesseur. Alors avec une clé de 4096 bits, on est large, malgré de possibles avancées technologiques secrètes développées par la NSA ou autres.
Le bot ne possède évidemment que la clé publique de l'administrateur, qui lui conservera sa clé privée secrètement et pourra éventuellement les changer à souhait.
L'administrateur n'aura alors qu'à chiffrer le condensat de son ordre à l'aide de sa clé privée. Si en déchiffrant le condensat à l'aide de la clé publique le bot obtient le condensat original du message, alors le bot saura que la commande vient bien de l'administrateur, il pourra faire passer le message aux autres bots auxquels il est connecté et exécuter la commande à son tour. Il faut tout de même que les autres vérifient eux aussi le message, car si le premier messager est un imposteur, il pourrais faire faire exécuter des commandes aux autres (enfin les clés publiques sont généralement hardcodées dans le bot par le botmaster).
En général le chiffrement asymétrique fonctionne ainsi :
L'émetteur récupère la clé publique du récepteur, chiffre le message avec cette clé, et le récepteur peut le déchiffrer avec sa clé privée qui as gardé.
La, L'émetteur chiffre le hash du message avec la clé privée, afin que le récepteur puisse déchiffrer avec la clé publique et ainsi vérifié que l'émetteur possède bien la clé privée.
Plus d'informations ici : http://www.linux-france.org/prj/edu/arch...23s03.html
Note : Le message ici n'est pas privé, tous les noeuds vont le recevoir, le monde entier pourrait le lire, alors chiffrer le hash ou le message n'est pas important (on peux faire l'un ou l'autre, mais pour des raisons de performances et de sécurité, le hash est mieux et reste compatible avec des applications dont le message doit rester secret (c'est-à-dire que personne d'autre que l'émetteur et le récepteur ne doit pouvoir le lire)
L'intérêt de tout ça, c'est d'authentifier l'auteur comme étant l'admin du botnet, si on ne le faisait pas, n'importe quel noeud pourrait envoyer n'importe quel ordre au botnet tout entier (ce qui est en pratique difficile, si les clés publiques servant à encoder/décoder les hash sont intégrées dans les binaires par le botmaster, un changement de clé empêchera la connexion du bot au réseau).
On voit donc qu'au final le mécanisme d'authentification est beaucoup plus poussé que dans une architecture centralisé, et ne peut être violé à moins qu'Interpol se mette à utiliser des supercalculateurs pour factoriser la clé RSA.

4. Usages

Généralement un botnet sert à quatre choses :

• ddos (http://fr.wikipedia.org/wiki/Attaque_par...de_service)
  
• spam
  
• récupération de données
  
• calcul distribué (reverse hash par exemple ou factorisation de clé RSA)
  

Les trois premiers de ces usages sont totalement illégaux, mais le quatrième reste légal si les propriétaires sont d'accord pour. (il existe un soft qui aide la recherche en donnant un peu de sa puissance de calcul, lien à retrouver)

5. Détection

Soit avec un honeypot qui réussit à détecter que l'attaque est "signée" par le botnet (genre 0day) ou comportement caractéristique.
Soit

quand tu le prends en pleine tete tu sais qu'il est la en general

6. Protection

6.1 Protection du botnet

Si c'est un botnet centralisé ou hiarchisé, le problème est double, le serveur qui n'est pas fiable (enfin si, juste avant le FBI :] ) et les zombies qui peuvent dire de la merde, genre (ouais, j'ai calculé la zone de hash, mais pas trouvé le hash, alors qu'il n'as rien fait, parce qu'au bout, c'est un connard de whitehat venu casser notre business)
Les contrôles doivent se faire "coté maître" et pas forcément croire ce que l'autre dit.

6.2 Protection de sa machine (avant infection)

• Etre à jour
  
• Etre sous GNU/Linux </troll>
  
• Pas jouer au con en installant des softs louches, ni exec des scripts "trouver sur internet"
  
• Pas chercher les problèmes
  

6.3 Protection de sa machine (qui se mange un ddos)

Attendre :] et poser des ban et des règles dans iptables (ce qui est très difficile voire impossible si on possède une "box", le mieux étant ici de s'équiper uniquement d'un modem ADSL et de monter soi-même un routeur, pourquoi pas avec un raspberry pi ?).
Mais sans oublier que les machines sont reliés par des "tuyaux" , si il est plein, même le meilleur firewall ne sert à rien.
Certaines entreprises par exemple, font appel à Arbor (http://www.arbornetworks.com) qui grâce a son système "PRAVAIL" (système de routeur) permet de réduire considérablement les IP entrantes en les filtrant en fonction de leur provenance (par pays) en amont afin de faire le tri, et ce routeur se doit toujours avoir un tuyau suffisament gros pour encaisser les requêtes.

7. Destruction

Reverse le binaire et envoyer des fausses informations afin de déstabiller le botnet, etc.... (je dévelloppe pas trop c'est pas mon domaine)
sinon :


8. Annexes

En 2007, l'attaque DDOS la plus emblématique de l'histoire as eu lieu contre l'Estonie, provoquant la coupure des systèmes bancaires et déorganisant totalement le pays, avec des émeutes et des scènes de pillage...
http://en.wikipedia.org/wiki/2007_cybera...on_Estonia
http://www.pcinpact.com/archive/36407-Es...Russie.htm
Certaines personnes pensent que l'informatique est un monde de 1 et de 0, ils oublient de croire que cela peut avoir des conséquences graves dans le monde physique.
Et voilà la visualisation d'une attaques ddos :




Ce post est très incomplet, ce n'est qu'une introduction, n'hésitez pas à réagir, on pouras le compléter et débattre
Merci à Ekroz, BadTasTe et aaSSfxxx qui ont participé à la rédaction de ce document.

et note toute personnelle, ça m'as fait plaisir de voir qu'en moins de 24h, on fait faire un petit truc colaboratif dans la joie, la bonne humeur et la passion

[Mazaki]

Eh bien, il faut croire que je ne savais pas tout au sujet des Botnets
Merci à toi!
Edit: à vous !

[InstinctHack]

Merci à toi!

Non, "vous" je suis pas le seul à avoir écrit. (c'est important pour moi)

Eh bien, il faut croire que je ne savais pas tout au sujet des Botnets

Oh tu sais, supersnail fait le malin ( ) à powned du malware toute la journée, mais lui aussi à appris des trucs en écrivant.

Travailler ensemble pour écrire, apprendre et partager ensemble =D

[Ekroz]

Eh bien, il faut croire que je ne savais pas tout au sujet des Botnets
Merci à toi!

Les malwares n'ont pour limite que la folie ou le génie de ceux qui les conçoivent :')
Je me rappelle pour exemple quelqu'un qui voulait réaliser un trojan qui communique par ICMP sur OpenSC, je me demande si il a fini par réussir.

[notfound]

@Ekroz : On ne sait pas, il n'a jamais répondu à nos ping !

@Khaled + Supersnail : Thx pour le thread, très instructif, bien écrit dans l'ensemble et très clair

[ark]

Super article, bravo a vous

[Atlas]

Très interessant , merci beaucoup à vous !

[0pc0deFR]

L'article est très bien réalisé. Merci à tous.

Pour la section "Destruction", il existe plusieurs techniques pour ça et comme toujours ça dépend de "qui on est" et du type de botnet. Les services de police peuvent aisément faire fermer le serveur C&C (enfin ça dépend ou il est hébergé mais en général ils y arrivent) d'autant plus que le nombre de C&C hébergé chez des hébergeurs type OVH augment énormément et ceux ci collabore avec les autorités. Dans d'autres cas les C&C possèdent des vulnérabilités et les Whites hats vont simplement faire un tour sur le serveur pour récupérer des infos et tomber le botnet (voir la présentation de Paul Rascagneres à la NDH2k12: http://www.youtube.com/watch?v=uXPnyYTLtno).

[thxer]

Super boulot les gars !

[fr0g]

Joli article dude , merci de ta contribution