Code Red - Le ver qui voulait faire tomber la Maison Blanche
Ça va, elle vous plait toujours ma série de l’été ? Je suis loin d’avoir fini mais on fera une petite pause bientôt. Toutefois, rassurez-vous, j’en ai encore sous le pied. La preuve avec cette nouvelle histoire d’un ver informatique qui a foutu le bordel sur Internet en juillet 2001.
Code Red. Un nom qui fait encore trembler les admins système qui l’ont vécu. Des centaines de milliers de serveurs infectés en quelques heures, des milliards de dégâts, et la Maison Blanche obligée de changer l’adresse IP de son site web pour éviter une attaque DDoS massive.
Et tout ça, découvert par deux hackers qui buvaient du Mountain Dew Code Red dans leur bureau de Californie un vendredi soir. Mais le plus dingue dans cette histoire, c’est surtout que la vulnérabilité exploitée avait été découverte un mois plus tôt.
Microsoft avait même publié le patch MS01-033, mais personne ne l’avait installé. Du coup, le 19 juillet 2001, Internet a découvert ce que pouvait faire un ver capable de se propager automatiquement sans intervention humaine….
Voici donc l’histoire complète de Code Red, depuis la découverte de la faille jusqu’à la panique mondiale.

L’histoire commence avec Riley Hassell, qui travaille chez eEye Digital Security à Aliso Viejo en Californie. En juin 2001, ce chercheur en sécurité passe ses soirées à chercher des vulnérabilités dans les logiciels populaires. Pas pour faire le mal, juste pour le défi, pour la gloire dans la communauté underground. Riley fait partie de cette génération de hackers qui considère que trouver des failles est un sport intellectuel.
Un soir, Riley s’attaque à IIS (Internet Information Services), le serveur web de Microsoft. IIS propulse des millions de sites web dans le monde, des petites entreprises aux gouvernements et si vous trouvez une faille dedans, c’est le jackpot. Riley commence donc à fuzzer l’ISAPI (Internet Server Application Programming Interface) d’IIS, envoyant des requêtes malformées pour voir comment le serveur réagit. Il faut savoir qu’à l’époque, IIS 5.0, intégré à Windows 2000, était devenu une cible de choix avec ses nouvelles fonctionnalités WebDAV et ses méthodes d’authentification avancées.

Et là, bingo. Riley découvre que si vous envoyez une requête GET avec une URL super longue au fichier idq.dll (utilisé par l’Indexing Service d’IIS), le serveur plante. Mieux encore, avec la bonne séquence de caractères, vous pouvez exécuter du code arbitraire sur le serveur. C’est ce qu’on appelle un buffer overflow, le Saint Graal des vulnérabilités. Plus précisément, la faille se trouve dans la façon dont idq.dll gère les requêtes puisque le filtre ISAPI .ida (indexing service) ne vérifie pas correctement les limites de ses buffers d’entrée.
Riley et l’équipe d’eEye publient leur découverte le 18 juin 2001. Microsoft réagit immédiatement en publiant le bulletin de sécurité MS01-033 et un patch. L’alerte est claire, cette vulnérabilité est critique car elle permet de prendre le contrôle total d’un serveur IIS avec des privilèges SYSTEM. Le bulletin précise aussi que la vulnérabilité affecte IIS 4.0 sur Windows NT 4.0 et IIS 5.0 sur Windows 2000.
Sauf que voilà, personne n’installe ce patch. C’est dramatique, mais les admins système sont débordés, les entreprises ont peur de “casser” leurs applications, et puis bon, qui va vraiment exploiter cette faille ? Un mois passe et les serveurs restent vulnérables…

