XSSLash – A Tale of Playing Quiplash at Work

Introduction

Quiplash – a game full of wit, banter and borderline acceptable humour… and security consultants on a lunch break.

To set the scene, the date was 19th February 2020 and the mood was cheerful in the Fidus office. Lunch had just been delivered and today was the day that Mario Kart was not going to be the first option. Our consultants quickly landed on Quiplash – a popular game created by Jackbox Games, a US based company and one I regret playing with my entire family at Christmas.

This occasion was going to be different however, as the mood changed quickly from witty answers to bypassing client-side filters.

Client Side < Server Side Filtering

For anybody not familiar with Quiplash, the game works by posing questions to users which they answer on their own device and render on all screens. The game works by designating a single host and the rest are simply normal players.

Due to the reflectiveness of answers, one of our consultants tried to be humourous and have the application play the Titanic theme song (Flute cover, obviously), something interested was noted. The application was simplying stripping out the < > tags and nothing more.

From here, the team broke out their tool of choice (we’ll use Firefox Dev Tools in this example) and began to examine what was happening and whether it was possible to complete the task of playing the theme song of choice.

From the start, a few key JS files were identified, especially the 1.74288104d01e62f051e8.js file.

 

The first thing to do here is beautify the JS so it’s easier to read as seen below.

An interesting function was identified very quickly – ‘sending message’. We set a breakpoint here to identify what was going on. We then restarted our game as normal to see if the breakpoint would be triggered.

As expected, the breakpoint was triggered as soon as we were given the chance to normally enter an answer. It was then possible to enter an answer manually in the console, rather than in the game as shown above. Once done, it was simply a matter of resuming the debugger.

The result of this? A successful XSS across all devices logged into the game, including the host, all participants and all viewers.

The Impact

Whilst it’s all fun and games making your logo rain on the screen, we wanted to dig further and see if we could create a Proof-of-Concept for something which could actually cause some harm in a real world attack. The following PoC was created to steal the session information of the party host to steal their session.

We then noticed Twitch.tv (streaming platform) had a popular section for people playing Quiplash live with their guests…. perfect. We then created own Twitch.tv channel to test our theory out and see whether we could steal popular streamer sessions.

The video below shows the outcome of the test. The box on the left shows the party host and the box on the right shows a standard user, or in this case the attacker. You will see the point in the video where the XSS silently triggers (note the empty answer box) and then at the end of the round you will see the attacker (right) reload his session with the host’s session information and hijack their session. Note how the next round continues and the original host session is invalidated and they are withdrawn from the game and only the attacker (new host) is able to continue.

 

The Good, The Bad & The Titanic

Throughout the process, we were always adamant we’d get the original plan working…. and we did (amongst other things). Here’s the video along with some random screenshots we took.

 

Disclosure

18th February 2020 – Issue Identified

19th February 2020 – Issue Reported

21st February 2020 – Response from Vendor stating they’d review the issue

<Issue fixed but no correspondence – quite a quick fix this time!)

19th March 2020 – Fidus Team Confirmed Remediation

20th March 2020 – Blog Published