sábado, 17 de marzo de 2018

[Facebook][ F5 BIG-IP ] PERSISTENCE COOKIE INFORMATION LEAKAGE

( El titulo alternativo era:
Leaking Facebook Internal Ip Infrastructure - no bounty payment from facebook )

Fugas de información de cookies de persistencia (en Facebook )

Un atacante puede recibir información confidencial sobre la red interna a través de la cookie de persistencia BIG-IP LTM.

Cookies que no nacen dentro de un aplicativo web. En cambio son seteadas por un intermediario: El balanceador de carga de la firma F5, quien seguramente siempre se encontrara entre el cliente y el servicio al que finalmente nos queremos conectar.

Entonces es el balanceador quien define para nosotros (cliente) un host  de entre un pool http/apps.
Además de determinar el camino mas optimo, a cada una de nuestras peticiones se le setea una cookie que al llegar a nuestro cliente trae como valor una IP y PUERTO ofuscados/encodeados, identificando al host (que el balanceador definió para nuestro request ) desde donde llegan los recursos que nosotros  inicialmente llamamos.   

Esas cookies en su respuesta traen valores encodeados y existe una documentación oficial al respecto; https://support.f5.com/csp/article/K6917?sr=19342610.




y un artículo de OWASP que trata el tema con mayor detalle:
https://www.owasp.org/index.php/SCG_D_BIGIP

Claramente a esta cookie el administrador podrá ponerle por nombre lo que desee. Por defecto las encontramos con este formato "BIGipServer<pool_name>".

Ejemplo de solicitud:
GET /app HTTP/1.1
Host: f4c3300k.com


*** La respuesta:


Luego de tomar la cookie y decodificar su valor un atacante estará recibiendo una dirección IP interna con su respectivo número de puerto. .

Además de saber que la tecnología implementada para balancear carga corresponde a la ofrecida por F5, también es posible recuperar otra información a través del sufijo “<pool_name>” del nombre de la cookie. Dado que los administradores suelen poner nombres muy significativos. Por ejemplo; “desa”,”pre”, “prod”,”Exchange_2010_External”, etc.

Contexto;  “The Facebook”    
Identifique cookies persistentes seteadas por el balanceador de carga F5 que filtran al mundo información de la red interna.

Donde ?
A continuación una lista de los dominios identificados como vulnerables:
  • maileast.thefacebook.com
  • autodiscover.instagram.com 
  • mail-ext.thefacebook.com 
  • mail.hack.tfbnw.net 
  • mail.thefacebook.com  
  • autodiscover.thefacebook.com  
  • autodiscover.fb.com 
  • autodiscover.internet.org 
  • autodiscover.oculus.com 
  • autodiscover.whatsapp.com
  • esbmbltest.thefacebook.com

EVIDENCIAS
A continuación se evidencia el hallazgo:



***




Peticion 



Response: 1




Response 2:




Response 3:






De seguir con el proceso descubriremos todas las posibilidades del pool de IP con las que cuenta el balanceador.


Automatizando el proceso

En favor de automatizar el proceso desarrolle una simple herramienta (subida a Github). A continuación les presento sus particularidades:


usr@pwn:~$ git clone https://github.com/ezelf/f5_cookieLeaks.git

Uso:

usr@pwn:~/$ python quickCook_v0.2.py --help
usage: quickCook.py [-h] [-v] --host HOST [--ssl] --cookie-name COOK
                   [--port PORT] [--req REQ] [--uri URI]

[ F5 BIG-IP ] PERSISTENCE COOKIE INFORMATION LEAKAGE

optional arguments:
 -h, --help          show this help message and exit
 -v, --version       show program's version number and exit
 --host HOST         Host
 --ssl               use ssl
 --cookie-name COOK  Cookie Name
 --port PORT         Port
 --req REQ           Total Request
 --uri URI           URI path

[+] Demo: quickCook.py --host 192.168.1.1 --cookie-name "BIGipServerPool_X" --req 50


Detalle: A la aplicación objetivo le envió "N" (--req <#>) peticiones y en cada una de sus respuesta tomo el valor de la cookie cuyo nombre pase por parámetro (--cookie-name <name>) eliminando los valores  repetidos y finalmente imprimió su equivalente sin encodear ( IP:PUERTO)

poc 1:


***
poc 2:

***
poc 3:


poc 4:



Extra (vuln ?):
Repasando comportamientos:

Ya sabemos que en cada petición desde el servidor (o mas bien el balanceador), a nosotros “clientes” se nos setean cookie. con sus respectivos valores.
Pero y si nos adelantamos y somos nosotros quienes pre-seteamos esas cookies ?



POC: pre-preteando valores de la cookie:

Al incluir alguna ip ajena al aplicativo, cambiar un puerto nuevo, o simplemente rellenar con “basura“, en todos los casos el balanceador no tomara en cuenta lo que enviamos, y seguirá seteando la cookie correspondiente para cada caso

En la siguiente captura cambie el puerto 8080 (encodeado):








El comportamiento de las respuestas siguen inmutables

POC: Fijando una cookie válida.
Como bien ya sabemos, los valores de la cookie son finitos y cada uno de esos define un host y puerto dentro del pool de aplicaciones que tiene cargado el balanceador:


Si en cada uno de esos request incluimos la cookie con alguno de los posibles valores(ip+puerto) precargados en el balanceador (correspondientes al pool http/apps) en las respuestas el balanceador ya no nos asignara una cookie y se toma como válida la que estamos forzando.

Partiendo de la base que ya conocemos todas las posibilidades de un host en particular:



Ahora me queda una pregunta que no me puedo responder (por falta de evidencias). 
Al setear desde el cliente cookies con un valor válido, estoy forzando/fijando un camino hacia un host en particular del pool de aplicaciones ? Por lo tanto; estoy burlando al balanceador?. 

-----------------
[fb] “The Bounty”  

El hallazgo se lo reporte a Facebook.

Sin saberlo Facebook ya se contaba con un reciente precedente similar, en donde @mishradhiraj_ ( reportaba ) publicaba: "Facebook Internal IP Disclosure" en el blog: https://datarift.blogspot.cl/p/facebook-internal-ip-disclosure.html


Luego de reportar ellos me responden:



y les contesto: "ok..., voy a escribir en mi blog sobre el asunto":







Finalmente: #noBounty










Saludos,
@capitan_alfa

No hay comentarios.:

Publicar un comentario