Les premiers signes d’alerte apparaissent finalement le 12 juillet 2001. Ken Eichman, ingénieur sécurité senior chez Chemical Abstract Services, remarque quelque chose d’étrange dans ses logs. Trois tentatives d’accès illégales depuis une seule adresse IP, apparemment en provenance de l’Université de Foshan en Chine. Et le lendemain, le 13 juillet, c’est l’escalade : 611 attaques depuis 27 serveurs différents. Eichman, contributeur régulier de DShield.org, alerte alors Johannes Ullrich. Le samedi 14 juillet, les sources d’attaque dépassent les 1 000. Le lundi 16 juillet, la confirmation tombe : c’est un ver.
A l’époque, les experts pensent à des scans de routine, donc rien d’alarmant. Mais ils ont tort car le ver est programmé pour rester relativement dormant jusqu’au 19 juillet inclus. C’est donc une énorme bombe à retardement.
Car quelque part dans le monde, un ou plusieurs programmeurs anonymes ont en réalité créé quelque chose de dangereusement nouveau… Ils ont pris la vulnérabilité découverte par Riley et codé le premier véritable ver informatique à propagation automatique. Pas besoin d’envoyer des emails, pas besoin d’interaction humaine. Le ver scanne Internet, trouve les serveurs IIS vulnérables, les infecte, et utilise ces nouveaux zombies pour scanner encore plus vite. Le code, écrit en assembleur Win32 Intel, ne fait que quelques milliers d’octets… C’est une œuvre d’art malveillante en miniature.
Le ver exploite astucieusement l’absence d’ASLR (Address Space Layout Randomisation) et de DEP (Data Execution Prevention) dans Windows 2001. Les DLLs se chargent toujours aux mêmes adresses sur tous les systèmes. Comme ça, le ver sait que l’adresse mémoire 0x7801CBD3 pointera vers MSVCRT.DLL, qui est la bibliothèque Microsoft Visual C Runtime. À cette adresse précise, il trouve l’instruction machine CALL [EBX], et ce registre EBX contient une adresse sur la pile modifiée par le fameux buffer overflow. Du coup le CPU exécute directement le code du ver. C’est du génie maléfique !
Dans les bureaux d’eEye Digital Security en Californie, Marc Maiffret et Ryan Permeh travaillent tard ce jeudi 19 juillet. Maiffret, qui n’a que 20 ans, est déjà une légende dans le milieu. Ancien hacker sous le pseudo “Chameleon”, il a fondé eEye à 17 ans après une visite du FBI chez lui. Ironie du sort, quelques semaines après cette visite, il s’associait avec Firas Bushnaq pour créer la société. Ryan Permeh, son collègue et ami, est quant à lui surnommé “Overflow Ninja” pour son expertise en reverse engineering.

Marc Maiffret (à gauche), Ryan Permeh (au milieu) et Riley Hassel (à droite) - source
Vers 20 heures, leurs systèmes de détection s’affolent. Un truc bizarre se passe sur Internet. Des milliers de serveurs IIS tentent de se connecter à d’autres serveurs avec des requêtes étranges contenant “/default.ida?” suivi d’une longue chaîne de caractères de ‘N’ et de shellcode encodé. Maiffret et Permeh commencent alors à analyser le trafic. Et ce qu’ils découvrent les glace.

C’est un ver qui exploite la vulnérabilité MS01-033 découverte par leur collègue Riley Hassell. Mais contrairement aux virus classiques, ce ver n’a pas besoin d’intervention humaine. Il scanne les adresses IP de manière pseudo-aléatoire avec une seed fixe, cherchant le port 80 (HTTP). Quand il trouve un serveur IIS non patché, il envoie sa charge utile et prend le contrôle du serveur.
Une fois installé, le ver fait plusieurs choses. D’abord, sur les systèmes en anglais, il défigure le site web en affichant un message : “HELLO! Welcome to http://www.worm.com ! Hacked By Chinese!” Un message provocateur qui fait immédiatement penser à une attaque chinoise.
En effet, le contexte géopolitique est tendu car trois mois plus tôt, le 1er avril 2001, un avion espion américain EP-3 et un chasseur chinois J-8 sont entrés en collision au-dessus de la mer de Chine méridionale. Le pilote chinois Wang Wei est mort, et l’équipage américain a été détenu pendant 11 jours. S’en est suivie une cyber-guerre entre hackers patriotes des deux pays. Ainsi, la Honker Union chinoise et des groupes américains se sont affrontés, défaçant des centaines de sites.

