RTC Security Newsletter

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

June 2023: Talks on VoIP security, WebRTC server-side attacks and WISH/WHIP

Published on Jun 30, 2023

It is finally conference season and so this newsletter covers 3 different events focused on RTC and opensource communications as well as the latest and greatest security fixes related to VoIP and WebRTC.

In this edition, we cover:

Kamailio World, CommCon and OpenSIPS summit presentations of interest
Our own work especially on WebRTC and WISH (WHIP) security
More open SIP relay attacks in the wild
DDoS, botnets and VoIP
RTC vulnerabilities and fixes in MacOS, iOS, WebRTC and more

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 communicate in real time in a safe way - 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 Attack Platform Dangerous Demo at Kamailio World

One of my personal favorites at Kamailio World is a regular session called Dangerous Demos run by James Body. For this year’s dangerous demo, we collaborated with Fred Posner who set up a test machine running Kamailio ready to be attacked. We then used our Attack Platform to do a number of denial of service tests against the SIP interface. We ran the following tests:

INVITE flood
indialog INVITE flood
indialog NOTIFY flood
indialog CANCEL flood
fuzzing

We had “3 minutes to completely vaporize Fred’s machine” (according to James). Although Fred’s system certainly felt the attack, it seems that it was able to reliably recover! You may watch the session on Youtube: https://youtu.be/yehYE34d3mI?t=9443

WebRTC & Video Delivery application security - what could possibly go wrong?

CommCon is a residential conference in the UK that happened during June, where we had the pleasure to present about WebRTC and video delivery security. The talk was split between providing a high level overview of vulnerabilities that may affect WebRTC infrastructure and actually diving into some of the details. In relation to WebRTC environments, we covered the following vulnerabilities in some detail:

CVE-2022-0778: Denial of Service vulnerability in OpenSSL
RTP Injection
RTP Bleed
RTP Flood
TURN relay abuse

Following that, we then looked at the new WISH / WHIP video delivery protocol - how it inherits the security features of WebRTC infrastructure, as well as the same attack surface too. Finally we outlined potential security issues that may affect this signalling protocol and gave examples of our concerns. More on that in the next part of this newsletter!

Anyone wanting to stream the presentations from CommCon is able to do so by buying a CommCon streaming ticket: https://2023.commcon.xyz/live

The presentation slides are made public: https://www.slideshare.net/sandrogauci/commcon-2023-webrtc-video-delivery-application-security-what-could-possibly-go-wrong

We would like to thank Dan Jenkins and his team for organising this conference and making it all happen!

WISH (WHIP) security updates thanks to our CommCon presentation

Our presentation at CommCon included a brief security review of the WISH/WHIP draft RFC which caused a bit of stir. We will be publishing a longer blog post about the topic but in short, we listed the following potential security issues with regards to this new protocol:

Access control issues (IDOR) on resource location
ICE restart flooding (PATCH)
POST flooding
Traditional HTTP-style attacks

As a result of our presentation, a number of public projects were updated by their respective authors. The following is the list we have so far:

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 for some of the concerns that we raised

The SIPVicious PRO demo server at Kamailio World

Our demo server is an Internet-facing machine that is used as an attack target and is purposely vulnerable to a number of VoIP and WebRTC security issues. It can be reached at demo.sipvicious.pro.

At Kamailio World, attendees had the opportunity to present their deployment of Kamailio in production in a 5 minute talk. Thus, we showed where Kamailio fits in the demo server’s stack and how it provides us with a stable environment for reproducing security issues using our tools. We finished off by showing an example of an SQL injection flaw that is present on the demo server by misusing the sqlops Kamailio module in a way that is vulnerable.

Watch the presentation here: https://youtu.be/EhjJMjZnfe8?t=30317

What’s happening?

Kamailio World 2023: DDoS Attacks Are Coming For SIP and APIBAN talk

Kamailio World happened in Berlin during June and included a number of high quality presentations from the community. Here we cover two presentations of interest:

Attacks Are Coming For SIP: Are You Ready? by Lucas Christian and Andreas Jansson from Twilio
Using APIBan In Productions by Fred Posner

