Electrogrid
Last updated
Last updated
We are provided with a downloadable UserLandCityPC-1.0.0.AppImage file. This is an Electron app image. We can extract the source code either by using binwalk or running the app image with the --appimage-extract option.
This gives us the app.asar file, which we can again extract using
which gives us the Electron app's source code.
At this point we can start running the Electron app, proxying the traffic through Burp Suite:
At the moment it does not load anything, but we will come back to this later.
Let's begin by taking a look at index.js.
A couple things of note here:
When the browser window is launched, the preload.js script is first run. This script has access to the Electron APIs.
The handle-links IPC event is handled by either saving the file to disk if it is a downloadable file, or using shell.openExternal to open the URL.
The shell.openExternal function is dangerous when used on untrusted user input, because it will “open the given external protocol URL in the desktop’s default manner”. This means that if shell.openExternal opens a local file using the file: protocol, it can automatically run executable files. We will come back to this later.
For now, we can look at preload.js. We see that the preload script exposes the handle-links IPC event to the renderer context through the click event handler.
This means that anytime a link is clicked, the handle-links IPC event is fired and either a file is downloaded or shell.openExternal is called.
It looks like we need to trigger an arbitrary URL link click, but we are not sure how yet. Let's now take a look at the rendered HTML.
In order to get the Electron app working properly, we must change the CSP in the above HTML, replacing 127.0.0.1 with the target server's IP. Additionally, in app.js , the BACKEND_URL also needs to be changed.
After this, the Electron app should run proper!
The app.js is minified, but at the end of the file we find the base64-encoded source map. Decoding it gives a JSON source map, from which we can recover the React source code.
In mainUIComponents/messages.js, dangerouslySetInnerHTML allows us to perform HTML injection in regular messages.
This allows us to send files for the admin to download, and a corresponding link pointing to that file using <a href="file:///opt/userland/<filename>">click me</a>.
For instance, I can spawn the Calculator app on my Mac.
Since the remote server is running Linux, we need a slightly different way of gaining code execution. Internally, shell.openExternal will use the xdg-open program to open files. This will not executable binaries, but will instead likely open them with other programs like hex editors.
However, on Ubuntu, .desktop files are executed by xdg-open, allowing us to specify an executable to be run when the .desktop file is opened. For example, here's a .desktop file that spawns a reverse shell to our IP address.
I was working on this challenge in the final few hours of the CTF and wasted a lot of time on this rabbit hole, so I thought I'd discuss it here (perhaps as a lesson learnt as both a CTF player and a challenge author).
At this point, I thought I needed to:
Send a reverse shell payload to the admin
Force a click trigger on the download link
Send a file:///opt/userland/<filename> link
Force another click trigger on the file link
This made the assumption that the exploit needed to be 0-click. I was quite strongly convinced of this because
I had tried to send a link to my IP address but did not receive a callback - but this might be because I had been trying a lot of different payloads prior to that, and the admin bot might have "died" from previous payloads at that point.
There was a very easily-bypassable filter in the server-side logic for sanitizing messages. For instance, sending onerror would result in the onerror attribute being stripped from the final message. This is bypassable using uppercase characters.
Since a 1-click exploit that requires the admin to click on both links does not require the bypass of such a filter (the filter did not sanitize <a> tags, it only made sense to me that this was introduced as another part of the challenge to create a working XSS filter evasion payload.
Most client-side web CTF challenges do not make the admin bot perform any extra interactions, and if they do, the source would be provided for the user to check - but again, this is not a "web" challenge per se.
A slight issue with performing XSS is the CSP restricts scripts to self. Since we are inserting HTML through innerHTML, script tags do not work and so we cannot simply load an uploaded file as a script.
I did, however, manage to get an XSS working locally by framing an uploaded file. Since we know that the admin bot and the API server reside in the same box, we could theoretically upload a file and use <iframe src="file:///path/to/upload/folder/exploit.html> to achieve XSS on the admin.
But since we don't know the local path of the uploaded files on the server, this is not exploitable (unless we are guess-gods).
In hindsight, that was probably too much of a logical leap and I should have thought simpler 🥲
After gaining a reverse shell, we can see that there is a Selenium server running locally as root.
From the Selenium documentation, exposing the Selenium Grid to external access is dangerous.
The Selenium Grid must be protected from external access using appropriate firewall permissions.
Failure to protect your Grid could result in one or more of the following occurring:
You provide open access to your Grid infrastructure
You allow third parties to access internal web applications and files
You allow third parties to run custom binaries
See this blog post on Detectify, which gives a good overview of how a publicly exposed Grid could be misused: Don’t Leave your Grid Wide Open.
Because of the sensitive actions that can be performed, the grid is usually only exposed to localhost. Since we now have access to the local Selenium grid, and it is being run as root, we can make use of it to escalate our privileges.
The API details can be found in Selenium's documentation. For instance, to start a new browser session:
But we can also pass in extension capabilities that change the browser-spawning behaviour.
In our case, we can specify the binary and args Chrome options to run any command as root.
In this case we gave SUID permissions to /bin/bash, allowing us to run bash -p to get a root shell.
