Skip to main content


OpenSIPIt'01: Lessons learned, STIR/SHAKEN security testing and RFC 8760

Published on Apr 16, 2021

Executive summary (TL;DR)

  • It was a great event, highly recommended if you’re a SIP developer.
  • We developed new STIR/SHAKEN capabilities in SIPVicious PRO.
  • And we found some vulnerabilities during the event that got fixed in the process.

What was OpenSIPIt#01 about?

This week the humble security researchers from Enable Security participated in OpenSIPIt#01, an online event run by the community to test interoperability across various independent open-source SIP implementations especially when it comes to new RFCs. Various parties participated, including:

  • Sippy Labs
  • OpenSIPS
  • Kamailio
  • FreeSWITCH
  • Asterisk
  • Sipfront
  • Enable Security

Mainly organized by Maxim Sobolev from Sippy Labs, Liviu Chircu from OpenSIPS and with the help of David Duffett, it was quite a successful event. The main purpose was to test the various implementations of both RFC 8760 as well as STIR/SHAKEN. The RFC 8760 brings SHA-256 and SHA-512 to SIP Digest authentication so that SIP Digest authentication can actually avoid using MD5. On the other hand, STIR/SHAKEN is meant to allow for the identity in SIP calls to be verified, thus targeting caller-ID spoofing. All in all, it was an excellent event because the systems on test, although running some pretty new code, were able to communicate with each other. And of course, a number of bugs were squashed from everyone’s side (including us of course), which actually is one of the main ways to measure the success of such an event!

Our work at OpenSIPIt#01

The first task that we carried out was to verify that the different implementations of RFC 8760 were correct, since we happened to have already implemented support for that in SIPVicious PRO during a previous event, OpenSIPIt#00, held back in September 2020. That was useful for everyone involved.

More interestingly, however, was the 3rd day where we actually had a slot dedicated to security testing. We developed new functionality in SIPVicious PRO to add support for STIR/SHAKEN’s Identity header which was useful for two main tasks:

  • Fuzzing
  • Manual testing

With regards to fuzzing, our internal build of SIPVicious PRO now has the capability of sending Identity headers with signed JWT headers, payloads, as well as invalid or malformed signatures and fuzzing the Identity header itself without any signing capability. This allowed us to identify some issues in the OpenSIPS implementation of STIR/SHAKEN which led to crashes. For an example, see this commit.

The manual testing, thanks to STIR/SHAKEN support in the SIPVicious PRO call utility, allowed us to do various tests. We especially focused on the x5u or info parameters which allow specification of a URL pointing to the public certificate for the service provider signing the call. What we found was that almost all implementations did not validate the URL which meant that we could specify non-HTTP protocols such as file://. So when we specified file:///dev/random as the location of the certificate, the following implementations ended up not taking it too well, ending up in a DoS state:

  • Asterisk
  • Kamailio with libstirshaken
  • FreeSWITCH with libstirshaken

In the case of OpenSIPS, the configuration in place was doing a check for the URL, checking if it is starting with http:// or https:// which meant that it was not vulnerable to this attack.

Short presentation about our tests

We gave this quick presentation, in preparation of the actual tests:

Presentation on security testing of RFC 8760 and STIR/SHAKEN at OpenSIPIt

What we learned

One thing that we learned from this event was that our efforts are actually appreciated. It is a pleasure to work with developers who are passionate about real-time communications and open source moving forward and show active interest in ensuring that stuff not only works, but is actually also robust and secure.

From a more technical standpoint, we validated our concerns that STIR/SHAKEN is quite complex and increases the attack surface of the systems in place. Otherwise we wouldn’t have had the results that we did!

And finally, we learned that we’re not the only ones struggling to make sense of all the different nuances and exceptions in each RFC or group of RFCs that we need to support in the RTC or VoIP world.

Our next steps

We hope to keep being of help to the open-source RTC community and participate in future OpenSIPIt events. In the meantime, we’ll be polishing our STIR/SHAKEN features and then making them available to our SIPVicious PRO members. And expect future blog posts delving deeper into what we’re learning about security testing of STIR/SHAKEN implementations on this blog.