Dvws-Node Pentest Report

Confidentiality Statement

This penetration testing report is intended for educational purposes only and should not be used for any malicious activities. The information contained within should not be interpreted as a guide for exploiting vulnerabilities.

It is an exclusive property of bL34cHig0 and BleachSec (BLS). Duplication, redistribution, or use, in whole or in part, in any form requires consent of bL34cHig0.

Disclaimer

A penetration test is considered a snapshot in time. The findings and recommendations reflect the information gathered during the assessment and not any changes or modifications made outside of that period.

Time-limited engagements do not allow for a full evaluation of all security controls. BLS prioritized the assessment to identify the weakest security controls an attacker would exploit. BLS recommends conducting similar assessments on an annual basis by internal or third-party assessors to ensure the continued success of the controls.

Contact Information

Name	Title	Contact Information
DVWS-NODE
Bob Ping	Chief Information Security Officer	bping@dvws-node.com
BleachSec
Ichigo	Lead Penetration Tester	ichigo@bleach-sec.com

Finding Severity Ratings

The following table defines levels of severity and corresponding CVSS score range that are used throughout the document to assess vulnerability and risk impact.

Severity	CVSS V3 Score Range	Definition
Critical	9.0-10.0	Exploitation is straightforward and usually results in system-level compromise. It is advised to form a plan of action and patch immediately.
High	7.0-8.9	Exploitation is more difficult but could cause elevated privileges and potentially a loss of data or downtime. It is advised to form a plan of action and patch as soon as possible.
Moderate	4.0-6.9	Vulnerabilities exist but are not exploitable or require extra steps such as chaining attacks. It is advised to form a plan of action and patch after high-priority issues have been resolved.
Low	0.1-3.9	Vulnerabilities are non-exploitable but would reduce an organization’s attack surface. It is advised to form a plan of action and patch during the next maintenance window.
Informational	N/A	No vulnerability exists. Additional information is provided regarding items noticed during testing, strong controls, and additional documentation.

Executive Summary

Dvws-Node approached BleachSec to conduct an Application Penetration Assessment against their external facing web application architecture. The intent of an application assessment is to dynamically identify and assess the impact of potential security vulnerabilities within the application. During this assessment, both manual and automated testing tools and techniques were employed to discover and exploit possible vulnerabilities.

All testing activities were conducted against the dvws local environment to limit the impact of any service disruptions. Assessment of the dvws local application began on June 1st and concluded on June 9th, 2024.

Testing was conducted from both an unauthenticated and authenticated context. Unauthenticated testing examines the exterior security posture of an application and looks for vulnerabilities that do not require authentication to exploit, while authenticated tests focus on discovering and exploiting vulnerabilities on portions of the internal application that are only accessible after successful authentication.

BleachSec penetration testers were able to identify and exploit instances of the following vulnerabilities:

Finding	Severity	Recommendation
WPT-01: Improper Assets Management	Critical	Inventory all API hosts and document important aspects of each one of them, focusing on the API environment (e.g., production, staging, test, development) , who should have network access to the host (e.g., public, internal, partners) and the API version.
WPT-02: Excessive Data Exposure	Critical	Never rely on the client side to filter sensitive data and implement a schema-based response validation mechanism as an extra layer of security
WPT-03: Broken Function Level Authorization	Critical	Use the authorization mechanism to check if the logged-in user has access to perform the requested action on the record in every function that uses an input from the client to access a record in the database.
WPT-04: Path Traversal	Critical	Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications.
WPT-05: Weak JWT Secret Key	Critical	Use an encryption scheme that is currently considered to be strong by experts in the field. i.e HS512, RS512
WPT-06: Mass Assignment	High	If possible, avoid using functions that automatically bind a client’s input into code variables or internal objects.
WPT-07: Authentication Bypass	High	Use an authentication framework or library such as the OWASP ESAPI Authentication feature and implement proper user authentication.
WPT-08: Broken Object Level Authorization (BOLA)	High	Implement a proper authorization mechanism that relies on the user policies and hierarchy.
WPT-09: Weak Password Requirements	High	Implement a password policy that enforce a minimum and maximum length, requires complex passwords with mixed character sets (alpha, numeric, special, mixed case) and password expiration.
WPT-10: Insufficient Entropy	High	Determine the necessary entropy to adequately provide for randomness and predictability. This can be achieved by increasing the number of bits of objects such as keys and seeds.
WPT-11: Security Misconfiguration	High	Ensure that all API communications from the client to the API server and any downstream/upstream components happen over an encrypted communication channel (TLS), regardless of whether it is an internal or public-facing API.
WPT-12: Improper Restriction of Excessive Authentication Attempts	High	Implement common protection mechanisms such rate limiting security header, disconnecting the user after a small number of failed attempts, locking out a targeted account, etc.
WPT-13: Observable Response Discrepancy	Moderate	Ensure that error messages only contain minimal details that are useful to the intended audience and no one else.

