SCG D BIGIP

This article is part of the OWASP Secure Configuration Guide.

Back to the OWASP Secure Configuration Guide ToC:
   https://www.owasp.org/index.php/Secure_Configuration_Guide
Back to the OWASP Secure Configuration Guide Project:
   https://www.owasp.org/index.php/OWASP_Secure_Configuration_Guide

Summary

The BIG-IP family of products offers the application intelligence network managers need to ensure applications are fast, secure and available. All BIG-IP products share a common underlying architecture, F5's Traffic Management Operating System (TMOS), which provides unified intelligence, flexibility and programmability. Together, BIG-IP's powerful platforms, advanced modules, and centralized management system make up the most comprehensive set of application delivery tools in the industry.

BIG-IP devices work on a modular system, which enables to add new functions as necessary to quickly adapt to changing application and business needs. The following modules are currently available for the BIG-IP system:

• Application Acceleration Manager (AAM)
• Advanced Firewall Manager (AFM)
• Access Policy Manager (APM)
• Application Security Manger (ASM)
• Global Traffic Manager (GTM)
• Link Controller (LC)
• Local Traffic Manager (LTM)
• Protocol Security Module (PSM)

Common Misconfigurations

BIG-IP persistence cookie information leakage

Description

An attacker can receive sensitive information about internal network via BIG-IP LTM persistence cookie.

To implement persistence sessions BIG-IP system inserts a cookie into the HTTP response, which well-behaved clients include in subsequent HTTP requests for the host name until the cookie expires. The cookie, by default, is named BIGipServer<pool_name>. The cookie is set to expire based on the time-out configured in the persistence profile. The cookie value contains the encoded IP address and port of the destination server [1] in the following format: BIGipServer<pool name> = <coded server IP>.<coded server port>.0000

After decoding [2] value of the BIG-IP persistence cookie an attacker receives an internal IP address and port number of backend servers. In some cases an attacker can also retreive sensitive informaion via <pool_name> suffix of the cookie name. For example, if an administrator give meaningful name to server pool (e.g. Sharepoint, 10.1.1.0, AD_prod) an attacker will get some additional information about network. Besides, an attacker detects that BIG-IP system is used in network infrustructure.

How to test

1. Run intercepting proxy or traffic intercepting browser plug-in, trap all responses where a cookie is set by the web application.
2. If possible, log in to web application and inspect cookies.
3. Find a cookie with name beginning with BIGipServer string or with value which has format as <coded server IP>.<coded server port>.0000 (e.g. 1677787402.36895.0000).
4. Try to decode this value using available tools (e.g., WhiteHat Security Big IP Cookie Decoder or BurpSuitePro Plugin for Big IP Cookie Decoding).
5. Inspect suffix of BIGipServer cookie name and verify that it does not contain any sensitive information about network infrustructure.

This example shows a GET request to BIG-IP with LTM module and a response containing BIGipServer cookie.

Example 1

GET /app HTTP/1.1
Host: x.x.x.x

Result Expected:

HTTP/1.1 200 OK
Set-Cookie: BIGipServerOldOWASSL=110536896.20480.0000; path=/

Here we can see that pool has the meaningful name OldOWASSL and get the following destination server address:

• IP Address = 192.168.150.6
• Port = 80

Remediation

Configuring secure cookie persistence by using the Configuration utility

• Log in to the Configuration utility.
• Navigate Local Traffic > Profiles > Persistence.
• Create new secure persistence profile with persistence type equals to "Cookie".
• Check the custom box for "Cookie Name" and enter a cookie name that does not conflict with any existing cookie names.
• Check the custom box for "Cookie Encryption Use Policy" and choose a "required" option. Enter a passphrase in "Encryption Passphrase" field.
• Click on "Finished" button.
• Assign created persistence profile to virtual server.

Configuring cookie persistence by using the TMSH

• Log in to TMSH.
• Run the following commands:

create ltm persistense cookie <profile_name>

modify ltm persistense cookie <profile_name> cookie-name <secure_cookie_name>

