Passman walkthrough - Cyber Apocalypse 2023

Last update: April 19, 2023

1 Introduction
2 Mapping the application via interaction
3 Vulnerability analysis
- 3.1 Broken access control
- 3.2 Username enumeration
4 Exploitation
5 Conclusion

→ 1 Introduction

I previously wrote about participating in the Hack The Box Cyber Apocalypse 2023 CTF (Capture the Flag) competition.

This walkthrough covers the Passman challenge in the Web category, which was rated as having an ‘easy’ difficulty. This challenge is a white box web application assessment, as the application source code was downloadable, including build scripts for building and deploying the application locally as a Docker container.

The description of the challenge is shown below.

The key techniques employed in this walkthrough are:

manual source code review
bypassing a broken authorization check
invoking a GraphQL endpoint

→ 2 Mapping the application via interaction

The target website was opened in the Burp browser, revealing an “IGMS Passman” login form and a “Create” account link.
The “Create” link was clicked, revealing a self-registration page hosted under /register
In a terminal, a UUID v4 value was generated in order to obtain a universally unique value
```
$ uuid -v4
669d146c-7e93-4ab1-8a97-58d68d0a69e3
```
The UUID v4 value was submitted as the username and password in the registration form, resulting in a dashboard being displayed. The approach of using a UUID v4 ensures the registered user will not be confused with any pre-existing user during any subsequent testing that manages to dump or enumerate users.
Logging in as the self-registered user displayed a dashboard at /dashboard
The raw HTTP request for the registration form submission was observed in Burp. The path of /graphql and the payload both seemed to indicate that GraphQL was being used:
In Burp, another GraphQL request was observed for querying phrases to be displayed on the dashboard:

→ 3 Vulnerability analysis

→ 3.1 Broken access control

In the server side source code, routes/index.js maps the /graphql route to the GraphqlSchema on line 15:
In GraphqlHelper.js, a mutationType corresponding to the registration request was observed, with the three corresponding args of email, username, and password being declared:
Similarly, a queryType corresponding to the querying of phrases was observed:
Notably, the mutationType also defines an UpdatePassword field

Moreover, the implemented authorization control on line 104 is incorrect, as it permits any valid user to update the password of any other user. This is an instance of the common weakness CWE-284: Improper Access Control. A good reference for mitigating this type of vulnerability is the OWASP Authorization Cheat Sheet.

→ 3.2 Username enumeration

In an attempt to discover a valid username, an attempt was made to register an account with a name of admin. This resulted in an error message indicating the username is already registered, which is an instance of the common weakness CWE-204: Observable Response Discrepancy. However, as CWE-204 indicates, this weakness can either be “inadvertent (bug) or intentional (design)”.¹

→ 4 Exploitation

A Burp repeater request based on the previously seen mutationType request was created but modified to invoke the UpdatePassword field in order to change the password of the admin user to an attacker controlled value. The cookie in the request was from the session of the authenticated self-registered user. This resulted in a response indicating the admin user’s password had been successfully changed.
The new admin password was used to successfully login as the admin user:
The flag was obtained by revealing the phrase plaintext on the admin user’s dashboard:

The flag was also observable in the raw HTTP request in Burp for querying the phrases:

→ 5 Conclusion

The flag was submitted and the challenge was marked as pwned

Submission of the flag marked the challenge as pwned

Footnotes

In the case of this self registration form, the weakness may be by design, depending on the underlying business requirements, which we can only hypothesize about. A potential alternative implementation would be to:
1. require a valid email address as the username
2. send a registration link to the email address if the email address is not already registered but always display a generic message. Therefore, unless the attacker controls their victim’s email address, they will not be able to confirm whether the username already exists.
  
  Also note to prevent predictable links and to reduce the risk of an attacker using another user’s link that was never visited, the registration link should contain a one time use, cryptographically pseudorandom token, such as a UUID v4, and the token should expire if it has not been used within a time frame suitable to the business context. For example, 1 day.
3. only successfully complete registration if the registration link is clicked
However, the downsides of this alternative implementation include:
1. the possibility of attackers spamming arbitrary email addresses with registration links. However, this could in turn be mitigated by rate limiting. For example, limiting the number of registration links that can be sent to a given email address per day.
2. the added complexity of an asynchronous registration process and an increased attack surface as a result. Generally in information security, the simplest secure approach is preferred.
Ultimately, like many security decisions, the downsides have to be balanced against the initial weakness. Depending on the application and context, either weakness might be preferable to the other.↩︎