Technical Findings

Web Application Penetration Testing Findings

Finding WPT-01: Improper Assets Management (Critical)

Description

During the penetration testing of the application, an unsupported version of an API endpoint was discovered, indicating improper assets management. The endpoint, GET /api/v1/info, was not identifiable through standard browsing of the application. Instead, it was discovered in the API documentation, which itself was initially uncovered using a directory brute-forcing tool.

Impact

The discovery of this hidden endpoint highlights a critical issue because it is accessible without authentication and exposes sensitive information such as the application server OS, tech stack and versions, and database credentials and version.

Evidence

Tools used:	gobuster, web browser, burp repeater
Command(s):	gobuster dir -u http://dvws.local -w /usr/share/wordlists/seclists/SecLists-master /Discovery/Web-Content/api/api-endpoints.txt
Endpoint(s):	http://dvws.local/api-docs/, http://dvws.local/api/v1/info
References:	OWASP, OpenAPIs

Remediation

• Inventory integrated services and document important aspects such as their role in the system, what data is exchanged (data flow), and its sensitivity.
• Document all aspects of your API such as authentication, errors, redirects, rate limiting, cross-origin resource sharing (CORS) policy and endpoints, including their parameters, requests, and responses.
• Make API documentation available to those authorized to use the API.
• Use external protection measures such as API security firewalls for all exposed versions of your APIs, not just for the current production version.
• When newer versions of APIs include security improvements, perform risk analysis to make the decision of the mitigation actions required for the older version: for example, whether it is possible to backport the improvements without breaking API compatibility or you need to take the older version out quickly and force all clients to move to the latest version.

Finding WPT-02: Excessive Data Exposure (Critical)

Description

BLS discovered an excessive data exposure vulnerability across the registration, login, and info endpoints. This vulnerability results in the disclosure of sensitive information, such as password hashes, details of the tech stack, and database credentials, within the HTTP responses.

Impact

The disclosure of password hashes, tech stack details, etc, can lead to severe security breaches, as attackers can use this information to compromise user accounts and exploit system vulnerabilities.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/users , POST /api/v2/login, GET /api/v1/info
Referer(s):	http://dvws.local, http://dvws.local/admin.html
References:	OWASP, CWE-497

Remediation

• Classify sensitive and personally identifiable information (PII) that your application stores and works with, reviewing all API calls returning such information to see if these responses pose a security issue.
• Implement a schema-based response validation mechanism as an extra layer of security. As part of this mechanism define and enforce data returned by all API methods, including errors.
• Production applications should never use methods that generate internal details such as stack traces and error messages unless that information is directly committed to a log that is not viewable by the end user.
• Review the responses from the API to make sure they contain only legitimate data.

Finding WPT-03: Broken Function Level Authorization (Critical)

Description

BLS identified a critical security vulnerability related to Broken Function Level Authorization (BFLA). Testing revealed that a user could delete another user’s notes using their authentication token. This indicates insufficient authorization checks in the application, allowing users to perform actions beyond their granted permissions.

Impact

