Tags › Denial of Service

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

• Fixed versions: mr12.1.1.2, mr12.0.1.3, mr11.5.1.16, mr10.5.6.3, mr10.5.6.2, mr9.5.8.2, mr8.5.12.2
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2023-03-rtpengine-dtls-hello-race/
• Vendor Patch: https://github.com/sipwise/rtpengine/commit/e969a79428ac4a15cdf1c0a1c6f266dbdc7e60b6
• Other references: CVE-2023-51275
• Tested vulnerable versions: mr11.5.1.6
• Timeline:
  • Report date: 2023-10-02
  • Triaged: 2023-10-02
  • Fix provided for testing: 2023-11-16
  • Enable Security verified fix: 2023-12-14
  • Vendor release with fix: 2023-12-14
  • Enable Security advisory: 2023-12-15

TL;DR

When handling DTLS-SRTP for media setup, RTPEngine 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 encrypted calls during 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.

OpenSIPS Security Audit Report is fully disclosed and out there

It’s almost a year since the OpenSIPS project published a minimized version of our security audit report from 2022. Now, the full version has been published, with all the information intact on how to reproduce the vulnerabilities and extra details in an 80+ page report.

The OpenSIPS security audit report can be found here.

What is the OpenSIPS security audit?

OpenSIPS is a SIP server that often has a critical security function within an IP communications system. Thus, it makes absolute sense to perform a thorough security audit for such software. We had been dealing with OpenSIPS servers from time to time in our work so we were rather familiar with the software and the project itself. Then back in January 2021, the lead developer for OpenSIPS, Bogdan-Andrei Iancu, asked us if we would be interested in doing some proper security work. Naturally, our answer was yes please!

How to perform a DDoS attack simulation

TL;DR

A DDoS simulation is a practical exercise that various organisations are capable of doing. Understand the reasons why you would want to do this, then combine custom with off-the-shelf attack tools. Follow the best practices, apply solutions and mitigation; and you can finally answer: what if we got attacked?

Introduction

In this post, we give an overview of how you too can perform your own distributed denial of service (DDoS) simulation exercises. We focus on attacking real-time communications systems because this is an area where DoS attacks can really cause damage. But the instructions and ideas outlined in this text will apply to any system in general that you might need to test. Even if in this article we do not really focus on the defensive side of protecting against DoS, ultimately the goal is to design and implement solutions that actually work for the systems and applications that need to be protected.

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

The story behind our FreeSWITCH advisories and how one sleepless night led to 4 vulnerabilities that needed reporting, plus one more found due to a bug in our own software. We explain how these flaws were discovered, reported, fixed and what we ultimately learned.…

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: 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.

Why volumetric DDoS cripples VoIP providers and what we see during pentesting

An epiphany

Until a few days ago, I was of the opinion that simulating volumetric DDoS attacks is not something we should be doing. If you had asked us for such a test, we would have given you a negative answer.

Ironically, we had been unwittingly simulating volumetric DDoS attacks while quietly ignoring our own results. But, it’s time to stop neglecting bandwidth saturation and start giving it the attention that it deserves.