Un nouveau malware détecté par les chercheurs de XLab exploite des failles vieilles de plus de dix ans pour constituer discrètement une infrastructure d'attaque mondiale. Ses victimes ne savent généralement pas qu'elles en font partie.

Un nouveau malware détecté par les chercheurs de XLab exploite des failles vieilles de plus de dix ans pour constituer discrètement une infrastructure d'attaque mondiale. Ses victimes ne savent généralement pas qu'elles en font partie.

Je ne me lasse jamais de tous ces projets qui ressuscitent des vieux jeux. Et celui dont je vais vous parler aujourd'hui, c'est à neuviemeporte qu'on le doit. Celui-ci s'est donné pour mission de reconstruire ligne de code par ligne de code, ce bon vieux F-15 Strike Eagle II, le simulateur de vol de combat sorti chez MicroProse en 1989. Et hier, le 20 juin dernier, le projet a passé un cap important puisque le portage est enfin jouable. Et son dev cherche maintenant des pilotes d'essai pour le mettre à l'épreuve.

Donc si ça vous chauffe, mes petits Maverick en herbe, faut récupérer les exécutables sur son dépôt, ensuite vous les balancez dans le dossier de votre copie du jeu à la place des originaux (faites un backup avant, hein) et vous décollez !! Et si ça plante, si un truc s'affiche de travers, si une touche ne répond plus, vous lui remontez le bug, tout simplement.

Je reconnais quand même que le boulot derrière, est dingue car ce n'est ni une émulation ni une recompilation à partir d'un code source volé. neuviemeporte a vraiment désassemblé le binaire de 1989, réécrit chaque morceau en C, et recompilé tout ça. Puis ensuite, il a comparé les instructions machine produites avec celles du jeu original et tant que les opcodes n'arrivent pas identiques au bit près, c'est que la reconstruction est faussée. Alors il recommence et ainsi de suite ! Je ne sais pas s'il utilise l'IA pour ça mais je lui conseille fortement afin d'automatiser au maximum tout ce travail de débugging. C'est exactement ce que je suis en train de faire avec mon recompilateur de Roms et à la main, ça me prendrait facile 10 ans, je crois...

Le plus fou, c'est qu'il a d'abord dû retrouver quel compilateur MicroProse utilisait à l'époque. Il a fait des recherches sur certaines chaînes de caractères présentes dans le code et il est tombé au fond de l'exécutable sur celle-ci : "MS Run-Time Library - Copyright (c) 1988, Microsoft Corp". Verdict, c'est du Microsoft C 5.1. Et sans ce détail, il n'avait aucune chance de générer exactement la même séquence d'instructions que le binaire d'origine.

Et puis il y a ce petit détail que j'adore... En fait, le mec fait une reconstruction "bug-for-bug". En gros, les bugs du jeu de 1989 doivent rester. Ainsi, si dans la version originale votre avion se met à tomber vers le ciel quand il est à l'envers et en panne de carburant, et bien il doit continuer à tomber vers le ciel... Même comportement, mêmes défauts, mêmes sensations qu'à l'époque.

Mais alors, d'où ça lui vient, cette obsession ?

Eh bien comme nous tous, de ses jeunes années de passion dévorante avec l'informatique, quand il était scotché à son premier 386 et qu'il a découvert là son premier monde ouvert sur son ordinateur. Et ce truc lui est resté... Développeur C/C++ le jour, dingue de MS-DOS et de reverse engineering la nuit, comme il le résume lui-même sur son site. Il a lancé ce projet de recompilation en 2022 et avoue que le rythme actuel le dépasse un peu aujourd'hui...

Mais c'est ce genre de "missions de vie" qui a déjà sauvé d'autres classiques. Je pense par exemple à Mario 64 qui a été décompilé au point de tourner aujourd'hui dans un navigateur , et plein de vieux jeux DOS ne survivent que parce que des passionnés s'en occupent un par un, un peu comme l'ont fait les ancêtres nés avant l'an 2000 (je me mets dans le lot, 1982 FTW! les gars !).

