Slack DTLS uses a private key that is in the public domain, which may lead to SRTP stream hijack

How it was found

• Affects: Janus DTLS certificate

Description

The Janus server in use by Slack is configured using a certificate and private key that were previously distributed by default. This certificate is used to authenticate the DTLS connection which is later used to exchange keys for the SRTP stream. As a result, the confidentiality of the WebRTC call over Slack cannot be ensured.

How to reproduce the issue

1. Start Wireshark and set a display filter for stun
2. In the web browser, open about:webrtc-internals
3. Start a call on Slack
4. Observe the packets containing the string rainmaker which would be part of the DTLS certificate
5. Notice that the SetRemoteDescription fingerprint in the about:webrtc-internals page is C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44

The old certificate can be obtained from the following commit where it was previously removed:

https://github.com/meetecho/janus-gateway/commit/6f98f2dde644b3ead4a162c241dff9da1587ec13

The certificate's SHA256 checksum can be calculated using the OpenSSL command line tool as follows:

openssl x509 -noout -fingerprint -sha256 -inform pem -in janus-cert1.crt 
SHA256 Fingerprint=C5:5F:DA:7D:84:47:B1:BF:6B:55:16:62:48:31:3E:D3:F1:7B:25:89:92:4A:4B:4D:4D:D9:D5:AF:EA:D8:15:44

Attachments:

• dump-stun.pcapng: contains the data stream containing the TURN tunnelled DTLS exchange and SRTP stream that follows
• janus-cert1.crt and janus-cert1.key are the certificate and key in use by Slack
• 2019-04-07_16-06-wireshark.png shows the certificate in the Wireshark dump
• 2019-04-07_16-13-fingerprint.png shows the SHA256 fingerprint which matches the public certificate and corresponding private key

An attacker would probably need to take the following steps to exploit this issue in the case of Slack:

1. Start a man-in-the-middle attack using any known method (ARP cache poisoning, DNS cache poisoning, static routes on compromised network router etc)
2. Actively hijack the Slack TURN servers between the victim and the Internet
3. Wait for victim to make a Slack call
4. Handle STUN packets from victim to attacker-controlled TURN server; allow authentication with any password
5. Start DTLS exchange
6. When DTLS certificate is required, present victim with the Janus default certificate
7. The attacker does NOT verify the victim's DTLS certificate
8. The SRTP Master Key is set over this DTLS connection
9. Attacker can now handle the SRTP stream between the victim and attacker

Solutions and recommendations

It is recommended to generate a new certificate and private key.

Impact

Attackers positioned as man-in-the-middle may hijack the DTLS connection and set their own SRTP keys, handling the SRTP stream instead of Slack. This is still research in progress but it does not appear that attackers can perform a two-way MITM attack due to the mutual authentication required by the DTLS exchange. Therefore, it seems that this vulnerability can only be abused to hijack the SRTP stream between the WebRTC client and Slack but not the other way round.