AET, contenu partiel et réflexions...

Publié le 20 octobre 2010 par Sid

D

ans mon précédent billet, je vous disais qu'on n'avait pratiquement aucun détail technique sur le contenu des fameuses AET découvertes par Stonesoft. Quelques mots ici, des chuchotements par là, pas de quoi se donner une véritable idée. La seule information réellement intéressante était fournie par SecurityVibes : il s'agirait de la combinaison de techniques d'évasion déjà connues.

On en sait aujourd'hui un peu plus, en particulier par l'intermédiaire de SecurityVibes une nouvelle fois. Jérôme Saiz y pointe très justement une présentation donnée par Stonesoft à Hack.lu l'an dernier...

Cette présentation est intéressante dans la mesure où on peut la rapprocher très précisément de la vidéo de démonstration mise en ligne sur Æntievasion que je pointais hier et que j'ai finalement déplacée ici :


Ajoutez à cela la présentation pointée par Johnjohn en commentaire. Certes, malgré son titre, elle ne contient pratiquement aucun élément technique, mais des indications qui permettent de confirmer tout ça.

On serait donc bien en face d'un arrangement de techniques d'évasions connues. Probablement quelques unes ont fait leur apparition entre temps, mais c'est l'idée globale. Je vais laisser de côté ce que je pense de la démarche marketing[1]. Mais une chose me semble claire : avoir bossé là-dessus avec ces résultats est quelque chose de fort respectable techniquement, mais je ne vois pas le rapport avec le cataclysme annoncé.

Ce qui m'amène à quelques réflexions sur l'impact global de cette (re-)découverte sur nos infrastructures. Il est clair que ces techniques permettent de délivrer des exploits pourtant connus sur des cibles vulnérables sans que l'attaque soit détectée par un IDS, un IPS ou tout autre système de sécurité basé sur ces techniques de détection. C'est un problème, mais il faut tout de même revenir un peu sur Terre.

Déjà, on a une cible vulnérable au bout de la chaîne. Les techniques d'évasion sont un facteur qui en accroît l'accessibilité. L'existence de ces techniques n'est pas une idée neuve, elle est vieille comme la sécurité réseau si j'ose dire. C'est donc une menace à prendre en compte dans la mise en place d'une architecture de sécurité, indépendamment du discours affirmatif et rassurant des vendeurs de boîtes. Cette prise en compte peut se matérialiser de pleins de manières différentes, comme par exemple faire ce qu'il faut pour ne pas avoir d'application vulnérable au bout du tuyau, ou du moins réduire le risque associé à cette éventualité.

Ensuite, comme la discussion a été portée sur le terrain du monitoring, avec la non détection de l'attaque par le IDS, là encore, il faut redescendre un peu. La problématique de la détection d'intrusion n'est pas une affaire de boîtes, encore une fois. La détection d'intrusion est un sous-ensemble du monitoring, et un bon monitoring ne se limite pas à une sonde posée au milieu du réseau. De fait, une bonne architecture de monitoring ne devrait pas être rendue aveugle par la cécité d'un composant. Dans le cas présent, et pour reprendre l'exemple de l'exploit Conficker proposé dans la vidéo, on ne sera peut-être pas capable d'empêcher la première infection. Par contre, on a les moyens de la détecter, ainsi que la propagation qui s'en suit. OK, on est en retard[2], mais on n'est pas à poil[3]...

Enfin, il y a là-dedans une idée autour des œufs dans le même panier. Si effectivement votre sécurité ne s'appuie que sur ce type de moyens techniques, vous êtes mal. Mais vous l'avez toujours été, parce que la menace qu'ils soient contournés a toujours été là, vous l'avez juste ignorée. Peut-être un risk analyst bien inspiré vous aura convaincu qu'elle était négligeable. Ce qui pose la question de la pérennité dans le temps des analyse de risque... Peut-être un vendeur vous aura convaincu que ça n'arriverait pas, ou que ça n'existait pas...

Évidemment, c'est très facile d'écrire tout ça dans un billet rapide sur un blog perdu au milieu de l'Internet mondial, entre trois tweets et deux articles. C'est nettement plus difficile à mettre en œuvre. Mais ce que je veux pointer surtout, c'est que l'existence même de ce buzz devrait nous ramener à la question nettement plus fondamentale de comment on fait de la sécurité, et de la robustesse de l'approche...

Notes

[1] Et le timing FAIL : ils ont clairement vendangé une place de choix à BlackHat ;)

[2] Comme pour un 0day en somme...

[3] Contrairement à un bon 0day par contre...