A Shallow Dive Into the Security of Signal

Written By Jason Minor

Introduction

My previous post was the first installment of my IT Security 101 (random) series, in which I took a look at vulnerability scoring. Today, I thought it might be fun to expand a little on the subject. I shall pick a system at random to take a closer look at its vulnerabilities.

Drum roll, please… Signal.

Signal is a private messaging application available for mobile and desktop. It offers text and voice messages, voice and video calls, and file sharing. It’s claim to fame that has made it popular with millions of users is its commitment to open-source tech, and the end-to-end encryption of private messages. Additionally, it offers temporary secure messages that can be set to self-destruct. Its secure protocols have been vetted and adopted by other commercial messaging apps.

Sounds super secure, right?

How secure is it?

Given the present topic of vulnerabilities, I will begin by reviewing its security in a historical sense from that perspective.

A search for vendor “Signal” using NIST’s NVD found 14 vulnerabilities. Given the app’s age, having been launched in 2013, this seems like a nice low number. Here is a list of the reported vulns, sorted by date in ascending order (scores in v3.x):

  • CVE-2018-9840 | CVSS v3.0: 6.1 Medium

    • A physical proximity attack allows screen locker bypass.

    • Affected versions: <2.23.2 for App on iOS

    • Requires local access.

    • Assuming fixed based on the <2.23.2, with lack of any other reference.

  • CVE-2018-10994 | CVSS v3.0: 6.8 Medium

    • A flaw in a .js library file allows XSS via a URL.

    • Affected versions: <1.10.1 for Desktop

    • URL sent via message.

    • Verified fixed by @bcrypt.

  • CVE-2018-11101 | 6.1 Medium

    • A sanitization failure allows XSS remote code execution.

    • Affected versions: <=1.10.1 for Desktop

    • Triggered through a message reply.

    • Unknown if this was fixed based on <=1.10.1 and lack of any other reference.

  • CVE-2018-14023 | CVSS v3.0: 4.0 Medium

    • Information leakage is possible (that is as specific as it gets).

    • Affected versions: < 1.15.0-beta.10 for Desktop

    • it is unclear how this is possible.

    • Assuming this is fixed based on <1.15.0, with lack of any other reference.

  • CVE-2018-16132 | 8.6 High

    • A failure to check for unreasonably large images allows memory resource exhaustion.

    • Affected versions: <2.29.0 for iOS

    • Triggered through a message.

    • Assuming this is fixed based on <2.29.0, with lack of any other reference.

  • CVE-2018-3988 | 4.7 Medium

    • A failure in cache mgmt of disappearing messages may expose private photos.

    • Affected versions: 4.24.8 for Android

    • Requires file system access.

    • Verified fixed by Talos.

  • CVE-2019-9970 | 6.5 Medium

    • An IDN homograph flaw allows a clickable link for different alphabets.

    • Affected versions: <=1.23.1 for Desktop and <=4.35.3 for the App on Android

    • URL sent via a message.

    • Verified fixed by Blaze Information Security.

  • CVE-2019-17191 | 7.5 High

    • A caller can force a call to be answered, allowing eavesdropping.

    • Affected versions: <4.47.7 for App on Android

    • Triggered by a voice call.

    • Verified fixed by @moxie.

  • CVE-2019-17192 | 9.8 Critical

    • A flaw in WebRTC may allow an attacker to cause a DOS or other unspecified impacts.

    • Affected versions: <4.47.7 for App on Android

    • Triggered by a video call.

    • Verified as not being addressed by @moxie.

  • CVE-2019-19954 | 7.3 High

    • A Trojan horse of wmic.exe allows local users to gain privileges.

    • Affected versions: <1.29.1 for Desktop on Windows

    • Verified fixed by Rich Mirch.

  • CVE-2020-5753 | 5.3 Medium

    • A flaw in ICE Candidate handling allows a caller to disclose the user’s DNS servers.

    • Affected versions: v4.59.0 for App on Android and v3.8.1.5 for App on iOS

    • Verified updated by Tenable.

  • CVE-2022-28345 | 7.5 High

    • Incorrectly rendered RTLO encoded URLs allow URI spoofing.

    • Affected versions: <4.34 for App on iOS

    • Verified fixed by Malwarebytes.

  • CVE-2023-24068 | 7.8 High

    • A failure to validate modifications of cached files allows malicious code injection.

    • Affected versions: <6.2.0 for Desktop on Windows, Linux and macOS

    • Assuming fixed based on <6.2.0, with lack of any other reference.

  • CVE-2023-24069 | 3.3 Low

    • Affected version: <6.2.0 for Desktop on Windows, Linux or macOS

    • A failure to fully clear cache could allow an attacker to retrieve attachments.

    • Requires local file system access.

    • No fix has been issued, and Signal disputes its relevance.

