Hacker101 Postbook Write-up

Hacker101 has ongoing CTF challenges that help you earn private program invites on HackerOne. Once you reach 26 points you are put into the queue for private invites. This can take some time to receive, so be patient. When I completed this challenge it was more than enough to get 26 points, but I’m not entirely sure how many points each flag is anymore with the updated system. This write-up will cover the vulnerabilities, put them in context of the OWASP Top 10 and serve as an example on writing good bug reports. Rather than using the long and random CTF url, I will refer to the site as postbook.com

IDOR on postbook.com/index.php?page=view.php allows for access to private notes of all users

The web application postbook.com is affected by an Insecure Direct Object Reference (IDOR) vulnerability, enabling authenticated users to access and read the private notes of other users, including privileged accounts such as admin accounts. By manipulating the ‘id’ parameter in the URL, users can bypass proper authorization checks and gain unauthorized access to private notes.

Severity:
Medium
This vulnerability should be classified as Medium severity, given the potential unauthorized access to sensitive information and compromise of user privacy. While this vulnerability affects all users, it does not provide a way to delete or modify the note while viewing someone else’s private note making it closer to a Medium than a High.

Steps to reproduce:

1. Log in to the application using valid credentials.
2. Navigate to the “Post timeline” feature and click on a note.
3. Access the URL: postbook.com/index.php?page=view.php&id=3.
4. Observe that the note corresponding to ‘id=3’ is displayed, which belongs to a regular user.
5. Modify the URL to: postbook.com/index.php?page=view.php&id=2.
6. Note that the private note belonging to an admin account or another unauthorized user is now accessible, despite not having the necessary privilege.

Proof of concept:

User logs in and select a note from their timeline. Observe the id parameter id=3.

User changes id to any numeric value and can view private notes

Attack scenario:

1. Attacker A registers for a user account on the application.
2. Attacker A identifies the vulnerability in the “Post timeline” feature, allowing access to other users’ private notes.
3. Attacker A logs in to their account and intercepts the HTTP request sent when viewing their own private note.
4. Attacker A modifies the request’s ‘id’ parameter to target the private notes of a privileged user, such as an admin, by changing it to id=2.
5. The application fails to enforce proper authorization checks, granting Attacker A access to the admin’s private note.
6. Attacker A can now read and potentially misuse the sensitive information contained in the admin’s private note, compromising the confidentiality of the system and its users.

Impact:

This IDOR vulnerability poses a significant security risk by allowing unauthorized users to gain access to sensitive information stored in private notes. It could lead to unauthorized disclosure of confidential data, compromising the privacy and trust of affected users. Additionally, unauthorized access to privileged accounts, such as admin accounts, can result in further security breaches and potential misuse of administrative functionalities.

Remediation and mitigation:

The application should have stricter access control mechanisms to ensure the ‘id’ parameter in the URL is validated against the authenticated user’s authorized access rights. Apply role based access controls to manage user permissions for accessing private notes and implement least privileged access for roles. It is also important to use unique and unpredicatble identifiers for notes to minimize the risk of IDOR vulnerabilities. Avoid sequential or easily guessable values for the ‘id’ parameter.

Broken Access Controls results in Information Disclosure via an IDOR in postbook.com/index.php?page=view.php

*for the purposes of this report we will assume the flag for this issue to be admin credentials

The application postbook.com has Insecure Direct Object Reference (IDOR) and Broken Access Controls vulnerabilities resulting in an information disclosure. By exploiting these design flaws, an attacker can access sensitive information, including secure credentials, stored within the application. Immediate attention is required to address this high-severity security issue.

Severity:
High
This vulnerability should be classified as a High severity, given the unauthorized access to sensitive information, including secure credentials which poses a significant security risk and access and ease of exploitation.

Steps to reproduce:

1. Login to the application with valid credentials.
2. Navigate to “Post timeline” and select a note.
3. Intercept the request to view the note.
4. Modify the ‘id’ parameter in the URL to target a different note, bypassing access controls.
5. Observe that the application allows access to the note, even if it belongs to another user, including confidential information such as secure credentials.
6. Note that the post ‘id’ are sequentially numbered and can be fuzzed with no rate limiting occurring. Filter out results whose length is 1311.
7. Observe that ‘id’ 945 contains secure credentials.

Proof of concept:
Using ffuf (or your fuzzer of choice), fuzz the id value with a word list that contains numeric values to however high you prefer. While pages return as 200, the error page size is 1311.

Note that ‘id=945’ contains an Information Disclosure

Attack scenario:

An attacker with access to the application can manipulate the ‘id’ parameter in the URL, bypassing access controls and gaining unauthorized access to sensitive information. By targeting specific IDs, the attacker can retrieve confidential data, including secure credentials, leading to potential account compromises or unauthorized actions.

