15

Subject:Computer SciencePrice: Bought3

Share With

15.3 Student Guide: Web Application Tool Time

Overview

Today's class is the final part of our introduction to web vulnerabilities. You will learn how to use tools to determine and automate the discovery of vulnerabilities that exist within a web application. The lesson will introduce web proxies and Burp Suite. You will use Burp Suite to exploit broken authentication vulnerabilities by conducting attacks such as session hijacking and brute force attacks. Additionally, you will learn mitigation methods used to protect against these exploits.

Class Objectives

· Identify ways in which web application security tools can assist with testing security vulnerabilities.

· Configure Burp Suite and Foxy Proxy to capture and analyze an HTTP request.

· Identify session management vulnerabilities using the Burp Suite Repeater function.

· Conduct a brute force attack against a web application login page with the Burp Intruder function.

Slideshow

· 15.3 Slides .

 

01. Introduction to Attacking Web Applications with Security Tools

Recap of the concepts covered in the last class:

· Back-end component vulnerabilities are vulnerabilities that exist within the back-end components of web application servers.

· Back-end components apply the business logic, or how the application works. They can include the following:

· Server content management and access control

· Back-end languages like PHP and Java

· Directory traversal is a web app back-end component vulnerability in which an attacker accesses files and directories from a web application outside a user's authorized permissions.

· In a directory traversal attack, attackers can modify the user input, using a dot-slash method, to access unintended files in other directories.

· Local file inclusion, or LFI, is another web app back-end component vulnerability, in which an attacker tricks the application into running unintended back-end code or scripts that are LOCAL to the application's file system.

· An example of a back-end coding language that can be used is PHP.

· LFI is typically conducted by an attacker uploading a malicious script into the web app's LOCAL file system, using the file upload functionality.

· After successfully completing the upload, the attacker can arbitrarily execute command-line code with that script.

· Remotely executing command-line code is defined as remote code execution.

· Remote file inclusion, or RFI, is a back-end component web app vulnerability in which an attacker tricks the application into running unintended back-end code or scripts—similar to LFI, except that the scripts are REMOTE to the application's file system.

· RFI is typically conducted by an attacker modifying the URL to reference a REMOTE malicious script.

· After successfully referencing the script, the attacker can arbitrarily execute command-line code with that script.

· Because the attacker can remotely execute command-line code, this is also considered remote code execution.

· Directory traversal, LFI, and RFI all fall under the OWASP risk broken access control.

· Per OWASP , broken access control is explained as follows:

· "Restrictions on what authenticated users are allowed to do are often not properly enforced. Attackers can exploit these flaws to access unauthorized functionality and/or data, such as access other users’ accounts, view sensitive files, modify other users’ data, change access rights, etc."

Web Application Security Tools

In the last two classes, we have covered several different vulnerabilities (SQL injection, XSS, directory traversal, LFI, and RFI), as well as methods to exploit them.

· Note that we exploited each of these vulnerabilities by directly interacting with the web application. For example:

· For SQL injection, we interacted with the web application by inserting a malicious SQL script payload into an input field.

· For LFI, we interacted directly with the web application by uploading a malicious PHP script.

While we successfully exploited these web app vulnerabilities with direct interaction with the web application, sometimes security professionals run into certain challenges during their testing.

For example:

· The following image shows a recap of the SQL injection attack that was demonstrated on the first day of this unit:

 

