Tags › Kamailio

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!

Kamailio’s exec module considered harmful

Executive summary (TL;DR)

• The combination of pseudo-variables and Kamailio’s exec can be risky and may result in code injection.
• By using special SIP headers and environment variables, it becomes effortless to exploit a vulnerable configuration.
• We have created a Docker environment to assist readers in reproducing this vulnerability and testing solutions.
• Protection is tricky and the official documentation may have previously misled developers - we aim to fix that by updating the module’s official documentation.
• Kamailio configurations should use a strict allow list or avoid the module altogether.

Introduction to Kamailio’s exec module and its capabilities

The Kamailio SIP server ships with a module for executing external commands from within a Kamailio configuration. The topic of this article is how the exec module may be misused to lead to remote code execution vulnerabilities. The default Kamailio configuration, which is used as a starting point for many live installations, does not make use of this module. On the other hand, we have seen this module being used in various production environments and have, in the past, found some of these installations to be vulnerable.

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.

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: header smuggling via remove_hf bypass

• Fixed versions: Kamailio v5.4.0
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2020-01-kamailio-remove-hf/
• Reproduction tools: https://github.com/EnableSecurity/advisories/tree/master/ES2020-01-kamailio-remove-hf
• References: CVE-2020-28361
• Tested vulnerable versions: 5.3.5 and earlier
• Timeline:
  • Report date & issue patched by Kamailio: 2020-07-16
  • Kamailio rewrite for header parser (better fix): 2020-07-16 to 2020-07-23
  • Kamailio release with fix: 2020-07-29
  • Enable Security advisory: 2020-09-01

Description

Kamailio is often configured to remove certain special internal SIP headers from untrusted traffic to protect against header injection attacks by making use of the remove_hf function from the Kamailio textops module. These SIP headers were typically set through Kamailio which are then used downstream, e.g. by a media service based on Asterisk, to affect internal business logic decisions. During our tests and research, we noticed that the removal of these headers can be bypassed by injecting whitespace characters at the end of the header name.

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:

Kamailio: off-by-one heap overflow

• Authors:
  • Alfred Farrugia alfred@enablesecurity.com
  • Sandro Gauci sandro@enablesecurity.com
• Fixed versions: Kamailio v5.1.2, v5.0.6 and v4.4.7
• References: CVE-2018-8828
• Enable Security Advisory: https://www.enablesecurity.com/advisories/ES2018-05-kamailio-heap-overflow/
• Kamailio Security Advisory: https://www.kamailio.org/w/2018/03/kamailio-security-announcement-tmx-lcr/
• Tested vulnerable versions: 5.1.1, 5.1.0, 5.0.0
• Timeline:
  • Report date: 2018-02-10
  • Kamailio confirmed issue: 2018-02-10
  • Kamailio patch: 2018-02-10
  • Kamailio release with patch: 2018-03-01
  • Enable Security advisory: 2018-03-19

Description

A specially crafted REGISTER message with a malformed branch or From tag triggers an off-by-one heap overflow.

Impact

Abuse of this vulnerability leads to denial of service in Kamailio. Further research may show that exploitation leads to remote code execution.