Hop, j'inaugure un nouveau type de post dans lequel je présente l'un des outils qu'il m'arrive d'utiliser en sécurité informatique et/ou que j'aurai aimé connaitre à un certain moment de ma vie. Pour ce premier article du genre je vais vous présenter "foremost", un outil de forensic (d'où l'image d'illustration que j'ai choisi).
foremost
Laissez moi vous raconter une petite histoire : il y a bien longtemp il est arrivé à ma copine de l'époque de graver toutes ses photos de vacances sur un DVD, puis de les effacer de son disque dur et de vider la corbeille afin de gagner de la place sur le disque. Seulement voilà : une fois les photos définitivement supprimées du disque dur impossible de lire le DVD ! Il refusait d'être reconnu sur son ordinateur, sur le mien, et sur le lecteur de salon...Je ne vous raconte pas le désespoir dans ses petits yeux à ce moment là :(
Etant du genre persévérant (et sous linux) j'ai tenté un petit "dd" du DVD incriminé dans un fichier sur mon disque dur, puis j'y ai jeté un oeil "à l'arrache" (i.e. : string|less) et j'y ai vu des séquences qui ressemblaient furieusement à ce qu'on trouve dans des en-têtes de fichiers JPG...Ni une ni deux je dégaine mes outils préférés de l'époque (à savoir VIM et GCC) et je pond un petit parser en C qui tente de repérer les en-têtes des images et des vidéos puis d'extraire les octets qui suivent pour recréer les fichiers illisibles du DVD. C'est ainsi que pendant les 2h qui ont suivi la constatation de la perte des fichiers sur le DVD je me suis retrouvé à faire des "trucs cabalistiques" . Et finalement, au bout de tout ce travail, petit moment de gloire quand j'ai finalement lancé un "startx" afin d'exhiber toutes les photos et vidéos que l'on croyait perdues mais que j'avais quand même réussi à récupérer "par magie" :) !
Et bien j'ai découvert, des années après, que des petits malins avaient codé sensiblement le même outil, mais sérieusement et proprement :) ! Le nom de ce petit outil c'est "foremost", il fait la même chose que ma bidouille en C (à savoir chercher des en-têtes connues dans de la donnée brute puis reconstruire le fichier) mais lui il gère un nombre impressionant de format de fichier différents (contre juste "JPEG" et "MOV" pour mon vieil outil) et il est truffé de petites options qui le rendent terriblement efficace et tout terrain. Bref : un véritable régal pour récupérer des fichiers effacés (par erreur ou pas ;) ).
Cerise sur le gateau : il est sous license GNU, vous pourrez donc en profiter avec un simple aptitude install foremost, et il est également par défaut sur backtrack 3. Mauvaise nouvelle par contre : sur ma gentoo le package est vieux et cassé, donc si vous ne voulez pas utiliser de ~x86 sur ce paquet oubliez tout de suite le emerge foremost qui vous est venu à l'esprit et allez plutôt récupérer les sources pour le compiler vous même.
Petite ouverture en guise de conclusion : foremost cherche les header mais également les footer, et en fait cette stratégie de récupération de fichier s'appelle le "File Carving". Cette stratégie est d'ailleurs assez répandue et il existe pas mal de soft de ce type, la star de la famille étant en ce moment "photorec". En deux mots photorec gère plus de type de fichiers que foremost (pour n'en citer qu'un : bz2), en revanche il n'est pas inclu dans backtrack3 par défaut (ou alors j'ai mal cherché) et il se trouve dans un paquet avec un nom à la c*n sur gentoo : testdisk.
Voici une bien jolie coïncidence je trouve, bien qu'avec un peu de travail et de jugeotte j'aurai peut être été capable de le faire exprès : on peut vaguement lier un récent buzz au sujet abordé dans l'un de mes tout derniers articles, article qui ne portait pas du tout sur une faille à la mode pourtant :) ! Du coup, faute de temps, vous n'aurez pas droit sur ce billet à un jeu de mot débile pour le titre et en prime il sera un peu moins fouillé que ce que j'aurai aimé faire. Mais bon, c'est le prix à payer pour publier pendant que c'est encore dans le vent :) (ne vous inquiétez pas : je ferai un article plus détaillé plus tard !)
Mais de quel buzz parle-t-il ?
Je parle du buzz portant sur le CVE-2008-5353. Oui : rien de bien nouveau (le numéro de CVE ne trompe pas), et pourtant ça ne buzz que maintenant (l'explication plus tard). Ce CVE parle d'une faille dans la JRE qui permet, via un petit tour de passe-passe, de contourner la sandbox dans laquelle les applet java sont cloisonnées lorsqu'elles sont exécutées dans le contexte d'un navigateur web. Pas mal du tout quand on sait qu'une fois sorti de la sandbox l'applet java peut exécuter n'importe quelle commande système avec les droits de l'utilisateur qui fait tourner le navigateur web. Par exemple en surfant simplement sur une page "lambda", si vous avez accepté les applet java (ce qui est par exemple le cas par défaut dans Safari sur MacOSX...) l'applet peut, à votre insu, télécharger un fichier, l'enregistrer dans un coin sur le disque dur, lui donner les droits d'exécution, et enfin s'arranger pour qu'il soit exécuté à chaque ouverture de session (si jamais ça vous rappelle quelque chose, c'est que vous n'êtes pas stupide ;) )
Parlons technique !
Comment, techniquement, celà se fait-il ? Et bien c'est sur cette partie que j'aurai aimé pouvoir passer plus de temps parce que n'étant pas un expert de Java j'ai un peu de mal à saisir rapidement toutes les subtilités du chmilblick. Enfin je tente tout de même de vous relater ce que j'ai saisi, et je ferai un article plus détaillé quand j'aurai eu le temps de bien comprendre.
En substance Java permet la sérialisation d'objets et c'est là dedans qu'on va aller fouiller. En effet la dé-sérialisation de l'objet de type "sun.util.calendar.ZoneInfo" est, semble-t-il pour des raisons historiques, gérée dans un bloc à privilèges élevés (i.e. il s'affranchit des restrictions de type sandbox). Jetons un oeil au code de désérialisation des objets de type "sun.util.calendar" pour bien comprendre :
private void readObject(ObjectInputStream input) throws IOException, ClassNotFoundException
{
...
ZoneInfo zoneinfo = (ZoneInfo)AccessController.doPrivileged(new PrivilegedExceptionAction() {
public Object run() throws Exception
{
return input.readObject();
}
});
if (zi != null) {
zone=zi;
}
...
}
Donc, comment exploiter ça ? L'idée c'est de demander la désérialisation d'un objet qui soit reconnu comme de classe "sun.util.calendar", nous démmerder pour que la désérialisation de l'objet "sun.util.calendar.ZoneInfo" soit en réalité la désérialisation d'un tout autre type d'objet, et que la méthode "readObject" de ce prétendue "sun.util.calendar.ZoneInfo" permettent de faire des choses ''sympa'' que la sandbox nous interdirait :) !
Dans cet article très complet l'auteur explique qu'il remplace son objet de type zoneinfo par un objet de type ClassLoader, et qu'il en surcharge la méthode "readObject" pour attribuer "this" (i.e. son objet ClassLoader) à une variable statique afin qu'il ne soit pas garbage-collecté. En effet son objet ClassLoader devrait être garbage collecté à la fin de la tentative de désérialisation en ZoneInfo puisqu'on voit bien dans l'extrait de code que je vous ai mis que l'objet retourné n'est pas attribué à la variable "zone" si il n'est pas classe ZoneInfo valide (et du coup il ne se retrouve référencé par rien, d'où le coup de garbage collector)
Bon, ça c'est l'idée du principe de base, et nous allons devoir (hélas) nous en contenter pour l'instant parce que je n'ai pas eu le temps de creuser plus que ça :( Mais, tant pis si je me répètes : je pondrai un autre article plus détaillé dès que j'aurai eu le temps de jouer un petit peu avec tout ça (ça tombe bien, c'est un weekend de 3 jours qui s'annonce ;) ...)
Pourquoi ça ne buzz que maintenant ?
Easy as a pie : Comme je l'ai dit en tout début d'article ce bug est vieux néanmoins les applets java sont toujours autorisés par défaut sur le navigateur par défaut de MacOSX (safari) et.....et....et....et la dernière JRE Apple n'est toujours pas patché :) ! Du coup quelques chercheurs ont commencé à faire du boucan et ça suffit à faire monter un petit buzz (on le comprend aisément n'empèche...si on résume : les utilisateurs de MacOSX sont par défaut vulnérables à de l'exécution de code à distance plus de 6 mois après que la faille ait pourtant été patché sur les JRE SUN :( )
C'est quoi le rapport avec l'un de mes articles précédents ?
J'avoue que c'est un peu capilotracté mais moi en tout cas j'y ai pensé tout de suite : Vous pondez une applet qui exploite cette faille, vous en faite un GIFAR, vous uploadez ce GIFAR n'importe où sur internet (simplissime vu le nombre de forum au monde qui permettent de s'inscrire en deux secondes et d'uploader un avatar), ensuite il ne vous reste qu'à trouver un XSS sur un site quelconque pour y insérer votre applet et vous ownez tout les MacOSX qui passent :) Flipant hein ? Boah...au moins ça me permet de taquiner mes amis qui sont sous Mac et qui croient encore que OSX est "imprenable" :D !
Allez, encore un titre de billet à la c*n basé sur un jeu de mot douteux. Donc, vous avez une petite idée de ce dont ce billet va parler ?...Nan ?..Toujours pas ?...Bon et bien je vous donne la réponse alors : les Gifar (jeu de mot avec "Jafar") Les gifars ne sont pas bien nouveaux (ça a au moins un an si je ne m'abuse), mais j'ai un petit peu l'impression que le concept a fait un "flop" assez vite après avoir été dévoilé, d'où la suite du titre : "j'suis coincé" (la citation entière "Jafar j'suis coincé" étant un moment drolissime du film "Aladdin" de Disney, 1992, ça ne nous rajeunit pas tout ça). Bon, maintenant que vous savez de quoi nous allons parler, passons aux choses sérieuses !
GIFAR, c'est quoi ?
Un GIFAR c'est un fichier GIF combiné à un fichier JAR. Pour être plus précis je pourrai d'ailleurs dire "concaténé" plutôt que "combiné". Et voilà. C'est juste ça.
L'intérêt des GIFAR c'est qu'un fichier GIF se lit à partir du début (c'est assez instinctif) avec un header suivit du contenu à proprement parler, en revanche les fichier JAR (qui ne sont en fait que des fichiers ZIP) se lisent en partant de la fin ! Ainsi si on concatène un fichier GIF avec un fichier JAR on peut lire le fichier résultant dans les deux sens (i.e. à partir du début ou à partir de la fin) et trouver ainsi, selon le sens choisi, un fichier GIF ou un fichier JAR tout à fait correct.
Ce type de fichier est donc assez amusant puisqu'on y voit ce que l'on vient y chercher : si vous cherchez un GIF vous trouverez bien un GIF, si vous chercher un JAR vous trouverez bien un JAR. Là où ça devient utile c'est que beaucoup de sites web permettent aux utilisateurs d'uploader des images et vérifient, au moment de l'upload, qu'il s'agit bien d'une image et non d'un quelconque code malveillant...ça tombe bien un GIFAR c'est une image au format GIF tout à fait correct :) ...mais un GIFAR c'est aussi un joli fichier JAR tout à fait correct également.
Et comment ça s'exploite ?
Bon, maintenant que l'on sait ce qu'est un GIFAR : à quoi celà peut il bien servir ? Dans le paragraphe précédent on a déjà apporté une réponse triviale : ça sert à travestir un fichier JAR sous les traits d'un fichier GIF, et donc ça peut servir à uploader des fichiers JAR sur des serveurs qui n'acceptent que les fichiers images. Mais ensuite ? Mon petit avis à deux sesterces sur la question c'est que les GIFAR n'ont pas fait tant de bruits que ça parce que, justement, ils sont assez délicats à exploiter.
La première attaque qui vient à l'esprit consiste en effet à uploader notre GIFAR puis à "se demmerder" pour faire exécuter le JAR dans le navigateur des visiteurs. Petit souci : pour que ça soit faisable il faut un XSS dans le site en question afin d'ajouter les balises HTML qui vont bien pour introduire notre GIFAR en tant que JAR dans les pages du site (et non en tant que GIF, ce qui manquerait d'intéret). On voit donc bien qu'une telle attaque nécessite à la fois une vérification laxiste du type d'image uploadé et un XSS, ce qui commence à faire beaucoup. De plus si on met en perspective l'intéret d'une telle exploitation on se rend compte que c'est beaucoup d'efforts pour pas grand chose : par défaut une applet java ne peut quasiment rien faire (pas d'accès au disque local du client, et pas de communication réseau sauf vers le site d'où provient l'applet). Néanmoins il y a moyen de contourner ces limitations :
- Navigateur web mal configuré qui autorise les applet à foutre le chantier sur le disque local (rarissime...j'espère);
- utilisation de requête réseau vers le site où est hébergé le GIFAR afin d'essayer de laisser des traces quelque part de données clients que l'on voudrait récupérer (ex: si on est sur un forum on fait une requête qui va nous envoyer un message privé contenant le contenu des cookies qui nous intéresse...pour peu qu'ils ne soit pas en http-only bien entendu);
- et enfin : la signature des applets.
La signature des applets ? Oui oui, la signature des applets. Une applet, ça peut se signer :) Une applet signée s'affranchit d'ailleurs de quasiment toutes les limitations (i.e. : on obtient l'accès au disque dur, on peut ouvrir des socket vers n'importe où, etc.) ce qui en fait d'excellents candidats à une attaque par GIFAR+XSS. Comment fait on pour signer une applet alors me direz vous ? Celà doit être extrèmement compliqué. Et bien non, ça se fait en deux lignes avec les outils du JDK :
$ keytool -genkey -alias votreAlias
$ jarsigner -verbose monapplet.jar votreAlias
Easy as a Pie :) ...MAIS ça n'est pas gagné pour autant. En effet une applet signée s'affranchit de toutes les limitations, mais pour qu'elle ai le droit de s'exécuter l'utilisateur doit l'y autoriser explicitement, donc vous allez avoir un gros vilain popup tout moche qui demandera à l'utilisateur si il souhaite exécuter cette applet. Bon, ça n'est pas la fin du monde, mais ça commence à devenir lourdingue puisqu'il nous faut, pour une exploitation réussi : pouvoir uploader un GIF, trouver un XSS, que la victime de notre XSS accepte explicitement de lancer notre applet.
Conclusion
Après ce petit article introductif tout mignon sur les GIFAR vous réalisez bien que ça n'est pas la panacée, mais je pense que c'est tout de même un excellent petit "trick" à avoir dans sa besace en cas d'attaques combinées ou d'exploitation délicate, et c'est pour ça que j'ai réalisé cet article :) Par exemple il pourrait vous être bien utile si vous vous retrouvez coincé en pentest sur une machine avec juste une ligne de commande limitée en taille et pas d'accès aux logiciels de téléchargement usuels (wget, tftp, etc.) mais que vous pouvez uploader des GIF...
Comme promis dans mon premier article sur les botnet voici un nouveau billet pour exposer quelques unes des utilités d'un botnet. Vous allez voir ça valait le coup d'attendre tant les botnet s'apparentent à des "outils à tout faire".
De nos jours tous les botnet sérieux appartiennent à la mafia et leur objectif est donc clairement de faire de l'argent. Certes, on trouve encore quelques petits botnets qui ne suivent pas la logique du profit, mais ils sont marginaux et je ne parlerait donc pas d'hacktivisme ici. Parlons donc de gros sous : Comment gagner de l'argent avec un botnet ?
Vous avez dit Mafia ?
D'abord la recette classiquissime au possible, celle qui a été à l'origine même des premières mafia (au sens usuel du terme) : la "vente" de protection. Je m'explique : visualisez votre magasin préféré. C'est fait ? Vous le voyez bien dans votre tête ? Avec les clients et les vendeurs ? Maintenant imaginez qu'il y a 1000 fois plus de clients que d'habitude : on se marche sur les pieds, on ne parvient pas à atteindre la caisse, on ne peut plus rentrer dans la magasin...bref : le magasin ne fonctionne plus :( Sur internet c'est pareil : vous choisissez un site web dont le métier est de prendre des paris online, et vous le menacez d'envoyer à ses portes 500 000 ordinateurs simultanéments (ce qui aura pour effet de rendre son site web inopérant, et donc de l'empécher d'exercer son activité de commerce tant que les 500 000 ordinateurs fraperont à la porte) sauf si, bien entendu, il vous accordes quelques menus piecettes...disons 10% du chiffre d'affaire qu'ils auraient perdu si vous aviez lancé votre attaque. C'est une bonne affaire : ils évitent de perdre 90% de ce chiffre d'affaire ;) ...Bref : extorsion par menace au DDoS.
Mais aussi...
Autre méthode toute bête : des centaines de milliers de machines ça fait beaucoup de puissance de calcul et beaucoup de bande passante sur internet, donc ça a la capacité d'envoyer beauuuuucouuuup de mails à l'heure. Vous proposez donc à un propriétaire de site web peu scrupuleux d'envoyer quelques millions d'e-mails de publicité pour son site, contre rémunération bien entendu :) (oui, ça s'appelle du spam.)
Une petire dernière pour la route, toute bête encore : on avait dit dans l'article précédant que les centaines de milliers d'ordinateurs membres du botnet étaient des ordinateurs appartenant "à madame Michu" sur lesquels on avait installé un logiciel malveillant. Ca serait pas mal si le logiciel malveillant avait la possibilité d'intercepter tous les couples "identifiants/mot de passe" qui transitent par cet ordinateur...par exemple celui qu'utilise madame Michu pour aller regarder son compte en banque tout les mois et, éventuellement, virer de l'argent depuis ce compte :)
Bref il y a pléthores de possibilités et je vais laisser votre imagination travailler un petit peu (après tout il n'y a pas de raison que ça soit moi qui fasse tout le travail ;) ). Donc en guise de conclusion : les botnets sont d'intéressants outils à multiples facettes pour les botmasters, et une source presque intarissable d'articles pour ce blog donc attendez vous à en voir quelques autres à l'avenir ;) !
Quand j'ai pensé au titre de ce billet je me suis tout de suite dit que c'était une excellente idée et j'ai carrément arboré un grand sourire niais tout seul devant mon écran...mais maintenant que je l'ai écrit je réalise que sans explication personne ne pourra deviner ce à quoi je pensais en le choisisant donc voici l'explication : C'est un jeu de mot (merdique, soit) avec l'onomatopé bien connu "Cot Cot Codec" que j'ai modifié en accord avec mon envie de parler de botnet aujourd'hui.
Quelques bases
Même si c'est l'enfance de l'art pour quiconque s'interesse un minimum à la sécurité informatique je vais ré-expliquer quelques bases sur les botnet (mais c'est vraiment parce que je suis trop gentil ;) ).
Avant tout un botnet c'est quoi ? Un "botnet" c'est un ensemble d'ordinateurs sur lesquels un individu (ou un groupe d'individu) possède une certaine influence, généralement à l'insu de leurs propriétaire. En version plus simple à comprendre (mais un peu moins exacte du coup) : un botnet c'est un ensemble d'ordinateurs que controlent secrètement de vilains pirates.
Comment sont construits ces botnets ? Les botnets sont, pour l'écrasante majorité, composés d'ordinateurs appartenant "à madame Michu". Ce sont donc des ordinateurs de particuliers qui sont compromis par l'installation d'un logiciel malveillant. Pas de trait de génie à attendre pour installer ce logiciel sur des centaines/milliers/millions d'ordinateurs d'ailleurs, les recettes classiques et évidentes s'appliquent :
- Vers/Virus
- Site web piégé
- Distribution directe du programme via P2P ou sites web dédiés sous un nom sympa comme "Mi-grosSoft Office.exe", "Universal NoCD crack.exe", "Free Virus Remover.exe", etc.
Enfin à quoi ça sert un botnet ? Basiquement ça sert à créer un groupe important d'ordinateurs qui sont capables de récupérer les ordres d'un individu (ou d'un groupe d'individu) et de les exécuter. A partir de là il y a de nombreuses utilisations possibles pour une armée d'ordinateur zombies et j'en expose quelques une dans un article en cours de rédaction (donc repassez sur ce blog dans les jours à venir si vous voulez une étude un petit peu plus en profondeur des usages qu'on peut faire d'un botnet ;) )
A vos ordres, chef
Bon, maintenant que les concepts théoriques de bases sont connus de tous mes lecteurs on va pouvoir passer à quelques études pratiques ! Le point auquel nous allons nous intéresser dans ce premier article sur les botnet c'est : comment les botmaster communiquent ils leurs ordres aux pc-zombie ?
Il y a bien longtemps, à l'époque des premiers botnets, le fonctionnement de base était simple. Une fois infecté un ordinateur allait systématiquement rejoindre un certain channel irc (éventuellement protégé par mot de passe) et il y recevait les ordres de son maitre puis y faisait son rapport. Simple, efficace, évident :) Peut être trop simple d'ailleurs...En effet cette méthode a beaucoup d'inconvénients : un chan IRC avec des centaines de milliers de personnes qui répondent "oui maitre" à l'un d'entre eux ça n'est pas très discret, de plus si le botnet se fait repérer il est facile pour les autorités de couper le serveur IRC et là c'est "bye bye botnet" pour le pirate qui avait passé du temps à le monter.
Du coup on a eu quelques raffinements. Par exemple au lieu d'ouvrir un channel sur irc.undernet.org les botmasters se sont mis à installer leurs propres serveurs irc (de préférence sur des serveurs compromis et avec des versions customisées d'IRC pour réduire le traffic superflus). C'est tout de suite plus discret, mais pas encore parfait parce que pas mal d'ordinateurs (en particulier en entreprise) sont derrière des firewall et/ou proxy applicatifs qui bloquent les ports IRC et/ou carrément le protocol IRC. Du coup on a eu une petite mode de botnet controllés non pas par IRC mais via des serveurs web HTTP (bah ouais : le HTTP c'est vachement plus discret que l'IRC). Mais ça s'est vite avéré limité...
En effet un botnet ça prend du temps (et de l'argent ?) à construire donc ça serait bien si on pouvait assurer sa survie, or avec un point de rendez-vous unique comme un serveur HTTP (ou IRC) pour controller le botnet on met en danger la survie du réseau (en effet il suffit à une autorité quelconque de couper le serveur de ralliement pour que tout le botnet soit perdu). Pour résoudre ce problème deux nouveaux concepts ont été introduits dans les botnets :
-
Le P2P > Des réseaux de P2P sont employés à tour de bras par énormément de monde pour partager des fichiers ou pour discutter, donc il est tout à fait possible de les utiliser pour donner des ordres à ses ordinateurs zombie. Un exemple pratique serait de distribuer un fichier texte "mes_ordres.txt" sur le réseau Kad(eMule) : Le pirate partage ce fichier sur Kad, les zombie (qui sont également sur Kad) le télécharge et exécutent les ordres. Le premier avantage c'est que, contrairement au cas où les ordres sont posés sur un serveur web, il est impossible d'empécher les zombie d'obtenir les ordres en coupant un simple serveur. Le second avantage c'est qu'il devient très dur de remonter à l'IP qui a posté le fichier sur le réseau (i.e. : celle du botmaster).
-
OTP > "OTP" ça signifie "One Time Password" et c'est un concept assez intéressant : en très résumé un "One Time Password" c'est du texte construit à partir d'une règle secrète connues des seuls initiés. Par exemple je peux convenir avec un ami que notre OTP ça sera "le jour de la semaine concaténé à l'année", ainsi si je veux communiquer avec mon ami je n'aurai qu'à regarder quel jour on est et pour lui prouver que c'est bien moi qui lui parle je lui donnerai le mot de passe "lundi2009". La force de l'OTP, par rapport à simplement convenir d'un mot de passe unique avec mon ami, c'est que même si quelqu'un intercepte notre mot de passe il est incapable de savoir quel sera le mot de passe du lendemain (bon...avec l'exemple que j'ai donné c'est pas trop dur de deviner, mais si à la place du jour et de l'année on avait décider de concaténer un sel énorme avec un timestamp unix et notre OTP serait finalement le SHA256 de tout ça, ça devient plus délicat à deviner ;) )
Grâce à ces deux concepts on peut créer des choses extrèmement puissantes, la plus belle dont j'ai connaissance ayant été employé par Storm : Les bots calculaient chaque heure un nouvel OTP, ils se connectaient au réseau Skype et rentraient en contact avec un compte qui avait pour identifiant l'OTP calculé; ce compte était la source des ordres. Résultat :
- Utilisant Skype les communications passaient aisément tout les firewall/proxy/nat.
- Utilisant Skype les communications étaient chiffrées donc discrètes.
- Utilisant un OTP il était impossible de prédire la source des ordres et donc de l'usurper.
- Utilisant Skype et un OTP il était imposible de couper le lien entre le botmaster et ses bot (à moins de couper Skype en intégralité...).
Bref : Du très bien pensé :)
Mais...à quoi ça sert tout ça ?
Les utilités d'un botnet sont aussi vastes que l'imagination humaine. Je pourrai arrêter cette section là, mais vous seriez frustrés de ne pas en savoir plus. Je pourrai également commencer à expliquer les nombreuses utilités d'un botnet, mais là ça ferait un post vraiment beaucoup trop long. Donc à la place je vais arrêter cet article ici, et vous donner rendez vous dans quelques jours pour un article exposant quelques unes des utilités d'un botnet :) ! Donc comme on dit aux "zoo essai" : stay tuned.
⇇ « Page 5 / 6 » ⇉