Impact:

The exploitation of this vulnerability poses a severe risk to the security and privacy of users. The disclosure of secure credentials can lead to unauthorized access, account compromise, or other malicious activities. The sensitivity of the exposed information raises concerns regarding confidentiality, integrity, and potentially legal implications.

Remediation and mitigation:

To address this high-severity vulnerability, the application should implement strict access controls, utilize unpredictable identifiers, and immediately remove and change any credentials stored in private notes.

Broken Access Controls Enable Unauthorized Deletion of Admin’s Secret Note in postbook.com/index.php?page=profile.php

The application postbook.com has a vulnerability that allows unauthorized users to delete any users (including admin) secret note. By manipulating the ID parameter in the delete request URL, an attacker can bypass access controls and delete sensitive information without proper authorization. This flaw is a result of insecure design and broken access controls within the application.

Severity:
High

The vulnerability allows for the unintended deletion of any user’s notes without proper access controls. This can significantly impact the application’s usability and data integrity. The straightforward nature of the attack, coupled with the lack of effective mitigations, raises concerns about potential exploitation. As all users are affected and there are no other options to prevent such deletions, the severity of this vulnerability is considered high.

Steps to reproduce:

1. Create a new note on the application.
2. Locate the option to delete the post, which triggers a GET request to postbook.com/index.php?page=delete.php&id=a87ff679a2f3e71d9181a67b7542122c.
3. Note that the id parameter in the request is an MD5 hash of the post identifier (“4”).
4. View the note by accessing postbook.com/index.php?page=view.php&id=4.
5. Modify the MD5 hash in the delete request to correspond to the desired post to be deleted (e.g., change the MD5 hash to c81e728d9d4c2f636f067f89cc14862c, which is the MD5 hash of “2”).
6. Execute the modified delete request, resulting in the unintended deletion of the target post, which in this example is an admin’s secret note previously disclosed.

Proof of concept:
Delete note function contains a simple md5 hash of the enumerable post id, and can easily be changed to any post id.

Change the id to a different MD5 hash of the id number and observe it is deleted.

To address this issue and mitigate the risk of user impersonation, the following measures should be implemented:

1. Implement proper access controls and authorization mechanisms to ensure that users can only create posts under their own account.
2. Perform robust input validation and sanitization to prevent tampering or manipulation of user-related parameters.
3. Employ secure session management techniques to verify the authenticity of user actions and prevent unauthorized post creation.
4. Regularly review and update the application’s design to adhere to secure coding practices and principles, ensuring that user actions are properly authenticated and authorized.

Attack scenario:

1. An attacker creates a new note and inspects the delete request URL.
2. The attacker modifies the ID parameter in the URL, replacing the existing hash with the hash of the admin’s secret note (e.g., c81e728d9d4c2f636f067f89cc14862c).
3. Upon submitting the modified delete request, the application fails to validate the user’s authorization and proceeds with the deletion.
4. As a result, the admin’s secret note is successfully deleted, granting unauthorized access to sensitive information.

Impact:
The identified vulnerability allows an authenticated user to delete any post on the application, including potentially sensitive content and even admin’s secret notes. This leads to unintended deletion of user data, compromising the integrity of the system and undermining the user experience. The lack of proper access controls exacerbates the impact by enabling unauthorized deletion of critical information.

Remediation and mitigation:

It is recommended to implement proper access controls to restrict users from deleting posts they do not own. Implement role-based access control to define specific permissions for different user roles, including restrictions on post deletion. Additionally, consider implementing validation checks on the delete request to ensure that users can only delete their own posts. It is crucial to avoid relying solely on obfuscated identifiers, such as the MD5 hash used in this case, as they provide limited security.

Broken Access Control Allow User Impersonation on postbook.com/index.php?page=create.php

The application on postbook.com suffers from a broken access control vulnerability, which enables unauthorized users to impersonate other users during the post creation process. By sending a POST request to the endpoint postbook.com/index.php?page=create.php with manipulated parameters, specifically altering the “user_id” value, an attacker can post content on behalf of any user in the system. This issue poses a significant risk to the integrity and authenticity of user-generated content.

Severity:
Medium
This vulnerability allows for unauthorized users to impersonate other users and post content on their behalf, the impact is limited to the integrity and autheticity of user-generated content on the platform. It does not directly expose sensitive information but still represents a significant security concern because you can post as anyone else, including admin.

Steps to reproduce:

1. Access postbook.com and navigate to the post creation page at postbook.com/index.php?page=create.php.
2. Intercept the POST request sent when creating a new post.
3. Modify the “user_id” parameter in the request body to a different user ID number.
4. Submit the manipulated request and observe that the post is successfully created under the impersonated user’s account.

Proof of concept:

Create a new post and intercept the POST request. Observe in the body that ‘user_id’ is set to 4. Change the number to any other numeric value associated with a user.