Attackers can perform unauthorized actions for any arbitrary user in the database. For proof of concept, the penetration testing team created two different users; User A and User B. They attempted to delete notes belonging to user A using user B’s authentication token.

The requests were crafted to target user A’s notes deletion endpoint and the notes belonging to user A were successfully deleted by user B, demonstrating a lack of proper authorization controls.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/notes, DELETE /api/v2/notes/Note
Referer(s):	http://dvws.local/notes.html
References:	OWASP, Access Control

Remediation

• The application should have a consistent and easy-to-analyze authorization module that is invoked from all your business functions
• The enforcement mechanism(s) should deny all access by default, requiring explicit grants to specific roles for access to every function.
• Review your API endpoints against function level authorization flaws, while keeping in mind the business logic of the application and groups hierarchy.

Finding WPT-04: Path Traversal (Critical)

Description

The penetration testing team discovered a path traversal vulnerability within the file upload and download functionality of the storage area, which allowed arbitrary reading of sensitive files on the server due to the filename parameter not being sanitized.

Impact

Adversaries can gain unauthorized access to sensitive files on the server, potentially exposing confidential information, system configurations, and user data. Testing the upload functionality showed that only xml files are accepted while the download functionality displays the content of the uploaded xml file on the web page.

Therefore, a path traversal payload was submitted in the download textbox, and the contents of sensitive local files (e.g., /etc/passwd, /etc/shadow) on the server were successfully retrieved on the webpage.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	GET /api/upload, POST /api/download
Referer(s):	http://dvws.local/upload.html
References:	CWE-35, CWE-23

Remediation

• When performing input validation, consider all potentially relevant properties, including length, type of input, the full range of acceptable values, missing or extra inputs, syntax, consistency across related fields, and conformance to business rules. As an example of business rule logic, “boat” may be syntactically valid because it only contains alphanumeric characters, but it is not valid if the input is only expected to contain colors such as “red” or “blue.”
• When validating filenames, use stringent allowlists that limit the character set to be used. If feasible, only allow a single “.” character in the filename to avoid weaknesses such as CWE-23, and exclude directory separators such as “/” to avoid CWE-36. Use a list of allowable file extensions, which will help to avoid CWE-434.

Finding WPT-05: Weak JWT Secret Key (Critical)

Description

BLS identified a critical vulnerability related to the use of weak JWT (JSON Web Token) secret key in the application. This weakness compromises the integrity and security of the authentication mechanism, allowing attackers to forge valid JWTs to gain unauthorized access and escalate privileges.

Impact

With this vulnerability, attackers can easily crack the tokens using brute-forcing tools to obtain the secret key. The penetration testing team retrieved the secret key with jwt_tool (a cracking tool) due to weak randomization and generation.

As a result, custom JWTs were signed with the cracked secret key using jwt.io, and the JWT payload was modified to assign admin privileges to a non-admin user. The signed token granted access to the admin area, demonstrating unauthorized access and privilege escalation.

Evidence

Tools used:	jwt_tool, jwt.io, burp repeater
Command(s):	jwt_tool -C -d /usr/share/wordlists/rockyou.txt
Endpoint(s):	GET /api/v2/users/checkadmin
References:	CWE-326, OWASP

Remediation

• Use a secure and up to date library to handle JWTs.
• Ensure that the signature is valid, and that it is using the expected algorithm.
• Use a strong HMAC key or a unique private key to sign them.
• Ensure that there is no sensitive information exposed in the payload.
• Ensure the secret key is of adequate length (at least 256 bits) to provide sufficient security.

Finding WPT-06: Mass Assignment (High)

Description

A mass assignment vulnerability was discovered in the user registration endpoint. This vulnerability allows attackers to exploit sensitive and undocumented parameters to perform unauthorized privilege escalation.

Impact

Adversaries can exploit this vulnerability to elevate privileges and perform unauthorized actions (i.e CRUD) on the application. The penetration testing team discovered 3 sensitive and undocumented parameters (admin, _id, __v) in the response header of the user registration endpoint.

