Results 1 to 8 of 8

Thread: Story of a PoC - F5 BIG-IP Cookie Information Disclosure Share/Save - My123World.Com!

  1. #1
    InfoSec Consultant the_empty's Avatar
    Join Date
    Jul 2010
    the blue no-where
    Blog Entries

    Story of a PoC - F5 BIG-IP Cookie Information Disclosure

    Curiosity is the biggest virtue of a hacker’s mindset. Only because curiosity people like me loose focus of the actual target and run behind the OTHER things. (Anyways, they are more interesting)

    Similar thing happened while I was Pen testing some Web servers which were running behind a load balancer. Nessus was showing some vulnerability associated with load balancer through which it was able to figure out the internal IP of the target server. I read about the vulnerability but was not able to manually test it. Now instead of completing the project in given time, I kept going deeper into the finding and had to stay in office up-to 2 AM just to complete the work. I want to share what ever I learnt, hope you find it useful and interesting.

    Little Bit of LOAD BALANCING

    Load balancing is a technique to distribute workload across number of servers, network links and other hardware resources in order to achieve optimal resource utilization and maximum throughput. It also serves the cause to avoid any overload and service outage.

    Server farms achieve high scalability and high availability through server load balancing, a technique that makes the server farm appear to clients as a single server. In general, server load balancing architectures are of two main types:

    1. Transport-level load balancing such as the DNS-based approach or TCP/IP-level load balancing which acts independently of the application payload.

    2. Application-level load balancing which uses the application payload to make load balancing decisions.

    Load balancing can further be classified into two types namely software-based and hardware based load balancers. Hardware based load balancers are used in transport level load balancing as they are faster than software based ones. On the other hands software based load balancers run on standard operating systems and hardware components (PCs).

    In this case we will look into a vulnerability associated with an application level load balancer named F5 Big IP. For balancing the load between the servers this load balancer uses a technique called "Load Balancing using Cookie injection". The load balancer checks if the request contains a specific load balancing cookie. If the cookie is not found, a server is selected using a distribution algorithm such as round-robin. A load balancing session cookie is added to the response before the response is sent. When the browser receives the session cookie, the cookie is stored in temporary memory and is not retained after the browser is closed. The browser adds the cookie to all subsequent requests in that session, which are sent to the load balancer. By storing the server slot as cookie value, the load balancer can determine the server that is responsible for this request (in this browser session).

    Now to talk about F5 Big IP Load balancer, to maintain the session between the client and allotted server it encodes the internal IP and the port being used for the session, stores it into the cookie and injects that into the client browser.

    When scanned, Nessus reports the vulnerability with name "F5 BIG-IP Cookie Information Disclosure" and also gives the Internal IP and port that was used while Nessus ran its script. When I read bout the vulnerability, I was eager to verify it manually. So I connected to the target server and in response I received the cookie from the Big IP load balancer. Cookies contents were something like

    Name: BIGipServerpool_reservations_80
    Content : 940968458.20480.0000
    Host : x.x.x.62
    Path : /

    When I read it, first thought that came to my mind was Nessus gave away a false positive. But then I observed that Nessus was not only detecting the vulnerability but also was able to find out the Internal IP which it was displaying in the result section.

    So, to go into little deeper I thought capturing the traffic at wire level while scanning might help somehow. So I started Wireshark and realized that running scan on an IP and analyzing the capture file for the needed result is like moving a mountain. Only option left for me was to run the .nasl script for this plugin and capture the traffic of it. So finally I meet the requirement to run a nasl script individually. I did searched on Google and found out how to do it on BT.

    For this we need to move to the directory where Nessus plugins are located which in case of Linux is


    From here we need to run the particular script which in this case is bigip_cookie.nasl

    I used the following command to run the script while being in the above mentioned directory

    /opt/nessus/bin/nasl -t x.x.x.62

    In result the script only displayed “successful”, nothing else. So I changed my focus to the data captured by wireshark. Through all the streams I was able to see nothing but similar data that I saw in the cookie. No Internal IP, no port and nothing. This was the time when I started getting annoyed, anxious and curious at the same time. (And also when my boss realised that the project will be delayed :P)

    So with all my frustration and curiosity I now opened the nasl script in editor and read the script. I observed that the script was trying to initiate a connection with the target and was capturing the cookie recieved in the response. Then the script parsed the cookie to find the string “BIGipServerpool” in order to confirm that cookie belongs to Big IP. From the contents of the cookie it was reading the encoded number format (940968458.20480.0000) which was supposed to be the IP. With some weird mathematics the script was able to decode the number and find out the Internal IP.

    I tried several techniques to decode the IP manually. I even tried using code part from the .nasl script but zero was all that I got in return.

    Now to understand what that script was doing exactly I read little bit about .nasl scripting. (Vijay Mukhi has written a small but very useful guide to start with nasl scripting). I kept putting a printing statement for every variable the script was using after every calculation. Then after I figured out (It took me nearly 3 hours) that from three partitions of the encoded string only first was containing entire IP and second was showing the encoded port number. For Example

    940968458 20480 0000
    (Encoded IP) (Port)

    It was very relaxing when I saw the output and understood how exactly it all was happening. But all that relaxation vanished when I realized that its nearly five o clock and I will now have to stay in office till midnight or even more to finish the remaining work of mine.

    After all of this I realised one more thing that till now I don’t have anything in hand which I can give as PoC of manual testing to the client. Here was when my boss also got actively intrested in this stuff. I explained him what all I have done so far and then he came up with an idea. He just took the code from nasl script which was doing the decoding stuff. Then he made a ruby script to do same stuff. Take the IP and port as input, connect, capture and parse the cookie and decode the IP and port from it. Only difference being that the script was giving output which shows us the Internal IP and the port being used.

    I ran that script in konsole and took the screenshot of output and made a PoC of that. That’s it. I am giving below the small script

    require 'net/http'
    require 'net/https'

    #~ puts "\n############################################### #\n"
    #~ puts "F5 Big-IP Cookie information Disclosure\n"
    #~ puts "################################################\ n\n"
    #~ puts "\n"
    #~ puts "Usage: bigip_cookie <IP Address> <port>\n"

    rrr = ARGV[0]
    ppp = ARGV[1]
    #~ puts rrr
    #~ puts ppp
    http ="#{ARGV[0]}", ARGV[1])
    http.use_ssl = true
    path = '/'
    resp, data = http.get(path, nil)
    cookie = resp.response['set-cookie']
    IP_port = /BIGipServer([^=]+)=([0-9]+)\.([0-9]+)\.[0-9]+/
    m = IP_port.match(cookie)
    puts m[2]

    oct1 = (m[2].to_i & 0x000000ff)

    oct2 = (m[2].to_i & 0x0000ffff) >> 8

    oct3 = (m[2].to_i & 0x00ffffff) >> 16
    oct4 = m[2].to_i >> 24
    port = (m[3].to_i & 0x00ff) * 256 + (m[3].to_i >> 8)
    puts "Cookie: #{cookie}"
    puts "Internal IP is: #{oct1}.#{oct2}.#{oct3}.#{oct4}"
    puts "Port is: #{port}"


    As soon as I got the PoC one more thought caught my mind. As the load balancer depends upon the cookie for maintaining the session, what will happen if we change the value of port in the cookie? Will the load balancer try to connect to the new port that we have given? Is it possible to do an internal port scan on the target IP with this idea?

    As I had to finish the project in given time, I kept this thought aside and finished the project nearly at midnight.

    Now to try all those things I will first have to find the Big IP load balancer running in this blue nowhere. Till then this question will keep haunting my mind.

    Last edited by the_empty; 08-26-2010 at 07:06 PM.

  2. #2
    Infosec Enthusiast AnArKI's Avatar
    Join Date
    Jul 2010
    Blog Entries
    gr8 writeup mate.....goes on to prove 'Where there is a will, there is a way'

  3. #3
    Security Researcher fb1h2s's Avatar
    Join Date
    Jul 2010
    Blog Entries
    awesome , keep more interesting stuffs coming , and the internal Port scanning sounds like a great plan so please don't give up on that
    Hacking Is a Matter of Time Knowledge and Patience

  4. #4
    ... I am no Expert b0nd's Avatar
    Join Date
    Jul 2010
    Location #g4h


    the_empty, that's a hackerish attempt!!! And you know, I am the happy most person reading your experience which you cared to share with all.

    Yesterday, 41.w4ri0r and fb1 have also done a great job by developing an exploit which earlier seemed impossible to make real. Soon they will share their experience as well.

    Sharing is Caring

    Great going guys!!!
    [*] To follow the path: look to the master, follow the master, walk with the master, see through the master,
    ------> become the master!!! <------
    [*] Everyone has a will to WIN but very few have the will to prepare to WIN[*] Invest yourself in everything you do, there's fun in being serious

  5. #5
    thanks!!! awesome..som uch to lean
    The three great essentials to achieve anything worth while are: Hard work, Stick-to-itiveness, and Common sense. - Thomas A. Edison
    __________________________________________________ _____________________

  6. #6

    Thumbs down Not too impressive

    Just noticed this. F5 published the algorithm years ago, did you bother to look?

    AskF5 | General Solution: SOL6917 - Overview of BIG-IP persistence cookie encoding

    and told you what to do about it

    AskF5 | General Solution: SOL7784 - Overview of cookie encryption

    now if you could break that you might have something. By the way this solution works with any cookie, not just the persistence ones. To you other question this feature is called "cookie persistence" and means you go to the same server you were initially load balanced to so changing the server data in the cookie is bad. The designer sent you to that server for a reason (maybe it contains your shopping cart). If you change the data the LTM will attempt to send you to the other server if that is a valid address but you will have an empty cart. If the designer wants to protect against this they would encrypt the cookie (it take checking a box).

    for beginners, watch this presentation by Joe McCray (no affiliation with me, but the guy rocks)

  7. #7
    InfoSec Consultant the_empty's Avatar
    Join Date
    Jul 2010
    the blue no-where
    Blog Entries

    thank you for providing your views. I admit that I was not aware of the those posts when I posted above write-up. However, please note that I was not posting any *discovery* . As the title clearly mentions, it was an attempt to generate a "konsole/shell" based PoC of a already known vulnerability/configuration flaw which may help an attacker to obtain internal IP addresses of the system.

    In penetration tests You may observe that the solution provided by vendor is not implemented in most cases (not all but most) and to figure such anomalies is job of a security consultant.

    Though I wouldn't grace your last question with an answer, Just keep in mind that designer may do whatever they want but as a security professional, it is our job (and as hackers its our nature) to use what is designed in a way it is not designed to be used. I hope that's not too much to understand or accept.


  8. #8
    It was really good writing , i was imagining who you was tackling the system. I got some points while doing pentesting
    Garage4Hackers bugs for the community , of the community

    We provide IT
    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.
    To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts