July 9, 2018 | Posted in Red Teams by Dan Herlihy

 

Background

One of the most common forms of information disclosure we see on engagements is the leaking of internal IP addresses and ports by Application Delivery Controllers (ADCs) or load balancers.  When each client makes a request to the web server, a cookie is set by load balancers running in persistence mode, where each client is mapped to the optimal node on first request and then continues to be routed to the same node on all subsequent requests.  To prevent the expensive operation of calculating the optimal node on every request, the IP address and port are sometimes stored in a cookie and passed back to the server for easy routing.  Of course, the tradeoff for speed is security, since the server is sending an internal IP address and port to the client, albeit slightly encoded.  The two most common examples of IP addresses leaking through cookies is from F5’s Big-IP and Citrix’s Netscaler load balancers.  Big-IP cookies contain an IP address and port, while Netscaler cookies contain a server name, IP address, and port.

Example of a Big-IP cookie being set:

 

 

 

 

 

 

 

Example of a Netscaler cookie being set:

 

 

 

 

 

 

 

 

Decoding the Cookies

Big-IP Cookies

The process to decode Big-IP cookies is actually given in official F5 documentation found here: https://support.f5.com/csp/article/K6917.  The process is summarized below:

  1. Start with a Big-IP cookie i.e. 1677787402.36895.0000 which represents [encoded IP].[encoded port].0000.
  2. To decode the IP Address:
    • Convert the number to its hex equivalent: 6401010A
    • Convert each hex byte to decimal: 100 1 1 10
    • Reverse the order and join with “.”: 10.1.1.100
  3. To decode the port:
    • Convert the number to its hex equivalent: 901F
    • Reverse the order of the first half and second half: 1F90
    • Convert the resulting hex value to decimal: 8080

Netscaler Cookies

Citrix does not publish any documentation about how to decode their cookies.  The work for figuring out how to decrypt Netscaler cookies was done by @catalyst256, who recorded his journey to discover the decoding method here: https://itgeekchronicles.co.uk/2012/01/03/netscaler-making-sense-of-the-cookie-part-1/.  In summary:

  1. Start with a Netscaler cookie i.e. NSC_qspe-xxx.tfdvsjuzsjtlbewjtpst.dpn=ffffffff68bc312c45525d5f4f58455e445a4a423660
    • Parsed is NSC_[hostname]=[Any 8 chars][8-char encoded IP]…[4-char encoded port]
  2. To decode the server name:
    • Simply shift each letter back one like a Caesar cipher i.e. a -> z, b -> a, etc: prod-www.securityriskadvisors.com
  3. To decode the IP Address:
    • Take the second set of 8 characters as hex and XOR it with key 0x03081e11 to get 0x6bb42f3d
    • Take each byte of hex and convert it to decimal: 107 180 47 61
    • Join with “.”: 107.180.47.61
  4. To decode the port:
    • Take the last 4 characters as hex and XOR it with key 0x3630 to get 0x50
    • Convert each byte to decimal: 80

 

The Burp Extension

After a few engagements where cookies like this were found and decrypted using separate scripts, I decided to create a Burp extension, called “Load Balancer Cookie Scanner”, found here: https://github.com/SecurityRiskAdvisors/Burp-Load-Balancer-Cookie-Scanner.  The extension passively scans sites as you browse, and if it detects a Big-IP or Netscaler cookie, it will create an issue and decode it automatically.  This ensures no cookies will be overlooked and eliminates the need to use external tools.

Example of a Burp Issue for an insecure Big IP cookie:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Example of a Burp Issue for an insecure Netscaler cookie:

 

 

 

 

 

 

 

 

 

 

 

 

 

 

I hope this makes your hacking a little easier!