By including the “admin” parameter during user registration, it was possible to assign administrative privileges to a newly registered user. The addition of the “admin” parameter granted the user full access to the Admin Area to perform administrative tasks such as viewing and validating if a user exists in the database as well as viewing user tokens.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/users , POST /api/v2/login
Referer(s):	http://dvws.local/home.html#{username}
References:	OWASP, CWE-915

Remediation

• Whitelist only the properties that should be updated by the client.
• Use built-in features to blacklist properties that should not be accessed by clients.
• If applicable, explicitly define and enforce schemas for the input data payloads.
• Refactor the code so that object attributes or fields do not need to be dynamically identified, and only expose getter/setter functionality for the intended attributes.

Finding WPT-07: Authentication Bypass (High)

Description

The penetration testing team identified a critical authentication bypass vulnerability in both the user registration and login endpoints. This flaw allows users to gain unauthorized access to the application without providing any credentials.

Impact

Attackers can gain access to the application by bypassing the authentication mechanism with just a click on the register and login button.

BLS discovered that when a username and/or password is not supplied during registration or login, the application automatically assigns the keyword “undefined” as the username and/or password, and provides access to the application.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/users, POST /api/v2/login
Referer(s):	http://dvws.local
References:	CWE-305, CWE-287, CWE-1390

Remediation

• Conduct a detailed review of the authentication mechanism to ensure robust input validation and authentication checks are in place.
• Implement checks to reject any registration or login attempts that do not include valid credentials.
• Prevent the application from assigning default values like “undefined” to missing credentials.

Finding WPT-08: Broken Object Level Authorization (High)

Description

BLS discovered a Broken Object Level Authorization (BOLA) vulnerability within the registration and note search endpoints. This vulnerability allows users to access other users’ resources using their own token.

Impact

Any authenticated user with a valid token can access notes belonging to other users as well as resources they are not authorized to access because the application fails to enforce proper object-level authorization checks. Therefore, this compromises data privacy and security.

The penetration testing team was able to successfully dump out all users in the database by using an authenticated user’s token and manipulating the HTTP method at the registration endpoint (from POST to GET). At the same time user A’s notes can be accessed with user B’s token.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/users, POST /api/v2/notesearch
Referer(s):	http://dvws.local/, http://dvws.local/search.html
References:	CWE-639, OWASP

Remediation

• For each and every data access, ensure that the user has sufficient privilege to access the record that is being requested.
• Make sure that the key that is used in the lookup of a specific user’s record is not controllable externally by the user or that any tampering can be detected.

Finding WPT-09: Weak Password Requirements (High)

Description

Dvws failed to implement a robust password policy that enforces a minimum and maximum password length, requires complex passwords with mixed character sets, and password expiration.

Users can create passwords as short as 1 or 2 characters during account registration.

Impact

Lack of robust password policy allows users to create easily guessable and insecure passwords. At the same time, weak passwords are more susceptible to brute force and dictionary attacks, which can lead to account take over or compromise.

Evidence

Tools used:	web browser, burp repeater
Endpoint(s):	POST /api/v2/users
Referer(s):	http://dvws.local/
References:	CWE-521, OWASP, INT07:2023

Remediation

• Enforce a minimum and maximum length, complex passwords requiring mixed character sets (alpha, numeric, special, mixed case).
• Implement restrictions against password reuse, common passwords, contextual string in the password (e.g., user id, app name).
• Consider a second authentication factor beyond the password, which prevents the password from being a single point of failure.
• Consider implementing a password complexity meter to inform users when a chosen password meets the required attributes.

Finding WPT-10: Insufficient Entropy (High)

Description

An insufficient entropy in the generation of authentication tokens was identified during the engagement. This weakness compromises the security of the application by making tokens predictable and susceptible to attacks.

Impact

Due to the lack of sufficient randomness, the generated tokens are predictable and can be guessed by attackers (the last 3 character position in each of the 341 analyzed tokens are poorly randomized). It also increases the risk of session hijacking, where attackers can impersonate legitimate users.

