[SOLUCIONADO] Wireshark - Cabeceras GET codificadas

Hola,
Estoy analizando un pcap y he encontrado una serie de paquetes TCP (unos 150) que contienen unos campos en las cabeceras con unos caracteres y números que no soy capaz de entender. ¿Alguien sabe qué es?

El cliente manda unos "GET /? numero" al servidor Apache y el servidor no envía respuesta mas allá de los ACKs. Parece ser algún tipo de exploit.

Aquí hay un par de ejemplos:

        GET /?234 HTTP/1.1
   User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/602.2.14 (KHTML, like Gecko) Version/10.0.1 Safari/602.2.14
   Accept-language: en-US,en,q=0.5
   meRFiuHRKK: 1011
   lmXHXBKP: 1335
   CvLgljhIm: 4929
   wOPnLjldiMmuPI: 323
   bkyqNBZVBZtY: 776
   mKUfCLAjLpUims: 4914
   VwiOOBWhoGnZg: 3418
   HylDfOQSwHMve: 1966
   
   GET /?587 HTTP/1.1
   User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:49.0) Gecko/20100101 Firefox/49.0
   Accept-language: en-US,en,q=0.5
   xshxoQjRo: 2368
   blXlMwQOuaLIKvHA: 383
   unFEBgIaOgTyjEv: 4268
   PaPIFTpgADq: 1932
   lPVecIHiaVBjqs: 108
   SvYTWxAnPgM: 1162
   HklrkTVq: 3438
   VaUTHBzRkibu: 445

¿Cómo están codificados los caracteres?
He buscado durante horas en Google para ver qué significan, pero no puedo encontrar algo que me oriente.

Muchas gracias.

Asi de lejos parece base64

No es Base64. Son solo letras mayúsculas y minúsculas.

Tal vez: base85

~ DtxdF

He probado diferentes codificaciones en baseXX o ROTXX, etc. pero no soy capaz de saber cómo están codificados.
Gracias.

Hola No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

La verdad, es un poco extraño. Nos mencionas que lo estás viendo desde WireShark y es un .pcap. ¿Existe alguna posibilidad de que vuelvas a hacer esas peticiones al sitio y lo hagas con netcat y/o Burp?.

Un saludo.

Hola,
El pcap es de un CTF que estoy intentando resolver. Contiene un intento de explotación a un Apache y hay que averiguar el CVE. No quiero saber la respuesta, si no algo que me permita continuar.
En el pcap se puede ver unos ping, un escaneo de puertos, la ejecución de DirBuster y 150 peticiones GET como las que se ven. Después de horas buscando en Google, no soy capaz de saber qué significa la cabecera.
Gracias.

Talves los valores no tengan un significado, talves solo está intentando enviar solicitudes con cabeceras aleatorias con urls aleatorias, talves está intentando evadir algún sistema de caché o intentando crear mucho caché, por ejemplo un DOS de algún tipo.

Talves sea buena idea darse una vuelta por acá y ver si alguna vulnerabilidad calza con ese tipo de ataque: No tienes permitido ver los links. Registrarse o Entrar a mi cuenta , por ejemplo No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Tienes el response de la petición? talves ahi indique la version del servidor y sus módulos activos.

Saludos.

Hola,
Una de mis ideas es que pudiese ser un DoS, como mencionas, pero no sé cuál. El servidor es un Apache/2.2.0 (Unix) DAV/2, y he revisado No tienes permitido ver los links. Registrarse o Entrar a mi cuenta sin ver nada convincente.

El servidor no devuelve respuestas, mas allá de los ACKs.

Muchas gracias por las aportaciones.

¿¿Y por que ves ACKs si detras hay un servidor web?? Deberías de ver la respuesta de pagina no encontrada o el index de esa web. ¿¿No será parte de un C&C que está escondido como tráfico web??  ¿Han podido introducir algo antes que deribe a que tengan ya el control de la máquina y eso séan órdenes?

Hola,

