Adobe Patches Magento Zero-Day Exploited to Deploy Rust Backdoor and PHP Web Shell
D'après les chercheurs de Sansec, c'est exactement ce qui vient de se passer avec StyleSmuggler, une faille zero-day d'exécution de code à distance qui fait des ravages sur Magento et Adobe Commerce. Et quand on parle de ravages, on est au sommet: un magnifique 10.0 sur l'échelle CVSS, soit le game changer absolu du cauchemar.
Une attaque en deux temps, sous le capot du moteur de templates
StyleSmuggler, c'est sournois: la faille exploite le moteur de templates PHP de Magento en injectant du code malveillant via les propriétés de styles (oui, oui, des propriétés CSS!), ce qui permet de contourner les protections existantes. Adobe a publié son correctif d'urgence APSB26-156 le 7 septembre à 20h20 UTC, distribué non pas comme une release classique mais comme un patch Composer à appliquer depuis repo.magento.com. Toutes les versions de 2.4.4 à 2.4.9 sont concernées — et les attaquants ont eu trois jours pour faire leurs emplettes avant que le hotfix n'arrive. Autant dire qu'on n'est plus dans la théorie!
Le backdoor Rust qui se déguise en processus système
Et ce n'est pas tout: une fois l'attaque réussie, elle déploie un petit programme Rust qui se fait passer pour un processus système tout ce qu'il y a de plus banal — kworker, fc-cache ou chronyd, au choix des opérateurs! Il se copie dans ~/.cache/fontconfig/fc-cache, installe une entrée cron qui le relance toutes les demi-heures, et contacte son serveur de commande (99.84.67.186) en se faisant passer pour du NTP — 48 octets en UDP sur le port 123 toutes les 60 secondes. À l'heure où Sansec publiait ses découvertes, aucun autre éditeur de sécurité ne détectait ce backdoor. Ambiance thriller.
Sur le terrain: ce qu'on patche, ce qu'on nettoie
On ne va pas se mentir: si vous maintenez une boutique Magento, vous avez probablement déjà reçu l'alerte. Trois actions concrètes s'imposent — parce que patcher sans nettoyer, c'est comme fermer la porte après que le cambrioleur ait fait le tour de la maison. D'abord, on applique le patch Composer d'Adobe sans délai et on vérifie qu'il est bien actif. Ensuite, on rotate la clé de chiffrement Magento ET toutes les credentials qu'elle protégeait: mots de passe admin, tokens REST/SOAP/GraphQL, secrets OAuth, clés API des passerelles de paiement, identifiants base de données, clés SSH et de deploy, et clés API des extensions tierces. Attention: rotation à la source, pas seulement dans l'admin — la rotation seule ne révoque rien de ce que l'attaquant a déjà lu. Enfin, on scanne ses processus à la recherche d'un [kworker/u:8:0], fc-cache ou chronyd qui n'a rien à faire là. Si vous utilisez Sansec Shield, il bloque les variantes connues, mais Adobe recommande quand même l'installation du patch officiel — la surface d'attaque est large et les opérateurs changent leurs payloads plusieurs fois par jour depuis le 4 septembre.
Bref, encore un legacy qui se rappelle à notre bon souvenir. C'est aussi pour ça qu'on bosse sur ses mises à jour, qu'on automatise ses patches, qu'on surveille ses serveurs — non? On en débat dans la communauté?