Serveur Compromis React2Shell : Réparation et Désinfection

Une faille redoutable

Dès le lendemain de la découverte de la faille, une série d’attaques opportunistes ont submergé les serveurs vulnérables utilisant les composants Serveur React (RSC) et des Frameworks tels que Next.js, RedwoodJS, Remix ou des outils tels que Vite, Colis et le Routeur React.
Cette vulnérabilité critique a permis à des attaquants non authentifiés d’exécuter du code à distance (RCE), ouvrant la porte à l’installation de backdoors, virus, chevaux de Troie (trojans) et de mineurs de cryptomonnaie.

Si votre infrastructure a été exposée, il est impératif de la considérer comme compromise. Ce Guide de Survie Ultime a été rédigé pour vous fournir la procédure complète et les étapes précises nécessaires pour désinfecter votre machine serveur Linux, stopper l’hémorragie et, surtout, récupérer votre serveur et vos données sans avoir à tout réinstaller.

Symptômes d’une machine piratée par la faille React2Shell

Si votre machine est infectée, il faut savoir que le pirate cherchera à exploiter votre serveur pour des objectifs lucratifs ou malveillants : transformer votre machine en relais pour le réseau zombie (botnet), y exécuter un mineur de cryptomonnaie (cryptojacking), ou pire, déclencher une attaque par rançongiciel (ransomware).

Attention : Ces symptômes peuvent apparaître progressivement !

Impossibilité de lister les process

Un symptôme particulièrement caractéristique réside dans le dysfonctionnement des commandes système :

• ps, top et htop cessent de fonctionner normalement.
• L’affichage des processus s’interrompt brutalement.
• Le message “Processus arrêté” apparaît sans explication.

Ce comportement vise à empêcher l’observation des processus actifs et à retarder toute tentative de diagnostic.

Sauvegardes impossibles ou incohérentes

Les mécanismes de sauvegarde deviennent rapidement inexploitables :

• tar, zip ou rsync ne terminent jamais leur exécution ou échouent.
• Les sauvegardes se coupent sans message d’erreur explicite.
• Aucune archive fiable ne peut être produite.

L’impossibilité de réaliser des sauvegardes fiables est un risque opérationnel critique. Le danger réside dans l’effet pervers d’une sauvegarde corrompue : elle peut se faire silencieuse et ne pas alerter immédiatement l’administrateur de la compromission. Cela empêche toute restauration rapide et toute analyse post-incident hors ligne.

Corruption des bases de données

Les bases de données relationnelles, telles que MariaDB ou PostgreSQL peuvent être affectées indirectement :

• Arrêts non maîtrisés des moteurs.
• Journaux de transactions endommagés.
• Tables ou index corrompus.

Ces effets sont souvent liés à des interruptions forcées de processus critiques ou à une instabilité prolongée du système.

Vous êtes développeur React et vous souhaitez monter en compétence ? Notre formation React avancé vous donnera les clés pour approfondir votre maîtrise et anticiper les risques liés aux composants serveur.

L’équipe Ambient IT

Diagnostiquer rapidement son serveur pour le réparer

Je vous propose ces 3 commandes dans l’ordre en espérant qu’on en tire quelque chose :

• Vérification des tâches utilisateur : crontab -e
• Vérification des tâches système : ls -la /etc/cron* /var/spool/cron
• Examiner les Services Suspects : systemctl list-units --type=service --state=running

STOP :

À ce stade, il faut regarder attentivement les tâches planifiées. Vous pourriez être amené à supprimer un composant du Malware Rondo et, si la situation est bloquée, à tenter un redémarrage du système.

Ce redémarrage ne doit être envisagé que si vous avez déjà supprimé un maximum d’éléments malveillants et que vous ne pouvez plus progresser sans repartir d’un état plus stable.

• Pour identifier d’éventuels processus anormaux : ps aux | grep -vE "sshd|bash|systemd"

• Pour repérer des binaires ou fichiers récemment modifiés (fenêtre de 10 jours ajustable) : find /etc /usr /bin /sbin /lib -type f -mtime -10 2>/dev/null

Cette dernière commande est facultative, mais souvent riche en enseignements.

Envie d’aller plus loin dans la cybersécurité offensive et la réponse aux incidents ? Notre formation certification OSCP vous donne les compétences pratiques pour analyser, exploiter et sécuriser des systèmes compromis.

L’équipe Ambient IT

Remédiations : s’aider de l’IA pour éliminer l’ennemi

