💪 Flex the findings

Hello readers!

Today we’ll be sharing some “modifications” that we have made on our Application Security Testing framework. The focus is on how we combine the findings found from web application Penetration Testing into simple workflows for people with little or no security background to better understand them. A simple product will be used to explain what we have done and how it improves our testing framework.

The article will be structured into 4 different sections:

1. The simulated use case

2. Structure the findings into workflows

3. Detailed breakdown of the various workflows

4. How the approach improves the overall security awareness in DCube

The simulated use case

The story :

Good Good product team has engaged team Merlin to conduct a Web Application Penetration Testing on a new product. The new product has the below features:

After 5 days of testing, team Merlin has discovered the below findings

The prefix that is used in the “S/N” refers to the severity of the finding and they’re based on the Common Vulnerability Scoring System (CVSS) framework.

With the list of findings found in the product, how can we (team Merlin) structure them into workflows that can be easily understood by the folks in DCube?

Structure the findings into workflows

Based on the test results, a total of 9 vulnerabilities were identified in the product. Next, let’s group the findings into workflows :

In total, we managed to group the findings into 4 different attack flows by leveraging on the list of vulnerabilities identified. Let’s go through the flows in detail.

Detailed breakdown of the various workflows

Flow 1: Account takeover through brute-forcing

Due to the usage of interactive error messages (I01), the portal will return a specific error message based on the below test combinations:

During the test, it was also found that :

1. No rate limiting (M02) implemented on the portal

2. Weak password policy / guessable password (M01)

With the combination of I01 and M02, it is possible to abuse the weakness to perform account enumeration (M04) to determine the list of valid user accounts.

Since the portal has implemented a weak password policy (M01) and there’s no rate limiting (M02), it is possible to perform brute forcing (H01) on the “Login” function (as shown below).

By using this workflow, any valid user will be able to successfully login into the portal with a valid username and password.

Flow 2: Account Takeover (Broken Controls)

Due to the broken security controls (H03) and design flaw of the “Change Password” feature, the portal will return specific messages based on the below combination:

Below are the analysis of the flaw:

1. The HTTP request payload only contains the current username and the new password combination

2. The server will update the record based on the username and password found in the HTTP request payload

3. The server only verifies if there’s a valid session ID in the HTTP request payload; it doesn’t check if this session ID belongs to the current user

With this flaw, any valid user can just replace the payload with any usernames that are valid in the system and a valid password. Once the payload is ready, it will be submitted to the server for processing.

Upon request completion, the password of the chosen username will be updated.

Flow 3: Client-side attack

Due to the weakness found on input field validation (M03), the portal will return a specific message based on the below combination:

Click to read about XSS Injection and CSV injection

With this flaw, any valid user can replace the booking request with a CSV injection payload in the “Full Name” field and submit it to the server processing. The outcome of performing such an exploit will:

1. trick the administrator to visit an unknown site, and/or
2. trigger a command execution via CLI

Since the portal allows administrators to download a CSV report that contains the booking details, the CSV injection payload will be generated into the CSV report.

In the event if the administrator’s document processing program has no security protection, the commands in the CSV inject payload will be executed.

Flow 4: Insecure Direct Object Reference (IDOR) / Data dump

Due to the weakness in the “View booking details” (M05), the portal will return a specific response based on the below combinations:

With this flaw, any valid user can replace the booking ID with another and enumerate till s/he gets a list of them.

Since booking details contain the “Full Name” and “Mobile Number”, this means that it is possible to use the obtained data for other usage (e.g social engineering).

How the approach improves the overall security awareness in DCube

With the above approach, team Merlin was able to achieve the following:

1. Educate the folks on the importance of secure coding

2. Creating awareness on how vulnerabilities can be exploited

3. Lower the complexity of understanding exploitation of vulnerabilities

The above is what we have gone through for the past 1+ years. Of course, we’re still constantly learning and continuously improving ourselves because #weAreAgile.

We hope that this article will help you improve on educating and spreading awareness by sharing and explaining vulnerabilities within your team!

- Merlin 💛