Tags › Asterisk

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.

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

• Fixed versions: 18.20.1, 20.5.1, 21.0.1,18.9-cert6
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2023-01-asterisk-dtls-hello-race/
• Vendor Security Advisory: https://github.com/asterisk/asterisk/security/advisories/GHSA-hxj9-xwr8-w8pq
• Other references: CVE-2023-49786
• Tested vulnerable versions: 20.1.0
• Timeline:
  • Report date: 2023-09-27
  • Triaged: 2023-09-27
  • Fix provided for testing: 2023-11-09
  • Vendor release with fix: 2023-12-14
  • Enable Security advisory: 2023-12-15

TL;DR

When handling DTLS-SRTP for media setup, Asterisk 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.

Asterisk: crash via INVITE flood over TCP

• Fixed versions: 13.37.1, 16.14.1, 17.8.1, 18.0.1
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2020-02-asterisk-tcp-invite-crash/
• Reproduction tools: https://github.com/EnableSecurity/advisories/tree/master/ES2020-02-asterisk-tcp-invite-crash
• Asterisk Security Advisory: https://downloads.asterisk.org/pub/security/AST-2020-001.html
• References: AST-2020-001, CVE-2020-28327
• Tested vulnerable versions: 17.5.1, 17.6.0
• Timeline:
  • Report date: 2020-08-31
  • Triaged: 2020-09-01
  • Fix provided for testing: 2020-10-29
  • Asterisk release with fix: 2020-11-05
  • Enable Security advisory: 2020-11-06

Description

When an Asterisk instance is flooded with INVITE messages over TCP, it was observed that after some time Asterisk crashes due to a segmentation fault. The backtrace generated after the crash is:

Asterisk PJSIP: stack corruption via large Accept header in SUBSCRIBE

• Authors:
  • Alfred Farrugia alfred@enablesecurity.com
  • Sandro Gauci sandro@enablesecurity.com
• Latest vulnerable version: Asterisk 15.2.0 running chan_pjsip
• Tested vulnerable versions: 15.2.0, 13.19.0, 14.7.5, 13.11.2
• References: AST-2018-004, CVE-2018-7284
• Advisory URL: https://www.enablesecurity.com/advisories/ES2018-01-asterisk-pjsip-subscribe-stack-corruption/
• Vendor Advisory: http://downloads.asterisk.org/pub/security/AST-2018-004.html
• Timeline:
  • Issue reported to vendor: 2018-01-30
  • Vendor patch made available to us: 2018-02-06
  • Vendor advisory published: 2018-02-21
  • Enable Security advisory: 2018-02-22

Description

A large SUBSCRIBE message with multiple malformed Accept headers will crash Asterisk due to stack corruption.

Impact

Abuse of this vulnerability leads to denial of service in Asterisk when chan_pjsip is in use. Brief analysis indicates that this is an exploitable vulnerability that may lead to remote code execution.

Asterisk PJSIP: crash via repeated INVITE messages over TCP/TLS

• Authors:
  • Alfred Farrugia alfred@enablesecurity.com
  • Sandro Gauci sandro@enablesecurity.com
• Latest vulnerable version: Asterisk 15.2.0 running chan_pjsip installed with --with-pjproject-bundled
• References: AST-2018-005, CVE-2018-7286
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2018-04-asterisk-pjsip-tcp-segfault/
• Vendor Advisory: http://downloads.asterisk.org/pub/security/AST-2018-005.html
• Tested vulnerable versions: 15.2.0, 15.1.0, 15.0.0, 13.19.0, 13.11.2, 14.7.5
• Timeline:
  • Issue reported to vendor: 2018-01-24
  • Vendor patch made available to us: 2018-02-05
  • Vendor advisory published: 2018-02-21
  • Enable Security advisory: 2018-02-22

Description

A crash occurs when a number of INVITE messages are sent over TCP or TLS and then the connection is suddenly closed. This issue leads to a segmentation fault.

Asterisk PJSIP: crash via invalid SDP media format description

• Authors:
  • Alfred Farrugia alfred@enablesecurity.com
  • Sandro Gauci sandro@enablesecurity.com
• Latest vulnerable version: Asterisk 15.2.0 running chan_pjsip
• References: AST-2018-002, CVE-2018-1000098
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2018-03-asterisk-pjsip-sdp-invalid-media-format-description-segfault/
• Vendor Advisory: http://downloads.asterisk.org/pub/security/AST-2018-002.html
• Tested vulnerable versions: 13.10.0, 15.1.3, 15.1.4, 15.1.5, 15.2.0
• Timeline:
  • Report date: 2018-01-15
  • Vendor patch made available to us: 2018-02-05
  • Vendor advisory published: 2018-02-21
  • Enable Security advisory: 2018-02-22

Description

A specially crafted SDP message body with an invalid media format description causes a segmentation fault in asterisk using chan_pjsip.

Impact

Abuse of this vulnerability leads to denial of service in Asterisk when chan_pjsip is in use.

Asterisk PJSIP: crash via invalid SDP fmtp attribute

• Authors:
  • Alfred Farrugia alfred@enablesecurity.com
  • Sandro Gauci sandro@enablesecurity.com
• Latest vulnerable version: Asterisk 15.2.0 running chan_pjsip
• References: AST-2018-003, CVE-2018-1000099
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2018-02-asterisk-pjsip-sdp-invalid-fmtp-segfault/
• Vendor Advisory: http://downloads.asterisk.org/pub/security/AST-2018-003.html
• Timeline:
  • Issue reported to vendor: 2018-01-15
  • Vendor patch made available to us: 2018-02-05
  • Vendor advisory published: 2018-02-21
  • Enable Security advisory: 2018-02-22

Description

A specially crafted SDP message body with an invalid fmtp attribute causes a segmentation fault in asterisk using chan_pjsip.

Impact

Abuse of this vulnerability leads to denial of service in Asterisk when chan_pjsip is in use.

Asterisk: RTP Bleed vulnerability

• Authors:
  • Klaus-Peter Junghanns kapejod@gmail.com
  • Sandro Gauci sandro@enablesecurity.com
• Vulnerable version: Asterisk 11.4.0 to 14.6.1 (fix incomplete)
• References: AST-2017-005, AST-2017-008, CVE-2017-14099
• Advisory URL: https://www.enablesecurity.com/advisories/ES2017-04-asterisk-rtp-bleed/
• Timeline:
  • First report date: 2011-09-11
  • Fix applied: 2011-09-21
  • Issue apparently reintroduced: 2013-03-07
  • New report date: 2017-05-17
  • Vendor patch provided for testing: 2017-05-23
  • Vendor advisory: 2017-08-31
  • Enable Security advisory: 2017-09-01
  • Vendor updated advisory: 2017-09-19

Description

When Asterisk is configured with the nat=yes and strictrtp=yes (on by default) options, it is vulnerable to an attack which we call RTP Bleed. Further information about the attack can be found at https://rtpbleed.com.