Reprenez les sorties de chaque commande, prenez votre meilleur LLM sous la main (ChatGPT, Gemini, Mistral, etc.) et demandez-lui avec ce simple prompt de vous aider :

Ma machine a été infectée par un virus suite à la faille React2Shell, aide-moi étape par étape à éliminer tous les processus susceptibles d’être dangereux pour mon serveur. Voici le résultat de mon investigation : [COPIER ICI LE RÉSULTAT DES 5 PRÉCÉDENTES COMMANDES]

Utile : Éliminer le malware Rondo ou autre trojan au démarrage

Neutraliser sa persistance

La première action vitale est d’empêcher le malware de redémarrer après un reboot, garantissant que l’effort de désinfection ne soit pas vain.

Voici la marche à suivre :

1. Ouvrez le crontab de l’utilisateur root pour édition :

crontab -e

2. Identifiez et supprimez la ligne SUPSECTE. Par exemple :

@reboot /etc/rondo/rondo react.x86_64.persisted

3. Enregistrez et quittez l’éditeur

Résultat : Le malware ne se lancera plus au démarrage. Cependant, il est toujours présent et actif en mémoire.

Après le nettoyage : Repenser la sécurité à l’ère du “Server-Side”

Si les manipulations précédentes vous ont permis de couper l’herbe sous le pied du malware Rondo et de stopper l’exfiltration active de données, ne considérez pas l’incident comme clos.

En cybersécurité, un serveur compromis ne redevient malheureusement jamais totalement fiable.

Le nettoyage que nous proposons est davantage un garrot, une mesure d’urgence qu’une solution pérenne pour votre infrastructure. Votre but étant d’éviter une récidive. Il faut agir sur 4 axes majeurs :

Scan de virus et monitoring

Sous Linux, les possibilités ne sont pas nombreuses mais il existe des solutions.

La suppression de la ligne dans le crontab est le verrou qui empêche le retour de l’attaquant. Cette manipulation empêchera le virus de se relancer automatiquement au démarrage de votre machine mais elle sera toujours considérée comme infectée.

Seul le nettoyage complet, validé par des outils qui pourront confirmer la reprise du contrôle du système :

• ClamAV va scanner le disque dur. Il compare chaque fichier présent sur votre serveur à une immense base de données de signatures virales connues. Il s’assure qu’aucun fichier inerte contenant du code malveillant reste sur le système
• Falco est plus subtil et moderne (très utilisé dans les environnements Cloud/Kubernetes). Il ne regarde pas les fichiers, il écoute le noyau (Kernel) du système en temps réel. En cas de comportements anormaux, il prévient l’utilisateur.

Nuke it from orbit

Comme il est techniquement presque impossible de déterminer si un attaquant n’a pas laissé un binaire dormant au fin fond d’une librairie, la meilleure solution est de détruire puis de reconstruire.

Si vous utilisez des conteneurs (Docker, Kubernetes) ou de l’Infrastructure-as-Code (Terraform, Ansible), redéployez une instance neuve et saine de votre application, puis basculez le trafic. Conservez l’instance infectée hors ligne uniquement pour l’analyse forensique.

Le changement de paradigme React / Next.js

Cette faille n’est pas un incident isolé. En réalité, elle est même plutôt logique lorsque l’on regarde l’évolution du web.

Avec l’avènement des React Server Components (RSC), la frontière étanche entre le navigateur (Client) et le serveur (Back-end) a disparu. Le code JavaScript, autrefois cantonné à l’esthétique et à l’interactivité, possède désormais les clés du système de fichiers et des bases de données.

Cette évolution implique une nouvelle réalité : le développeur React est désormais aussi (un peu) un administrateur système, qu’il le veuille ou non.

La formation des équipes Front-end aux problématiques de sécurité serveur (OWASP, injection de commandes, gestion des droits) n’est plus une option, c’est une nécessité vitale

L’après-crise : Forensic et RGPD

C’est une question douloureuse, mais qu’il est crucial de se poser après l’attaque : Qu’ont-ils emporté ?

Avant la suppression définitive des logs, il faut absolument :

• Identifier si des données personnelles ou clients ont été exfiltrées.
• Déterminer si vous avez l’obligation légale de notifier la CNIL (dans les 72h) et vos utilisateurs, conformément au RGPD.
• Comprendre comment le payload a contourné vos défenses actuelles (WAF, pare-feu) pour durcir votre configuration future.

C’est également le bon moment pour utiliser la crise à bon escient, utilisez cet incident comme levier pour imposer une culture Security by Design dans vos cycles de développement.