Forum Discussion
jksingh_44237
Nimbostratus
NimbostratusThe 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
HamishCirrocumulus
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_53191Hamish: thanks for your perspective on this - very good post.
-Matt- HamishMore 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. - HamishI 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 
hoolioCirrostratus
Hi Hamish,
That's an interesting point. Can you post the CR once you get one?
Thanks,
Aaron- HamishI've sent the request in via our supplier. Just waiting for a response now.
H - HamishNo CR. The request for enhancement was denied. The wording was a little... unflattering...
- L4L7_53191CR or not, this is a super valuable thread that lays out a bunch of great information for us. Many thanks.
-Matt 
rhoads_77011jksingh,
Did you ever find a solution to this problem? Our PCI compliance scanning vendor is failing us because of this vulnerability.
Thank you,
Robert- L4L7_53191Encrypt the cookies.
-Matt