Maiffret et Permeh réalisent l’ampleur de la catastrophe. Ils ont besoin d’un nom de code pour l’incident. Sur le bureau, une canette de Mountain Dew Code Red, la nouvelle boisson caféinée rouge cerise lancée quelques semaines plus tôt. “Code Red”, dit-il. Le nom est parfait car c’est une alerte rouge pour Internet.
Mais ce n’est que la partie visible de l’iceberg. Le ver installe aussi une backdoor, désactive le service d’indexation d’IIS pour éviter les plantages, et surtout, il contient une bombe logique car à partir du 20 juillet, et jusqu’au 28 de chaque mois, tous les serveurs infectés lanceront une attaque DDoS coordonnée contre l’IP 198.137.240.91. C’est celle de www.whitehouse.gov . Des centaines de milliers de serveurs zombies s’apprêtent à bombarder simultanément le site du président américain. C’est de la cyberguerre, ni plus ni moins, cependant, le ver a une faiblesse : il cible une IP hardcodée, et pas le nom de domaine.
Les deux chercheurs passent la nuit à analyser le ver. Le code est relativement simple mais très efficace. Avec ses 100 threads simultanés pour scanner Internet, chaque serveur infecté devient un nouveau point de départ pour l’infection. C’est de la croissance exponentielle pure. Le ver cherche d’abord kernel32.dll en mémoire, scannant la plage 77E00000h–78000000h par incréments de 64K à la recherche de la signature ‘MZ’. S’il ne trouve rien, il essaie à partir de 0BFF00000h, supposant qu’il tourne peut-être sur Windows 9x plutôt que NT.
Le plus brillant dans le code, c’est la méthode de génération des adresses IP. Grâce à un générateur pseudo-aléatoire avec une seed fixe basée sur la date, tous les vers scannent les mêmes adresses dans le même ordre, évitant ainsi de saturer inutilement les mêmes cibles. C’est de l’optimisation de haute volée. Si SP1 ou SP2 est installé sur la machine, ou si elle tourne sous Windows NT 4.0, le ver ne peut pas se propager et le service WWW Publishing d’IIS plante simplement.
Au matin du 19 juillet, eEye publie une alerte d’urgence. Mais c’est déjà trop tard. Le ver se propage à une vitesse folle. À midi, plus de 100 000 serveurs sont infectés. David Moore et Colleen Shannon du CAIDA (Cooperative Association for Internet Data Analysis) à l’UC San Diego observent des chiffres hallucinants : en 14 heures, Code Red infecte 359 000 serveurs. Le pic d’infection atteint plus de 2 000 nouveaux hôtes par minute. Les réseaux commencent à saturer sous le trafic de scan.
Les CERT (Computer Emergency Response Team) publient l’Advisory CA-2001-19 à 14h00 et Microsoft republie en urgence son patch avec des avertissements en gros caractères. Les FAI commencent à bloquer le trafic suspect mais le ver est déjà partout. Le FBI et le NIPC (National Infrastructure Protection Center) lancent une enquête.
La communauté de la sécurité informatique est en ébullition. Sur Bugtraq, SecurityFocus, et les mailing lists, les experts échangent frénétiquement des informations. Comment stopper le ver ? Comment protéger les serveurs ? Comment éviter l’attaque DDoS contre la Maison Blanche prévue pour le lendemain ?
Car c’est ça le vrai danger. Si des centaines de milliers de serveurs attaquent simultanément whitehouse.gov, non seulement le site tombera, mais les dégâts collatéraux seront énormes. Les routeurs Internet pourraient saturer, les DNS pourraient flancher. C’est potentiellement Internet tout entier qui pourrait être affecté. 43% des serveurs infectés sont aux États-Unis, 11% en Corée, 5% en Chine, 4% à Taiwan.