Lucas’ and Andreas’ talk was very interesting because they spoke about a topic that is close to heart for us. They classified VoIP DDoS attacks as one of the following:

Low sophistication consisting of bandwidth saturation, reflection / amplification attacks and ICMP flooding; not SIP specific
Medium sophistication targeting the actual application ports but not SIP specific either; including TCP SYN flood, TLS handshake attacks and HTTP specific attacks
High sophistication which targets specifically SIP application servers especially SIP authentication flows

If you would like to learn about what Twilio have been doing to prepare for future DDoS attacks, this is the most comprehensive public presentation on the topic so far.

Fred Posner’s latest talk about APIBAN was given at Kamailio World. The resources, including slide and Kamailio configuration examples can be found at https://pgpx.io/kw2023/.

References:

Another Open Relay Scan detected by Kwancro’s honeypots

Our friend Ivan Nyarko published a new blog post about SIP open relay scans that are being detected through his honeypots.

The background story is that legitimate SIP servers were getting blocked by APIBAN, the free SIP blacklisting solution. That is when Ivan started suspecting that these servers were relaying attacker-borne SIP traffic. Thanks to historic data from the honeypots and a bit of investigation confirmed his suspicions. What then followed was further research and a very interesting article. Here are some of the highlights:

legitimate SIP servers are being used for scanning SIP servers
the pattern to detect such scans typically consists of multiple Via SIP headers and/or a SIP user-agent header that includes PolycomSoundPointIP
he includes a list of vulnerable open SIP relay servers that were abused, which includes OpenSER, Ingate SIParator and OpenSIPS, Icewarp and Kamailio

After reading this blog post, we were left with a few open questions:

was the default configuration for OpenSER 1.3.2 vulnerable?
which Ingate and Icewarp products are vulnerable by default and have they yet fixed it?
were there old version of OpenSIPS or Kamailio that were vulnerable by default or is this simply a misconfiguration?
if it is, what does the configuration look like? is it the most obvious mistake (e.g. an unprotected t_relay) or something a bit more complex?

We answered the first question by first taking a look at the default configuration included with OpenSER 1.3.2 and noticing that it is indeed vulnerable. Then we actually compiled that version, gave it a run with the default configuration and tested it with SIPVicious PRO as follows:

sipvicious sip utils repeater udp://172.17.0.3:5060 -m invite -D example.org

The result was that the OpenSER server at 172.17.0.3:5060 sent the SIPVicious PRO traffic to example.org, which validated our concerns that it was vulnerable by default.

We recommend reading the original article that includes a lot more details. Ivan also includes a free online tool to check for the vulnerability against your own SIP servers.

References:

Securing your OpenSIPS Deployment at OpenSIPS Summit

The OpenSIPS Summit happened at the end of May in Houston. Unfortunately we missed it but the presentations slides and videos are online. We reviewed the presentation by Vlad Paiu from the OpenSIPS project which was all about securing OpenSIPS deployments.

In his presentation, Vlad covered a lot of ground, including:

passive attacks which should be countered by making use of network encryption and hardening the system (e.g. traditional firewall)
active attacks, which tend to be more problematic
attacks from authenticated/compromised users or inside attacks

The presenter mentioned our work multiple times, which naturally makes us happy, especially with regards to the OpenSIPS security audit as well as the articles on rtcsec.com!

Highlights include:

preventing attacks that rely on malformed SIP packets, by using sipmsg_validate() functions from the sipmsgops OpenSIPS module.
protect against SQL injection by escaping variables or performing input validation before passing them to functions such as avp_db_query()
usage of exec functions is inherently dangerous and it seems to happen more often than one would assume
DDoS is hard to protect against; he recommends hiding behind DDoS protection services

The attacks described as inside attacks are very interesting and seem to warrant their own presentation and blog posts in our opinion.

References:

Mirai botnet article and DDoS attacks

Alan Quayle pointed us to the IEEE story covering the Mirai botnet that was run by teenagers. This is a fascinating story and in many ways is very interesting to us since we do DDoS testing and have been presenting about the topic.