Un petit mot quand même pour les futurs testeurs, parce que ce n'est pas tout à fait du plug-and-play... La version reconstruite ne passe pas par l'écran de configuration d'origine car elle part du principe que vous êtes en affichage MCGA/VGA, sans son et sans joystick. Donc pas la peine de régler votre Roland MT-32 virtuel, ça démarre direct au manche. Et pour signaler un souci, une capture via Ctrl+F5 dans DOSBox + une description de ce qui se passait avant le plantage et c'est réglé.

Voilà, si une copie traîne dans vos archives, allez voir son appel et reprenez les commandes.

Un vieux routeur DD-WRT qui prend la poussière et que vous n'avez pas mis à jour depuis des lustres, c'est pile poil ce que recherche C0XMO. C'est un nouveau botnet repéré par les chercheurs de Fortinet qui enrôle les machines via une faille de 2021 que beaucoup n'ont jamais bouchée. Et une fois dedans, il dégage les autres malwares déjà présents pour rester seul maître à bord.

La faille, c'est la CVE-2021-27137, un débordement de tampon planqué dans le service UPnP de DD-WRT. En clair, le composant qui gère les requêtes UPnP encaisse mal certains paquets envoyés sur le port UDP 1900, et ça suffit à un attaquant distant pour balancer son code sans même avoir besoin d'un mot de passe.

Bref, tout ça pour dire que toutes les builds antérieures au change set 45723 sont vulnérables, et les routeurs Buffalo livrés d'origine avec DD-WRT sont concernés aussi. Donc le réflexe immédiat si vous avez un de ces engins c'est de mettre à jour le firmware vers une build plus récente, et couper l'UPnP si vous ne vous en servez pas.

Cette faille a beau dater de 2021, elle reste grande ouverte sur tous les routeurs que personne n'a retouchés depuis, et je sais que des vieux routeurs flashés un week-end pour leur donner une seconde vie, vous êtes nombreux à en avoir. Par exemple mon bon vieux WRT54GL ressuscité qui fait point d'accès au fond du garage, ou encore la box recyclée en répéteur Wi-Fi... Tant qu'ils tournent sur un firmware figé, ce sont des cibles parfaites. C'est pile ce qu'un botnet adore à savoir du matériel branché en permanence, que plus personne ne surveille.

Ce qui rend C0XMO un peu particulier pour un dérivé de Gafgyt , c'est sa hargne à éliminer la concurrence. Car comme je vous le disais, une fois installé, il scanne les processus en cours pour repérer les clients d'autres botnets, supprime leurs binaires et démonte tout ce qui les fait persister : tâches cron, scripts d'init, services système, profils shell. En gros, c'est un squatteur qui change les serrures en s'installant. C'est pourquoi les chercheurs y voient un niveau de sophistication plus élevé que le Gafgyt habituel. Lui-même se réinstalle via une tâche cron toutes les 15 minutes, histoire de ne pas se faire déloger à son tour.

Et tout ça pour faire quoi me direz-vous ??

**Hé bien du DDoS, pardi !! **

C0XMO embarque 19 méthodes d'attaque, des classiques floods UDP, TCP, SYN et ICMP aux amplifications NTP et Memcached, jusqu'à des floods qui visent les serveurs vocaux Discord. Ça reste un dérivé de Gafgyt qui cogne plutôt dans les gigabits, mais c'est suffisant pour alimenter l'écosystème DDoS où les records se comptent maintenant en térabits par seconde . Et le botnet ne s'arrête d'ailleurs pas aux routeurs, puisqu'il vise aussi des DVR, des plateformes de gestion vidéo et des appareils Android, sur à peu près toutes les architectures qui existent (ARM, MIPS, PowerPC, SuperH, x86).

Ces failles UPnP qui transforment des appareils oubliés en chair à botnet, c'est une vieille histoire faut dire... Je me souviens de mon article d'il y a plus de 10 ans, où je vous parlais déjà de dizaines de millions d'appareils vulnérables à cause d'UPnP. Et comme le matériel, ne disparaît pas vraiment mais finit recyclé, revendu, ou planqué derrière un meuble en marche H24, c'est un vrai running gag.