La Maison Blanche prend la menace au sérieux. Une réunion de crise est organisée avec Akamai Technologies, qui héberge le site. La décision est radicale : Il faut changer l’adresse IP de whitehouse.gov. Si le ver attaque l’ancienne IP hardcodée, il ne touchera qu’une adresse vide.
Le 19 juillet au soir, Akamai procède au changement d’IP en urgence. L’opération est délicate : il faut propager la nouvelle adresse dans tous les serveurs DNS du monde. Normalement, ça prend 24 à 48 heures. Ils n’ont que quelques heures….
Les dégâts sont considérables car des milliers de sites web affichent “Hacked by Chinese!” au lieu de leur contenu normal. Des entreprises perdent des millions en revenus. Les équipes IT travaillent jour et nuit pour patcher et nettoyer les serveurs. Le coût total sera estimé à 2,6 milliards de dollars par Computer Economics : 1,1 milliard en coûts de nettoyage et 1,5 milliard en perte de productivité.
Mais le pire est évité. Le 20 juillet à 20h00, quand les serveurs infectés lancent leur attaque DDoS, ils bombardent l’ancienne IP de whitehouse.gov. Et rien. Ouf, la Maison Blanche a réussi son pari. Le stratagème a fonctionné parfaitement.
De plus, le ver Code Red original a une particularité : il ne survit pas au redémarrage. Il persiste uniquement en mémoire vive. Redémarrez le serveur, et il disparaît. Mais si vous ne patchez pas, il sera réinfecté en quelques minutes par un autre serveur zombie. C’est Sisyphe version numérique. Le ver est d’ailleurs programmé pour arrêter de scanner après minuit UTC et reprendre son activité le 1er et le 19 de chaque mois.
Et le 31 juillet, sans surprise, le ver se réactive comme prévu provoquant une nouvelle vague d’infections, et un nouveau chaos. Cette fois, les admins sont mieux préparés, mais les dégâts restent importants. Le CERT publie l’Advisory CA-2001-23 “Continued Threat of the Code Red Worm”.
Et puis, le 4 août 2001, c’est l’escalade. Une nouvelle variante apparaît : Code Red II. Malgré son nom, c’est un ver complètement différent, écrit par d’autres auteurs qui ont juste inclus la chaîne “CodeRedII” dans leur code. Au lieu de défigurer les sites, il installe une backdoor permanente qui survit aux redémarrages.
Code Red II modifie le système pour permettre l’exécution de commandes à distance. Il copie cmd.exe (l’invite de commandes Windows) dans les répertoires web comme “scripts” et “msadc”. N’importe qui peut maintenant exécuter des commandes sur les serveurs infectés via une simple URL. C’est la porte ouverte au pillage de données. Le ver installe aussi un rootkit appelé “Virtual Root” et n’a pas de fonction DDoS mais cherche à infecter les systèmes proches géographiquement.

