Reviewing vulnerability scanner results for an Access Policy Manager (APM) protected Virtual Server

Introduction from your F5 Security Incident Response Team (F5 SIRT)

Hello there! I'm Arvin, Sr. Security Engineer with the F5 Security Incident Response Team (F5 SIRT), sharing security knowledge in this article, and hopefully you will find this useful. The F5 SIRT regularly releases security articles here in DevCentral and we invite you to read and soak in the team's collective security and technical knowledge in our individual article's and the weekly release of F5 SIRT's This Week In Security!   

F5 SIRT articles are tagged with the following:

• F5 SIRT
• series-F5SIRT-this-week-in-security
• TWIS

Article Introduction

This is part one of two of this article series.

Here is part two: https://community.f5.com/t5/technical-articles/reviewing-vulnerability-scanner-results-for-an-apm-protected/ta-p/322403 

The purpose of this article is to guide BIG-IP Administrators running a vulnerability scanner against a BIG-IP Virtual Server protected by an Access Policy Manager (APM) policy through an APM profile and reviewing the result. The vulnerability scanner typically will provide guidance on how to resolve a finding, and we will run through this excercise for an APM-protected Virtual Server. Implementing resolutions improves the security of the protected application.

It starts with a vulnerability scanner report, but before that..

A quick disclaimer, (vulnerability) scanning/penetration testing websites and networks should be commissioned and should/must have permission from a site owner's organization. There are legal consequences when things don't go as planned in these exercises. Therefore, a security tester should be prepared with the approvals and the "Get Out of Jail Free Card"   

https://en.wiktionary.org/wiki/Citations:get_out_of_jail_free_card#:~:text=In%20other%20words%2C%20a%20%22Get,Out%20of%20Jail%20Free%20Card.%22

Course Technology (2010) Penetration Testing Procedures and Methodologies‎^[3] (computers), page 2–6:

A "Get Out of Jail Free Card" is a legal agreement signed by an authorized representative of an organization that indemnifies the tester against any loss or damage that may result from the testing. In other words, a "Get Out of Jail Free Card" is a letter from the company to a penetration tester giving legal authority to test the network and stating legal release from inadvertent damages caused to the network during the test. For this reason, it is called a "Get Out of Jail Free Card."

For this article, I only tested a lab BIG-IP APM device.

Here is a vulnerability scanner report for an APM-protected Virtual Server.

The Scanner - Zed Attack Proxy (ZAP)

The Zed Attack Proxy (ZAP) web app scanner can run Automated Scans on target sites. 

https://www.zaproxy.org/

Here is ZAP's Automated Scan page. The Alerts pane shows the result of the recently ran scan. The Sites Pane also shows what sites were scanned. 10.71.26.8 is the lab APM-protected VS.

Typically, end clients accessing an APM protected Virtual Server will need to pass client side checks, authentication, 2 Factor Authentication  (2FA) checks before they can access protected resources behind BIG-IP APM.

In the context of an automated vulnerability scanner scan on an APM VS, it would end its scan on the APM logon page and not proceed further and would likely fail the authentication challenge. 

Findings on Cookies

APM uses Cookies to track sessions, and there are a couple of common vulnerability scanner results that get flagged. As APM has many features and uses of its MRHSession cookie, certain Cookie Flags or Attribute may or may not be applicable as it may interfere with APM's traffic processing.

Cookie No HttpOnly Flag

K15387: Overview of BIG-IP APM session cookies and K05289053: Security scan identified Session Cookie Missing 'HttpOnly' Attribute have the answer to this. "An access profile configured with the Http Only attribute will impede session traffic for Network Access and Network Access Tunnels, and the BIG-IP system will not run Access Policies with client side checks or actions." Thus, depending on APM resources or features used, this can be a false-positive finding.

Cookie without SameSite Attribute

"BIG-IP APM Access Profile Samesite Cookie option is available beginning v16.0.0 BIG-IP Software version.

With the Same-Site cookie attribute, browsers can control whether cookies are sent along with the request initiated by third-party websites.

Samesite: Enable this setting to add the samesite attribute to the session cookie. This attribute enforces same-site usage and prevents the cookie from being included with cross-site requests."

K24108053: Configuring BIG-IP APM Access Profile Same-Site Cookie option

See also https://owasp.org/www-community/SameSite

SameSite cookie attribute is also mentioned in K19135413: SAML SLO Error ''SAML SSO: Cannot identify SAML SP object to create SLO " response, where "(be) Aware (ness) that this can cause issues resulted in a new attribute for session cookies. The "SameSite" attribute." can affect SLO (SAML Single logout) where the IDP does not include the MRHSession cookie that APM expects and thus failing.

From an APM general perspective, if SAML is not used/processed, having the "SameSite" attribute in APM cookies is fine, however, rarely that is the case in today's landscape that SAML is not used.

This vulnerability scan result on Cookies were flagged during a failed logon attempt as requests to an APM-protected VS, thus, from a risk perspective, the findings are Low risk.

Findings on HTTP Headers

(HTTP) Strict-Transport-Security (HSTS) Header Not Set

In the scan result, it points out that the APM response does not include an HSTS HTTP header. The suggested solution in the scan, "Ensure that your web server, application server, load balancer, and more is configured to enforce Strict-Transport-Security."

