SCG D BIGIP

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)

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. 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 in the following format: BIGipServer = . .0000

After decoding 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  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 . .0000 (e.g. 1677787402.36895.0000).
 * 4) Try to decode this value using available tools (e.g., Metasploit module for F5 BigIP Backend Cookie Disclosure 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


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

Configuring cookie persistence by using the TMSH


 * 1) Log in to TMSH.
 * 2) Run the following commands:
 * create ltm persistense cookie 
 * modify ltm persistense cookie  cookie-name 
 * modify ltm persistense cookie  cookie-encryption required
 * modify ltm persistense cookie  cookie-encryption-passphrase 
 * modify ltm virtual  persist replace-all-with {  }

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.


 * 1) Log in to the Configuration utility.
 * 2) Navigate Local Traffic > Profiles > Services > HTTP.
 * 3) Create new secure HTTP profile.
 * 4) Enter empry string in "Server Agent Name" field.
 * 5) Click on "Finished" button.
 * 6) Assign created HTTP profile to virtual server.

Removing Server header via TMSH


 * 1) Log in to TMSH.
 * 2) Run the following commands:
 * create ltm profile http 
 * modify ltm profile http  server-agent-name none

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 :


 * 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):
 * 2) * inurl:"tmui/login.jsp"
 * 3) * intitle:"BIG-IP" inurl:"tmui"
 * 4) Try to use the following queries for Un1c0rn
 * 5) * BIG-IP
 * 6) * bigip
 * 7) * BigIP
 * 8) Try to use the following queries for Shodan
 * 9) * F5-Login-Page
 * 10) * WWW-Authenticate: Basic realm=BIG-IP
 * 11) * BigIP
 * 12) * 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.
 * 3) * Log in to the Configuration utility.
 * 4) * Navigate Network > Self IPs.
 * 5) * For all self IPs set "Port Lockdown" option to "Allow None".
 * 6) * Click on "Update" button.

Description
Host header in HTTP requests is not always validated by BIG-IP systems by default. This validation depends on enabled modules, features and their configuration: for example, BIG-IP system in APM portal access mode performs a base sanitization of HTTP host header against XSS attacks. In most cases BIG-IP systems handle HTTP request with arbitrar Host header. This weakness can lead to vulnerabilities which can be used in different attacks based on HTTP Host header (e.g., DNS Rebinding, XSS, password reset poisoning, etc).

How to test

 * 1) Run intercepting proxy, trap all responses from a web application.
 * 2) If possible, log in to web application.
 * 3) Change Host header in HTTP requests. If responses for requests with normal and modified Host header are the same then BIG-IP does not validate Host header.

Remediation
BIG-IP systems can be protected against HTTP host header attacks using Centralized Policy Matching (CPM) feature of LTM module. Let's consider an example of configuration BIG-IP system with LTM and APM modules that illustrates the main idea of protection against these attacks. The following settings ensures that user will be redirected to /vdesk/hangup.php3 script deleting a user's session if HTTP host header contains a value different from permitted and correct hostnames.

Configuring host validation in CPM by using the Configuration utility


 * 1) Log in to the Configuration utility.
 * 2) Navigate Local Traffic > Policies.
 * 3) Click on "Create" button. Input "_host_header_validation" in Name field. Add "http" to Requires box.
 * 4) Click on "Add" button in Rules section.
 * 5) Add the following Condition:
 * 6) * Operand: http-host
 * 7) * Event: request
 * 8) * Selector: host
 * 9) * Negotiate: not
 * 10) * Condition: equals
 * 11) * Values: , , <dns_name_3>, etc
 * 12) Click on "Add" button.
 * 13) Add the following Rule:
 * 14) * Target: http-uri
 * 15) * Event: request
 * 16) * Action: replace
 * 17) * Parameters
 * 18) ** Name: path
 * 19) ** Value: /vdesk/hangup.php3
 * 20) Navigate to Local Traffic > Virtual Servers. Choose a virtual server that should be protected by CPM.
 * 21) Click on Resources. Click on "Manage" button for Policies and add _http_host_validation to "Enabled" box.
 * 22) Click "Finished".

Configuring host validation in CPM by using the TMSH

ltm policy _http_host_validation { requires { http } rules { host_validation { actions { 0 {                   http-uri replace path /vdesk/hangup.php3 }           }            conditions { 0 {                   http-host host not values { <dns_name_1> <dns_name_2> <dns_name_3> } }           }            ordinal 1 }   }    strategy first-match }
 * Prepare CPM config for host validation
 * 1) Log in to TMSH.
 * 2) Run the following command:
 * load sys config from terminal merge


 * 1) Copy the config and press CTL-D to submit.
 * 2) Run the following command:
 * modify ltm virtual <virtual_server> policies add { _http_host_validation }