How our milion dollar system got hacked by a bunch of high schoolers

Have you ever seen those movies where a figure cloaked in a black hoodie and sunglasses, surrounded by a six-monitor array displaying cascading green characters, swiftly types at a rate of 600 words per minute and casually utters, "I'm in"?

Well, that scenario didn't precisely unfold, but something even more embarrassing took place. You see, our team has been diligently developing a system for years now, only to have it breached by a group of high schoolers this week. The details are intricate, but it's a rather amusing tale with a fortunately positive outcome.

Before diving in, I believe a bit of context is necessary to truly grasp the intricacies of the narrative. However, I'm unsure about the extent to which I can openly discuss the products I assist in developing in real life. While I haven't signed any formal NDA, there could be other guidelines in place to safeguard our clients and other pertinent information. Therefore, I'll aim to avoid naming or describing anything overly specific.

So let's put it this way: One of our products incorporates touchscreen technology and features an application akin to virtual noticeboards, which have gained popularity in recent years. Among its various functionalities, we enable our clients to integrate their own website (or any whitelisted website) into this application, should they choose to do so.

Now, here's the kicker: We don't have complete control over what our clients display on their screens. While we offer guidelines for best practices, ultimately, clients have the freedom to feature platforms like Facebook or YouTube on their noticeboards if they desire.

You might ask: Isn't that risky? Well, yes, it can be. That's why we implement domain whitelisting, ensuring users can only access approved websites and why we block certain web page elements.

Typically, we also block modal windows and system dialogs such as "open file" or "save file" prompts. However, an unexpected glitch occurred. It could have been due to a library update, system upgrade, or changes in the embedded browser component we utilize. The bottom line is, one of the dialogs ceased to be blocked: the print dialog used for printing web pages.

Even though our embedded browser lacks traditional toolbars or menus, some websites include their own print links in headers or footers, reminiscent of a bygone era.

To our dismay, the students stumbled upon one such page whitelisted in our system. Clicking the print link opened the unblocked print window in the version of the system they were using.

You might think: How bad could that be? In reality, it's catastrophic. By reaching this point, they effectively breached the boundaries of our application's sandbox, potentially unleashing chaos.

And chaos they unleashed.

In most modern printing dialogs, there's typically a shortcut to print to a file, often a PDF. And what happens when you click on that? You guessed it—a file explorer dialog pops up, allowing you to choose the destination file.

Initially, the students clicked on a random folder they had permissions to access and selected "Open in file explorer" or a similar option. Since we use either Fedora or Ubuntu (UPDATE: apparently it is EndeavourOS, previous versions run on Ubuntu) for the front-end of our systems, which have interfaces similar to Windows, these shortcuts and context menus are quite familiar even to a casual user.

A new file explorer window opened, devoid of the modal window restrictions for file selection. That's when chaos ensued—they gained complete access to the file system.

You might wonder: Don't you have additional layers of protection for files? And permissions? Don't you utilize Docker or other sandboxing techniques to safeguard against malicious behavior? And what about kiosk mode? Well, yes, we do implement those (though I'm not privy to the specifics since it's not within my active work domain). However, despite these measures, the students now had an operational file explorer at their disposal, regardless of whatever restrictions might still be in place.

Think that's bad? Just wait until you hear what they did next. They discovered the file explorer had a system menu. And within the "File" option, there was a prompt to open the terminal...

And so they did precisely that. They launched a Unix terminal window and began experimenting with commands like a child eagerly unwrapping presents on Christmas morning. They attempted apt-get, pacman, dpkg, and perhaps other package management tools, hoping to install whatever they desired. When they correctly identified the program we employ, they hit a roadblock—they didn't know the root account password, leaving them stranded.

Growing frustrated, they resorted to trolling by executing curl parrot.live, a command none of my team members were even aware of. But hey, every day brings new knowledge, so now we know how to display a moving ASCII art of a dancing parrot in a Linux console window.

The students persisted in their attempts to "hack" the system for several days, consistently starting from the printing file dialog.

They soon realized that there wasn't a standard internet browser installed on the system, and they were determined to have one. However, lacking the root password, they couldn't install it conventionally. So, they devised an alternative plan. They managed to procure a portable version of Google Chrome for Linux, most likely through curl, wget, or scp, which didn't necessitate additional permissions. And that's what they aimed to use.

Here's an amusing part: They weren't sure how to execute the script to launch the browser. They knew they needed to chmod it to make it executable, but they were stumped on how to proceed from there. They attempted to double-click the file in the file explorer, perhaps inadvertently opening it for editing or achieving nothing at all.

Ordinarily, one could simply open the terminal and run ./something.sh, but it seemed they were unaware of this option, which is quite ironic considering their prior exploits.

Yet, they were nothing if not resourceful, and they found a remarkably unconventional solution to their predicament.

You see, they discovered that the file explorer offered a prompt to edit system shortcuts. Realizing the potential, they created a shortcut to execute any selected script file. After creating the shortcut, they selected the file and used the virtual keyboard on the screen to trigger the shortcut. Voilà! They had their own internet browser, free from any restrictions or whitelisting rules.

Afterward, they proudly displayed whichever webpages they desired on the screen, likely boasting to their schoolmates. They even made an attempt to send themselves an archive containing some of the system files they had accessed, perhaps in an effort to study our system or further their hacking endeavors. However, their efforts were in vain as we were already aware of their actions. One of my colleagues cleverly filled the archive with gibberish, effectively trolling the students in return (though I briefly entertained the idea of using a trollface instead, but alas, it was too late for that).

Anyway, this is where the tale concludes. We were alerted to the situation by school staff members who informed us of everything that had transpired. Swiftly, we patched the security hole by disabling the print dialog and monitored the kiosk for a while through a VNC connection.

Despite their persistence, the students struggled to find another entry point into the file system. Though they made valiant attempts, their endeavors ultimately proved fruitless, and they eventually relented.

As a small Easter egg, we inserted a 5-second slide into the playlist area of the kiosk, displaying a message (in Czech) along with a gif from parrot.live:

Thank you for testing our system!
Team F. wishes you successful hacking in the future.