Code Red II a été programmé pour se propager plus agressivement en Chine. Si le système infecté est configuré en chinois, le ver lance alors 600 threads de scan au lieu de 300. C’est drôle, vu le message “Hacked by Chinese!” de la première version. Le ver s’arrête de fonctionner après le 1er octobre 2001.
Bien sûr la communauté chinoise proteste contre l’amalgame créé par le message et le gouvernement chinois dément toute implication. Les experts en sécurité sont également sceptiques car le message semble être une diversion. eEye pense que le ver vient de Makati City aux Philippines, le même endroit d’où venait le ver VBS LoveLetter .
En réalité, l’origine de Code Red reste encore aujourd’hui mystérieuse car contrairement à ILOVEYOU (de Onel de Guzman aux Philippines) ou Solar Sunrise (deux ados californiens), aucun auteur n’a jamais été identifié. Les théories abondent bien sûr. Certains pensent que ce seraient des hackers chinois de la Honker Union, d’autres un groupe criminel russe, ou un script kiddie américain provocateur, ou encore un false flag d’une agence de renseignement… Le mystère reste entier…
Ce qui est sûr, c’est que Code Red a fait découvrir au monde la puissance des vers à propagation automatique. Plus besoin de social engineering, plus besoin que des utilisateurs cliquent sur des pièces jointes. Un ver se propage maintenant tout seul, exploitant la négligence des admins.
Grâce à sa découverte, Marc Maiffret devient une célébrité du jour au lendemain. Ce jeune de 20 ans qui a baptisé Code Red est invité sur CNN, interrogé par le FBI, consulté par le Congrès américain…etc. Ryan Permeh, plus discret mais tout aussi brillant, continue à l’époque son travail de reverse engineering et dans les mois qui suivent, lui et Maiffret découvriront des dizaines d’autres vulnérabilités critiques dans les produits Microsoft. De son côté, Permeh co-fondera plus tard Cylance, vendue à BlackBerry pour 1,4 milliard de dollars en 2020, puis rejoindra SYN Ventures comme partenaire.
Riley Hassell, le découvreur de la vulnérabilité originale, dira bien plus tard dans une interview : “J’ai publié la vulnérabilité de manière responsable. Microsoft a publié un patch. Ce n’est pas ma faute si personne ne l’a installé.” Il travaillera ensuite pour @stake, Immunity, et d’autres grandes boîtes de sécurité.
L’impact de Code Red sur l’industrie sera d’ailleurs profond et durable débutant en janvier 2002, par Bill Gates qui lancera l’initiative “Trustworthy Computing” afin que la sécurité soit au cœur du développement. Le projet Windows Server 2003 sera même arrêté pendant deux mois pour former tous les développeurs à la sécurité. C’est un tournant historique pour Microsoft.

Microsoft accélère aussi son programme de patchs mensuels “Patch Tuesday”, lancé en octobre 2003 et les entreprises commencent à prendre au sérieux la gestion des vulnérabilités. Les outils de scan automatique et de déploiement de patchs deviennent la norme et Windows Server Update Services (WSUS) est développé.
Code Red inspire aussi une nouvelle génération de malwares tel que, en janvier 2003, SQL Slammer (seulement 376 octets !) qui infectera 75 000 serveurs en 10 minutes, doublant de taille toutes les 8,5 secondes. Un record jamais battu. Puis en août 2003, Blaster exploitera une faille RPC Windows. Il y a eu également Welchia/Nachi qui tentera de nettoyer Blaster… un ver “bénéfique” mais qui en réalité causera autant de problèmes. Sans oublier Conficker en 2009 qui infectera des millions de machines.
Le Mountain Dew Code Red, la boisson qui a donné son nom au ver, profite également de la publicité gratuite. Lancé quelques semaines avant l’incident, le soda devient rapidement culte dans la communauté tech et les hackers et les admins système adoptent la boisson comme leur carburant officiel.
En 2002, David Moore, Colleen Shannon et leurs collègues du CAIDA publieront une analyse détaillée dans IEEE Security & Privacy et leurs conclusions sont glaçantes : si Code Red avait été mieux conçu, il aurait pu infecter la quasi-totalité des serveurs vulnérables en moins d’une heure. L’article devient une référence, mais aussi un manuel involontaire pour les futurs créateurs de vers. C’est le dilemme éternel de la recherche en sécurité qui est de publier pour éduquer et protéger, au risque d’armer les attaquants.
Bref, la prochaine fois que Windows vous harcèle pour installer des mises à jour, pensez à Code Red et cliquez sur “Installer maintenant” !!!
Sources : Wikipedia - Code Red , CAIDA Analysis of Code-Red , ACM SIGCOMM - Code-Red case study , Microsoft Security Bulletin MS01-033 , CERT Advisory CA-2001-19 , GIAC - The Code Red Worm , Scientific American - Code Red , GAO Report on Code Red , Microsoft Trustworthy Computing , Houston Chronicle - Code Red costs