References:

VoIP Uncovered - penetration testing article

A new article about VoIP pentesting was published on Security Boulevard, a security news and blog website. This is the first of a series of blog posts about the topic and actually provides the reader with an introduction to SIP and VoIP security and covers SIP reconnaissance. Of interest, it lists the following test cases:

Enumerating SIP servers
Extension enumeration and number harvesting
Capturing SIP authentication
Eavesdropping calls
Packet sniffing and packet drop / black hole attacks
Capturing authentication using SIP dump
Offline cracking SIP digest response hashes
Online brute-force attack
Password spraying extensions
Caller ID spoofing / flooding
Voicemail spoofing
VLAN hopping from data network to voice network
RTP injection
Signalling manipulation
Identification of insecure services
Testing for default credentials
Application level vulnerabilities
Voicemail attacks

For recon, the author makes use of a tool by Pepelux called sippts and uses it against our own demo.sipvicious.pro. Read the rest of the article here.

3CX again in the security news

Cybernews reported that their research team discovered open Elasticsearch and Kibana instances belonging to a third-party vendor of 3CX, the PBX vendor. The researchers found that call metadata, license keys and database strings were available publicly on the Internet. The article mentions the recent 3CX compromise and tries to correlate the two incidents and draw certain conclusions.

However, it seems that the affected party is not actually 3CX but rather a 3CX distributor. If this is the case, then such a security incident would not usually fall under the responsibility of 3CX. As a vendor, you are not responsible for what your clients do with their own servers, especially when the attack vector (ELK stack) is not part of your product-line.

Reference: https://cybernews.com/security/3cx-data-leak-third-party/

Discord C2 using RTP

A pentester called Vincent Mentz published a free tool called DCVC2 which stands for Discord Voice Channel C2. What is interesting here is that while most Discord Command and Control servers make use of the chat feature for communication, Vincent’s new tool makes use of the voice feature of Discord by sending and receiving RTP.

References:

iOS and MacOS SIP vulnerability

Ivan Fratric from Project Zero reported a vulnerability in the iOS/macOS telephony library (libIPTelephony.dylib) that is triggered through specially crafted SIP messages. This sort of vulnerability is especially interesting as the library is used during VoLTE calls and thus might be triggered through the baseband on Apple’s iPhone.

This vulnerability has now been fixed, is tracked as CVE-2023-32412 with public details from Google are published at https://bugs.chromium.org/p/project-zero/issues/detail?id=2440.

BIG-IP products fix to SIP DoS vulnerability

BIG-IP’s products were issued a security update for a vulnerability that seemed to be triggered through SIP. According to the vendor’s CVSS score, the vulnerability affects the availability of the system, thus leading to denial of service when triggered. It sounds somewhat similar to another security fix by BIG-IP that was issued back in February.

References:

CVE-2023-3215 - use after free fixed in WebRTC

A high severity vulnerability has been fixed in WebRTC in Google Chrome and is tracked as CVE-2023-3215. No technical details are published yet, other than the following:

[$3000][1446274] High CVE-2023-3215: Use after free in WebRTC. Reported by asnine on 2023-05-17

Reference: https://chromereleases.googleblog.com/2023/06/stable-channel-update-for-desktop_13.html

SRS command line injection vulnerability fixed

SRS is a simple, high-efficiency, real-time video server supporting RTMP, WebRTC, HLS, HTTP-FLV, SRT, MPEG-DASH, and GB28181. The included api-server was vulnerable to a standard command injection vulnerability, which was reported by the GitHub Security Lab team and then fixed.

References:

Kamailio’s CVE-2020-27507 now detected using vulnerability scanners

Back in March this year, a CVE was assigned to a Kamailio vulnerability that was actually fixed in October 2020. Thanks to this, vulnerability scanners that rely on versioning to detect security issues, can now detect potentially insecure versions of Kamailio. Tenable’s Nessus scanner recently added a check for this, as (we would guess), did other scanners.

References:

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