DAST in TryHackMe

This is a writeup for the room DAST on Tryhackme

Room Objectives using OWASP ZAP

• Learn how DAST can be applied to find weaknesses in real-world applications.
• Understand the pros and cons of using DAST instead of other techniques.
• Familiarize yourself with some of the tools used for DAST.

Task 1 [Introduction]

This Task just gives a brief walkthrough about what you are going to learn in this Room. Its better to complete at least OWASP Top 10 room before learning with this Room.

Question > No Answer Needed.

Task 2 [Dynamic Application Security Testing (DAST)]

Dynamic Application Security Testing (DAST) is the process of testing a running instance of a web application for weaknesses and vulnerabilities. It focuses on a black-box testing approach where vulnerabilities are found just like a regular attacker would find them. Simply put, DAST identifies vulnerabilities by trying to exploit them, either manually or through automated tools.

There are two ways in which DAST can be performed:

• Manual DAST: A security engineer will manually perform tests against an application to check for vulnerabilities.
• Automatic DAST: An automated tool will scan the web application for vulnerabilities.

SSDLC:-

This room also tells you about the Pros and Cons of DAST which you can find on the room itself

Most of the time, you will find DAST contextualised as a series of automated tests. In general terms, a DAST tool will perform at least the two following tasks against the target website:

• Spidering/Crawling: The tool will navigate through the web app, trying to map the application and identify a list of pages and parameters that can be attacked.
• Vulnerability Scanning: The tool will try to launch attack payloads against the identified pages and parameters. The user can typically customise the type of attacks to include only the ones relevant to the target application.

Questions/ Answers

Question > Is DAST a replacement for SAST or SCA? (Yea/Nay)

Answer :- Nay

Question > What is the process of mapping an application’s surface and parameters usually called?

Answer:- Spidering/Crawling

Question > Does DAST check the code of an application for vulnerabilities? (Yea/Nay)

Answer:- Nay

Task 3 [Spiders and Crawlers]

A Spider will navigate to a starting page you provide and fundamentally explore the website by following all the links it can detect.

To spider a website using OWASP ZAP, we can go to Tools -> Ajax Spider.

(Note:- While you first start the machine and then start OWASP ZAP, it will uninstall few plugins and then if you check you wont get the Ajax Sprider in Tools Menu. Close the OWASP ZAP session and restart a new session of OWASP ZAP to get the option in Tools Menu)

This will show us the Spider dialogue, where we only need to specify a website as our starting point. For now, we’ll leave the Context and User boxes empty. You can check the following additional options if needed:

• Recurse: Spider the website for links recursively.
• Spider Subtree Only: Limit the spidering to subfolders of the Starting Point URL.
• Show Advanced Options: Enable the Advanced tab, where you can specify additional parameters to tune your spidering.

Select the AJAX Spider from Tools menu and enter as per below format and click on “Start Scan”

After the scan, you should see all the URLs that the spider found on the Sites tab

Question/ Answers

Question > ZAP can run an AJAX spider by using browsers without a Graphical User Interface(GUI). What are these browsers called?

Answer:- Headless

Question > Analysing the Sites tab, what HTTP parameters can be passed to login.php using the POST method? (In alphabetical order and separated by commas)

Answer:- pass, user

Question > What other .php resource, besides nospiders-gallery.php was found by the AJAX spider but not by the regular spider?

Answer:- /view.php

Task 4 [Scanning for Vulnerabilities]

When running DAST tools, it is crucial to customise what types of tests will be run against the application. The more you fit your scanning profile to your web application, the less time the scanner will spend sending payloads that aren’t relevant to your specific scenario. Since DAST tools will mainly be used in a white box setup, all the details of the underlying technologies used to support your application are known.

To create or modify scanning policies in ZAP, go to Analyse -> Scan Policy Manager. The room shows step by step process on how to set up the policies which can be utilized to streamline the DAST scan as per the specific application

After configuring the Policy and running a new scan you will come up with multiple vulnerabilities like below

Question/ Answers :-

Question > Will disabling some test categories help speed up the scanning phase? (Yea/Nay)

Answer:- Yea

Question > There should be two high-risk alerts in your scan results. One is Path Traversal. What’s the name of the other one?

