Tags › Freeswitch

New White Paper: DTLS “ClientHello” Race Conditions in WebRTC Implementations

We’re excited to announce the release of our latest white paper, “DTLS ‘ClientHello’ Race Conditions in WebRTC Implementations”. This comprehensive study delves into a critical vulnerability affecting various WebRTC implementations, with potential implications for real-time communication security.

Our research team at Enable Security conducted extensive testing on both open-source and proprietary WebRTC implementations, focusing on media servers and popular communication platforms. The study aimed to identify vulnerabilities related to the processing of DTLS ClientHello messages in WebRTC sessions.

A Novel DoS Vulnerability affecting WebRTC Media Servers

Executive summary (TL;DR)

A critical denial-of-service (DoS) vulnerability has been identified in media servers that process WebRTC’s DTLS-SRTP, specifically in their handling of ClientHello messages. This vulnerability arises from a race condition between ICE and DTLS traffic and can be exploited to disrupt media sessions, compromising the availability of real-time communication services. Mitigations include filtering packets based on ICE-validated IP and port combinations. The article also indicates safe testing methods and strategies for detecting the attack.

FreeSWITCH: denial of service via DTLS Hello packets during call initiation

• Fixed versions: 1.10.11
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2023-02-freeswitch-dtls-hello-race/
• Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-39gv-hq72-j6m6
• Other references: CVE-2023-51443
• Tested vulnerable versions: 1.10.10
• Timeline:
  • Report date: 2023-09-27
  • Triaged: 2023-09-27
  • Fix provided for testing: 2023-09-29
  • Vendor release with fix: 2023-12-22
  • Enable Security advisory: 2023-12-22

TL;DR

When handling DTLS-SRTP for media setup, FreeSWITCH is susceptible to Denial of Service due to a race condition in the hello handshake phase of the DTLS protocol. This attack can be done continuously, thus denying new DTLS-SRTP encrypted calls during the attack.

Exploiting CVE-2022-0778, a bug in OpenSSL vis-à-vis WebRTC platforms

Executive summary (TL;DR)

Exploiting CVE-2022-0778 in a WebRTC context requires that you get a few things right first. But once that is sorted, DoS (in RTC) is the new RCE!

How I got social engineered into looking at CVE-2022-0778

A few days ago, Philipp Hancke, self-proclaimed purveyor of the dark side of WebRTC, messaged me privately with a very simple question: “are you offering a DTLS scanner by chance?”

He explained how in the context of WebRTC it would be a bit difficult since you need to get signaling right, ICE (that dance with STUN and other funny things) and finally, you get to do your DTLS scans. He added that he hopes that these difficulties raise the bar for exploiting latest OpenSSL CVE.

Killing bugs … one vulnerability report at a time

Executive summary (TL;DR)

We tell the story behind the latest FreeSWITCH advisories and how it all came together one sleepless night in April 2021 so that we ended up with 4 vulnerabilities that needed reporting. And then, one more vulnerability found due to a bug in our own software, SIPVicious PRO. We explain how these flaws were discovered, reported, fixed and what we ultimately learned through this process.

What is this about?

This article shares the same title with the presentation that I gave at ClueCon 2021, organised by SignalWire - main FreeSWITCH sponsors. The presentation can be watched on Youtube.

ClueCon: FreeSWITCH Security Advisories

The FreeSWITCH team has just published version v1.10.7 which fixes a number of security issues that we reported. If you use FreeSWITCH, please do upgrade to get these security updates.

To learn about the background work that went into getting these security bugs squashed, follow Sandro’s talk called Killing bugs … one vulnerability report at a time. This will be presented at at ClueCon on Thursday, October 28th.

Here are the titles of each advisory and a very short summary:

FreeSWITCH: unauthenticated SIP MESSAGE requests allow spam and spoofing

• Fixed versions: v1.10.7
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2021-07-freeswitch-SIP-MESSAGE-without-auth/
• Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-mjcm-q9h8-9xv3
• Other references: CVE-2021-37624
• Tested vulnerable versions: <= v1.10.6
• Timeline:
  • Report date: 2021-06-07
  • Fix provided for testing: 2021-07-27
  • Vendor release with fix: 2021-10-24
  • Enable Security advisory: 2021-10-25

Description

By default, SIP requests of the type MESSAGE (RFC 3428) are not authenticated in the affected versions of FreeSWITCH. MESSAGE requests are relayed to SIP user agents registered with the FreeSWITCH server without requiring any authentication. Although this behaviour can be changed by setting the auth-messages parameter to true, it is not the default setting.

FreeSWITCH: SIP digest leak for configured gateways

• Fixed versions: v1.10.7
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2021-05-freeswitch-vulnerable-to-SIP-digest-leak/
• Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-3v3f-99mv-qvj4
• Other references: CVE-2021-41158
• Tested vulnerable versions: <= v1.10.6
• Timeline:
  • Report date: 2021-04-22
  • Triaged: 2021-04-23
  • Fix provided for testing: 2021-08-13
  • Second fix provided for testing: 2021-09-14
  • Vendor release with fix: 2021-10-24
  • Enable Security advisory: 2021-10-25

Description

An attacker can perform a SIP digest leak attack against FreeSWITCH and receive the challenge response of a gateway configured on the FreeSWITCH server. This is done by challenging FreeSWITCH’s SIP requests with the realm set to that of the gateway, thus forcing FreeSWITCH to respond with the challenge response which is based on the password of that targeted gateway.

FreeSWITCH: denial of service via SIP flooding

• Fixed versions: v1.10.7
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2021-06-freeswitch-flood-dos/
• Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-jvpq-23v4-gp3m
• Other references: CVE-2021-41145
• Tested vulnerable versions: <= v1.10.6
• Timeline:
  • Report date: 2021-05-28
  • Triaged: 2021-06-18
  • Fix provided for testing: 2021-10-08
  • Second fix provided for testing: 2021-10-13
  • Vendor release with fix: 2021-10-24
  • Enable Security advisory: 2021-10-25

Description

When flooding FreeSWITCH with SIP messages, it was observed that after a number of seconds the process was killed by the operating system due to memory exhaustion. The following excerpt from syslog shows one such instance:

FreeSWITCH: denial of service via invalid SRTP packets

• Fixed versions: v1.10.7
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2021-09-freeswitch-srtp-dos/
• Vendor Security Advisory: https://github.com/signalwire/freeswitch/security/advisories/GHSA-jh42-prph-gp36
• Other references: CVE-2021-41105
• Tested vulnerable versions: <= v1.10.6
• Timeline:
  • Report date: 2021-09-06
  • Triaged: 2021-09-10
  • Fix provided for testing: 2021-09-17
  • Vendor release with fix: 2021-10-24
  • Enable Security advisory: 2021-10-25

TL;DR

When handling SRTP calls, FreeSWITCH is susceptible to a DoS where calls can be terminated by remote attackers. This attack can be done continuously, thus denying encrypted calls during the attack.

Description

When a media port that is handling SRTP traffic is flooded with a specially crafted SRTP packet, the call is terminated leading to denial of service. This issue was reproduced when using the SDES key exchange mechanism in a SIP environment as well as when using the DTLS key exchange mechanism in a WebRTC environment.