Skip to main content
RTC Security Newsletter

Curated VoIP and WebRTC security news, research and updates by Enable Security.

Subscribe

December 2023: Round-up of this year’s VoIP and WebRTC security news, and DTLS hello race flaw

Published on Dec 22, 2023

It’s the end of the year and if you are still reading your emails, make sure to read this one! Wish you all restful holidays and a happy New Year!

In this edition, we cover:

  • our community contributions for 2023 and our new security advisories
  • the best and the worst of 2023
  • Asterisk and 3CX vulnerabilities
  • and a few more news items but not that much this time!

RTCSec newsletter is a free periodic newsletter bringing you commentary and news around VoIP and WebRTC security. We cover both defensive and offensive security as they relate to Real-time Communications.

What is RTC security anyway? Real-time communications security is what determines if you can safely communicate in real time - whether it be with other humans or machines.

You may sign up to receive the RTCSec newsletter here. Do:

  • forward to that person who may find this newsletter particularly fruitful.
  • let us know if we should include or cover any RTC security news.

To view past issues, please visit our website at https://www.rtcsec.com/newsletter.


Our news

Our contributions to VoIP and WebRTC security in 2023

This part of the newsletter is reserved for bragging about the past year’s publications from Enable Security. First, we are proud to have published the OpenSIPS Security Audit Report in full. The security audit exercise led to the discovery of 15 security findings, most of which could be exploited at least to cause a crash of the server. We hope that the report proves convincing enough for most OpenSIPS installations to be kept up to date.

This year we also started publishing about the WebRTC infrastructure attack surface. The presentation at the UK conference CommCon on this very topic was called WebRTC & Video Delivery application security - what could possibly go wrong? This presentation can now be watched on Youtube which covers potential security vulnerabilities related to signaling, media, NAT traversal and gateways. The talk was split between providing a high level overview of vulnerabilities that may affect WebRTC infrastructure and diving into some of the details with practical examples. A variation of this talk was given to the WebRTC Live audience and also to a private event called Bloomberg RTC Summit.

In addition to talking about WebRTC vulnerabilities, at CommCon we took a sneak peek at the WISH (WHIP) protocol. This led to some potential vulnerabilities in its design and implementations, which the developers working on this standard quickly reacted to. We’re proud to have done our part. There were at least the following changes:

  • Sergio Garcia Murillo updated the WHIP draft document to include our concerns as security considerations
  • Lorenzo Miniero updated his simple WHIP server to randomize the resource address - see pull request
  • The SRS server project updated both their FFmpeg WebRTC fork and SRS to cater to some of the concerns that we raised

DTLS-SRTP hello race vulnerability affects multiple VoIP and WebRTC products

Speaking of contributions and publications, our last one for this year is the DTLS-SRTP hello race condition vulnerability. This security flaw was discovered by Alfred Farrugia, our very own chief demolition officer at Enable Security. It affects a number of media servers and in the past week, two well-known open-source projects issued security advisories and fixes to address their implementation.

We published the following advisories so far:

Apart from open-source projects, we came across one proprietary solution (an SBC) that was vulnerable. Expect more news about this vulnerability in the next year.

What’s happening?

The best & worst of RTC Security in 2023

As this year is about to close, we looked at the past 12 months for the most concerning stories covered here. Making it to the top of this list is the 3CX supply chain compromise which affected a large number of people and organisations. The hackers, said to be a North Korean threat actor, compromised the build server which in turn led to the distribution of their malware inside 3CX’s binary updates. We covered this story in March and April as it unfolded. It is a story that includes some lessons - from how (not) to respond to security incidents, to how when a company - even if small - has a large enough user base, it becomes the target of nation-state level adversaries.

Another dramatic story was that concerning compromised FreePBX servers and security reports, a presentation at DEF CON 31, and the vendor, Sangoma’s lacking responses to the whole thing. We covered all of this in the October edition but back in February, we had also seen reports of FreePBX ARI attacks in the wild.

Finally, some amazing research was published by Google’s Project Zero concerning baseband SIP parser vulnerabilities. We covered this in April under the title of New advisories for the Samsung Exynos chipset, due to SIP attacks on VoLTE and then again in May as Shannon Baseband vulnerabilities abusing SIP decoders by Project Zero. Although this work might not have gotten the sort of attention that other stories did, we think that it is highly important work. Vulnerabilities affecting the baseband are more likely when in order to support VoLTE, the baseband needs to parse complex protocols such as SIP and RTCP. These vulnerabilities ultimately affect anyone who uses phones with the affected chipsets.

Other notable news were the following:

Asterisk advisories issued for AMI, fake log entries and a low-severity overflow

Apart from the DTLS hello race condition, Asterisk’s latest releases fixed the following:

The most interesting from the above is the Asterisk Management Interface (AMI) GetConfig issue which has a moderate severity rating. The reason for this is that to execute AMI commands, you would usually need authentication. In many systems, not only do you need authentication to reach the AMI service but also the network service needs to be reachable. Quite often, the AMI listens only on the loopback or has an IP allow list.

That said, we have often also seen web applications and APIs that take arbitrary user input from potential attackers and pass it to the AMI service. In such cases, the severity rating might be different than a mere medium or 4.9.

The fake log entries vulnerability is concerning when the logs are used for sensitive operations, such as blocking particular IP addresses. The advisory notes the following:

Servers running fail2ban or similar against the Asterisk logs may then take inappropriate action based on the fake log entries.

Although a patch exists, it has not yet released according to this advisory. The following PJSIP tickets contain more information:

Finally, the last vulnerability is only exploitable by users who can write dialplans which makes it very hard to reach and therefore a low severity vulnerability.

SQL injection vulnerabilities affecting 3CX’s CRM integration

The 3CX phone system has a CRM integration feature that was vulnerable to SQL injection when a specific configuration was in place. The vulnerability was reported to 3CX by a security researcher, Theo Stein who showed that it could be abused through the 3CX WebClient as well as the LiveChat API.

At the time of writing, the proposed hotfix (18.0.9.23, 20.0.0.1494) is not yet out. Therefore 3CX is recommending that customers disable CRM integrations that rely on a direct SQL connection and instead make use of one of the various APIs supported by the system.

The vulnerability is tracked as CVE-2023-49954 and has its own website at cve-2023-49954.github.io. It stems from 3CX’s use of templates for the SQL integration, which requires changes to the templates and is therefore not an easy solution to apply. This would explain why they seem to be delaying their hotfix - such changes might break existing installations.

Bleeping Computer has an article about this and 3CX has released two blog posts:

Chromium WebRTC vulnerabilities, exploited in the wild

This December, Chromium had two releases that included security fixes in the WebRTC code:

The second one, CVE-2023-7024, is especially important because it is known to be actively exploited in the wild.

Short news and commentary

  • VoIP DDoS article
  • APIBAN now detects HTTP and SIP
    • The guys at the Palner Group / Fred Posner are now collecting HTTP honeypot data so that apart from blocking SIP-based attacks, users can block ones that hit the web server. Check out their announcement and sponsor the project if you want to support it.
  • What’s Wrong With Fast VoLTE Deployments?
    • A telecom security company called SecurityGen has published a document covering the sort of security issues that could be found when phone companies expose their internal networks to 5G subscribers. Sensitive services such as SSH, FTP, X11, and web-management interfaces can be reached by potential attacks in cases where the necessary precautions haven’t been taken.

This newsletter was prepared by Sandro Gauci and the Enable Security team for the RTCSec newsletter subscribers. If you have someone in mind who would benefit from our content, please do share.

To subscribe: here