Esto es un ejemplo de uno de los streams TCP:



Corresponde con:

GET /?1606 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/53.0.2785.143 Safari/537.36
Accept-language: en-US,en,q=0.5
RKJcNHfThQI: 483
lCWLUznSf: 3628
mEuzcEeauUjrECh: 3724
wbZgmcAnAowLtSu: 3824
rzaqbxkZvqdi: 4419
oiPxdbFJyEiSBTf: 919
sHndmkXpoQVVxEu: 3
dYUvQOLfVvdT: 4660

Como se ve, mas allá del ACK no hay respuesta por parte del servidor.
Gracias.

Quiere decir que no existe una respuesta por parte del servidor, pero si te ha respondido con un ack es porque si tiene un puerto a escucha. Lo único que se me ocurre es que el apache está indisponible y por eso no es capaz de responder. No creo que sea un slowris porque la petición finaliza correctamente pero el servidor no es capaz de responder. Estoy casi seguro que es un denial of service pero no estoy claro aun a que le está afectando exactamente. Habría que tener mas contexto, talves exista algún paquete clave que de mas pistas como algún handshake o algún protocolo de proxy, etc. Estoy seguro de que no es nada por fuerza bruta porque solo parecen caracteres aleatorios, no creo que esté intentando desbordar nada porque no hay un indicio de paquetes concatenados para poder armar una shellcode o algo por el estilo. Talves su subes el .cap a algún sitio y nos das la url para descargarlo podremos ver bien de que se trata. Solo toca esperar que el reto sea de una vulnerablidad real y no de algo que haya que estar adivinando.

Saludos.

Hola,
Comparto el fichero, por si alguien ve algo mas.

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Gracias por todas las aportaciones.

Bueno, se ven muchas cosas, es un dump un poco largo con muchos tipos de ataque, por ejemplo lo primero que hace el atacante es probar si el servicio existe desde el mismo navegador, de hecho no es un bot porque tambien hace la petición al favicon con el referer correcto, de hecho se puede ver que el apache responde con la página de instalación por defecto, eso quiere decir que no está accediendo al host virtual correcto y por eso ve la pagina por defecto o simplemente no tiene nada. Lo más destacable es que el atacante proviene desde una dirección ip dentro de la misma red local.

Luego de esto se ven los ataques, primero un SYN flood desde el frame 24 al 2026, más abajo en el frame 2026 al 2672 intentó ver si el servidor aun estaba vivo o talves intentó hacer un flood ICMP xD, no conozco a nadie con vida que haya intentado botar un servidor con un ping xD, no se si este paquete corresponda a un ataque real o es un reto pero se nota en este punto que el atacante no tiene mucha idea de lo que hace porque no le está pegando al servidor web sino al sistema o al switch de red.

Más abajo en el frame 2673 al 46713 se puede ver un dirbuster (personalmente me gusta más el dirsearch), de seguro que el atacante ha pensado que no le ha atinado al directorio correcto o que hay algún sitio web oculto, pero eso es porque el atacante simplemente tiene falta de habilidad y no sabía que existen los host virtuales. Nadie va a poner un sitio web dentro de la página por defecto de apache, lo que tenía que haber hecho era sacar el host virtual por fuerza bruta, no a los directorios.

Los últimos frames con PSH ACK y ACK son las conexiones remanentes del dirbuster, luego en el frame 46721 comenzó a hacer ping al servidor para ver si se cae o no porque desde el frame 46714 hasta el 47748 creo que está intentando hacer un ACK flood o talves solo sean las desconexiones de los threads del dirbuster, pero me inclino a que está intentando hacer un ACK flood fallido.

Desde el frame 47749 al final (los paquetes que te inquietan) debes darte cuenta que dice "reassembled", quiere decir que son restos de la continuación de una misma petición realizada por partes, por ejemplo, si le das click derecho al paquete con frame 80043 y le das en Follow -> TCP Stream, verás el paquete completo pero este cuenta con múltiples paquetes repartidos en diferentes frames:

