APM Configuration to Support Duo MFA using iRule
Overview BIG-IP APM has supported Duo as an MFA provider for a long time with RADIUS-based integration. Recently, Duo has added support for Universal Prompt that uses Open ID Connect (OIDC) protocol to provide two-factor authentication. To integrate APM as an OIDC client and resource server, and Duo as an Identity Provider (IdP), Duo requires the user’s logon name and custom parameters to be sent for Authentication and Token request. This guide describes the configuration required on APM to enable Duo MFA integration using an iRule. iRules addresses the custom parameter challenges by generating the needed custom values and saving them in session variables, which the OAuth Client agent then uses to perform MFA with Duo. This integration procedure is supported on BIG-IP versions 13.1, 14.1x, 15.1x, and 16.x. To integrate Duo MFA with APM, complete the following tasks: 1. Choose deployment type: Per-request or Per-session 2. Configure credentials and policies for MFA on the DUO web portal 3. Create OAuth objects on the BIG-IP system 4. Configure the iRule 5. Create the appropriate access policy/policies on the BIG-IP system 6. Apply policy/policies and iRule to the APM virtual server Choose deployment type APM supports two different types of policies for performing authentication functions. Per-session policies: Per-session policies provide authentication and authorization functions that occur only at the beginning of a user’s session. These policies are compatible with most APM use cases such as VPN, Webtop portal, Remote Desktop, federation IdP, etc. Per-request policies: Per-request policies provide dynamic authentication and authorization functionality that may occur at any time during a user’s session, such as step-up authentication or auditing functions only for certain resources. These policies are only compatible with Identity Aware Proxy and Web Access Management use cases and cannot be used with VPN or webtop portals. This guide contains information about setting up both policy types. Prerequisites Ensure the BIG-IP system has DNS and internet connectivity to contact Duo directly for validating the user's OAuth tokens. Configure credentials and policies for MFA on Duo web portal Before you can protect your F5 BIG-IP APM Web application with Duo, you will first need to sign up for a Duo account. 1. Log in to the Duo Admin Panel and navigate to Applications. 2. Click Protect an application. Figure 1: Duo Admin Panel – Protect an Application 3. Locate the entry for F5 BIG-IP APM Web in the applications list and click Protect to get the Client ID, Client secret, and API hostname. You will need this information to configure objects on APM. Figure 2: Duo Admin Panel – F5 BIG-IP APM Web 4. As DUO is used as a secondary authentication factor, the user’s logon name is sent along with the authentication request. Depending on your security policy, you may want to pre-provision users in Duo, or you may allow them to self-provision to set their preferred authentication type when they first log on. To add users to the Duo system, navigate to the Dashboard page and click the Add New... -> Add User button. A Duo username should match the user's primary authentication username. Refer to the https://duo.com/docs/enrolling-users link for the different methods of user enrollment. Refer to Duo Universal Prompt for additional information on Duo’s two-factor authentication. Create OAuth objects on the BIG-IP system Create a JSON web key When APM is configured to act as an OAuth client or resource server, it uses JSON web keys (JWKs) to validate the JSON web tokens it receives from Duo. To create a JSON web key: 1. On the Main tab, select Access > Federation > JSON Web Token > Key Configuration. The Key Configuration screen opens. 2. To add a new key configuration, click Create. 3. In the ID and Shared Secret fields, enter the Client ID and Client Secret values respectively obtained from Duo when protecting the application. 4. In the Type list, select the cryptographic algorithm used to sign the JSON web key. Figure 3: Key Configuration screen 5. Click Save. Create a JSON web token As an OAuth client or resource server, APM validates the JSON web tokens (JWT) it receives from Duo. To create a JSON web token: 1. On the Main tab, select Access > Federation > JSON Web Token > Token Configuration. The Token Configuration screen opens. 2. To add a new token configuration, click Create. 3. In the Issuer field, enter the API hostname value obtained from Duo when protecting the application. 4. In the Signing Algorithms area, select from the Available list and populate the Allowed and Blocked lists. 5. In the Keys (JWK) area, select the previously configured JSON web key in the allowed list of keys. Figure 4: Token Configuration screen 6. Click Save. Configure Duo as an OAuth provider APM uses the OAuth provider settings to get URIs on the external OAuth authorization server for JWT web tokens. To configure an OAuth provider: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Provider. The Provider screen opens. 2. To add a provider, click Create. 3. In the Name field, type a name for the provider. 4. From the Type list, select Custom. 5. For Token Configuration (JWT), select a configuration from the list. 6. In the Authentication URI field, type the URI on the provider where APM should redirect the user for authentication. The hostname is the same as the API hostname in the Duo application. 7. In the Token URI field, type the URI on the provider where APM can get a token. The hostname is the same as the API hostname in the Duo application. Figure 5: OAuth Provider screen 8. Click Finished. Configure Duo server for APM The OAuth Server settings specify the OAuth provider and role that Access Policy Manager (APM) plays with that provider. It also sets the Client ID, Client Secret, and Client’s SSL certificates that APM uses to communicate with the provider. To configure a Duo server: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > OAuth Server. The OAuth Server screen opens. 2. To add a server, click Create. 3. In the Name field, type a name for the Duo server. 4. From the Mode list, select how you want the APM to be configured. 5. From the Type list, select Custom. 6. From the OAuth Provider list, select the Duo provider. 7. From the DNS Resolver list, select a DNS resolver (or click the plus (+) icon, create a DNS resolver, and then select it). 8. In the Token Validation Interval field, type a number. In a per-request policy subroutine configured to validate the token, the subroutine repeats at this interval or the expiry time of the access token, whichever is shorter. 9. In the Client Settings area, paste the Client ID and Client secret you obtained from Duo when protecting the application. 10. From the Client's ServerSSL Profile Name, select a server SSL profile. Figure 6: OAuth Server screen 11. Click Finished. Configure an auth-redirect-request and a token-request Requests specify the HTTP method, parameters, and headers to use for the specific type of request. An auth-redirect-request tells Duo where to redirect the end-user, and a token-request accesses the authorization server for obtaining an access token. To configure an auth-redirect-request: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Request. The Request screen opens. 2. To add a request, click Create. 3. In the Name field, type a name for the request. 4. For the HTTP Method, select GET. 5. For the Type, select auth-redirect-request. 6. As shown in Figure 7, specify the list of GET parameters to be sent: request parameter with value depending on the type of policy For per-request policy: %{subsession.custom.jwt_duo} For per-session policy: %{session.custom.jwt_duo} client_id parameter with type client-id response_type parameter with type response-type Figure 7: Request screen with auth-redirect-request (Use “subsession.custom…” for Per-request or “session.custom…” for Per-session) 7. Click Finished. To configure a token-request: 1. On the Main tab, select Access > Federation > OAuth Client / Resource Server > Request. The Request screen opens. 2. To add a request, click Create. 3. In the Name field, type a name for the request. 4. For the HTTP Method, select POST. 5. For the Type, select token-request. 6. As shown in Figure 8, specify the list of POST parameters to be sent: client_assertion parameter with value depending on the type of policy For per-request policy: %{subsession.custom.jwt_duo_token} For per-session policy: %{session.custom.jwt_duo_token} client_assertion_type parameter with value urn:ietf:params:oauth:client-assertion-type:jwt-bearer grant_type parameter with type grant-type redirect_uri parameter with type redirect-uri Figure 8: Request screen with token-request (Use “subsession.custom…” for Per-request or “session.custom…” for Per-session) 7. Click Finished. Configure the iRule iRules gives you the ability to customize and manage your network traffic. Configure an iRule that creates the required sub-session variables and usernames for Duo integration. Note: This iRule has sections for both per-request and per-session policies and can be used for either type of deployment. To configure an iRule: 1. On the Main tab, click Local Traffic > iRules. 2. To create an iRules, click Create. 3. In the Name field, type a name for the iRule. 4. Copy the sample code given below and paste it in the Definition field. Replace the following variables with values specific to the Duo application: <Duo Client ID> in the getClientId function with Duo Application ID. <Duo API Hostname> in the createJwtToken function with API Hostname. For example, https://api-duohostname.com/oauth/v1/token. <JSON Web Key> in the getJwkName function with the configured JSON web key. Note: The iRule ID here is set as JWT_CREATE. You can rename the ID as desired. You specify this ID in the iRule Event agent in Visual Policy Editor. when ACCESS_POLICY_AGENT_EVENT { if { [ACCESS::policy agent_id] eq "JWT_CREATE" } { set duo_uname [ACCESS::session data get "session.logon.last.username"] # Inline logic for creating JWT set header "{\"alg\":\"HS512\",\"typ\":\"JWT\"}" set exp [expr {[clock seconds] + 900}] set client_id "<Duo Client ID>" set redirect_uri "https://[ACCESS::session data get session.server.network.name]/oauth/client/redirect" set payload "{\"response_type\": \"code\",\"scope\":\"openid\",\"exp\":${exp},\"client_id\":\"${client_id}\",\"redirect_uri\":\"${redirect_uri}\",\"duo_uname\":\"${duo_uname}\"}" set jwt_duo [ACCESS::oauth sign -header $header -payload $payload -alg HS512 -key "<JSON Web Key>"] ACCESS::session data set session.custom.jwt_duo $jwt_duo # JWT Token creation set aud "<Duo API Hostname>" set jti [string range [clock seconds] 0 31] set token_payload "{\"sub\": \"${client_id}\",\"iss\":\"${client_id}\",\"aud\":\"${aud}\",\"exp\":${exp},\"jti\":\"${jti}\"}" set jwt_duo_token [ACCESS::oauth sign -header $header -payload $token_payload -alg HS512 -key "<JSON Web Key>"] ACCESS::session data set session.custom.jwt_duo_token $jwt_duo_token } } when ACCESS_PER_REQUEST_AGENT_EVENT { if { [ACCESS::perflow get perflow.irule_agent_id] eq "JWT_CREATE" } { set duo_uname [ACCESS::session data get "session.logon.last.username"] set header "{\"alg\":\"HS512\",\"typ\":\"JWT\"}" set exp [expr {[clock seconds] + 900}] set client_id "<Duo Client ID>" set redirect_uri "https://[ACCESS::session data get session.server.network.name]/oauth/client/redirect" set payload "{\"response_type\": \"code\",\"scope\":\"openid\",\"exp\":${exp},\"client_id\":\"${client_id}\",\"redirect_uri\":\"${redirect_uri}\",\"duo_uname\":\"${duo_uname}\"}" set jwt_duo [ACCESS::oauth sign -header $header -payload $payload -alg HS512 -key "<JSON Web Key>"] ACCESS::perflow set perflow.custom $jwt_duo # JWT Token creation set aud "<Duo API Hostname>" set jti [string range [clock seconds] 0 31] set token_payload "{\"sub\": \"${client_id}\",\"iss\":\"${client_id}\",\"aud\":\"${aud}\",\"exp\":${exp},\"jti\":\"${jti}\"}" set jwt_duo_token [ACCESS::oauth sign -header $header -payload $token_payload -alg HS512 -key "<JSON Web Key>"] ACCESS::perflow set perflow.scratchpad $jwt_duo_token } } Note: iRule updated 11/27/2024 to eliminate CMP demotion. Figure 9: iRule screen 5. Click Finished. Create the appropriate access policy/policies on the BIG-IP system Per-request policy Skip this section for a per-session type deployment The per-request policy is used to perform secondary authentication with Duo. Configure the access policies through the access menu, using the Visual Policy Editor. The per-request access policy must have a subroutine with an iRule Event, Variable Assign, and an OAuth Client agent that requests authorization and tokens from an OAuth server. You may use other per-request policy items such as URL branching or Client Type to call Duo only for certain target URIs. Figure 10 shows a subroutine named duosubroutine in the per-request policy that handles Duo MFA authentication. Figure 10: Per-request policy in Visual Policy Editor Configuring the iRule Event agent The iRule Event agent specifies the iRule ID to be executed for Duo integration. In the ID field, type the iRule ID as configured in the iRule. Figure 11: iRule Event agent in Visual Policy Editor Configuring the Variable Assign agent The Variable Assign agent specifies the variables for token and redirect requests and assigns a value for Duo MFA in a subroutine. This is required only for per-request type deployment. Add sub-session variables as custom variables and assign their custom Tcl expressions as shown in Figure 12. subsession.custom.jwt_duo_token = return [mcget {perflow.scratchpad}] subsession.custom.jwt_duo = return [mcget {perflow.custom}] Figure 12: Variable Assign agent in Visual Policy Editor Configuring the OAuth Client agent An OAuth Client agent requests authorization and tokens from the Duo server. Specify OAuth parameters as shown in Figure 13. In the Server list, select the Duo server to which the OAuth client directs requests. In the Authentication Redirect Request list, select the auth-redirect-request configured earlier. In the Token Request list, select the token-request configured earlier. Some deployments may not need the additional information provided by OpenID Connect. You could, in that case, disable it. Figure 13: OAuth Client agent in Visual Policy Editor Per-session policy Configure the Per Session policy as appropriate for your chosen deployment type. Per-request: The per-session policy must contain at least one logon page to set the username variable in the user’s session. Preferably it should also perform some type of primary authentication. This validated username is used later in the per-request policy. Per-session: The per-session policy is used for all authentication. A per-request policy is not used. Figures 14a and 14b show a per-session policy that runs when a client initiates a session. Depending on the actions you include in the access policy, it can authenticate the user and perform actions that populate session variables with data for use throughout the session. Figure 14a: Per-session policy in Visual Policy Editor performs both primary authentication and Duo authentication (for per-session use case) Figure 14b: Per-session policy in Visual Policy Editor performs primary authentication only (for per-request use case) Apply policy/policies and iRule to the APM virtual server Finally, apply the per-request policy, per-session policy, and iRule to the APM virtual server. You assign iRules as a resource to the virtual server that users connect. Configure the virtual server’s default pool to the protected local web resource. Apply policy/policies to the virtual server Per-request policy To attach policies to the virtual server: 1. On the Main tab, click Local Traffic > Virtual Servers. 2. Select the Virtual Server. 3. In the Access Policy section, select the policy you created. 4. Click Finished. Figure 15: Access Policy section in Virtual Server (per-request policy) Per-session policy Figure 16 shows the Access Policy section in Virtual Server when the per-session policy is deployed. Figure 16: Access Policy section in Virtual Server (per-session policy) Apply iRule to the virtual server To attach the iRule to the virtual server: 1. On the Main tab, click Local Traffic > Virtual Servers. 2. Select the Virtual Server. 3. Select the Resources tab. 4. Click Manage in the iRules section. 5. Select an iRule from the Available list and add it to the Enabled list. 6. Click Finished.OWASP Tactical Access Defense Series: Broken Function Level Authorization (BFLA)
Broken Function Level Authorization (BFLA) is a type of security vulnerability in web applications where an attacker can access functionality or perform actions they should not be authorized to perform. This problem happens when an application doesn’t check access control on functions or endpoints correctly. This lets users do things that are not allowed. In this article, we are going through API5 item from OWASP Top 10 API Security risks and exploring F5 BIG-IP Access Policy Manager (APM) as a role in our arsenal Let’s consider our test application for each retail agent to submit their sales data, but without the ability to retrieve any from the system. In HTTP terms, the retail agent can POST but not allowed to perform GET, while the manager can perform GET to check agents performance, and collected data. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity: with per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Function Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that authorized users can only perform specific authorized functions (actions) on specified resources. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict permission checks at the object level, F5 BIG-IP APM prevents unauthorized functions. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object-Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM OWASP Tactical Access Defense Series: Broken Object Property-Level Authorization and BIG-IP APM OWASP Tactical Access Defense Series: Unrestricted Resource ConsumptionOWASP Tactical Access Defense Series: Broken Object Property Level Authorization and BIG-IP APM
AUTHOR NOTE: Unauthorized access to private/sensitive object properties may result in data disclosure, data loss, or data corruption. Under certain circumstances, unauthorized access to object properties can lead to privilege escalation or partial/full account takeover. In this article we are going through API3 item from OWASP top 10 API Security risks exploring BIG-IP Access Policy Manager (APM) role in our arsenal. Identifying Vulnerable APIs In order to identify the API endpoint is vulnerable to Broken Object Property Level Authorization, Sensitive properties exposure of certain object for non-intended user (Excessive Data Exposure). import requests # Assuming the API endpoint for retrieving user data is /api/users api_endpoint = "https://example.com/api/users" # Sending a GET request to the API endpoint response = requests.get(api_endpoint) # Checking if the request was successful (status code 200) if response.status_code == 200: # Printing the response content (which could contain excessive data) print(response.json()) else: print("Failed to retrieve data from the API") API allow to change, add or delete sensitive object property for non-intended user (Mass assignment). import requests # Assuming the API endpoint for updating user information is /api/users api_endpoint = "https://example.com/api/users" # Malicious payload containing additional fields malicious_payload = { "username": "malicious_user", "password": "password123", "isAdmin": True # Malicious user attempts to elevate privileges } # Sending a POST request with the malicious payload response = requests.post(api_endpoint, json=malicious_payload) # Checking if the request was successful (status code 200) if response.status_code == 200: print("User information updated successfully") else: print("Failed to update user information") Object Property Level Authorization involves controlling access to specific properties or attributes of an object within a system. Instead of granting blanket access to an entire object, this approach enables fine-grained control, allowing administrators to restrict or permit access to individual properties based on user roles or permissions. While implementing protection against such security risk involves different aspects, one is making sure the user is authorized to access object property, and here BIG-IP APM plays crucial role. Mitigating Risks with BIG-IP APM BIG-IP APM per-request granularity. With per-request granularity, organizations can dynamically enforce access policies based on various factors such as user identity, device characteristics, and contextual information. This enables organizations to implement fine-grained access controls at the API level, mitigating the risks associated with Broken Object Property Level Authorization. Key Features: Dynamic Access Control Policies: BIG-IP APM empowers organizations to define dynamic access control policies that adapt to changing conditions in real-time. By evaluating each API request against these policies, BIG-IP APM ensures that only authorized users can access specific resources and perform permitted actions. Granular Authorization Rules: BIG-IP APM enables organizations to define granular authorization rules that govern access to individual objects or resources within the API ecosystem. By enforcing strict authorization checks at the object level, F5 APM prevents unauthorized users from tampering with sensitive data or performing unauthorized actions. Conclusion In conclusion, BIG-IP APM per-request granularity is a powerful tool for defending against Broken Object-Level Authorization vulnerabilities in APIs. By enforcing fine-grained access controls at the API level, organizations can mitigate the risks associated with unauthorized access to sensitive data. Additionally, proactive security assessments and vulnerability scans are essential for identifying and addressing vulnerabilities in APIs, thereby strengthening overall security posture in the digital ecosystem. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller) OWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APMOWASP Tactical Access Defense Series: Broken Authentication and BIG-IP APM
The threat of broken authentication poses a significant risk to organizations, potentially leading to unauthorized access and data breaches. In the face of this formidable challenge, F5's Access Policy Manager (APM) emerges as a robust and indispensable solution. By seamlessly integrating advanced authentication mechanisms and comprehensive access controls, F5 BIG-IP APM stands as a stalwart guardian against the vulnerabilities associated with broken authentication. This article explores the pivotal role played by BIG-IP APM in fortifying authentication protocols, mitigating risks, and ensuring a resilient defense against unauthorized access, ultimately safeguarding the integrity and security of sensitive data in today's dynamic digital environment. Broken Authentication Authentication mechanism is an exposed target due to the nature of this function, as authentication is the first point of entry to any platform. The difficulty to exploit authentication weaknesses differs based on how the authentication platform is secured. In the current digital era the security perimeters are very fluid, and so are the trust boundries for our authentication platforms those require more cautions from the developers and security architects regarding authentication flows. Not only we need to protect authentication endpoints and flows, but also some overlooked items like forget and reset password endpoints. How can we consider endpoint to be vulnerable? Credential stuffing. Brute force attacks targetting users' accounts. Weak Passwords. Sensitive details in the URL (passwords, Tokens). Allow users sensitive actions without confirmation. No validation for the tokens authenticity. Accept unsigned or weak jwt tokens. No validation for jwt expiration. Use of plain-text, non-encrypted or non-hashed passwords. Use of weak encryption algorithms. Endpoint can access each other without proper authentication. Use weak or predictable tokens for intra-endpoint authentication. Broken Authentication Examples Making use of GraphQL query patching to bypass API ratelimiting and brute force user's login. POST /graphql [ {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"}, {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"}, ... {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"}, ] Update / modify user's sensitive information without API authorization token. PUT /account Authorization: Bearer <token> { "newpassword": "<new_password>" } BIG-IP APM and Broken Authentication We start with creating our Per-Request policy, this policy works in a different way than the per-session policy, as the flow will be evaluted on a per-request basis, making sure to consider variations throught the session life-time. Below are some of the key benefits: Wide range of Authentication, SSO, and MFA mechanisms to properly identify the initiating machine or user. Ability to integrate with 3rd parties to provide additional enforcement decisions based on the organization's policy. Ability to apply endpoint checks on the client side before session initiation. This goes to BIG-IP in general, the ability to apply custom traffic control on both of the traffic sides, Client and Server. The ability to create whitelist / blacklist for API Access tokens, JSON Web Tokens ID (JTI) or a different element based on the used authentication method, below example steps for JWT: Extract JTI value from Access token. Add JTI value to whether Allow/Block lists. Related Content F5 BIG-IP Access Policy Manager | F5 Introduction to OWASP API Security Top 10 2023 OWASP Top 10 API Security Risks – 2023 - OWASP API Security Top 10 API Protection Concepts OWASP Tactical Access Defense Series: How BIG-IP APM Strengthens Defenses Against OWASP Top 10 OWASP Tactical Access Defense Series: Broken Object Level Authorization and BIG-IP APM F5 Hybrid Security Architectures (Part 5 - F5 XC, BIG-IP APM, CIS, and NGINX Ingress Controller)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. 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 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 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, and APM Access policy, the ZAP web app scanner, and the 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. In this part-two article, 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 solves browser 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, and as 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.What Is BIG-IP?
tl;dr - BIG-IP is a collection of hardware platforms and software solutions providing services focused on security, reliability, and performance. F5's BIG-IP is a family of products covering software and hardware designed around application availability, access control, and security solutions. That's right, the BIG-IP name is interchangeable between F5's software and hardware application delivery controller and security products. This is different from BIG-IQ, a suite of management and orchestration tools, and F5 Silverline, F5's SaaS platform. When people refer to BIG-IP this can mean a single software module in BIG-IP's software family or it could mean a hardware chassis sitting in your datacenter. This can sometimes cause a lot of confusion when people say they have question about "BIG-IP" but we'll break it down here to reduce the confusion. BIG-IP Software BIG-IP software products are licensed modules that run on top of F5's Traffic Management Operation System® (TMOS). This custom operating system is an event driven operating system designed specifically to inspect network and application traffic and make real-time decisions based on the configurations you provide. The BIG-IP software can run on hardware or can run in virtualized environments. Virtualized systems provide BIG-IP software functionality where hardware implementations are unavailable, including public clouds and various managed infrastructures where rack space is a critical commodity. BIG-IP Primary Software Modules BIG-IP Local Traffic Manager (LTM) - Central to F5's full traffic proxy functionality, LTM provides the platform for creating virtual servers, performance, service, protocol, authentication, and security profiles to define and shape your application traffic. Most other modules in the BIG-IP family use LTM as a foundation for enhanced services. BIG-IP DNS - Formerly Global Traffic Manager, BIG-IP DNS provides similar security and load balancing features that LTM offers but at a global/multi-site scale. BIG-IP DNS offers services to distribute and secure DNS traffic advertising your application namespaces. BIG-IP Access Policy Manager (APM) - Provides federation, SSO, application access policies, and secure web tunneling. Allow granular access to your various applications, virtualized desktop environments, or just go full VPN tunnel. Secure Web Gateway Services (SWG) - Paired with APM, SWG enables access policy control for internet usage. You can allow, block, verify and log traffic with APM's access policies allowing flexibility around your acceptable internet and public web application use. You know.... contractors and interns shouldn't use Facebook but you're not going to be responsible why the CFO can't access their cat pics. BIG-IP Application Security Manager (ASM) - This is F5's web application firewall (WAF) solution. Traditional firewalls and layer 3 protection don't understand the complexities of many web applications. ASM allows you to tailor acceptable and expected application behavior on a per application basis . Zero day, DoS, and click fraud all rely on traditional security device's inability to protect unique application needs; ASM fills the gap between traditional firewall and tailored granular application protection. BIG-IP Advanced Firewall Manager (AFM) - AFM is designed to reduce the hardware and extra hops required when ADC's are paired with traditional firewalls. Operating at L3/L4, AFM helps protect traffic destined for your data center. Paired with ASM, you can implement protection services at L3 - L7 for a full ADC and Security solution in one box or virtual environment. BIG-IP Hardware BIG-IP hardware offers several types of purpose-built custom solutions, all designed in-house by our fantastic engineers; no white boxes here. BIG-IP hardware is offered via series releases, each offering improvements for performance and features determined by customer requirements. These may include increased port capacity, traffic throughput, CPU performance, FPGA feature functionality for hardware-based scalability, and virtualization capabilities. There are two primary variations of BIG-IP hardware, single chassis design, or VIPRION modular designs. Each offer unique advantages for internal and collocated infrastructures. Updates in processor architecture, FPGA, and interface performance gains are common so we recommend referring to F5's hardware page for more information.
Enterprise Web Access and Federated Identity – match made in heaven?
The reality of enterprise web access today and the challenges it brings to the companies and their security departments are pretty well described in this blog post. The conclusion of that post is that: “F5 Secure Web Gateway – with BIG-IP Access Policy Manager – delivers this, and more…” Let’s pick it up where that blog post left off and explore the “more” part of that sentence in order to uncover the unique value proposition that F5 brings. Over the past five years, many F5 customers have used F5 Access Policy Manager (APM) to provide granular, context-aware secure access into enterprise applications. In that time, customers have deployed APM to provide strong multi-factor authentication for the applications, perform single sign-on, and enable access control based on Layer 4 and Layer 7 ACLs. Further, as of about 18 months ago, F5 capabilities expanded to include federated access to applications using SAML 2.0. The need to provide federated identify in the enterprise grows rapidly as companies turn to outsourcers and cloud-based applications to meet their needs: Office 365, Salesforce.com, Concur, Amazon Web Services, Microsoft Azure, etc. In fact, it’s hard to find an enterprise today that is not relying on at least one cloud-based application, and thus has the need to provide user identity services to these applications. Based upon real-world APM implementations that I have seen, as well as quite a few DevCentral posts from customers and partners, a real need exists to perform “silent” user authentication and seamless sign-on into cloud-based applications. Let’s go over how that normally works in the enterprise environment: APM would be configured to act in the SAML Identity Provider (IDP) role. When a user attempts to access cloud-based SAML-enabled applications, those applications ask for a SAML assertion from the user’s IDP. So, when a user who has not yet been authenticated attempts to access a cloud application, that user is sent to the IDP that has been defined for that application as the trusted identity provider. The user has to authenticate to that IDP, after which the IDP will issue a SAML assertion to the cloud-based application. The user will then be logged in based upon the SAML assertion data sent by the IDP. Many enterprises today want their users to seamlessly authenticate to the IDP while accessing external applications from an internal network. While many IDPs leverage forms-based authentication method for external access—where a user enters their username and password and submits it to authentication store such as Active Directory for verification—internal IDPs can take advantage of the fact that the user has already authenticated from an endpoint inside the internal network. As such, users may silently authenticate to the IDP using either NTLM or Kerberos authentication, which can then provide seamless logon experience into the IDP. Now, let’s revisit the need to provide enterprise web access control and to ensure the compliance with the outbound security access policy. F5 Secure Web Gateway Services can protect users from exposure to potentially dangerous websites and malware-infected web apps, ensuring compliance with the organization’s web access policy. And because F5 Secure Web Gateway is tightly coupled with APM, customers can now solve two problems simultaneously—ensure efficient web access control while providing seamless federated identity services for accessing SaaS applications. What’s important is that this is all accomplished on the same device, using the same policy-editing GUI, preserving transparency and enhancing end-user experience for both outbound web access and use of cloud applications. By combining the power of Secure Web Gateway Services and Access Policy Manager, you’ve got the cake, and you get to eat it too. It tastes delicious!