· This image represents where we used the always true payload (jsmith OR '1' = '1) to conduct a SQL injection attack and displayed all the contents from a database table.

Note that while we successfully conducted this SQL injection attack on the first attempt, most security professionals have to try many different payloads before determining which payload works.

· For example, a security professional might have to try lots of different types of payloads, such as the following:

· jsmith" or true--

· jsmith OR "1" = "1

· jsmith -- OR '1' = '1

· jsmith') or true--

The challenge is that it is very time-consuming and inefficient for the security professional to manually enter one payload at a time and examine each individual result.

· Fortunately, there are web application security tools that can help you solve challenges like this.

Web application security tools can assist security professionals by automating testing processes.

· Web application security tools can also assist with capturing, displaying, and modifying web application requests and responses.

· Certain web application security tools have built-in features that are designed to test for certain web app vulnerabilities.

In today's lesson we will be introducing and demonstrating a popular web application security tool that offers all three of the preceding features: Burp Suite.

· Additionally, we will be demonstrating how Burp Suite can be used to exploit vulnerabilities that fall under the OWASP risk broken authentication.

· Broken authentication risks are risks that permit an attacker to either view or bypass the authentication methods that are used by a web application.

Class Overview

Today's class will cover how to use Burp to exploit two broken authentication vulnerabilities. The class will proceed as follows:

· We will begin with introducing Burp Suite and Foxy Proxy and how to configure them to capture and analyze HTTP requests and responses.

· Then we will learn how to use the Burp Repeater feature to determine session hijacking vulnerabilities.

· Lastly, we will show how to use the Burp Intruder feature to conduct an automated brute force attack.

? IMPORTANT HEADS UP: ?

The techniques we will learn throughout this unit can be used to cause serious damage to an organization's systems. This is ILLEGAL when done without permission. All of the labs we provide are safe locations to test the methods and tools taught during the week.

NEVER apply any of these methods to any web applications you do not own or do not have clear, written permission to be interacting with.

Make sure to cover the daily objectives and answer any questions before proceeding on to the first topic of the day.

02. Introduction to Web Proxies and Burp Suite (0:15)

In last week's class, we illustrated how the browser, using a web application, interacts with the back-end web server by using HTTP requests and responses.

· For example, let's say that a user wants to view a picture of a car by clicking on a link on a website.

· A user's browser (the client) requests an image of a car to be displayed with an HTTP request.

· The web server (the server) responds with that car image by sending an HTTP response.

· The browser receives the HTTP response and renders the image of the car to the user.

· The following image illustrates the HTTP request-response cycle:

 

Behind the scenes in this process, HTML requests and responses are constantly exchanged between the browser and the web server.

· Note that security professionals often need to examine and modify these raw HTML requests and responses to test for security vulnerabilities.

Web Proxy

Security professionals can capture and view these requests and responses by using a web proxy. Introduce web proxies by covering the following:

· A web proxy is an intermediary between the client and the server.

· In its simplest terms, internet traffic flows through the proxy on the way to its intended destination.

· Web proxies can be used for the following scenarios:

· By organizations, to monitor and block harmful web traffic, as some web proxies can be configured to block specific websites.

· By individuals, to provide themselves anonymity when using the internet, as some web proxies can change the source IP address.

· The following image show how the client's request for the car image and the server returning the car image flows through the proxy:

 

· Some web proxy tools can also intercept and hold the requests or responses before passing them along to their destination.

· Security professionals use this intercept functionality to analyze or modify the raw HTTP requests and responses.

· The security tool that we will be using in the class, which has this intercept functionality, is called Burp Suite.

Burp Suite

Burp Suite is a web application security tool that lies between your browser and your target application.

· Burp Suite intercepts raw HTTP traffic from the browser or the server.

· This means that it functions as a web proxy.

· Burp offers many additional features and capabilities to allow a security professional to analyze, modify, and automate the HTTP traffic before passing it along to its final destination.

· We can only cover a few of its many features in class.

· If you want to learn about all of Burp's features, refer to the following resource: PortSwigger: Burp Suite tools .

· In this lesson, we will be using the free version of Burp Suite, called the Burp Suite Community Edition.

· There are paid versions, Burp Suite Pro and Burp Enterprises, that offer many additional features that we will not use in this class.

Burp Demonstration

In the next demonstration, we will complete the following steps to configure Burp to capture and inspect a simple HTTP request.

1. Start and access Burp Suite.

2. Navigate Burp Suite.

3. Configure the proxy on Burp Suite.

4. Configure Foxy Proxy on your browser.

5. Enable Foxy Proxy to send traffic to Burp Suite.

6. View the captured traffic on Burp Suite.

Part 1: Launch and Access Burp Suite

1. We will begin by launching and accessing Burp Suite.

· Open a terminal within Vagrant and run the command sudo burpsuite, then press Enter.

· This will open the Burp Suite application:

 

2. On the first page of Burp Suite, select Temporary project from the list of options. Select Next on the bottom right of the page.

 

· ? If you encounter any pop-ups about updating Burp Suite, DO NOT update. Cancel the pop-up.

3. On the second page, select Use Burp defaults from the list of options. Select Start Burp on the bottom right of the page.

· Do not select any other options on this page:

 

· The Burp Suite Dashboard will appear once you have successfully accessed Burp Suite.

· The following image illustrates the page that should be displayed:

 

Part 2: Navigate Burp Suite

4. Now we will navigate the Burp interface to access Burp features.

· We are currently on the Burp Suite Dashboard.

· ???? Note that features on the Burp Suite Dashboard are outside the scope of the class, but if students want to learn about them, you can send them the following link: PortSwigger: Burp Suite Dashboard .

 

· We will use the following three features, which you will find to the right of the Dashboard tab:

· Proxy

· Intruder

· Repeater

· These features contain their own tabs as well. For example, Proxy contains the following sub-options:

· Intercept

· HTTP history

· WebSockets history

· Options

 

· In the demonstrations and activities, you will be accessing several sub-options.

Part 3: Configure the Proxy on Burp Suite

5. We will now navigate the various features within Burp. Let's begin by configuring the proxy to capture a HTTP request.

· Select the Proxy tab from the tool bar at the top of the Burp window.

· When you open the Proxy feature, you will be taken to the default sub-option Intercept.

· On this page, confirm that Intercept is on. You should see a gray button that reads Intercept is on:

 

· Note that when Intercept is on, the traffic will be captured and held.

· When Intercept is off, the traffic will flow right through to its destination.

· If the button says Intercept is off, click the button to turn it back on.

6. Under Proxy, select the Options tab.

· Under Proxy Listeners, confirm that you have the interface 127.0.0.1:8080 set up, with the Running option checked.

· The following image illustrates how the listener should be set up.

· Note that this is the default proxy setup in Burp.

 

· This means that Burp will listen for traffic directed to the following:

· IP: 127.0.0.1 (your localhost)

· Port: 8080

Part 4: Set Up the Proxy on Firefox

7. Now that the proxy is configured to listen for web traffic, we need to configure the browser to send the traffic to this IP and port.

· Begin by opening the Firefox browser. You can open Firefox from the Vagrant menu or type "firefox" in your terminal.

· Next we need to add a free add-on browser feature called Foxy Proxy.

· In your browser, search for "Foxy Proxy":

 

· It should be the first result listed in a Google search. Select that option, which should take you to a page like the one shown in the following image:

 

· Select Add to Firefox.

· If a pop-up appears on the top of your screen, select Add to proceed.

· Once you have added it, you will see the Foxy Proxy icon in the top-right corner of your browser:

 

8. Let's configure Foxy Proxy to send the web traffic to Burp Suite.

· Click on and open the Foxy Proxy add-on.

· Within the Foxy Proxy window that opens, select Options.

 

· This will take you to a page where you can create the various proxy options to send your traffic to.

· Select Add on the top left, to go to the Add Proxy page.

 

· Under Title, enter "Burp".

· On the right, update the following fields to match what we configured in Burp:

· Proxy Type: HTTP

· Proxy IP address or DNS name: 127.0.0.1

· Port: 8080

· Leave the rest of the fields blank.

· Select Save on the bottom right to save your proxy:

 

· After selecting Save, you should now see your new Burp proxy option listed on the Options page:

 

· Burp is not yet enabled.

Part 5: Capture Proxy Traffic from Your Browser

9. Now that we have configured the proxy settings on Burp and Foxy Proxy, let's capture the first HTTP traffic request!

· Open a new tab on your browser. The webpage will look something like the following image:

 

· Click the Foxy Proxy icon and select the proxy that you just configured: Burp/Burp Suite.

· A check mark will appear to the left of that option once you have selected it. This green icon indicates that all future traffic will be forwarded to Burp Suite!

 

10. Let's send the first HTTP request to Burp.

· From the webpage, enter the URL "www.example.com" and press Enter.

· Notice how, after you enter the URL, the screen turns blank and the page appears to be spinning.

· The bottom of the webpage states, Waiting for www.example.com ...

· This indicates that the HTTP request has been sent to Burp and the browser is awaiting a response:

 

· Burp has intercepted and hung on to the HTTP request!

Part 6: View the Captured Traffic from Burp Suite

11. Return to Burp Suite and find the intercepted traffic.

· Select Proxy on the primary tool bar.

· Within Proxy, select Intercept.

· Your captured HTTP request will appear:

 

· Look at the Host line of your HTTP request.

· Important: It is very likely that your Firefox browser sends requests looking for WiFi networks to log into. You will notice this if the HTTP traffic you see shows the host as detectportal.firefox.com.

· To prevent Burp from capturing these requests, right-click on the HTTP traffic and select Don't intercept requests > To this host.

· This will prevent Burp from capturing future requests.

 

· You may have many of these captured detectportal requests. To remove them you can do one of the following:

· Continue to select Drop from the Intercept page until the host of your HTTP traffic is www.example.com.

 

· Alternatively, toggle the Intercept is on button to Intercept is off, then back to Intercept is on again. This will clear all the captured requests.

· Note that with this method, you will need to return to the browser and re-enter "example.com" in the URL to create a new capture.

· You have successfully captured the HTTP traffic request when the HTTP traffic shows the following:

· GET / HTTP/1.1

· Host: www.example.com

· User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

· Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

· Accept-Language: en-US,en;q=0.5

· Accept-Encoding: gzip, deflate

· Connection: close

Upgrade-Insecure-Requests: 1

· Note that this is the raw HTTP GET request that your browser sent to request example.com.

· Additionally, note that what has happened is that Burp has captured and held this HTTP request before it is forwarded to the host, www.example.com .

· This is why the loading bar on the browser tab is still spinning.

12. Now we will let go of the hold and forward this HTTP request to the host.

· Select the forward option to forward the HTTP request to www.example.com .

· Return to the browser and note that we can now see that the response was returned, as the correct webpage has been displayed:

 

13. Finally, it is good practice to disable your Burp Suite Foxy Proxy setting when you are done capturing traffic.

· To disable the setting, click on the Foxy Proxy icon again and select Turn Off.

Demonstration Summary

The walkthrough we just completed illustrated the steps that a security professional would take to capture and view raw HTTP traffic using Foxy Proxy and Burp Suite.

03. Configuring Burp Suite Activity

· Activity File: Burp Suite Setup

04. Session Management Vulnerabilities

Recap:

· Security professionals use web application security tools to assist with analyzing and automating web application security tests.

· Burp Suite is a popular web application security tool that has a functionality called a web proxy.

· A web proxy is an intermediary through which traffic flows between the client and the server.

· A web proxy can intercept web traffic, so that security professionals can analyze or modify it.

· In addition to the web proxy intercept functionality, Burp Suite offers many custom features designed for testing security vulnerabilities.

In this next section, we will learn how to use a Burp Suite feature called Repeater to test for session management vulnerabilities.

Before we start using Burp Suite, we will revisit how applications use cookies to manage a user's session.

Cookies and Session Management

Remember that last week we covered the following:

· HTTP resources are inherently stateless, meaning that whenever your browser requests a webpage, there is no way for that webpage to distinguish you from anyone else.

· Websites need a way to deliver content that is specific to each user. To do so, they establish sessions, using cookies.

· Sessions are unique server-side sets of user data used to specify the webpages being accessed and the content displayed on them, for the specific user accessing them.

· Cookies are small pieces of text data that, when sent by an HTTP server's response header, are saved by the user's HTTP client.

· After a user authenticates into a secure website, the web server issues the user a unique session cookie, so that the information displayed is specific just to that user.

· For example, if a user logs in with their correct username and password to an online banking website, they will receive their own unique session cookie, providing them with all their private account information (accounts, balances, transactions) when they navigate within the online banking application.

· When the user logs out, or after a period of inactivity, the session cookie should expire.

The intended purpose of session cookies is to maintain a state between webpages when a user accesses a web application.

Session Hijacking

After a user authenticates into a web application, the data that is displayed is specific and private to the user accessing the application.

Note that if a malicious user can obtain another user's unique session cookie, the malicious user could hijack the victim's private session.

· This unintended attack method is defined as session hijacking.

· Note that in last week's lesson, we conducted a session hijacking attack when we used the Chrome browser extension Cookie-Editor to swap sessions.

· Session hijacking attacks exploit session management vulnerability.

· It falls under the OWASP Top 10 risk of broken authentication because if an attacker has access to a user's session, they can bypass the application's authentication measures.

Session hijacking can be conducted by several methods:

· Sniffing traffic: If a malicious user can sniff encrypted traffic, then they can potentially capture the session cookie and take over a victim's session.

· Client-side attacks: A malicious user can deploy a cross-site scripting attack to steal a user's session cookie.

· Predictable sessions: A malicious user can predict what a unique session cookie might be.

Session Hijacking with Predictable Sessions Scenario

The following scenario explains how an attacker could use the predictable sessions method of session hijacking.

· Henry, a malicious user, is using a stock-trading website to buy and sell stocks and mutual funds.

· Henry logs in with his own credentials on Monday, February 9th, 2021, to the stock-trading site, then views his session cookie in his browser settings: 020921MON-1454.

· He logs out and immediately logs back in again with his own credentials, then checks his session cookie again: 020921MON-1455.

· Henry logs in the following day, Tuesday, February 10th, 2021, and his session cookie is now 021021TUE-3834.

· Henry can look at these session cookies that are generated and determine that the algorithm used by the stock trading site likely comprises the following:

· The six-digit numerical date

· The three-letter day of the week

· A four-digit number that increments

 

· By figuring out the algorithm, Henry can try and guess another user's session cookie, then hijack another user's session.

· For example, on Wednesday, Henry can manually update his session cookie using the Chrome Cookie-Editor, until he manages to hijack another user's session:

· Henry might first try 021121WED-1111.

· If that doesn't work, he might next try 021121WED-1112.

· If that doesn't work, he might next try 021121WED-1113.

· If that doesn't work, he might next try 021121WED-1114.

· If that doesn't work, he can keep trying.

· Note that with this method, the victim that Henry is attacking is usually random, as the attacker likely does not know who is accessing the application at what time.

· Eventually, after many tries, Henry tries a session cookie of 021121WED-1187, and then he ends up inside the stock-trading account of another user, Julie Jones.

· Henry can now view Julie's private stock information and even potentially sell her stocks without her permission.

Scenario Summary

· In this scenario, the session management vulnerability was that the session cookie was predictable, as Henry was able to predict the session cookie of another user, Julie Jones.

· Henry exploited the vulnerability by conducting a session hijacking attack, using the predicted session cookie of 021121WED-1187 to hijack Julie Jones's private session.

· Lastly, note that in this scenario, Henry had to log out and log back in again to determine the pattern of the session cookies.

· Note that this manual process can be time-consuming and inefficient.

05. Analyzing Session Management Vulnerabilities with Burp Repeater

We just covered the following:

· How session cookies are intended to maintain a private session within a web application.

· That an unintended session management vulnerability exists if an attacker can obtain or determine the session cookie, as the attacker could hijack the user's private session.

· There are several methods that an attacker can use to obtain or determine the session cookie: sniffing traffic, client-side attacks, and predictable sessions.

· With the predictable sessions method, if an attacker can determine the algorithm being used to create session cookies, they can use the algorithm to predict future session cookies and hijack another user's private session.

Note that in the scenario, we illustrated how Henry used an inefficient method of logging out and back in each time to view his session cookies and determine the algorithm.

· Burp Suite has a feature called the Repeater that can simplify this process.

· We will now demonstrate how we can determine an algorithm used for generating session cookies, by using the Burp Repeater feature.

Burp Repeater Demonstration Setup

In this demonstration, we will continue to work on the Replicants web application.

Specifically, we will conduct this demonstration by completing the following four steps:

· Access the session cookie generator and enable proxy settings.

· Generate and view the session cookie.

· Move the HTTP request to Burp Repeater.

· Use Burp Repeater to view the HTTP response.

Part 1: Access the Session Cookie Generator and Enable Proxy Settings

1. To access the Replicants website within Vagrant, access the following page: http://192.168.13.25 .

· We will select the Weak Session IDs option from the menu on the left side of the page.

· Alternatively, access the webpage directly by accessing this page: http://192.168.13.25/vulnerabilities/weak_id/ .

· Note: If you have any issues accessing this webpage, you might need to repeat the Activity Setup steps from the 06_SQL_Injection activity from 15.1.

· The page will look like the following image:

 

· Note that while this webpage is technically part of the Replicants website, it is designed to simulate the session ID that is created each time a different user logs into the application.

· View how it works by clicking the Generate button.

 

· While it looks like nothing happened, an HTTP request for a new session cookie is made behind the scenes.

· The page states, "This page will set a new cookie called dvwaSession each time the button is clicked."

· We will be viewing this new dvwaSession cookie shortly.

2. Next, to enable the Burp proxy, repeat the same steps we completed in the previous activity:

· On your browser, enable the Burp selection from Foxy Proxy.

· From Burp Suite, under Proxy > Intercept, confirm that Intercept is on.

· Now we are ready to capture this new request!

Part 2: Generate and View the Session Cookie

3. We will now capture the HTTP request that is generated when we click the button.

· Click the Generate button again.

· Note that the loading bar on the browser tab should be spinning:

 

· This means that the HTTP request has been intercepted by Burp, and the browser is waiting on the response.

4. Now we'll return to Burp Suite to view this intercepted HTTP request.

· Under Proxy > Intercept, we should see an HTTP POST request that looks similar to the following image:

 

POST /vulnerabilities/weak_id/ HTTP/1.1

Host: 192.168.13.25

User-Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Content-Type: application/x-www-form-urlencoded

Content-Length: 0

Connection: close

Referer: http://192.168.13.25/vulnerabilities/weak_id/

Cookie: PHPSESSID=kk3k2ir7hf156ultvtetcv7br4; security=low

Upgrade-Insecure-Requests: 1

· This is a raw HTTP POST request that gets generated and sent to the web server after we select the Generate option.

· Similar to the previous activity, because Intercept is ON, this request is being held and has not yet reached the destination web server.

· We're now ready to send this to the Burp Repeater feature, to assist with analyzing the responses.

Part 3: Move the HTTP Request to Burp Repeater

5. Send this request to the Repeater tool by completing the following steps:

· Right-click on the Intercept page and select Send to Repeater (or press CTRL+R):

 

· Note that now the Repeater icon color on your tool bar has changed from black to orange.

· This indicates that the HTTP request has been sent to Repeater.

· Click on the Repeater icon from your tool bar to view this HTTP request.

· Note that this should display the same HTTP POST request that you saw under Intercept:

 

Part 4: Use Burp Repeater to View the HTTP Response

6. On the Repeater page, note the following:

· The Repeater feature is a tool within Burp Suite for manually manipulating and reissuing individual HTTP messages.

· We will use this tool to reissue the HTTP request to generate a cookie and then view the HTTP response of the cookie that was generated.

7. Complete the following steps:

· From the Repeater page, select Send to send the HTTP request.

· After you select Send, the HTTP Response panel should appear on the right side of the Repeater page.

· Note that this data is the complete HTTP response sent back from the web server.

 

8. Briefly return to your browser and note that loading bar is still spinning.

· This means that even though the HTTP request was sent to the web server, and the web server returned the response to Burp, the response has not yet been returned to the browser.

 

9. Return to Burp and point to the HTTP response:

· Specifically note the line that contains the session ID returned from the web server:

· Set-Cookie: dvwaSession=1

· This is the first session cookie, 1. This session cookie will be stored in the browser to maintain a private session:

 

10. We will now generate another session cookie, but we do not have to return to the webpage, as we can do this within Burp.

· From the same Burp Intercept page, press the Send button again. Then note how the session ID has changed: Set-Cookie: dvwaSession=2.

 

· Press the Send button again several more times. Note that the session IDs increment by one digit each time.

· The algorithm for generating session cookies for this web application increments the number by one.

· This illustrates the intended purpose of the application, to generate a different session ID every time a user selects Generate from the web application.

· Additionally, note that this is WEAK security, as an attacker could use the knowledge of how the session ID gets generated to hijack a user's session.

This demonstration shows how with the Burp Repeater tool, an attacker could capture, generate, and analyze HTTP requests and responses without having to constantly use the web application.

Real-World Challenges

Note that while the purpose of the lesson was to illustrate how to determine session management vulnerabilities with the Burp Repeater feature, in the real world we need to be aware of several issues not covered in this class.

· Generation of Session Cookies

· While we clicked a button to generate session cookies, real applications do not have a generate button.

· Most web applications generate the session cookie on successful authentication into the web application.

· Security professionals have to determine the HTTP request that generates the session cookie and use that request in Burp Repeater.

· Use of Burp Repeater

· While we used Burp Repeater to simply reissue the same HTTP request, Burp Repeater can be used to modify the request one at a time.

· On the HTTP Request panel, an attacker can simply change any data in the request to check how it changes the response.

· Attackers can used this to try attacks against different hosts, resources, and types of HTTP requests.

Impact

The reason that session hijacking is considered a harmful attack is due to the impact that can be caused:

· If a malicious actor can successfully launch a session hijacking against a web application's users, they can potentially do the following:

· View a user's confidential data.

· Use features that are not intended to be accessed by unauthorized users within a secure application.

Mitigation Methods

We just learned that a session hijacking attack is conducted by finding session management vulnerabilities.

· Methods that can be used to mitigate this attack depend on the attack being conducted. For example:

· To mitigate against sniffing attacks, the web developer of the application can use an HTTP header to have a Secure cookie attribute. This ensures that the client only sends the session cookie encrypted and cannot be exposed in the web traffic.

· To mitigate against client-side attacks, the web developer of the application can use an HTTP header to have an HttpOnly cookie attribute. This ensures that the client does not allow scripts, such as JavaScript, to access the session cookie. This can protect against a cross-site scripting attack trying to steal a cookie.

· To mitigate against predictable sessions, the web developer of the application can prevent the session cookie being generated from being predicted or brute forced, by ensuring the following:

· The cookie is long enough to make it difficult to brute force.

· The cookie is random enough to be unpredictable.

· The cookie doesn't contain any details about the user.

 Refer to the following resource, which illustrates the best practices to ensure proper session management: OWASP: Session Management Cheat Sheet .

Session Management Vulnerability Summary

· The intended purpose of the original function: Session cookies are INTENDED to maintain a user's session within a web application.

· The vulnerability and method of exploit: With a session management vulnerability such as a predictable session, an attacker could predict a future session cookie and conduct a session hijacking attack.

· The unintended consequence of the exploit: The unintended consequence is that if an attacker determines a victim's session cookie, they can access the victim's private session.

· The mitigation of the vulnerability: Mitigations can vary depending on the session management vulnerability you are protecting against. Mitigations can include using protective HTTP headers and generating session cookies that are difficult to predict.

· The potential impact of the exploit: The impact could include viewing a victim's confidential data inside the application or conducting unauthorized activities inside the application.

06. Analyzing Session Management Vulnerabilities with Burp Repeater Activity

· Activity File: Session Management

07. Analyzing Session Management Vulnerabilities with Burp Repeater Review

· Solution Guide: Analyzing Session Management Vulnerabilities with Burp Repeater

08. Conducting Brute Force Attacks with Burp Intruder

Recap

· In addition to the web proxy intercept functionality, Burp Suite offers many custom features designed for testing security vulnerabilities.

· One Burp Suite feature called Repeater can be used to manually manipulate and reissue INDIVIDUAL HTTP messages.

· The Burp Repeater can be used to help determine session management vulnerabilities, such as the predictability of the algorithm used by a web application to generate session cookies.

Burp Intruder

Note that while the Burp Repeater functionality was helpful to determine session management vulnerabilities, Burp Repeater is limited to reissuing individual HTTP messages.

There are certain web vulnerabilities in which the following would be beneficial:

· Issuing multiple HTTP messages.

· Automating multiple HTTP messages with a single request.

Consider the following scenario, in which automating multiple HTTP messages would be beneficial:

· An attacker is trying to attack a web application form field with a SQL injection attack.

· The attacker attempts a SQL injection attack with the common ' OR '1' = '1 payload.

· Unfortunately for the attacker, the common ' OR '1' = '1 payload doesn't work.

· The attacker now wants to try many other payloads, such as the following:

· ' or "

· -- or #

· ' OR '1

· ' OR 1 -- -

· " OR "" = "

· " OR 1 = 1 -- -

· ' OR '' = '

· Rather than trying this list one at a time and checking the results individually, it would be more efficient for the attacker to use a tool to try all of these payloads with a single request.

Fortunately there is a tool within Burp, called Burp Intruder, that can automate issuing multiple HTTP messages. Burp Intruder can also provide an understandable summary of the results of the different payloads.

Brute Force Attacks

We will demonstrate Burp Intruder by conducting a brute force attack against a web application's login page.

A brute force attack is defined as systematically attempting many passwords, or username/password combinations, with the hope of correctly determining the correct result to obtain access in an unauthorized area.

· Other variations of bruce force attacks can include the following:

· Credential stuffing: Using lists of usernames to conduct brute force attacks that were obtained from breaches of other websites.

· Password spraying: Using a single weak password, such as "123456", against a large list of usernames.

· Bruce force attacks also fall under the OWASP Top 10 risk of broken authentication, as the attacker aims to bypass an application's method to securely authenticate a user.

We will now demonstrate how, with the Burp Intruder feature, we can launch a brute force attack and easily determine which credentials were successful.

· In this upcoming demonstration, we will be launching a brute force attack against the administrative section of the Replicants web application.

· To access the administrative section, a Replicants administrator has to authenticate with their username and password on a login page.

· The goal is to brute force into the administrative section of the Replicants web application without being provided any usernames or passwords.

Burp Intruder Demonstration

In this demonstration, we will continue to work in the Replicants web application.

We will conduct this demonstration by completing the following six steps:

· Access the Replicants administrator login page and enable proxy settings.

· Generate and view a login request.

· Move the HTTP request to Burp Intruder.

· Identify the payload positions.

· Update the intruder payloads.

· Launch the brute force attack, and analyze the results.

Part 1: Access the Replicants Administrator Login Page and Enable Proxy Settings

1. To access the Replicants website within Vagrant, navigate to the following page: http://192.168.13.25 .

· We will select the Brute Force option from the menu on the left side of the page.

· Alternatively, access the webpage directly here: http://192.168.13.25/vulnerabilities/brute/ .

· NOTE: If you have any issues accessing this webpage, you might need to repeat the Activity Setup steps here: GitHub: SQL Injection Activity .

· The page should look like the following image:

 

2. Recall the intended purpose of this page on the Replicants web application:

· It is designed for an administrator to log in and access the secure administrative section of the Replicants web application.

· An administrative user enters their username and password, then clicks the Login button.

· Remind the class that to use Burp, we need to enable the Burp proxy again.

· From your browser, enable the Burp option on Foxy Proxy.

· From Burp Suite, under Proxy > Intercept, confirm that Intercept is on.

· Now we're ready to capture this new HTTP login request!

Part 2: Generate and View a Login Request

3. On this login page, we will test the intended purpose of the application by entering a username and password that will purposely fail.

· Note that the purpose of this is to observe how the payloads that we enter are used in the HTTP request.

· In the username field, enter "test-user".

· In the password field, enter "test-passwd".

· Press Login.

 

· Note that after you press Login, the loading bar starts spinning, as Burp has captured this HTTP request:

 

4. We will now return to Burp Intercept to see the HTTP Request.

· Access the Burp Intercept tab, and note that the top line of the HTTP request contains the username and password that were entered:

· GET /vulnerabilities/brute/?username=test-user&password=test-passwd&Login=Login HTTP/1.1

 

· This shows how the application is intended to work. When a user inputs the username and password on the login page, those payloads get added into an HTTP request parameter to be sent to the web application.

Part 3: Move the HTTP Request to Burp Intruder

5. We will now right-click on the Intercept page and select Send to Intruder (or press CTRL+I).

 

· Note that after you select Send to Intruder, the Intruder icon color on your tool bar changes from black to orange.

· This confirms that the HTTP request has been sent to Intruder!

 

6. We will now click on the Intruder icon from the tool bar to view this HTTP request.

· Click on the Intruder option from the tool bar.

7. The Intruder feature includes four sub-pages, which we will review.

 

· Introduce the four sub-pages:

· Target: This tab indicates the host (IP address) and port against which the attack will be launched.

· Positions: This tab is used to configure the positions in which the payloads will be inserted.

· Payloads: This tab is used to select the payloads that will be inserted into the positions, with several custom configurations.

· Options: This tab contains custom options and settings to customize the attack.

· By default, the first page you will see is the Target tab, where the IP and port of the web server will be added automatically.

· Note that there is no need to change this unless you are launching your attack against a different host.

· To view the HTTP request we forwarded, we need to select the Postions tab from the tool bar.

· When you navigate to this page, it will display the same HTTP POST request that you saw under Intercept.

Part 4: Identify the Payload Positions

8. This Positions page is where you indicate the positions of the payloads that you will change with each HTTP request.

· Starting from the top of the Positions page, point to the Attack Type drop-down.

· Note that it provides four attack type options, which determine how the positions will be used with payloads:

· Sniper

· Battering Ram

· PitchFork

· Cluster Bomb

· It is outside the scope of this class to know how all of these attack types work, but we will select the Cluster Bomb attack type.

· We selected Cluster Bomb because it is the attack type for multiple payload positions, such as a username and password.

· If you want to learn about the other attack types, refer to following resource: Portswigger: Payload positions .

9. Next note that Burp attempts to figure out all of the payload positions that you would like to use.

· It indicates those by doing the following:

· Highlighting them in green.

· Using a section sign marker § to indicate the start and end position of where you want to inject each payload.

· Note that Burp predetermined five payload positions:

 

· While it can be helpful to use Burp's suggested payload positions, because we are only using the username and password, we will clear the recommended payload positions.

· Clear the payload positions by clicking Clear § on the right side of the page.

· Now that the payload are positions are clear, we will select the payload positions of username and password.

10. To select the first payload position of the username, highlight it by holding down the left button and dragging your cursor over the value of test-user.

· Then, to place the markers, select Add §.

 

· Repeat these same steps for the password: test-passwd.

? Important: Be sure to ONLY highlight test-user and test-passwd, and DO NOT include the = or &!

· Note that, when completed, the page will look like the following image, indicating that these are the two positions where we want to inject the payloads.

 

Part 5: Update the Intruder Payloads

11. Since we just indicated WHERE the payload positions will be, we are now ready to indicate WHAT the payloads are.

· Select the Payloads tab. This is where we indicate WHAT the payloads are:

 

· Find the first drop-down field, Payload set at the top of this page.

· This field refers to the position that you want to inject the payloads into, which was previously indicated on the Positions page.

· The number 1 refers to the first field (from the top left) selected on the Positions page.

· The username

· The number 2 refers to the second field (again, from the top left) selected on the Positions page.

· The password

· Reference the following image, and from the Positions page, show how the selected payload set indicates where to inject the payload:

 

12. Return to the Payloads page, point to the Payload type field. We will be using a simple list, which is just a text list of payloads.

· Note that there are many other payload types that will not be covered in this class.

Before covering how to select the payloads, remind the class that the goal for this demonstration is to determine a username/password combination to successfully log in to the administrative section of the Replicants website.

· For this demonstration, though, we will be trying just two common usernames and two passwords to illustrate how this feature works.

· Usernames: "administrator" and "admin"

· Passwords: "123456" and "password"

· EA real attacker will likely use much larger lists to find a working username/password combination

13. We will cover how to select the payloads:

· Note that because we selected simple list, the subsequent panel is configured for us to enter the payloads.

· Note that the panel will change if we select a different Payload type option.

· This is where we will enter which payloads get injected into the positions.

· We will start by selecting payload sets for the first position that we selected, the username.

· Confirm that the Payload set field is set to 1, as this is the username location.

· There are several methods to create the simple list, such as the following:

· Pasting a list.

· Loading a list from another document.

· Adding payloads one at a time to make a list.

14. Since we are only going to use two usernames and passwords, we will use the Add button.

· We will enter the first username, "administrator", then select Add.

 

· Repeat this same step for the second username, "admin", and select Add again.

· Note how the two payloads now appear in the payload box:

 

· Now to enter the two payloads for the password, we have to change the Payload set field to 2.

· Repeat the preceding steps to add the passwords "123456" and "password".

· After adding the passwords, note how the passwords payloads display:

 

· We have just configured four total payload combinations:

· Two usernames

· Two passwords

· We are ready to launch the brute force attack.

Part 6: Launch the Brute Force Attack and Analyze the Results

15. To launch the attack, select Start attack on the top right of your page.

 

· You might receive a pop-up that indicates that you are on a limited version of Burp. Select OK to bypass this alert.

· Note that after you select OK, a new page displays the results of your attack.

 

16. Note the following about the contents of the attack results page:

· The top of the page contains the 4 payload combinations.

· Note that each of them should have a HTTP response code of 200 (listed under Status), as well as the length of the HTTP response.

· Even though they all show 200, this doesn't mean that all four were successful logins. It means that you didn't get an HTTP error from the web server.

· To accurately determine which was a successful login, we have to inspect the HTTP response on the bottom of this page.

· To view the HTTP response of the first payload combination, highlight the first combination:

· Payload1: administrator

· Payload2: 123456

· On the bottom panel, change the view from Request to Response to view the HTTP response.

· While we could search the raw HTML response to check whether the login was successful, we will use a Burp feature to render the HTML.

· Directly below that Response option, change the value from Pretty to Render, which will render the HTML on the page within Burp.

· This simulates how your browser would render this HTML response.

 

· To determine whether this first payload combination worked, scroll down on the image until you see the following message: "Username and/or password incorrect."

 

· This indicates that the username/password combination of "administrator" and "1234" did not result in a successful login.

17. Let's see what a successful login looks like:

· Repeat the preceding steps and select the fourth payload:

· Payload1: admin

· Payload2: password

· Scroll down on the image until you see the webpage display the following message: "Welcome to the password protected area admin".

 

· This demonstrates that the username/password combination of "admin" and "password" is a correct combination to access the administrative section of the Replicants website.

18. Lastly, note that if an attacker uses a much larger list of usernames and passwords, it would be time-consuming to render and examine each of the HTTP responses.

· Burp Intruder has a solution for this challenge:

· Point to the length of the successful username/password combination of "administrator" and "1234", and note that the size of this HTTP response is 4590.

· Now point to the length of the three failed username/password combinations, and illustrate that those are 4552.

 

· An attacker could use this understanding of the length of the HTTP response, then sort descending by the length to easily determine which are the working combinations.

 

This demonstration illustrated how an attacker can use the Burp Intruder to test multiple payloads or payload combinations, then examine the results to determine a web application's vulnerabilities.

Real-World Challenges

Note that while the purpose of the lesson was to illustrate how the Burp Intruder feature can automate sending multiple HTTP requests with different payloads, in the real world we need to be aware of several issues not covered in this class.

· Uses of Burp Intruder

· While we used Burp Intruder to test a small list of two users and two passwords, most brute force tests would include much larger lists.

· We used the Burp Intruder to conduct a brute force attack, but Burp Intruder can be used to conduct a variety of other web application attacks that test different payloads and payload combinations, such as the following:

· SQL injection

· Cross-site scripting

Impact

· If a malicious actor can successfully launch a bruce force attack against a web application's users and gain access to users' accounts, they can do the following:

· View a user's confidential data.

· Use features that are not intended to be accessed by unauthorized users within a secure application

Mitigation Methods

We just learned that a bruce force attack is conducted by systematically attempting many user/password combinations.

· Note that developers can use several mitigation methods which developers to protect against a brute force attack:

· Require complex usernames and passwords.

· For example, require the user to include special characters, upper and lowercase, and numbers in the username and password.

· Lock out accounts after a number of failed attempts.

· For example, after three failed login attempts, the user's account gets locked.

· Use multi-factor authentication (MFA).

· For example, require users to have a password and a secondary form of authentication, like a pin generated by an external token.

· Note that it is beneficial to apply all of these forms of mitigation together.

· If you want to review OWASP's best practices on mitigating brute force attacks, refer to the following resource: OWASP: Credential Stuffing Prevention Cheat Sheet .

Brute Force Attack Summary

· The intended purpose of the original function: Web applications use usernames and password input fields to authenticate a user before they can access a secure part of a web application.

· The vulnerability and method of exploit: Without proper protections on the login page, an attacker can apply a bruce force attack to systematically test many user/password combinations to attempt to gain access to unauthorized accounts.

· The unintended consequence of the exploit: The unintended consequence is that if an attacker can determine a correct username/password combination, they can access an account that they do not have permission to access.

· The mitigation of the vulnerability: Mitigations can include requiring complex usernames and passwords, using multi-factored authentication, and enabling a lockout after a certain amount of failed login attempts.

· The potential impact of the exploit: The impact could include viewing a victim's confidential data inside the application or conducting unauthorized activities inside the application.

09. Conducting Brute Force Attacks with Burp Intruder

· Activity File: Brute Force

10. Conducting Brute Force Attacks with Burp Intruder Review

· Solution Guide: Conducting Brute Force Attacks with Burp Intruder