Evidence

Tools used:	burp sequencer
Endpoint(s):	N/A
Referer(s):	N/A
References:	CWE-331, CSPRNG

Remediation

• Use a cryptographically secure random number generator (CSPRNG) to generate tokens with high entropy.

Finding WPT-11: Security Misconfiguration (High)

Description

BLS identified several security misconfigurations that exposes sensitive information and increases the application’s attack surface. These misconfigurations include verbose error messages, hosting the web service on an insecure port (port 80), missing TLS, and the disclosure of sensitive information through specific API responses.

Impact

The check admin endpoint reveals verbose error messages that provides attackers detailed information about the parameter used to set privileges for users. Hosting the web service on port 80 exposes the application to MITM attacks, where attackers can intercept and manipulate data transmitted between the client and server.

Lastly, the web server leaks information about the technology stack used on the server-side across all HTTP response headers via X-Powered By, and the registration endpoint returns users’ hashed password in the response header.

Evidence

Tools used:	burp repeater, web browser
Endpoint(s):	POST /api/v2/users, POST /api/v2/users/checkadmin
Referer(s):	http://dvws.local/, http://dvws.local/passphrasegen.html
References:	CWE-209, OWASP

Remediation

• Ensure that error messages only contain minimal details that are useful to the intended audience and no one else. The messages need to strike the balance between being too cryptic (which can confuse users) or being too detailed (which may reveal more than intended).
• Transition the web service from port 80 to port 443 to enforce HTTPS, ensuring encrypted communication between the client and server.
• Implement strict transport security measures such as HTTP Strict Transport Security (HSTS) to prevent downgrading attacks.
• Use naming conventions and strong types to make it easier to spot when sensitive data is being used. When creating structures, objects, or other complex entities, separate the sensitive and non-sensitive data as much as possible.

Finding WPT-12: Improper Restriction of Excessive Authentication Attempts (High)

Description

Dvws failed to implement security headers such as rate limiting on the login endpoint. The absence of this security header enabled successful brute-forcing of user accounts, posing a significant risk to the application’s security.

Impact

Attackers can repeatedly attempt different password combinations until gaining unauthorized access.

Evidence

Tools used:	burp intruder, ffuf
Endpoint(s):	POST /api/v2/login
Command(s):	ffuf -request request.txt -request-proto http -mode clusterbomb -w users.txt:USERFUZZ -w pass.txt:PASSFUZZ -mc 200
References:	CWE-307, OWASP

Remediation

• Implement a limit on how often a client can interact with the API within a defined timeframe (rate limiting).
• Rate limiting should be fine-tuned based on the business needs. Some API Endpoints might require stricter policies.
• Limit/throttle how many times or how often a single API client/user can execute a single operation (e.g. validate an OTP, or request password recovery without visiting the one-time URL).
• Disconnect the user after a small number of failed attempts
• Implement a timeout
• Lock out a targeted account
• Require a computational task on the user’s part.

Finding WPT-13: Observable Response Discrepancy (Moderate)

Description

BLS discovered an observable response discrepancy vulnerability in the registration endpoint. This vulnerability allows attackers to perform user enumeration attacks by confirming the existence of usernames.

Impact

By observing the responses from the registration API, attackers can infer the existence of usernames based on subtle differences in error messages. Combining this with brute-force attacks enables attackers to systematically guess passwords for existing usernames, leading to unauthorized access to user accounts.

Evidence

Tools used:	burp repeater, web browser
Endpoint(s):	POST /api/v2/users
Referer(s):	http://dvws.local/
References:	CWE-204, OWASP

Remediation

• Avoid inconsistent messaging that might accidentally tip off an attacker about internal state, such as whether a user account exists or not.
• Ensure default system accounts and test accounts are deleted prior to releasing the system into production (or exposing it to an untrusted network).

Credit

Shoutout to TCM Security and PurpleSec for making their report templates free and accessible to use. As well as to Sam Sanoop for creating an awesome web/api lab for testing and practice.