Now the post has successfully posted as another user:

Attack scenario:

1. The attacker accesses the postbook.com website.
2. The attacker navigates to the post creation page (postbook.com/index.php?page=create.php).
3. The attacker crafts a malicious POST request, including the desired content in the “body” parameter and modifies the “user_id” parameter to the ID of the target user they want to impersonate.
4. The attacker submits the POST request, which is processed by the server.
5. The server accepts the request and creates a new post associated with the manipulated user ID, falsely attributing it to the target user.
6. The malicious content is now visible on the platform, appearing as if it was authored by the impersonated user.
7. The attacker can repeat this process multiple times, posting unauthorized content on behalf of different users by manipulating the “user_id” parameter.
8. This vulnerability allows the attacker to deceive other users by posting misleading or malicious content under someone else’s identity, potentially leading to reputation damage or the spread of misinformation.

Impact:

The impact of this vulnerability is twofold. Firstly, it allows unauthorized users to post content on behalf of legitimate users, leading to potential misuse, misinformation, or fraudulent activities. Secondly, it undermines the integrity and trustworthiness of user-generated content on the platform, impacting the overall user experience and reputation of the application.

Remediation and mitigation:

In order to mitigate the vulnerability, the application should enforce proper authentication and authorization during the post creation process. This includes verifying the user making the request has the necessary privileges to create a post on behalf of another user. Additionally, implementing a secure session management mechanism that ties user actions to their authenticated session can help prevent unauthorized post creation.

Insecure ID parameter in Edit function allows for unauthorized post modification in postbook.com/index.php?page=edit.php

The application’s edit functionality is vulnerable to an insecure ID parameter, which enables unauthorized post modification. By manipulating the “id” parameter in the URL (postbook.com/index.php?page=edit.php&id=4), an attacker can change the ID value to any other numeric value, allowing them to edit posts that do not belong to them. This vulnerability extends to posts created by administrators as well, posing a significant security risk.

Severity:
Medium
The severity of this vulnerability should be Medium. While it allows unauthorized modification of posts, including those created by administrators, it does not directly result in sensitive data exposure or compromise the entire system.

Steps to reproduce:

1. Log in to the application as a regular user.
2. Visit a post’s edit page by accessing the URL pattern postbook.com/index.php?page=edit.php&id=4.
3. Observe the ability to modify the post content.
4. Change the “id” parameter in the URL to any other numeric value.
5. Notice that the post associated with the new ID is now editable, even if it belongs to another user or an administrator.

Proof of concept:
Click edit on a post and intercept the request

Change the value and now you can edit any post:

Attack scenario:

1. The attacker visits the target website and navigates to the “Edit Post” functionality.
2. The attacker identifies a specific post of interest by changing the ID parameter in the URL.
3. By manipulating the ID value, the attacker gains access to the editing functionality for the selected post.
4. The attacker makes unauthorized modifications to the post content, potentially altering its message, introducing malicious links, or defacing the post.
5. The changes made by the attacker are saved and displayed publicly on the website, affecting the post’s integrity and potentially misleading other users.
6. If the attacker targets posts created by administrators, they could potentially inject harmful content or compromise the credibility of the website.
7. The unauthorized modifications may go unnoticed for some time, leading to potential reputational damage and loss of user trust in the affected website.

Impact:

This vulnerability allows unauthorized users to modify posts that do not belong to them, including those created by administrators. An attacker can leverage this flaw to manipulate content, introduce malicious or misleading information, or disrupt the integrity of the application’s data. It undermines the intended access controls and compromises the overall confidentiality and integrity of the system.

Remediation and mitigation:

The application should enforce proper access controls to ensure that only authorized users can edit posts. Access control checks should be performed to validate the user’s permissions and verify their association with the post being edited.

Insufficient Session Management Allows Unauthorized Access on postbook.com

The application postbook.com suffers from an insufficient session management vulnerability, which allows unauthorized access to user accounts. The vulnerability lies in the cookie mechanism used for session management. The cookie value is an MD5 hash of the user ID, which can be easily enumerated due to sequential numbers. By modifying the “id” parameter in the cookie to a valid MD5 hash associated with another user account, an attacker can gain unauthorized access and impersonate that user. Notably, switching the cookie “id” value to the MD5 hash of “1” (c4ca4238a0b923820dcc509a6f75849b) allows the attacker access to the admin account.

Severity:
Critical
Considering the ease of exploitation and the potential impact of gaining unauthorized administrative access, this vulnerability should be categorized as critical. The ability to impersonate admin accounts can lead to significant harm, including unauthorized system modifications, data breaches, and other malicious activities.

Steps to reproduce