Answer:- Cross Site Scripting (Reflected)

Note:- The Policy created in this block will be utilised in the below blocks as well.

Task 5 [Authenticated Scans]

An important part of Automated Scans which can be configured into Pipelines are Automated scripts which can be utilized to perform the manual actions needed like Authentication which running a deep scan.

The room explains in details how to

• Record Authentication
• Create context
• Configuring the context specific to the requirement
• Rescanning the application with the above configurations

The Configuration needs Policy created in Task 4, Authentication script in Task 5, Context created in Task 5 and User created in Task 5.

After the Active scan is completed. In Alert section, below issues will be displayed

Questions/ Answers

Question > Which type of script was used to record the authentication process to our site in ZAP?

Answer:- ZEST Scripts

Question > What additional high-risk vulnerability was found on the site after running the authenticated scan?

Answer:- remote OS command injection

Task 6 [Checking APIs with ZAP]

In this task, we will focus on APIs which are the current backbone of any applications.

In this task, Instead of spidering APIs, we will rely on the development team to give us a precise specification of the available endpoints in an API and all of the parameters we can send to them. This way, we don’t need to spend time on the discovery process but can focus on testing its security directly.

ZAP can import APIs defined by OpenAPI (formerly Swagger), SOAP or GraphQL.

Import OpenAPI defination in ZAP

ZAP supports two methods to import API definitions: you can provide an offline file or a URL from where to download them. Since the API exposes its definition file in machine_Ip/swagger.json, let’s use the URL option. Go to Import -> Import an OpenAPI definition from a URL. Specify the corresponding URL and hit the Import button.

You will be able to see the available links in Site option:

Do an active scan on the Sites as per below screenshot

The results will be displayed in Alert section again as per below screenshot

Question/ Answers

Question > What high-risk vulnerability was found on the /asciiart/generate endpoint?

Answer:- Remote OS Command Injection

Question > Read the details on the Path Traversal vulnerability detected. Based solely on the information presented by the scanner, would you categorise this finding as a false positive? (yea/nay)

Answer:- Yea

Note:- The reason the Path Traversal Vulnerability is False Positive is the because when you go to More Info after you double click on the Alert, it does not have any info

Now, when you copy the URL used for attack and open it in browser, it just gives a bank JSON as below and does not allow any traversal

Instead the resultant page seems similar if we change the Art_ID to random value as 1 or 2. Hence it can be considered as False Positive

Task 7 [Integrating DAST into the development pipeline]

One of the major part of Automated DAST is configuring the pipeline to run the same.

Having DAST added to your development process may sound pretty straightforward, but there are some caveats to it:

• We must decide at which stages of the development process we will run scans.
• We must decide what will trigger a scan. We can run scans on each commit made to code or on a scheduled basis.
• We must determine the intensity of each scan. Doing a full vulnerability scan on a medium-sized application will require significant time, and we don’t want to slow down the development team.

Steps to follow for the Room

1> Go the the given URLs for Gitea and Jenkins with thm/thm credentials

2> In Jenkins, go to thm -> simple-webapp -> main and click on main to see the stages

3> Go to Gitea, click on thm/simple-webapp in the repository section and open Jenkins file (Note: Click on Filename to have the edit option enabled)

4> Edit and remove the comment in the body

5> Commit changes on the main branch

6> Go to Jenkins, thm -> simple-webapp -> main and click on main to see a new stage getting added

7> The script will fail as per below screenshot

8> Click the build from left screen (cursor as per below screenshot)

9> Click on Workspace and follow the path to below sturcture

10> Open the first report in New Tab

Follow the same above mentioned steps for Simple-api.

Questions/ Answers

Question> Download the ZAP report for the simple-webapp repository. How many medium-risk vulnerabilities were found?

Answer> 3

Question> Check the main branch of the simple-api repository on Jenkins. One of the builds failed during the Build the Docker image step. What is the number of the pre-existing failed build?

Answer> 4

Reason:- You can see in above screenshot that 4th build has failed

Question> Download the ZAP report for the simple-api repository. What high-risk vulnerability was found?

Answer> Remote OS Command Injection

Task 8 [Conclusion]

Question> No Answers needed