vendredi 28 février 2014

400 Gigabits par seconde, c'est beaucoup pour un DDOS?

Il y a un peu moins d'un an, je titrais un article de blog "300 Gigabits par seconde, c'est beaucoup pour un DDOS"? Il y a de cela deux semaines, CloudFlare donnait de nouveaux chiffres alarmant, citant une attaque à 400Gbit/s.

Cette info m'a inspiré deux réflexions. La première concerne  le messager: on sait que cloudflare vend de la protection antiDDos, ils sont donc les plus intéressés de citer des DDos de grande ampleur en raison de la publicité que cela leur fait. Les chiffres ont en effet été repris par un certain nombre de sites d'infos techniques avec des liens vers cloudflare. Vu les moyens mis en oeuvre pour l'attaque contre SpamHaus pour atteindre 300GBit/s, ce chiffre de 400 avait une odeur de suspicion. La seconde réflexion concerne les motivations de la personne effectuant ce DDos qui ne sont jamais données, non plus que la cible. Nous aurions une personne (ou un groupe de personnes) capable de lancer le DDos le plus puissant du monde, sans raison, ni motivations, ni cible. Ce qui semble étrange. J'ai donc laissé de côté un peu cette info, pensant être en face d'un "coup" marketing plus que technique.

Puis des informations techniques sont tombées, extrêmement intéressantes.

Tout d'abord, sur la méthode employée. Comme attendu, les attaquants ont utilisés de l'amplification. Au lieu d'attaquer le serveur, on requête un serveur tiers avec l'IP source de la victime, et on s'arrange pour que la réponse de ce serveur tiers soit plus grosse que la requête. Double effet: on masque la véritable IP de l'attaquant, et on gagne en puissance de feu^W débit. Il y a 6 mois, on entendait beaucoup parler d'amplification par les serveurs de jeux (par exemple à la GreHack). Un nouvel amplificateur particulièrement puissant a été trouvé: le NTP. Un bon article de Bortzmeyer explique cette attaque. Je me demande si des gens ont scanné Internet à la recherche de "chargen", ça pourrait être très pratique. [EDIT : effectivement : Cf https://isc.sans.edu/diary/A+Chargen-based+DDoS%3F+Chargen+is+still+a+thing%3F/15647]

Ensuite, des chiffres équivalents ont été donnés par d'autre fournisseurs de service comme OVH, ce qui tend à prouver la réalité de ces chiffres élevés.

Enfin, un document interne de CloudFlare donne beaucoup d'informations sur l'attaque (contrairement à leur premier communiqué). L'amplification NTP permet de faire un x200 en débit (!!!). L'autre information percutante, c'est celle-ci "Remarkably, it is possible that the attacker used only a single server running on a network that allowed source IP address spoofing to initiate the requests." En x200, il suffit de deux cartes réseaux à 1Gbit/s pour atteindre 400GBit/s... CloudFlare compare ensuite l'attaque au DDos qui a eu lieu contre spamhaus (qui avait sollicité de gros moyens) avec celle-ci. Il a suffit à l'attaquant 7 fois moins de machines amplificatrics pour un résultat 33% supérieur. Finalement, l'attaque à 400Gbit/s est relativement plus simple que celle contre SpamHaus, permettant d'imaginer ce DDos comme un test grandeur nature.

Pour terminer, il semblerait que le prochain amplificateur soit trouvé avec  snmp. Les premiers calculs indiquent une amplification maximale de 650! S'il se réalise, le prochain DDos dépassera le Terabit/s. Comme disent les anglais: "wait and see".

lundi 10 février 2014

Bluetouff et gogleuh

Vous n'avez pas pu le rater, Bluetouff est désormais un cybercriminel.

Résumé des faits : Bluetouff cherche à l'aide de Google diverses données. Il tombe sur le site web de l'Anses qui contient des documents très intéressants. Il en télécharge plusieurs, et commente certains d'entre eux sur le site de reflets. L'Anses s'émeut du fait de trouver ses documents et décide de mener une enquête.
Bluetouff se voit donc face à la justice, et tout geek un minimum versé dans la technique ne voit pas d'autre issue dans ce procès que la relaxe puisque Bluetouff n'a rien fait d'autre que de télécharger des documents accessibles publiquement.

Le jugement en appel, décidé par le parquet uniquement (l'Anses n'a pas voulu poursuivre la procédure) montre le contraire puisque Bluetouff est condamné. On a pu voir fleurir un bon nombre de commentaires mi amusé, mi ecoeuré sur le thème: la justice n'y connait rien, et utiliser gogleuh n'a rien de répréhensible. Le jugement est pourtant très clair et n'a rien à voir avec Google.

Le jugement, public, est disponible : Arrêt Bluetouff. Il se lit très bien (6 pages). Les juges vont devoir qualifier en droit les actes qu'on leur a soumis. Le procès va donc chercher à éclaircir trois points, pour juger de ces trois infractions:
1/ Bluetouff s'est introduit de manière frauduleuse dans le site de l'Anses
2/ Bluetouff s'est maintenu frauduleusement dans le site de l'Anses
3/ Bluetouff a volé des données sur le site de l'Anses

