Wild DevTools
Browser-based Port Scan + Puppeteer Remote Debugging
Challenge
One of our hackers stole the source code for a top-secret screenshot service. However, he wasn't able to get the flag.
He kept saying it was impossible. That made me think of you, think you can do it?
Solution
The goal was to read the flag file, which is written to disk when the server starts up.
async function main() {
const port = 8080;
const server = express();
// write flag to disk
fs.writeFileSync('/tmp/flag.txt', process.env.FLAG);
...This was essentially a "screenshotter" service that allows us to enter arbitrary URLs to be rendered by a Chromium instance.
The validateScreenshotRequest middleware makes sure that we specify a HTTP(S) URL, so the file:// protocol will not work here.
Of particular interest, however, is the way that the browser instance is launched.
A remote debugging port is exposed. This normally allows us to send commands to the browser through the DevTools protocol. In this case, however, we can see that the debugging port is randomised.
Leaking the Debugging Port
We had a range of 2000 possible ports to scan, but the browser will only live for 30 seconds before it was closed.
If we could leak the debugging port, then we could communicate with the Chromium instance to open a new page with the file:///tmp/flag URL, and read its contents.
There are many ways to do this, but my first reaction was to do it through a common XS-Leaks technique. The idea is that if the port is closed, trying to load it as a resource would yield a Connection Refused error, triggering the onerror event handler. Otherwise, the onload event handler would be fired instead on successful loading.
This was sufficient to leak the debugging port within 5-10 seconds. Once we get the port number, we need to modify our second-stage payload with the updated port number, so I wrote the port number to a port.txt file to be read by another script later on.
Reading the Response
Now that we know the port, we could fetch http://127.0.0.1:<PORT>/json/new?file:///tmp/flag.txt to tell the browser to open a new page with the file:///tmp/flag.txt URL.
The response would then contain a webSocketDebuggerUrl that allows us to send commands to the browser through a WebSocket connection.
Unfortunately, due to the same-origin policy, we can't directly read the response through the Fetch API. But by loading an iframe, the response is shown in the screenshotter service as an image. We can add the following to our script above, to load the iframe and open a second-stage exploit after 10 seconds to communicate with the WebSocket URL.
The result of the screenshotter service would look something like this. We need to interpret the result and modify our second-stage exploit before the 10 seconds is up and the browser opens it.

I used PyTesseract to perform OCR on the result and extract the WebSocket URL. Due to the quality of the image, this was only fully accurate about 1 in 5 times. The script will also update our second-stage payload with the correct port and WebSocket URL.
Getting the Flag
After we have done all that, the second-stage payload is opened. The Runtime.evaluate method is used to execute JavaScript on the file:///tmp/flag.txt page, and exfiltrate its contents.
Last updated
Was this helpful?