modify ltm persistense cookie <profile_name> cookie-encryption required

modify ltm persistense cookie <profile_name> cookie-encryption-passphrase <secure_passphrase>

modify ltm virtual <virtual_server> persist replace-all-with { <profile_name> }

BIG-IP HTTP Server header information leakage

Description

An attacker can receive information that a web application is protected by BIG-IP system via HTTP Server header.

BIG-IP system uses different HTTP Profiles for managing HTTP traffic. In particular, BIG-IP system uses HTTP Profile that specifies the string used as the server name in traffic generated by LTM. The default values are equal to "BigIP" or "BIG-IP" and depended on BIG-IP system version. An attacker can detect that BIG-IP is used in network infrustructure and then know role, type, and version of the BIG-IP system.

How to test

1. Run intercepting proxy or traffic intercepting browser plug-in, trap all responses from a web application.
2. If possible, log in to web application and inspect HTTP responses.
3. If Server header contains "BIG-IP" or "BigIP" value then BIG-IP is used.

This example shows a GET request to BIG-IP and a response containing Server header inserted by BIG-IP LTM.

Example 2

GET / HTTP/1.1
Host: x.x.x.x

Result Expected:

HTTP/1.0 302 Found
Server: BigIP
Connection: Close
Content-Length: 0
Location: /my.policy
Set-Cookie: LastMRH_Session=05da1fc5;path=/;secure
Set-Cookie: MRHSession=03e47713f1a8ef1aaa71cd9d05da1fc5;path=/;secure
Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/

Remediation

It is recommended to remove Server header from HTTP responses.

Removing Server header via Configuration Utility.

• Log in to the Configuration utility.
• Navigate Local Traffic > Profiles > Services > HTTP.
• Create new secure HTTP profile.
• Enter empry string in "Server Agent Name" field.
• Click on "Finished" button.
• Assign created HTTP profile to virtual server.

Removing Server header via TMSH

• Log in to TMSH.
• Run the following commands:

create ltm profile http <profile_name>

modify ltm profile http <profile_name> server-agent-name none

Administrative access to BIG-IP system via Internet

Description

An attacker can access to BIG-IP management interface via Internet. This is can lead to different attacks on BIG-IP administrative tools, unauthorized access or mass enumeration of BIG-IP systems via search engines.

The BIG-IP system uses the following two network connection entry points [3]:

• TMM switch interfaces
• Management interface (MGMT)

Either the TMM switch interfaces or the MGMT interface can provide administrative access to the BIG-IP system. The TMM switch interfaces are the interfaces that the BIG-IP system uses to send and receive load-balanced traffic. The MGMT interface is the interface to perform system management functions via browser-based or command line configuration tools. The MGMT interface is intended for administrative traffic and cannot be used for load-balanced traffic. It is recommended to connect MGMT interface to a secure, management-only network, such as one that uses an RFC1918 private IP address space. Otherwise an attacker can identify BIG-IP systems in your network and then attack them via management plane.

How to test

1. Try to use the following queries for Google (googledorks):
   • inurl:"tmui/login.jsp"
   • intitle:"BIG-IP" inurl:"tmui"
2. Try to use the following queries for Un1c0rn
   • BIG-IP
   • bigip
   • BigIP
3. Try to use the following queries for Shodan
   • F5-Login-Page
   • WWW-Authenticate: Basic realm=BIG-IP
   • BigIP
   • BIG-IP

Remediation

1. Connect MGMT interface to management network only.
2. Set "Allow None" on all Self IPs and only administer the BIG-IP using the Management Port. Setting "Allow None" on each Self IP will block all access to administrative IP addresses except for the Management Port. Access to individual ports can be selectively enabled, but this is not recommended in a secure environment.
   • Log in to the Configuration utility.
   • Navigate Network > Self IPs.
   • For all self IPs set "Port Lockdown" option to "Allow None".
   • Click on "Update" button.

References

• F5 Networks Official Site
• BIG-IP Modules Datasheet