Voilà, donc si vous avez du DD-WRT en service, prenez cinq minutes pour mettre à jour et couper l'UPnP si vous ne vous en servez pas et surtout, dites vous qu'un boîtier que vous ne touchez plus jamais, à un moment faut trancher : **soit vous le maintenez vraiment à jour, DD-WRT ou OpenWRT peu importe, soit c'est direction la poubelle (euh pardon la déchetterie). **

Le garder branché en mode mort-vivant, ni mis à jour, ni débranché, c'est le pire que vous pouvez faire... Un routeur qu'on a sauvé de la poubelle mérite quand même mieux que de finir zombie dans une armée de cybercriminels à faire du DDoS.

Source + Photo par Jonathan Zander , CC BY-SA 3.0

Il y a des failles qui réclament un arsenal de hacker chevronné, et puis il y a HTTP/2 Bomb, qui se contente de quelques kilo-octets pour faire vaciller des serveurs parmi les plus utilisés de la planète. Dévoilée le 2 juin sous la référence CVE-2026-49975, elle s'attaque à HTTP/2, le protocole qui transporte une bonne partie des pages que vous consultez chaque jour.

Le résultat ressemble à une mauvaise blague. Une poignée d'octets envoyés au bon endroit, et la mémoire vive du serveur se met à enfler jusqu'à engloutir des dizaines de gigaoctets en quelques secondes, jusqu'à ce que la machine ne réponde plus à personne.

On parle ici d'une attaque par déni de service, un DoS dans le jargon, dont le but n'est pas de dérober quoi que ce soit mais d'asphyxier le serveur. Rien de bien neuf, donc, sauf que l'ampleur du désastre, elle, l'est totalement.

Toute l'astuce tient dans le mariage de deux mécanismes connus depuis des lustres. HTTP/2 sait compresser les en-têtes des requêtes pour éviter de répéter cent fois la même chose, et c'est précisément cette générosité que l'attaquant retourne contre le serveur, en faisant référence des milliers de fois à un en-tête glissé une seule fois, si bien que la machine réserve de la mémoire à tour de bras pour quelque chose qui, au départ, ne pèse presque rien. C'est le principe de la bombe de décompression, ce fichier piégé minuscule qui se déplie en montagne de données dès qu'on l'ouvre.

Et comme si ça ne suffisait pas, l'attaquant fait mine de ne pas pouvoir recevoir la réponse, ce qui interdit au serveur de boucler sa tâche et de relâcher ce qu'il a accumulé. Quelques octets envoyés de loin en loin, et la connexion reste ouverte indéfiniment. C'est diabolique de simplicité.

Les chiffres, eux, font carrément peur. Sur Envoy, les chercheurs ont mesuré un rapport de plus de 5 000 pour 1, avec 32 Go engloutis en une dizaine de secondes, là où Apache craque en moins de vingt secondes et nginx comme IIS en moins d'une minute. Une simple connexion domestique à 100 Mb/s peut donc mettre à genoux une infrastructure entière.

Le plus déroutant dans cette histoire, c'est que les deux ingrédients de la recette traînaient en accès libre depuis des années. Il aura fallu attendre l'équipe de Codex, et le chercheur Quang Luong, pour avoir l'idée de les mélanger et constater les dégâts.

Du côté des correctifs, tout le monde n'est pas logé à la même enseigne. nginx a réagi avec sa version 1.29.8 et une nouvelle option pour brider les en-têtes, Apache a corrigé dans mod_http2 2.0.41, mais Microsoft IIS, Envoy et Cloudflare Pingora attendaient encore leur rustine au moment de la divulgation.

Bref, vieille recette, ingrédients connus, mais cocktail dévastateur. Si vous gérez un serveur en HTTP/2, allez vérifier vos versions avant qu'on ne teste la recette à votre place.

Source : The Hacker News