signal-desktop HTML tag injection [source: barreraoro]

Here’s the story of how a casual conversation uncovered a huge security hole in one of the most reliable messaging services.

Story time

It was Thursday afternoon: we were chatting as usual and suddenly Alfredo shows us an XSS in an Argentinian government site (don’t worry, it’s been reported). He was using the Signal add-on for Chrome. Javier and I were using the desktop version, based on the insecureelectron framework. As I was reading, something caught my attention: an icon was showing next to the URL, as a “picture not found” icon.

I jumped from my chair and warned: “your XSS is triggered in signal-desktop!!”. Javier confirmed the finding and Alfredo was astounded: he couldn’t believe it. Later on, we confirmed the vuln with different people and in different platforms, such as Linux and Windows (and for sure it works in MacOS).

The critical thing here was that it didn’t required any interaction form the victim, other than simply being in the conversation. Anyone can initiate a conversation in Signal, so the attacker just needs to send a specially crafted URL to pwn the victim without further action. And it is platform independent!

We tried different kinds of HTML elements: img, form, script, object, frame, framset, iframe, sound, video (this last two where funny). They all worked, except that CSP blocked the execution of scripts, which halted in some way this attack. However, to abuse this vuln, we could:

  • crash the app with repeated and specially crafted URLs, obtaining segmentation fault/DoS (Alfredo’s app crashed several times but mine didn’t, so we couldn’t reproduce it)
  • send a crafted image in base64 format (we didn’t carry on with this)
  • send a file/phish and execute it with <iframe src=”…”></iframe>
  • have fun with <img>, <audio> and <video> 🙂

Inside iframes, everything was possible, even loading code from an SMB share!. This enables an atacker to execute remote code without caring about CSP. Juliano worked on this with Alfredo, along with trying to get a manageable segmentation fault.

Some examples

  • Show the user’s /etc/passwd content (or any other file):
  • Include and execute a remote JavaScript file (for Windows clients):
  • Load signal inside signal (this may crash):
  • Show message in an iframe:
  • Play an audio file (you’ll hear a dog bark if you have gnome desktop or derived):
  • Play a video file (you’ll see a how-to configure dual monitor if you have gnome desktop or derived):
  • Display a form, and send some data:

Note: most PoCs says “hacktheplanet” and “PWONED“, those are jokes for us 🙂

Responsibly, we contacted the Signal security team on Friday in the early afternoon. They confirmed and patched right away, publishing a new version in under 2 hours.

signal-desktop mishap

However, the patch caught my attention: it was a big regex and I was surprised how fast they wrote it. So I decided to check on the file’s history to observe since when it has been vulnerable and I found this wonderful mistake: the applied “patch” already existed, but was (accidentally?) removed in a commit on April 10th to fix an issue with linking (I guess the issue is back 😛 ). I’m still not convinced about that regex and I’m afraid someone might exploit it, specially those resourceful three-letter agencies…

For more, click here.