Foro de elhacker.net

Hace algunos días infectaron un servidor con un malware (ver https://blog.manchestergreyhats.co.uk/2018/11/07/php-malware-examination/ (https://blog.manchestergreyhats.co.uk/2018/11/07/php-malware-examination/)), entonces llegue al blog de Jeff Starr (@perishable), en donde vi la siguiente entrada: https://perishablepress.com/protect-post-requests/.

Me llamo mucho la atención el poder ejecutar un script desde un .htaccess con la directiva ErrorDocument, así:

ErrorDocument <3-digit-code> <action> 

Segun la entrada, ejecuta el script sí el retorno de la petición es 403 o 404

ErrorDocument 403 /error-handler.php
ErrorDocument 404 /error-handler.php

Aquí es donde entra mi duda, entiendo que los codigos de respuesta 403 (Forbidden) y 404 (Not Found), pero si existe algun malware oculto en un archivo que si exista y se encuentre digamos index.php, como podría ejecutar el script si la petición arroja un codigo 200 (OK)?

La entrada de Jeff solo guarda peticiones POST por medio de file_get_contents('php://input'), necesito esto tanto como para POST y para GET. Alguna idea?

Hasta donde yo tengo entendido, lo que necesitas es un WAF.


El artículo en sí solo menciona ejemplos de como detectar posibles malas peticiones (por ejemplo, el user agent). Se queda muy corto en lo que yo consideraría posible SPAM y payloads para exploits y no hace mención a como automatizar el proceso (hasta donde yo leí, le di un vistazo rápido).

Básicamente, el inspecciona las peticiones recibidas, busca un patrón en las peticiones que considera son SPAM o dañinas y luego crea una regla para redirigir todas esas peticiones que encajen el patrón a una pagina de error 403, así las peticiones nunca llegan a tocar los scripts que intentaban tocar.

Es una estrategia muy rudimentaria. Si acaso, lo que puedes tomar de esto es que es buena idea inspeccionar tus peticiones antes de que lleguen a procesar los scripts.

Concuerdo con MinusFour, ese tipo de cosas no se recomienda validar desde el lado de la aplicación en php ya que una aplicación web solo debiera dedicarse a funcionar como servicio y nada mas, todos los puntos de control de seguridad adicional que no sea para mitigar una vulnerabilidad ya existente debiera hacerlo un waf, en este caso mod security por ejemplo.

Desde el apache puedes configurar que user agent quieres denegar, rangos de direcciones ip, cabeceras extrañas, peticones mal formadas, limpieza de variables, etc. Ten en cuenta que Apache carga las reglas en memoria, en cambio php debe leer e interpretar tus reglas y modificaciones cada ves que un usuario accede al sitio, por lo cual apache es mucho mas rápido y eficiente en el uso de memoria porque está diseñado para ello, no así php.

En Apache puedes configurar reglas de dos maneras, utilizando el htaccess o el host virtual. El .htaccess sólo sirve cuando necesitas especificar configuraciones muy puntuales para una aplicación web como por ejemplo el sistema de ruteo con mod rewrite, la ruta de los archivos de errores por defecto, etc, pero las configuraciones persistentes que ya no debieran depender de una aplicación específica como las reglas de seguridad debieran estar en el host virtual ya que estas se cargan una sola ves ahorrando latencia en las peticiones.

Por otro lado, tu primer link está caido, por otro lado debes tener en cuenta que debes atacar el problema raiz y es corregir la vulnerabilidad que se usó para hackear el sitio y darle un vistazo mas a profundidad sobre lo que pasó.

Saludos.

@MinusFour, entiendo.
@WHK no estaba caido jeje no use la etiqueta URL correctamente  :silbar:

En si, lo que paso es que hay un sitio con wordpress con buenas contraseñas, pluggins "seguros" (mejor aun, muy basicos para aplicarles exploits), y es la ultima versión. Lo que quiero es ver que peticiones envia el atacante para saber por donde esta ingresando ya que todo esta a la ultima versión.

Obviamente sin llamar la atención por WAF's ni nada de eso, para ver si existe un posible 0day de wordpress que anden usando.

Mi pregunta sigue siendo, analizar toda petición y guardarlo tipo log? Es decir, generar un script php que guarde información básica, por ejemplo:

-Generar este codigo es bastante sencillo lo que no sé, es como implementarlo para que en cada petición, sea cual sea, 200 403 404 etc... se llame el código-


Aunque sólo sea necesario a que archivo esta llamando y las peticiones sean GET o POST.

Lo mejor sería que no fuera parte de un script como resultado de una petición, sino que el servidor maneje todo esto por tí. Mod Security puede guardar las peticiones completas.

Por lo pronto, lo que puedes hacer es revisar los access logs por las URLs por la cual se acceden al backdoor. Con un poco de suerte hay información en común para encontrar como metieron el backdoor o por lo menos inspeccionar que estaban haciendo antes de usar el backdoor.

Entiendo @MinusFour, el lio esta en que no tengo todos los permisos necesarios para instalarlo. Por eso queria si o si un script simple. Buscaré alguna solución.

En el caso de wordpress, debe ser posible agregar logs a través de un plugin. Lo único es que estás limitado solo al acceso por medio de wordpress. No se si wordpress tenga "early hooks" para colgarse antes de todos (por si algo falla antes de ejecutarse el plugin), pero yo empezaría por ahí.

Si no puedes controlar la seguridad de tu propio sitio debieras considerar cambiar de hosting, talves a un vps y crear tus propias reglas de seguridad.

No es eso, solo me contrataron pero no me dieron todos los permisos, solo puedo editar y subir archivos por ftp. Por eso quiero hacer algo simple mi propio log de peticiones.

Como me sospechaba, siempre eliminaba las rutas y archivos "infectados" (includes a un archivo malicioso) y volvia a aparecer. El sitio usa WordPress a una versión anterior a la actual. Genere un codigo básico y lo agregue en el archivo /public_html/xxx/wp-blog-header.php y pude captar la siguiente petición:

[Request   : 2020/03/19 11:34:40]
User-Agent : Mozilla/5.0 (Windows NT 6.1; WOW64; rv:54.0) Gecko/20100101 Firefox/54.0
Ip Address : 85.10.245.113
Method     : POST
URL        : xxx .com/?uhl=pzdem
Params     : 
    sjcvfu = cDVjKSVjcG90NTZvejRtf2wxN3BvPGRqLXFhJCYoYzNjJmQ2c2pjdmZ1c2pjdmZ1c2pjdmZ1c2pjdmZ1c2pjdmZ1c2pjdmZ1MzQs
 
--
 
[Request   : 2020/03/19 15:11:50]
User-Agent : Mozilla/5.0 (iPhone; CPU iPhone OS 10_3_2 like Mac OS X) AppleWebKit/603.2.4 (KHTML, like Gecko) Version/10.0 Mobile/14F89 Safari/602.1
Ip Address : 35.187.121.58
Method     : POST
URL        : xxx .com/?fcfrm=dmhgv
Params     : 
    bi = YTZiNiF/YWx1KjJzazdsYGgtJnNuI2B2PHJgOyI0cjBiOWAqYmliaWJpYmliaWJpYmliaWJpYmliaWJpYmliaWJpYmliaWJpIjct

Buscando patrones de malware ofuscado encontre esto:

https://ghostbin.co/paste/9kotok39
pass: n4

Tienes un wordpress ultra desactualizado no? las versiones de hace varios años atrás permitian la infección de shells a traves de una botnet que modificaba la carpeta wp-admin y el index.php.

Quizás no sea una vulnerabilidad de wordpress en sí si no de algún plugin o tema que tengas instalado.

Pues la versión que tenia era 5.2.2 y la subi a 5.5. Agregaba código malicioso en varios archivos, además de crear archivo con nombres randoms. El código en sí ejecutaba publicidad.

Nopues, talves vengas arrastrando ese backdoor desde hace mucho tiempo más. Dale un vistazo al log de accesos de apache del año pasado y busca las urls afectadas.

Viste que son base 64 el valor del parámetro no?

a6b6!alu*2sk7l`h-&sn#`v<r`;"4r0b9`*bibibibibibibibibibibibibibibibibibi"7-