F5 BIG-IP Security Cheatsheet

This document describes common misconfigurations of F5 Networks BIG-IP systems and their elimination. Some settings can be different for different BIG-IP versions.

Slides

• F5 BIG-IP Misconfigurations (Zero Nights 2016).

Table of Contents

• Summary
• Common Misconfigurations
  • Persistence Cookie Information Leakage
  • HTTP Server Header Information Leakage
  • Access to Management Interface from Internet
  • HTTP Host Header Insufficient Validation
  • Mass Enumeration using Search Engines
  • APM Session Exhaustion DoS attack
  • APM Brute Force Passwords Attack
• Getting an A-grade on Qualys SSL Labs
  • Enabling TLS Fallback SCSV extension
  • Enabling Strict Transport Security
  • Prioritizing PFS ciphersuites
  • Disabling SSLv3 on management interface
• Securing Administrative Access
  • SSH
  • Legal Notification Banner
  • Inactive Administrative Session Timeout
  • Connection Settings
  • Password Policy for Administrative Users
• Vulnerability Search
• ASM Misconfigurations
• iRules Injection

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 on BIG-IP systems:

• 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

Persistence Cookie Information Leakage

Description

An attacker can get some sensitive information about internal network stored in 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 name, by default, contains BIGipServer string and configured name of virtual servers pool. 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 one of the following format:

• IPv4 pool members: BIGipServer<pool name> = <The encoded server IP>.<The encoded server port>.0000
• IPv6 pool members: BIGipServer<pool name> = vi<The full hexadecimal IPv6 address>.<The port number calculated in the same way as for IPv4 pool members>
• IPv4 pool members in non-default route domains: BIGipServer<pool name> = rd<The route domain ID>o00000000000000000000ffff<The hexadecimal representation of the IP address of the pool member>o<The port number of the pool member>
• IPv6 pool members in non-default route domains: BIGipServer<pool name> = rd<The route domain ID>o<The full hexadecimal IPv6 address>o<The port number of the pool member>

Examples:

• BIGipServer~DMZ_V101~web_443=1677787402.36895.0000
• BIGipServer~CORP_DC1=vi20010112000000000000000000000030.20480
• BIGipServer~EE_ORACLE=rd5o00000000000000000000ffffc0000201o80
• BIGipServer~ES~test.example.com=rd3o20010112000000000000000000000030o80

After decoding of the BIG-IP persistence cookie value an attacker can get an internal IP address, port number, and routed domain for backend servers. In some cases an attacker can also get sensitive informaion recorded in <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.

Testing

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 a name beginning with BIGipServer string or with a value that has one of the formats above (e.g., 1677787402.36895.0000 for IPv4 pool members scheme).
4. Try to decode this value using available tools (see below).
5. Inspect suffix of BIGipServer cookie name and verify that it does not contain any sensitive information about network infrustructure.

The following example shows a GET request to BIG-IP and its response:

GET /app HTTP/1.1
Host: example.com

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

Here we can see that backend's pool has the meaningful name OldOWASSL and includes backend server 192.168.150.6:80

Tools

• Metasploit Framework Module
• Burp Suite Extension
• BeEF Module

Remediation

Configuring secure cookie persistence using the Configuration utility

1. Log in to the Configuration utility.
2. Go to Local Traffic > Profiles > Persistence.
3. Create a 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 the required option. Enter a passphrase in the Encryption Passphrase field.
6. Click Finished.
7. Assign the created persistence profile to the virtual server.

Configuring secure cookie persistence using TMSH

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> }
save /sys config

HTTP Server Header Information Leakage

Description

An attacker can get 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 BIG-IP LTM. The default value is equal to BigIP or BIG-IP and depends on BIG-IP system version. An attacker can detect that BIG-IP system is used in network and then know a role, type, and version of the BIG-IP system.

Testing

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. Send requests using HTTP and HTTPS.
4. If HTTP Server header contains BIG-IP or BigIP value then BIG-IP is used.

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

GET / HTTP/1.1
Host: example.com

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=/

Tools

• Metasploit Framework module

Remediation

It is recommended to remove Server header from HTTP responses.

Removing Server header using the Configuration Utility

1. Log in to the Configuration utility.
2. Go to Local Traffic > Profiles > Services > HTTP.
3. Create new secure HTTP profile.
4. Enter empty string in Server Agent Name field.
5. Click Finished.
6. Assign created HTTP profile to the virtual server.

Removing Server header using TMSH

create ltm profile http <profile_name>
modify ltm profile http <profile_name> server-agent-name none
save /sys config

Access to Management Interface from Internet

Description

If an attacker can access to BIG-IP management interface from Internet this can lead to different attacks on BIG-IP administrative tools, unauthorized access or mass enumeration of BIG-IP systems using search engines. The BIG-IP system uses the following two network connection entry points:

• TMM switch interfaces
• Management int