Forum Discussion

jksingh_44237's avatar
jksingh_44237
Icon for Nimbostratus rankNimbostratus
Jan 04, 2010

The remote load balancer suffers from an information disclosure vulnerability at port 80 and 443

I am looking a solution for this issue.....

 

I have BIGIP (BIG-IP 9.3.1 Build 37.1)

 

 

Port http (tcp/80)

 

Synopsis :

 

The remote load balancer suffers from an information disclosure vulnerability.

 

 

Description :

 

The remote host appears to be a F5 BigIP load balancer which encodes within a cookie the IP address of the actual web server it is acting on behalf of. Additionally,information after 'BIGipServer' is configured by the user and may be the logical name of the device. These values may disclose sensitive information, such as internal IP addresses and names.Contact the vendor for a fix.

 

 

Plugin output :

 

The first column is the original cookie, the second the IP address and the third the TCP port:

 

BIGipServerwww_http_pool=2248217772.20480.0000 255.255.255.127

 

80BIGipServerwww_http_pool=2181108908.20480.0000 255.255.255.127

 

80BIGipServerwww_http_pool=2114000044.20480.0000 172.20.1.126

 

80BIGipServerwww_http_pool=2097222828.20480.0000 172.20.1.125

 

80BIGipServerwww_http_pool=2046891180.20480.0000 172.20.1.122

 

80BIGipServerwww_http_pool=2063668396.20480.0000 172.20.1.123

 

80BIGipServerwww_http_pool=2080445612.20480.0000 172.20.1.124

 

80BIGipServerwww_http_pool=2197886124.20480.0000 255.255.255.127 80

 

 

 

Port https (tcp/443)

 

 

Synopsis :

 

The remote load balancer suffers from an information disclosure vulnerability.

 

 

Description :

 

The remote host appears to be a F5 BigIP load balancer which encodes within a cookie the IP address of the actual web server it is acting on behalf of. Additionally,information after 'BIGipServer' is configured by the user and may be the logical name of the device. These values may disclose sensitive information, such as internal IP addresses and names.Contact the vendor for a fix.

 

 

Plugin output :

 

The first column is the original cookie, the second the IP address and the third the TCP port:

 

BIGipServerwww_http_pool=2248217772.20480.0000 255.255.255.127

 

80BIGipServerwww_http_pool=2181108908.20480.0000 255.255.255.127

 

80BIGipServerwww_http_pool=2114000044.20480.0000 172.20.1.126

 

80BIGipServerwww_http_pool=2097222828.20480.0000 172.20.1.125

 

80BIGipServerwww_http_pool=2046891180.20480.0000 172.20.1.122

 

80BIGipServerwww_http_pool=2063668396.20480.0000 172.20.1.123

 

80BIGipServerwww_http_pool=2080445612.20480.0000 172.20.1.124

 

80BIGipServerwww_http_pool=2197886124.20480.0000 255.255.255.127 80

 

dev
devops
iControl

14 Replies

Sort By
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jan 04, 2010

     

    Hi. Wrong forum for this question... You should be asking over in 'Advanced Design & Config', or maybe the iRule forums.

     

     

    However

     

     

    I'm not sure I ever agree with anyone who claims that letting users know your internal IP's and ports is a security problem... I tend to adhere more to the view that security by obscurity is no security at all. If your site is vulnerable to people knowing the backend IP's, then you have a bigger problem elsewhere rather than in the fact your cookies aren't opaque.

     

     

    I tend to lump this 'vulnerability' in the same vein as running a secure webserver on port 443 is vulnerable because people can find it easier...

     

     

    About the only real 'vulnerability' I could see from this is that over time someone might be able to determine how many backend servers you have... Which given they don't know how big they are doesn't tell them a lot other than how effiicient your code is over time.

     

     

    If you're really feeling bothered there's an iRule available to encrypt and decrypt cookies for you. Checkout the codeshare.

     

     

    regards

     

    Hamish

     

  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Jan 04, 2010
    Hamish: thanks for your perspective on this - very good post.

     

    -Matt
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jan 05, 2010
    More thoughts...

     

     

    There is also the possibility that someone could alter the information in the cookie to deliberately target a particular backend server without going through the correct load-balancing sequence for a user without a current session...

     

     

    Which begs a question...

     

     

    When the F5 receives a cookie for the poolmember, is it validated against the configured poolmembers? Or is it just used as it is? I'm raising a case on our F5 support contract to verify what happens here because it has implications on some work we're doing here too...

     

     

    (I'm not sure if could be validated in a fast & scalable way. Because an iRule can over-ride the pool & poolmember being used [and more questions arise from this]. Unless the BigIP keeps a list of all pools and poolmembers it's ever used... But I could surmise forever on this one. Hopefully we can get a definitive answer - It's possible SOL9815 answers this already, but in a bit of a round-about manner).

     

     

    Of course this would be all moot if the cookie value was opaque... (i.e. a key into a hash table that had the information in it)... But that isn't as scalable of course. Although is in theory safer than either un-encrypted or even encrypted cookies.

     

  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jan 05, 2010
    I got an answer from F5...

     

     

    Looks like the un-encrypted cookie is safe IF you're not performing 'Match Across Pools' or match across services (Or VS) for persistence... if you are, then the rules change somewhat.

     

     

    Match across service or match across VS will let an attacker alter the port specified by the poolmember. Match across pools is more open. The attacker can specify any poolmember they like (I'm paraphrasing what F5 told me).

     

     

    Hmm... Inherently unsafe in certain situations... (i.e. your secure website can be compromised by an insecure config on a non-secure VS). I've requested a CR to change the default behaviour to encrypting all persistence cookies and a SOL note to ensure people know about it...

     

     

    H
  • hooleylist's avatar
    hooleylist
    Icon for Cirrostratus rankCirrostratus
    Jan 08, 2010
    Hi Hamish,

     

     

    That's an interesting point. Can you post the CR once you get one?

     

     

    Thanks,

     

    Aaron
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Jan 08, 2010
    I've sent the request in via our supplier. Just waiting for a response now.

     

     

    H
  • Hamish's avatar
    Hamish
    Icon for Cirrocumulus rankCirrocumulus
    Feb 03, 2010
    No CR. The request for enhancement was denied. The wording was a little... unflattering...
  • L4L7_53191's avatar
    L4L7_53191
    Icon for Nimbostratus rankNimbostratus
    Feb 04, 2010
    CR or not, this is a super valuable thread that lays out a bunch of great information for us. Many thanks.

     

    -Matt
  • rhoads_77011's avatar
    rhoads_77011
    Icon for Nimbostratus rankNimbostratus
    Mar 21, 2011
    jksingh,

     

    Did you ever find a solution to this problem? Our PCI compliance scanning vendor is failing us because of this vulnerability.

     

    Thank you,

     

    Robert