Commençons par les choses qui fâchent. Est-ce que c'est vraiment grave ? Mon pronostique sur la question : oui. Et ce pour plusieurs raisons. D'abord parce que les auteurs sont crédibles. Au moins à mes yeux. Je les avais croisé à Recon en 2005 où ils avaient mentionné Unicornscan pendant leur talk. J'avais ensuite pu en discuter avec eux et l'impression que j'ai gardé de ces deux compères n'est clairement pas celle de gens qui manipulent des concepts qui leur sont étrangers. Ensuite, parce qu'ils ont récemment fait une présentation à Sec-T au cours de laquelle, bien qu'ils n'aient pas révélé de détail technique, ils ont produit deux démos. Et le moins qu'on puisse dire, c'est que les retours sur leur prestation vont plutôt dans leur sens. On peut en particulier lire :

Actually, the demo was cool. With 200 packets per second,
they DDOSed an apache on a wintendo in seconds. They
estimate 7KBPS is all they need to DDOS just about any
webserver. In addition, they just killed a whole windows
box with this attack.

Sans commentaire... Les slides de leur talk sont disponibles en archive[1] sur le site de la conférence. Allez les lire, parce qu'ils ne sont clairement pas dénués d'intérêt.

Enfin, parce que l'interview qu'ils viennent de donner et dont le podcast est en ligne, ajoute quelques pistes qui ne font, je pense, que renforcer la crédibilité de l'annonce. Ça commence en néerlandais, mais ça passe en anglais à partir de la cinquième minute, et c'est extrêmement instructif. Les philosophes du disclosure apprécieront en particulier la partie où ils expliquent pourquoi ils publient même si c'est grave et qu'il n'ont pas trouvé de patch.

Question suivante : est-ce la fin du monde ? On verra bien, mais je ne pense pas.


Maintenant, comment ça marche ? Très bonne question à laquelle je n'ai pas de réponse pour le moment. Juste des pistes, telles qu'ils les ont présentées. Ce qui est clair, c'est que leur attaque est un déni de service basé sur une surconsommation de ressources dans la pile TCP de la machine sollicitée. L'idée est donc pour l'attaquant de parvenir à faire effectuer à sa cible des opérations infiniment plus coûteuse qu'elles ne le sont pour lui. C'est cette asymétrie qui conduit à l'écroulement, l'effort du méchant étant faible par rapport à l'effet induit.

Comment s'y prennent-ils ? Une piste est très claire : ils utilisent des SYN-Cookies côté client. C'est quoi un SYN-Cookie ? C'est un mécanisme défini à la fin des années quatre-vingt-dix comme parade au SYN-Flood. Cette attaque en déni de service visait en effet à conduire une machine à consommer de la mémoire en lui envoyant un maximum de TCP SYN. On voit bien l'asymétrie : avec un seul paquet et aucun besoin de conservation d'état, l'attaquant poussait sa cible à créer les entrées contenant les paramètres des connexions TCP en attente, lesquelles ne se concrétisaient jamais. Avec le SYN-Cookie, le serveur ne crée plus d'entrée. Il ne fait que renvoyer en SYN-ACK un numéro de séquence[2] qui n'est en fait qu'un hash des paramètres de la connexion à ouvrir, plaçant ainsi ces paramètres dans le paquet lui-même, et pas en mémoire. Si un ACK parvient à la machine, il suffira de vérifier son numéro d'acquittement pour voir s'il correspond bien à un hash valide. Sinon, on le jette. Et s'il n'arrive jamais, ce n'est pas grave, on n'a pas consommé de mémoire. Exit le SYN-Flood.

On vient de voir comment appliquer cette idée à un serveur. Mais ça marche aussi avec un client. En effet, quand un client ouvre une connexion TCP avec un serveur, il doit également créer des structures en mémoire le temps que handshake se termine. D'où une consommation de ressources. Or, on peut tout à fait appliquer le principe du SYN-Cookie au SYN. L'ISN est une nouvelle fois un hash des valeurs courantes qu'on pourra vérifier de façon identique avec le numéro d'acquittement renvoyé en SYN-ACK. Sans consommer de ressource. Ainsi, un client peut compléter des handshakes de connexions TCP sans aucune consommation de mémoire, et se retrouve en position asymétrique par rapport à un serveur qui n'utilise pas ce mécanisme, ce qui est le comportement par défaut aujourd'hui, le concept de SYN-Cookie n'étant pas super compatible avec un aléa des ISN fort.

Rien que se contenter d'ouvrir et fermer des connexions implique déjà, à lui seul, un impact significatif sur les performances de la machine interrogée. Ce type d'attaque n'est pas nouveau et a déjà fait l'objet de publications en 2000 et un approfondissement avec Naptha, dont le principe consiste certes à ouvrir de nombreuses connexions, mais surtout à amener la pile cible dans des états gourmand en ressources. Quelques exploits ont suivi et plus ou moins bien démontré l'efficacité de la méthode.

Je suis d'accord une analyse publiée par Fyodor sur deux points. D'abord, je pense effectivement que cette tendance à nous annoncer la fin du monde avant chaque conférence est quelque peu... dérangeante. Même si cette mode n'a pas été initiée par Kaminski, loin de là, croyez-moi. Ensuite, il me semble également qu'il y a là-dedans quelque chose de similaire. Mais contrairement à lui, je pense que, si on a effectivement affaire à des améliorations du concept, il y a très probablement quelques idées nouvelles. Comme ils l'expliquent très clairement dans le podcast, l'attaque n'intervient réellement qu'une fois la connexion établie. L'histoire des SYN-Cookie côté client n'est donc effectivement qu'un nice to have permettant d'initier l'attaque à peu de frais, en particulier face à une machine implémentant les SYN-Cookies. Ce n'est donc clairement pas le fond du problème, et c'est ce qui fait qu'on ne la bloquera pas en activant les Syn-Cookies. Les références nombreuses à la notion d'état de la connexion me semblent aller dans ce sens. De plus, les effets annoncés et confirmés en démo sont plus importants que ceux de Naphta. Il est donc clair que c'est plus efficace, et qu'ils peuvent pousser le bouchon jusqu'à un ou plusieurs états dans lesquels la connexion se retrouvera bloquée indéfiniment.

Il y a ensuite ces histoires de timers et de compteurs qui reviennent quelques fois dans l'interview et font l'objet d'un slide dans leur présentation. Là encore, la gestion de temps d'attente et de compteur est quelque chose de pénalisant. Cela peut sembler ridicule à l'échelle d'une connexion, mais lorsque vous en avez quelques milliers en parallèle qui s'amusent toutes au même petit jeu, ça devient vite le cauchemar. Rajoutez à tout ceci des options intéressantes[3], des fonctionnalités pas piquées des vers et quelques problèmes d'implémentation, et je pense que vous ne manquerez pas d'obtenir un cocktail relativement détonnant. Par exemple, il faut des piles sérieusement buggées pour que Naphta puisse planter une machine, même si ça arrive. En général, lorsque vous arrêtez l'attaque, votre cible récupère rapidement ses capacités. Or là, ils ont montré des cas pour lesquels un reboot s'avérait être la seule solution...

Maintenant, entre faire ces constatations et juger de la criticité du problème, il y a un gouffre que je suis un poil trop fatigué pour enjamber à l'heure où je rédige ces quelques lignes. Et quant à entrevoir des solutions, il me semble un peu tôt pour s'y aventurer...


Pour conclure, je dirai que comme avec l'histoire de DNS, on peut passer des heures à tirer des plans sur la comète, à émettre des hypothèses ou à les vérifier. C'est bien quand on a un peu de temps libre à y consacrer et de l'infrastructure pour monter un petite maquette, mais ce n'est pas mon cas en ce moment. Je vais donc vous laisser là avec ces quelques explications et hypothèses qui n'apportent au fond pas grand chose de plus à ce qu'on trouve déjà en ligne, mais qui auront peut-être le mérite de vous en livrer une compilation en quelque chose d'à peu près intelligible.

Quoi qu'il en soit, on verra bien le 17 ce qu'il en est réellement. Enfin, on espère... Je n'y serai pas, mais Fabrice fera le déplacement pour aller chercher le prix de l'élégance qu'il a remporté au Challenge T2, celui de la vitesse ayant été remporté par un autre français, Florent Marceau. Félicitations à tous les deux !

Notes

[1] Avec tous les autres.

[2] ISN.

[3] Ajustement de la taille de la fenêtre, l'adaptation à la vitesse du lien ou encore la gestion des congestions par exemple.