VoIP and WebRTC
Security Articles and News

Details about CVE-2020-26262, bypass of Coturn’s default access control protection

Video demonstration

The following demonstration shows the security bypass of the default coturn configuration on IPv4:

Background: why does coturn have default access control rules in the first place?

TURN servers are an important part of many WebRTC infrastructures because they make it possible to relay the media even for hosts behind restrictive NAT. We wrote about this extensively in the post called How we abused Slack’s TURN servers to gain access to internal services. To summarize: from the perspective of a pentester, a TURN server is very similar to a proxy server, allowing relaying of TCP connections and UDP packets. One somewhat obvious problem is that attackers can abuse these TURN servers to connect to network services behind the firewall, such as those on the TURN server itself. To address this problem, coturn prevents connections to loopback IP addresses 127.0.0.1 on IPv4 and [::1] on IPv6. This default protection mechanism has been there since coturn version 4.5.1.0 ‘dan Eider’ which was released back in November 2018.

Bug discovery diaries: uncovering sngrep overflow issues with blackbox fuzzing

Executive summary (TL;DR)

During OpenSIPIt, we crashed sngrep by mistake while briefly fuzzing OpenSIPS. Later on we setup a docker environment to reproduce the issue, identified the actual bugs and reported them upstream. If you want to learn the simple steps to do this, you actually have to read the rest of the post :-)

sngrep crash during the live OpenSIPit event

Last year we participated in OpenSIPIt’s interoperability testing event which was held between the 14th and 15th of September 2020. Amongst the topics discussed were RFC8760 (SHA-digest), STIR/SHAKEN and RFC8599 (push notifications). Whilst trying to stick to the agenda, we couldn’t resist the temptation to fuzz test the servers that were available to us. An instance of OpenSIPS was tested for a very short period of time, however, we did not observe any server crashes.

SIPVicious PRO beta release contains SIP fuzzer and better automation

We just made SIPVicious PRO v6.0.0-beta.1 available to our beta testers. This latest release brings a new SIP fuzzer and enhancements for automation to your favourite RTC offensive security toolset. We have the following highlights with this release:

• New fuzzing tools - sip fuzz method. This used to be in a separate internal tool called gasoline (see our toolset page); this now been polished and has joined the SVPRO toolset; this has been used to identify vulnerabilities in Kamailio (advisory), sngrep (advisory 1 and 2) and other SIP servers.
• Tool results provided at the end of a test are now standardized with a JSON schema so that they can easily be parsed or used to produce reports by third-party tools. See the documentation about automation and results.
• Exit codes updated for future compatibility when using it within automation systems. See the documentation about signal handling and exit codes.
• Full IPv6 support across all tools.
• Documentation site is now refreshed, and central to SIPVicious PRO at https://docs.sipvicious.pro.
• And of course, various bug fixes. Full changelog can be seen here.

How doing QA testing for SIPVicious PRO led to an Asterisk DoS

Executive summary (TL;DR)

While heavily testing SIPVicious PRO for bugs, we encountered an unexpected crash in Asterisk. We reported this to the Asterisk team, who recently issued a fix. If you’re a vendor, you too can beta test SIPVicious PRO!

How the Asterisk crash was found

We test our software as much as we can because, like any other software, ours contains bugs too! When it comes to SIPVicious PRO, one of our quality assurance tests is to run it against instances of Asterisk and Kamailio and check for expected results. Our test suite loads these servers in a docker environment and automatically runs SIPVicious PRO against these targets. During these tests, we look for crashes, race conditions and other unchecked states that we might have failed to address in our own code. We do this through various methods, one of which is to observe exit codes in SIPVicious PRO that indicate the result of the test.

ClueCon Weekly with Sandro Gauci, demonstration of SIP Digest Leak

ClueCon weekly is a regular video by the people behind Freeswitch and Signalwire, hosted by the very friendly David Duffet. I had the pleasure of recording an interview and a presentation with David a few weeks back. If you would like a summary of what the video chat was about, scroll down to the points below. Otherwise, hope you enjoy the chat as much as I did!

Summary

Here’s an outline of what went on:

RTC Security chat at Kamailio World Online with Daniel and Olle

It’s been a month already since the Kamailio World RTC security chat! The conversation included Daniel-Constantin Mierla and Olle E. Johansson from the Kamailio project and myself. Daniel is the lead developer of Kamailio, can be found at ASIPTO while Olle is behind Edvina.net.

If you don’t have time to watch the entire conversation, the following is my summary of this discussion:

The great Kamailio security debate and some misconceptions debunked

Introduction

The Kamailio community has always been very welcoming to us since our first connection in 2015 where I gave a dangerous demo showing the open-source version of SIPVicious scanning the Internet and discovering all sorts of SIP devices. Since then, we’ve been contributing through presentations at Kamailio World each year, highlighting various security concerns for the RTC community and the occasional security report and advisory urging people to upgrade their Kamailio. One thing that I personally appreciate is the positive reception of security reports and the security fixes that are made very quickly available in the public git repository.

Smuggling SIP headers past Session Border Controllers FTW!

Executive summary (TL;DR)

SIP Header smuggling is a thing; in some cases it may be super-bad. It affected Kamailio and we have published a Github project to easily demonstrate and test this for yourself. Kamailio has since fixed the issue in release 5.4.0 but similar issues are likely to affect other SBCs.

Usage of special SIP headers

When it comes to trusted SIP networks, one of the primary ways that information is passed across different hops is through SIP headers. Some of these headers are quite standard, such as the P-Asserted-Identity header, while many are custom and specific to the requirements of the business logic and infrastructure. During our work, we have seen headers being passed to identify authenticated customers, to store information such as the source IP for a particular SIP message (which could be used for authentication purposes), to pass the name of the SIP trunk originating a call and of course, for billing purposes.

Kamailio World Online SIP and VoIP Security Panel

On 2nd September, 14:00-14:30 Berlin time, the author of this post is joining Olle E. Johansson to chat at Kamailio World online about (guess what?) SIP and VoIP security, and recommendations on how working from home impacts security. I very much look forward to our discussions that will be streamed live on the Kamailio World youtube channel!

My arguments will likely be turned into an opinion piece later on, but they’ll likely steer towards the following thoughts:

Bug bounty bout report 0x01 - WebRTC edition

Read the full report here.

In April 2020, in between SIPVicious PRO development and VoIP Pentesting and WebRTC, we dedicated some days to bug bounties and vulnerability disclosure programs to see what comes out of it. Our focus was on those that have WebRTC infrastructure in scope. In the end, we reported 3 vulnerabilities to 4 different vendors, for 6 different products. So finally, after making sure that the affected vendors have addressed these security issues and have agreed with publication, we are putting out a compiled report!