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 Serverprotected 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), page2–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 ordamagethat 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. Here is the lab APM VS configuration from the BIG-IP's Network Map view Here is the basic APM Access Policy applied to the VS traffic through the access profile—only have a Logon Page, a message Box, and a Deny ending. 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 typestyleand the MIME type is nottext/css, or of typescriptand the MIME type is not aJavaScript 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 After applying the iRule, we see CSP policy, X-Content-Type-Options, (HTTP ) Strict-Transport-Security (HSTS) headers added in the APM logon page response. HTTP/1.0 302 Found Server: BigIP Content-Length: 0 Location: /my.policy Set-Cookie: LastMRH_Session=ccd54d30;path=/;secure;samesite=strict;HttpOnly Set-Cookie: MRHSession=98b0f696225a13cd630a5a2bccd54d30;path=/;secure;samesite=strict;HttpOnly Set-Cookie: MRHSHint=deleted; expires=Thu, 01-Jan-1970 00:00:01 GMT; path=/;secure Connection: close X-Content-Type-Options: nosniff Strict-Transport-Security: max-age=15552000; includeSubDomains Content-Security-Policy: object-src *;script-src * 'unsafe-inline' 'unsafe-eval' data: How about the SameSite and HttpOnly Cookie attribute? SameSite and HttpOnly Cookie attribute are configurable in the Access Profile under the SSO/Auth Domains configuration. K24108053: Configuring BIG-IP APM Access Profile Same-Site Cookie option K15387: Overview of BIG-IP APM session cookies As seen in the screenshot, these options are enabled. By default, these are not enabled as depending on the APM use case, these may prevent some features from working as expected. Thus, enable these only if it applies to your use case. As a result, we see "samesite=strict;HttpOnly" appended to the APM cookiesReviewing vulnerability scanner results for an APM protected Virtual Server - part two
This article is part two of the article series "Reviewing vulnerability scanner results for an Access Policy Manager (APM) protected Virtual Server" from your F5 SIRT. Here is part one:https://community.f5.com/t5/technical-articles/reviewing-vulnerability-scanner-results-for-an-access-policy/ta-p/321112 Recap of part one In part one, we reviewed the disclaimer/"Get Out of Jail Free Card", the lab APM virtual server setup, andAPM Access policy, the ZAP web app scanner, andthe sample web app scan result. We looked at the findings and resolutions for HTTP Cookie attributes and HTTP Security headers such as the CSP policy. Inthispart-twoarticle, we will review a Time stamp disclosure finding and then the Conclusion. Timestamp Disclosure - Unix There was also a finding from the ZAP web app scan about 'Timestamp Disclosure' Details: A timestamp was disclosed by the application/web server—Unix 1684411196, which evaluates to: 2023-05-18 04:59:56 Looking at the response body, the following lines include the timestamp '1684411196' href="/public/include/css/modern/framework.css?q=1684411196" /> <script type="text/javascript" src="/public/include/js/modern/loader.js?q=1684411196"></script> <script type="text/javascript" src="/public/include/js/modern/main.js?q=1684411196"></script> ZAP's recommendation is, "Manually confirm that the timestamp data is not sensitive, and that the data cannot be aggregated to disclose exploitable patterns." The format of these lines includes a query string "?q=1684411196" and the files are JS and CSS files. The query string value is a timestamp of the related files and is used in a technique called Cache Busting. This will cause the browser/client to use the newer version of the JS and CSS files from the webserver. In this case, it’s the APM presenting these JS and CSS files. Here are some details about Cache Busting: Cache-busting solvesbrowser caching issues by using a unique file version identifier to tell the browser that a new version of the file is available. Therefore, the browser doesn't retrieve the old file from the cache but rather makes a request to the origin server for the new file. Using Query Strings Another cache-busting technique is to add a query string parameter to the URL of a file. For example, a CSS file with the URL https[:]//example[.]com/styles[.]css can be modified to https[:]//example[.]com/styles[.]css?v=2. The ?v=2 query string parameter tells the browser that this is a new version of the file, and it should be downloaded from the server. The value of the query string parameter can be any string, such as a timestamp or a version number. As long as the value changes each time the file is updated, the browser will treat it as a new file and download it from the server. https://www.keycdn.com/support/what-is-cache-busting So, is there a problem with this? Based on what we know of what this timestamp is used for, it has a valid use in APM logon page and simply instructs clients to use the CSS and JS files with the certain timestamp. Conclusion Vulnerability / web scanner reports will contain many findings. The web app scanning excercise results in this article are just a small subset of potential findings. In this case, we ran through resolving some of the findings by applying necessary configurations — such as an iRule or an Access profile change — to be compliant and some, analyzing the purpose of an entity (timestamp used in CSS query string for cache busting) and determine it has valid use. Implementing these resolutions and understanding of the findings improves the application's security, andas security analysts, we become familiar with the security gaps and functionalities of the application. Our counterparts in network and system administration and application teams will look to us for guidance on keeping our organizations assets secure. Running regular vulnerability scans is an industry norm. We should review the findings and evaluate the risk on the assets that we protect. Keeping networks and systems up to date with security fixes and review of access - allowing only trusted users and networks - to these assets is bare minimum. Implementing additional controls such as BIG-IP APM or BIG-IP ASM/Adv WAF to protect networks and web applications are a great counter to unexpected web scans or even malicious attempts to your web applications. I hope you find this article educational and the concepts and learnings can be added to your security mindset and arsenal. Till next time.