1. Visit postbook.com and log in as a regular user.
2. Intercept the response and locate the session cookie named “id”.
3. Modify the value of the “id” cookie to the MD5 hash of another user’s ID.
4. Refresh the page or navigate to another area of the site.
5. The application will now treat the attacker as the user associated with the modified “id” cookie, granting unauthorized access to the account.

Proof of concept:
Log in as a regular user and intercept the request

Change the Cookie: id= to the md5 hash of 1 and observe you are now admin

Attack scenario:

1. Identify a target user account by enumerating the sequential MD5 hash values associated with the user IDs.
2. Obtain the MD5 hash value for the target user account (e.g., c4ca4238a0b923820dcc509a6f75849b for admin).
3. Modify the value of the “Cookie” header in the HTTP request to set the user ID to the MD5 hash value of the target account.
4. Send the crafted request to the vulnerable endpoint (postbook.com/index.php) to initiate the login process.
5. The application will treat the modified “Cookie” value as valid authentication and log you in as the target user (admin in this case).
6. Gain unauthorized access to the administrative functionality and perform actions with elevated privileges.

Impact:

This vulnerability allows attackers to bypass proper authentication mechanisms and gain unauthorized access to user accounts, including privileged admin accounts. By exploiting this issue, an attacker can potentially perform various malicious activities, such as accessing sensitive user information, modifying account details, performing actions on behalf of the user, or even tampering with the system’s overall functionality.

Remediation and mitigation:

To mitigate the identified vulnerability, it is crucial to address the insecure session management practices within the application. The current implementation, where the cookie value is an easily enumerable and predictable MD5 hash of the user ID, poses a significant risk of unauthorized access. To remediate this issue, the application should implement strong session management controls.

Lack of secure password policy and rate limiting allows for Brute-Force Attacks

The application postbook.com suffers from a critical vulnerability due to a lack of secure password policy enforcement and the absence of rate limiting measures. Specifically, the user with the username “user” has a weak password set as “password,” making it highly vulnerable to brute-force attacks. Furthermore, there are no rate limit protections in place, allowing an unlimited number of login attempts. This combination of weaknesses creates a significant risk of unauthorized access to user accounts.

Severity:
High
The lack of a secure password policy and absence of rate limiting significantly increase the risk of unauthorized access to user accounts. The absence of rate limit protections allows attackers to launch automated tools or scripts for unlimited login attempts, further facilitating the compromise of user accounts. Weak password policies and the lack of rate limiting are common vulnerabilities that attackers frequently exploit, making them critical security concerns.

Steps to reproduce:

1. Visit the target website in your browser.
2. In Burp Suite, go to the “Proxy” tab and locate the intercepted login request in the “HTTP history” section.
3. Right-click on the login request and select “Send to Intruder” to open the Intruder module.
4. In the Intruder module, go to the “Positions” tab. Identify the username and password fields in the request and mark them as “Attack” positions.
5. Go to the “Payloads” tab. For the username field, set up a payload list containing a variety of usernames, including “User.” For the password field, create a payload list with common passwords or a dictionary of potential passwords.
6. Configure the “Attack type” to “Cluster bomb” or “Pitchfork,” depending on whether you want to perform username-password combinations or sequential attacks.
7. Go to the “Options” tab and set the desired number of concurrent connections and any other desired options.
8. Start the attack by clicking on the “Start attack” button in the Intruder module.
9. Burp will automatically send the modified requests with different combinations of usernames and passwords to the target server.

Proof of concept:

Brute-force the password for ‘user’ using rockyou.txt or another wordlist. Observe the password ‘password’ is successful. Log in as ‘user’.

Attack scenario:

1. An attacker identifies the target user account with the username “user.”
2. The attacker utilizes automated tools or scripts to initiate a brute-force attack on the login page of the application.
3. The attacker systematically submits various password combinations, starting with commonly used or easily guessable passwords such as “password.”
4. Since there are no rate limit protections, the attacker can make an unlimited number of login attempts without any delays or restrictions.
5. The attacker continues the brute-force attack until successfully guessing the weak password of “password.”
6. With the correct credentials, the attacker gains unauthorized access to the “user” account and can exploit the associated privileges and sensitive information.

Impact:

The impact of this vulnerability is significant as it allows an attacker to perform automated brute force attacks on user accounts. By exploiting the lack of a secure password policy and absence of rate limiting, an attacker can systematically attempt various username-password combinations without restrictions. This exposes user accounts to a high risk of unauthorized access.

Remediation and mitigations:

It is crucial to enforce a strong password policy that requires users to create complex and unique passwords. This policy should include minimum length requirements, a combination of alphanumeric and special characters, and restrictions on commonly used passwords. Additionally, implementing rate limiting mechanisms is essential to prevent brute force attacks. By limiting the number of login attempts within a specific time frame, the risk of successful brute force attacks can be significantly reduced.