Aurora FAIL

Je ne vais pas faire l'insulte à mes lecteurs de revenir sur le déroulement de ce qu'il est convenu d'appeler "l'opération Aurora".

A peu près tous les vendeurs d'antivirus, de HIPS et de NIPS vous ont déjà sensibilisés au fait que leur produit aurait permis de bloquer cette attaque (sauf que les 30+ entreprises concernées - dont Symantec -disposaient déjà probablement de nombreux produits de sécurité actifs sur leur réseau, mais c'est un autre débat).

Au final, toute cette histoire aura été l'occasion d'un FUD considérable sur Internet, et d'une superbe opération de communication de la part de Google qui se pose en champion de la liberté.

FAIL#1 Ce qui me choque le plus, c'est qu'une société aussi innovante que Google soit à la merci d'une faille dans Internet Explorer 6. Moi qui pensait qu'ils utilisaient Chrome ;)

Compte-tenu de l'historique de sécurité d'Internet Explorer 6, et du nombre de failles "annexes" qui peuvent être déclenchées automatiquement par le biais de ce navigateur (tous les ActiveX et les codecs installés localement, ainsi que Acrobat Reader, Flash, ShockWave, QuickTime, RealPlayer ...), la conclusion évidente est que surfer sur Internet avec IE6 sans protection (ex. SandBoxIE ou au minimum DropMyRights) est juste parfait pour attraper le SIDA, la syphilis et la variole de l'informatique.

Toute entreprise dont la sécurité interne dépend directement de la sécurité d'IE6 est condamnée à l'infection. Avec le nombre de gens brillants en charge de la sécurité chez Google, j'aurais cru cette vérité comme évidente pour eux.

Personnellement, je ne sors plus qu'avec FireFox + NoScript, et encore je me méfie de la surface d'attaque offerte par le plugin NoScript lui-même ...

FAIL#2 "Les attaques proviennent de la Chine".

Dans le cas de Google, il est fort probable qu'il s'agisse d'un insider job depuis leur bureau en Chine. Toute personne qui a ouvert un bureau ou une usine en Chine sait que ce scénario est très crédible.

Mais quand on regarde le schéma global de toutes les attaques, très peu d'adresses IP sont effectivement situées en Chine. N'importe qui aurait pu faire l'acquisition de cette faille IE (comme il s'en vend plein sur Internet). Et la "sophistication" des attaques reste à démontrer ... car après tout il s'agit juste de déposer des exécutables sur le système de la victime, utilisant un protocole basé sur le chiffrement "XOR" avec une clé de 1 octet. N'importe quel pare-feu personnel devrait être capable de détecter ce type d'activité anormale.

Si vous êtes paranoïaque, il ne vous coûtera pas grand'chose de bloquer toutes les adresses IP chinoises sur votre réseau. Ainsi que tous les domaines de la forme "[0-9]+.{org|.net}" (par exemple, les domaines chinois 8800.org et 3322.net étant exclusivement connus pour héberger du malware).

FAIL#3 Data Execution Prevention (DEP)

Tous les problèmes de sécurité ont été résolus en même temps qu'ils sont apparus. Mais l'industrie s'est tout de suite confrontée aux problèmes, tandis que les solutions ont été beaucoup plus longues à faire leur chemin.

Ainsi au début des années 2000, le problème de la non-exécution de code dans les zones de données a été parfaitement résolu par PaX, mais ce patch n'a jamais été intégré dans le noyau Linux pour des histoires personnelles entre Linus et la PaX team.

Parmi les conditions de mise en oeuvre de la non-exécutabilité des données (DEP sous Windows), il est évident depuis le début que le positionnement des exécutables en mémoire doit également être aléatoire (ASLR), sinon il est possible d'utiliser une technique connue sous le nom de retour dans la libc.

Bref, tout le monde a spéculé sur l'efficacité de DEP pour protéger Internet Explorer. Outre le fait que les versions 6 et 7 n'utilisent pas DEP par défaut, cette protection est de toute façon inefficace sur Windows XP puisque le placement en mémoire des exécutables est prédictible (sauf à utiliser WehnTrust).

Le plus gênant dans cette affaire, ça n'est pas le fait que DEP puisse être contourné sous certaines conditions. C'est que personne n'a pris la peine de tester avec l'exploit public avant d'écrire tout et n'importe quoi.

FAIL#4 Secure Development Lifecycle (SDL)

Ce qui me semble extrêmement intéressant dans les dernières failles Internet Explorer et Acrobat Reader, c'est que les méthodes de développement sécurisé proposées par Microsoft (SDL) n'auraient pas permis de les éviter.

En effet, le SDL vise (entre autres) à bannir les API "dangereuses" (de type strcat() ou sprintf()) - c'est-à-dire à lutter contre les buffer overflows.

Or les failles dont on parle sont de type use after free. Par exemple dans le cas de la faille IE, celle-ci se résume à:

1. Ajouter un évènement sur un objet du DOM
2. Supprimer l'objet en accédant au DOM via JavaScript
3. Attendre que l'évènement soit invoqué

Trivial, n'est-il pas ? Pourtant ces failles sont extrêmement difficiles à détecter, aussi bien en analyse statique qu'en analyse dynamique (fuzzing) que par une revue de code manuelle, surtout sur du code massivement multi-threadé.

On peut donc suspecter que le use after free va encore faire parler de lui ... et pas seulement dans Internet Explorer 6 !

Conclusion

L'affaire "Aurora" ne change rien à mes conclusions antérieures. Si vous avez des vrais problèmes de sécurité, prenez conseil auprès de vrais spécialistes. 95% de l'information disponible sur Internet est partielle, fausse ou non vérifiée.