Et là, les juges vont faire du juridique et non pas de la technique. Sur le premier point, ils indiquent que Bluetouff n'est pas poursuivi car rien ne vient prouver l'intention frauduleuse d'accéder à ces données, puisque même l'Anses le reconnaît. Point besoin d'être expert sécu pour comprendre que si le plaignant indique n'avoir rien fait pour protéger ses données, la bonne foi du visiteur passant par là peut être acquise. Sur le second point, c'est là que tout se joue. Les juges indiquent noir sur blanc que le prévenu "a constaté la présence de contrôles d'accès" et qu'il le reconnaît. Point besoin de technique non plus pour lui mettre le dos le "maintien frauduleux". Dans l'esprit des juges, il savait que c'était protégé, il est resté, donc maintien frauduleux; c'est simple. Sur le vol, les juges indiquent que Bluetouff a copié, dupliqué et partagé ces fichiers sans plus d'explications. Les juges indiquent vol de fichiers inaccessibles au public, mais le point 1 montre qu'en tout état de cause ces fichiers étaient accessibles au public (de manière involontaire, certes). C'est un point léger dans leur argumentaire.

Que peut on en conclure? Le raisonnement des juges est assez clair et le point central repose sur cet "aveu" de Bluetouff disant qu'il est resté après avoir su qu'il s'agissait de documents protégés. Si vous vous faites arrêter un jour (et je ne le souhaite à personne), faites attention à ce que vous dites...


Pour la suite, il y a le point de vue du principal intéressé sur son blog, et un pourvoi en cassation qui est en cours. Je ne suis malheureusement pas très optimiste sur le pourvoi en cassation :-( l'histoire nous le dira.

jeudi 23 janvier 2014

Haka est sorti: TCP/IP security is not boring anymore!

Il y a trois ans, je publiais un article intitulé "TCP/IP security is boring" dans lequel j'indiquais que la sécurité TCP/IP était devenue ennuyeuse.
La sécurité remonte sur les couches hautes, et les firewalls sont finalement limités dans leur usage: on coche une case pour appliquer une politique de sécurité sans jamais pouvoir sortir du carcan initial prévu par l'outil.

Mais le projet HAKA voit le jour, et je vais en faire un peu sa pub [1].

Je fais partie de l'équipe qui développe le projet HAKA, et avec HAKA la sécurité réseau ne sera plus jamais ennuyeuse. Haka est un langage orienté sécurité et réseau permettant d'accéder à n'importe quel champ protocolaire d'une communication et d'interagir avec celle-ci de manière simple (modification, suppression, création de paquet) sans avoir à se poser des questions compliquées sur la gestion bas niveau (gestion de la mémoire, dissection de protocole, ordonnancement des paquets, etc..). Ceci donne des possibilités illimitées quant à l'application de règles de sécurité et d'analyse des flux réseaux.

Un site web a été ouvert, ainsi qu'un github car HAKA est open-source. Get it, commit, play with it, fork it ou tout autre mot en 'it' :) Une version précompilée pour debian (32 ou 64bits) est disponible afin de pouvoir le tester facilement. Haka peut être lancé sur du trafic live pour l'analyser (le logger, bloquer, modifier, etc..) ou bien sur des pcap. La version 0.1 permet d'accéder à n'importe quel champ IP, TCP et HTTP.

Pour montrer la facilité d'usage de HAKA, des tutoriels montrent comment utiliser Haka. Après l'inévitable Hello World, sont présentés la manière de faire du filtrage sur n'importe quel champ IP/TCP/HTTP puis une méthode originale pour bloquer les navigateurs webs qui ne sont pas à jour en les forçant à être redirigés sur les sites d'update. Puis un module de statistiques est écrit sur une manière de browser des pcaps. Ensuite un exemple de détection de SQL injections est écrit: en une centaine de lignes de code, il devient possible de détecter et bloquer (ou modifier, ou ce que vous voulez en fait) des SQLi sur flux sans utiliser de proxy applicatifs ou autre outil lourd, avec des possibilités d'extensions simples. Pour finir, un exemple de groupe de règles est expliqué.

Pour donner un avant goût, voici un exemple de règle haka:
Pour les exemples, un seul endroit: le site web.

Haka a beaucoup d'autres fonctions qui en font un langage facile à utiliser:
debugger, analyse interactive, API C/Lua pour l'étendre, etc... La version 0.1 permet d'utiliser les règles de sécurité, les versions suivantes vont donner la possibilité de définir une grammaire et une machine à état pour définir soi-même des règles de dissection protocolaire.

Haka, c'est bon, mangez-en :-)
---
[1] Ce blog reste un blog personnel, le site officiel et la communication officielle autour de Haka se fait sur son site web et sur github.