References in F5 documentation show ways to implement HSTS, easily, natively, through the HTTP Strict Transport Security configuration in the BIG-IP HTTP Profile—see K68657325/ID737355. It can also be implemented through iRules HTTP::header insert.

OWASP's cheat sheet lists the threats of not having the HSTS header. For BIG-IP APM's perspective and purpose, APM implementations are recommended and expected to use valid SSL certificates and use of strong SSL ciphers to protect APM traffic. It is good practice to make sure the HSTS header is present so that an end client/web browser understands that the site/application APM is protecting should only be accessed securely thru TLS and not in plain HTTP.

HTTP Strict Transport Security Cheat Sheet

https://cheatsheetseries.owasp.org/cheatsheets/HTTP_Strict_Transport_Security_Cheat_Sheet.html

Bug ID 737355: HTTP Strict-Transport-Security (HSTS) headers not being added to all APM-generated files

https://cdn.f5.com/product/bugtracker/ID737355.html

K68657325: How to enforce HTTP Strict Transport Security (HSTS) on a virtual server

https://my.f5.com/manage/s/article/K68657325

X-Content-Type-Options Header Missing

ZAP's solution for "X-Content-Type-Options Header Missing", "Ensure that the application/web server sets the Content-Type header appropriately, and that it sets the X-Content-Type-Options header to 'nosniff' for all web pages. If possible, ensure that the end user uses a standards-compliant and modern web browser that does not perform MIME-sniffing at all, or that can be directed by the web application/web server to not perform MIME-sniffing."

X-Content-Type-Options: nosniff

OWASP describes X-Content-Type-Options impact as the "header that will prevent the browser from interpreting files as a different MIME type to what is specified in the Content-Type HTTP header (e.g. treating text/plain as text/css).

https://owasp.org/www-project-secure-headers/#x-content-type-options

"nosniff" is the X-Content-Type-Options value and described as "Blocks a request if the request destination is of type style and the MIME type is not text/css, or of type script and the MIME type is not a JavaScript MIME type."

https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/X-Content-Type-Options

From the APM login page perspective for this scan, inspecting the response payload, it is in HTML format. 

Content Security Policy (CSP) Header Not Set

https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP has enough details to explain how important the CSP header is.

Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross Site Scripting (XSS) and data injection attacks.

F5 Support already has Content Security Policy (CSP) related content. An analyst can start with "K10312824: What does the Content-Security-Policy HTTP header do?" to understand what the CSP header is.

After that, look into implementing the irule in "K71130157: Adding HTTP security headers to an APM enabled Virtual Server" .

It has the specific line for CSP, namely, "HTTP::header insert "Content-Security-Policy" "object-src *;script-src * 'unsafe-inline' 'unsafe-eval' data:""

In general, the policy directive used in the CSP will depend on the use case of the web application. For the scan result of the APM login page and for compliance purposes, the iRule can be used to add the CSP header and a basic policy.

In "Content Security Policy Cheat Sheet" from OWASP, the basic CSP policy is listed as "Content-Security-Policy: default-src 'self'; frame-ancestors 'self'; form-action 'self';"

The stricter policy "Content-Security-Policy: default-src 'none'; script-src 'self'; connect-src 'self'; img-src 'self'; style-src 'self'; frame-ancestors 'self'; form-action 'self';" can also be considered.

https://cheatsheetseries.owasp.org/cheatsheets/Content_Security_Policy_Cheat_Sheet.html#csp-sample-policies

See also:

K000133657: CSP / Content Security Policy Level-2 headers with BIG-IP APM.

K10312824: What does the Content-Security-Policy HTTP header do?

https://content-security-policy.com/

https://csp.withgoogle.com/docs/strict-csp.html

Putting it all together

As per the ZAP's web app scan result, we need to add a CSP policy, X-Content-Type-Options, (HTTP ) Strict-Transport-Security (HSTS) headers to be compliant and improve the security of the APM logon page.

Adding these HTTP Security headers to the APM logon page's response can be done using an iRule command that enables to interact with APM URIs during Access Policy execution. This is the ACCESS::restrict_irule_events disable command. 

https://clouddocs.f5.com/api/irules/ACCESS__restrict_irule_events.html

K71130157: Adding HTTP security headers to an APM-enabled Virtual Server shows an iRule that inserts these HTTP security headers and using the  ACCESS::restrict_irule_events disable command.

https://my.f5.com/manage/s/article/K71130157

For this lab, I used this iRule:

when CLIENT_ACCEPTED {
  ACCESS::restrict_irule_events disable
}

when HTTP_RESPONSE_RELEASE {
    HTTP::header insert "X-Content-Type-Options" "nosniff"
    HTTP::header replace "Strict-Transport-Security" "max-age=15552000; includeSubDomains"
    HTTP::header insert "Content-Security-Policy" "object-src *;script-src * 'unsafe-inline' 'unsafe-eval' data:"
}

Before applying the iRule, we do not see the CSP policy, X-Content-Type-Options, (HTTP ) Strict-Transport-Security (HSTS) headers in the APM logon page response.

HTTP/1.0 302 Found
Server: BigIP
Content-Length: 0
Location: /my.policy
Set-Cookie: LastMRH_Session=bfa0b270;path=/;secure;samesite=strict;HttpOnly
Set-Cookie: MRHSession=afdbc4882444caf26bbb49edbfa0b270;path=/;secure;samesite=strict;HttpOnly
Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;secure
Connection: close