sábado, 17 de marzo de 2018

Leaking Facebook Internal Ip Infrastructure - no bounty payment from facebook _(english - google)

An attacker can receive confidential information about the international network through the BIG-IP LTM persistence cookie. 

Cookies that are not inside a website. Instead, they have been sent by an intermediary: The load balance of the signature F5, who always has the possibility of finding the client and the service that finally wants to connect us 

Then it is the balancer that defines for us (client) a host from an http / apps group. 

In addition to determining the most optimal path, one each time a cookie is requested that reaches our client as value an IP and PORT confused / encoded, identifying the host (that the balancer defined for our request) from where the resources that we we have called 


These cookies in their response bring codified values and there is official documentation in this regard: https://support.f5.com/csp/article/K6917?sr=19342610.   



and an OWASP article that addresses the issue in more detail:
https://www.owasp.org/index.php/SCG_D_BIGIP

Clearly to this cookie the administrator can name what you want. By default we find them with this format "BIGipServer<pool_name>".

Demo Request:
GET /app HTTP/1.1
Host: f4c3300k.com




*** Response:


After taking the cookie and decoding its value an attacker will be receiving an internal IP address with its respective port number.

In addition to knowing that the technology implemented to balance load corresponds to that offered by F5, it is also possible to retrieve other information through the suffix "<pool_name>" of the name of the cookie. Since administrators usually put very significant names. For example; "Desa", "pre", "prod", "Exchange_2010_External", etc.

Context;  “The Facebook”    

I managed to identify the persistent cookies established by the F5 load balancer that filters the internal network information of the world.


Where ?
Below is a list of domains identified as vulnerable:
  • 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

Evictions:



***




Request:




Response: 1




Response 2:




Response 3:



If we continue with the process, we will discover all the possibilities of the IP pool that the balancer has.


Automating the process
To automate the process, develop a simple tool( Upload to Github).
Here I present its particularities:


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

Use:

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



Detail of use:
To the target application he sent "n" requests (--req <#>) and in each of your answers I take the value of the cookie whose name passes by parameter (--cookie-name <name>) eliminating repeated values then their equivalents are printed without encoding ( ip:port)

poc 1:


POC 2:


***
poc 3:




poc 4:


Extra ( Vuln ? ):
Reviewing behaviors:
We already know that in each request from the server (or rather the balancer), we "cookie clients" are set to us. with their respective values.


But what if we go ahead and we are the ones who pre-set those cookies?

POC: pre-set values of the cookie:
By including any ip outside the application, change a new port, or simply fill with "garbage", in all cases the balancer will not take into account what we send, and will continue setting the corresponding cookie for each case

In the following capture change port 8080 (encoded):


The behavior of the answers remain immutable

POC: pre-set to cookie válid.
As we already know, the values of the cookie are finite and each of those defines a host and port within the application pool that the balancer has loaded:


If in each of these requests we include the cookie with any of the possible values (ip + port) preloaded in the balancer (corresponding to the http / apps pool) in the responses, the balancer will no longer assign us a cookie and the validity is considered valid. what we are forcing

Starting from the base we already know all the possibilities of a particular host:








Now I have a question that I can not answer (due to lack of evidence).
By setting the cookie from a client with a valid value, am I forcing / fixing a path to a particular host in the application pool? Thus; I'm making fun of the balancer ?.


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


The finding was reported to Facebook.




Without knowing it Facebook already had a recent similar precedent, where @mishradhiraj_ posted: "Facebook Internal IP Disclosure" in the blog: https://datarift.blogspot.cl/p/facebook-internal-ip-disclosure.html

After reporting my find, Facebook answers me:




and I reply: "ok ..., I'm going to write in my blog about the matter":


Finally: #noBounty


PD: Thanks "Google Translate"


Saludos,

3 comentarios: