← back

Reverse Engineering a "Secure" Exam Browser

i sure love RCE'ing myself


Introduction

Recently, I was invited to take a online coding assessment, which required installing an exam browser to lock down your system.

Pretty understandable, considering the rampant cheating going on lately, so I completely support the idea, however...

Unpacking

I prefer to audit any random software I run on my PC, especially if its main goal is something that could be considered "malicious". Let's unpack the browser to see what it's doing.

DoSelect app directory structure
DoSelect app directory structure

Seems to be a fairly standard electron app, so should be easy to unpack and examine.

	cd C:\Users\User\AppData\Local\Programs\doselect-secure-browser\resources
	npx asar extract .\app.asar unpacked

After unpacking, we get this, which is... concerning.

Unpacked Electron app files
Unpacked Electron app files

First of all, they seem to have included a confidential internal company document in here. Inside the binary of a publicly available app... won't be discussing those here though.

There's also a Dockerfile and a couple of READMEs that obviously shouldn't be here, but nonetheless, nothing too interesting there.

Examining the Browser

Well, let's get onto the actual examination though. Checking the utilApps folder reveals how they're blocking keystrokes like Alt+Tab, or switching Virtual Desktops.

Hotkey Blocking scripts
Hotkey Blocking scripts

For whatever reason, they seem to have also accidentally included the AutoHotkey compiler in here, which they don't disclose, so this technically goes against the GNU GPL v2 license, but whatever.

On Windows, they use 2 compiled AutoHotkey scripts, one for disabling the hotkeys, and one that reverts the changes on exit.

AutoHotkey blocking script (looks LLM-generated...)
AutoHotkey blocking script (looks LLM-generated...)

On linux systems, they choose to use the approach of using a custom xmodmap file for blocking hotkeys, which is fine, but has the same issue of persisting in case of an app crash until a reboot. They block individual keys here though which is more extreme than blocking hotkeys.

The Real Problem

Well, the index.js looks fairly standard at first glance. It checks if you have a compatible OS, runs the hotkey disabling script depending on your OS, and then opens the browser.

Then you look closer and it's doing something that's kinda dangerous. This handler in particular:

Sinister event handler
Sinister event handler

On receiving this 'CONFIGURE' event, it executes commands from the server on your PC, remotely. This is... essentially the definition of remote code execution, and they have ZERO protections in place, nothing is verified before running.

They most likely do this so they can remotely update the commands to run without having to push an update to the browser, but wow. Here's the 4 commands I discovered during my usage by logging them:

How bad is this?

Well, it's not as bad as I made it sound, but doing it this way doesn't make it any easier to bypass their "security". In fact, you can do it pretty trivially by modifying the command handler like so, just to return the expected values:

Bypassing the "security"
Bypassing the "security"

Conclusion

What mainly irks me is the incredibly naive approach they're using, it's like they lack all concept of "secure software development" and just think "well that seems to work, whatever now".

What is gonna come of this? If I had to take a guess, at most, they'll just obfuscate their browser's code to shove the issue under the rug. And hopefully get rid of those confidential documents at least...