The first thing I find interesting is that the first vulnerability wasn’t reported until 5 years after its initial release. One explanation could be that in 2018 oversight of its development was officially taken over by a newly formed organization the Signal Foundation, and it truly began its open-source journey. Another explanation, for those with a playful imagination, might be that using the NVD is like the user being a farmer asking a fox if it knows about any holes in their fence.

“Certainly!” replies the fox as it stands with its back to the East side of the fence, looking innocent, “why I heard that a wolf was rummaging around on the North side of the fence just yesterday! You should go take a look.”

Another interesting thing to note is the flaw with the highest criticality rating (CVE-2019-17192) which Signal had no intention of resolving:

The WebRTC component in the Signal Private Messenger application through 4.47.7 for Android processes videoconferencing RTP packets before a callee chooses to answer a call, which might make it easier for remote attackers to cause a denial of service or possibly have unspecified other impact via malformed packets. NOTE: the vendor plans to continue this behavior for performance reasons unless a WebRTC design change occurs.

-https://www.cve.org/CVERecord?id=CVE-2019-17192

Another noteworthy response comes from the vendor for CVE-2023-24069 which could allow sensitive file recovery after deletion:

Signal Desktop before 6.2.0 on Windows, Linux, and macOS allows an attacker to obtain potentially sensitive attachments sent in messages from the attachments.noindex directory. Cached attachments are not effectively cleared. In some cases, even after a self-initiated file deletion, an attacker can still recover the file if it was previously replied to in a conversation. (Local filesystem access is needed by the attacker.) NOTE: the vendor disputes the relevance of this finding because the product is not intended to protect against adversaries with this degree of local access.

-https://www.cve.org/CVERecord?id=CVE-2023-24069

It is not entirely clear from the documentation on CVE or NVD whether some of the older vulnerabilities have ever been addressed as some of the links in the references section are broken.

Finally, I noticed that there hasn’t been another reported vulnerability since January 2023. It seems curious, but then again, these folks are very, very smart.

Going Deeper

Before I begin, let me preface this by saying I am not a cryptographer and trying to analyze the math does go beyond my general knowledge of encryption. I suggest verifying any of my interpretations. Despite being outclassed intellectually, I’m going to take a closer look.

Abiding by its commitment to openness, Signal provides documentation on the cryptographic algorithms it utilizes.

Taking a look at the docs, the algorithms in use are, I believe, all products of the devs, and are based on previously known, verified secure standards:

  • XEdDSA and VXEdDSA - This is used to enable use of a single key pair for elliptic curve D-H and signatures.

  • X3DH - This provides forward secrecy, cryptographic deniability and mutual authentication using shared secrets, through a three-way key agreement phase.

  • PQXDH - This is a revision of X3DH that adds quantum protection.

  • Double Ratchet - This utilizes shared secrets in a way that ensures forward-secrecy, preventing a key from being used to decrypt previous or future messages.

  • Sesame - This is used to manage encryption sessions asynchronously across multiple devices.

The software libraries are also available on GitHub for review, but that is beyond the scope of this post, and there are enough “eyes on” doing static code analysis already.

Conclusion

I don’t have the crypto chops to dispute the technology involved in this app, but given its openness and the adoption of its protocols in other major closed-source applications, I think it would be difficult for anyone to dispute its inherent security. It has had some concerning flaws; however, many of them required local access to the device, or the flaw existed in an external component.

That brings up an important point. An app might offer incredible security features to protect its users’ privacy, and an innovative organization that has already begun the quest to combat quantum attacks should certainly be applauded for their efforts. However, apps still need something on which to run - an OS and a device - neither of which can ever be fully trusted, and as Signal points out in their reply to CVE-2023-24069, it’s not up to them to provide that level of security.

Not to mention the human component, which is considered the weakest link in any security system.

Daily Cuppa

Today’s cup of tea is Organic Earl Grey provided by Equal Exchange.

Fair Trade, organic, and bursting with bergamot!

If you enjoyed this post or found use from it, feel free to buy the author a cup of tea.

Jason Minor
Previous

Fun With Python: Log Analysis with Regex
Next

IT Security 101: Vulnerabilities