GET /?331 HTTP/1.1
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36
Accept-language: en-US,en,q=0.5
QuhKeTBB: 3744
OyoswOZIKvkxer: 4520
WFtaPmeJPFBs: 1306
nKyMCleAC: 2068
fzKtNhtifBshrRh: 4699
XNjVIywyh: 1694
UdDZzPSyXiSaQI: 4862
gScsQrckh: 3670

Esto corresponde a los frames ( No tienes permitido ver los links. Registrarse o Entrar a mi cuenta eq 1175 ): 7553, 7556, 7557, 7559, 7561, 7562, 7568, 7875, 7877, 18698, 18698, 18701, 32485, 32488, 45469, 46483, 47037, 47040, 47364, 47368, 47715, 74418, 78043 y 48048.

Si te fijas, cada línea de la petición fue enviada en tiempos muy distintos y no fueron frames con trozos de la solicitud sino líneas, esto claramente fue programado y no fue un retraso por problemas de red o del equipo, sino los frames tendrían partes desiguales con saltos de línea entremedio, pero cada frame finalzia con su salto de línea, eso quiere decir que el bot lanza una línea cada x tiempo. Esto es un ataque Slowloris donde se intenta enviar una petición muy lenta para detectar si el servidor apache tiene configurado un tiempo máximo de espera por la petición, de esta manera el atacante podría dejar tomado múltiples sockets TCP sin que estos finalicen, y hay que recordar que apache y linux tienen un límite de sockets disponibles por puerto, asi que, por ejemplo, si el servidor apache soporta como máximo 100 conexiones simultáneas entonces bastaría con que el atacante conecte 100 sockets al servidor y a tracves del envío lento de la petición http evitar la desconexión y provocar que nadie más pueda acceder.

Esto funcionaba en verisones antiguas de apache, hoy apache, a demás de utilizar sockets con multiprocesos de manera dinámica según la carga, cuenta con una configuración con límites de conexión por dirección ip (aunque esto debiera encargarse el firewall de hardware de la compañía o de software como iptables siempre y cuando no haga uso de proxies reversos o terminará bloqueando el proxy).

De todas maneras, como puedes ver, no hubo ninguna solicitud rechazada o por tiempo expirado, asi que el ataque también falló, si te fijas, el dirbuster no tuvo problemas para hacer la avalancha de peticiones mientras se estaba lanzando el Slowloris xD.

Mira:
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta
No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Y eso es todo, no está intentando explotar nada en ese dump, de hecho se nota que fue solo un intento básico de querer atacar a un servidor que realmente ni si quiera el atacante podía entender lo que era o como acceder y decidió lanzar ataques a lo tonto dejando logs por todos lados.

Claramente el servidor apache jamás va a entregar un contenido de sitio web si hubiera alguno porque nunca supo que tenía que buscar en otros host virtuales tratando de simular el hostname a traves de la cabecera HTTP Host, tampoco puedes comenzar a lanzar un syn flood a lo bestia sin un objetivo real, o sea, a quien se le ocurriría lanzarle un DOS a un servidor que no tiene nada o que no sabes lo que tiene? xD. Si yo fuera el dueño de ese servidor y viera ese tráfico apagaría el monitor y me iría a hacer un café, reportaría la ip del atacante para que le den sus buenas palmadas y luego me iría a dormir xD, no es nada para preocuparse.

Saludos.

Hola WHK,
Muchas gracias por tu análisis. Revisando lo que mencionas en tu mensaje, he visto que las peticiones se envían alrededor de cada 15 segundos, como se indica en No tienes permitido ver los links. Registrarse o Entrar a mi cuenta

Basado en tu información e investigando un poco mas, la vulnerabilidad que se estaba intentado explotar es la que tu mencionas, slowloris. En concreto CVE-2007-6750.

Muchas gracias por tu ayuda. También gracias al resto de aportaciones.
Un saludo.