Skip to main content

Celebrations, presentations and new VoIP security tools

Published on Oct 31, 2022

Welcome to a jam-packed edition of RTCSec newsletter for October. What have we this month?

In this edition, we cover:

  • This very newsletter is one year old!
  • We’re looking for freelance pentesters to join us
  • This time, 12 years ago in VoIP security incidents (Sality botnet scanning)
  • Upcoming and past presentations of interest at TADSummit, CTI-Summit, Blackhat & ClueCon
  • WebRTC security news: the “most secure VoIP” award and censorship busting
  • New VoIP security tools and workshop by Jose Luis Verdeguer (Pepelux)
  • And various security advisories, and other reports of concern

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 me 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

Happy birthday to RTCSec newsletter!

We launched this newsletter back in October 2021 which makes it now one year old. And growing it has been, covering more and more VoIP and WebRTC security related matters each month. As always, if you have suggestions, we’re all ears. And if you think it is useful to any of your friends and colleagues, do share it with them or let them know that they can subscribe here: https://rtcsec.com/subscribe.

We are looking for Freelance Penetration Testers

We’re looking for pentesters who love dealing with network protocols, debugging obscure behaviors and perhaps, share a familiarity with real-time communications security. Do you know someone (maybe you!) who might be fit? Please find the description of the role here: Penetration Testers - Freelancer/Contract-based & Remote

Distributed SIP scanning, 12 years ago over Halloween weekend

Apart from scoring one year since we launched RTCSec newsletter, this month also marks 12 years since we first observed distributed SIP scanning in the wild. The traffic came from a botnet that had deployed a modified version of SIPVicious OSS. Eventually we learned that this botnet was called Sality which was documented later in 2011.

References:

What’s happening?

TADSummit 2022 is happening on 8 and 9 November

GoContact will be hosting TADSummit 2022 next month, where yours truly will be presenting about DDoS as they affect real-time communications systems. I will also be joining Alan Quayle in coordinating a workshop / discussion session about this very topic. While many of the scheduled talks are not RTC security specific, the following might be interesting to this audience:

  • Open Source Telecom Software Survey Results. Alan Quayle (covers various aspects of security)
  • eSIM as Root of Trust for IoT security. João Casal, Head of R&D at Truphone
  • Playing at the intersection of CPaaS and Digital Identity. Kola Layokun, Telesign
  • What Everyone Needs to Know about Protecting the CPaaS Ecosystem from Unlawful Robocalls. Gerry Christensen, VP YouMail
  • Supercharging CPaaS Growth & Margins with Identity and Authentication. Aditya Khurjekar, GM Prove Protocol

If you’re around, do come say hello! And if not, check out the timings and live-stream the sessions of interest.

References

WebRTC is the most secure VoIP protocol

Bloggeek.me published a new post explaining why WebRTC is by design, the most secure “VoIP protocol”, as opposed to traditional SIP-based VoIP. The article is short and to the point, listing why WebRTC is superior, essentially because (I quote):

  • It is encrypted
  • Requires signaling to be encrypted
  • Enables end-to-end encryption via media servers by using Insertable Streams

At round tables and in various private conversations, this has also been my personal conclusion. If you are designing a new RTC solution, it makes a lot of sense to make use of WebRTC because of the various built-in security advantages. That said, I have also argued that the WebRTC attack surface is quite large given the number of protocols, layers and applications involved. This makes it a very interesting target especially since almost every WebRTC solution relies on just a few software projects in combination with various custom signalling protocols. So, although I would recommend WebRTC for new projects, I would also caution that in terms of threat modelling, one has to account for more elements and complexity than in a simpler SIP-based VoIP solution.

In response to the Bloggeek.me’s article, Nir Simionovich wrote the following on his Linkedin:

WebRTC is superior to traditional VoIP in many aspects - however, as you stated yourself - it’s just a building block. And just like any other block, in the hands of the unskilled - it’s a ticking time bomb.

An encrypted media and signalling layer doesn’t help, if your implementation doesn’t account for proper authorization. An encrypted signalling layer doesn’t do any good if the payloads are predictable.

In other words, WebRTC is awesome in providing the developer with the right tools - but like any other tool out there, it doesn’t explicitly enforce a “secured solution design”. It is the job of the various platforms and libraries to provide an “opinionated” WebRTC design/architecture/work-flow, to ensure the developed applications are really secured.

Over the course of the past 15 years I’ve helped companies secure their VoIP products. Same applies for the past 6 years with WebRTC. We invested countless hours into designing our platform worksflows, to ensure tighter security and privacy - be it traditional VoIP (SIP) or WebRTC. Please don’t turn WebRTC into 1999’s equivalent of a firewall - it’s not a magical solution or a silver bullet. It’s just a tool - a good one - but even the best hammer can smash your finger.

Reference to the original article: https://bloggeek.me/webrtc-is-the-most-secure-voip-protocol/

Snowflake uses WebRTC data channels to bypass censorship

Tor project describes Snowflake in these ways:

Snowflake is a system that allows people from all over the world to access censored websites and applications.

Snowflake is a new WebRTC Pluggable Transport.

Snowflake is a kind of Tor bridge that allows bypassing of censorship in non-democratic countries such as Iran. It allows you to help people in those countries and fight censorship, through one of the following methods:

  • opening relay.love website
  • installing the official Snowflake browser extension on Firefox or Chrome-based browsers so that it runs in the background
  • running a standalone open source software on your computer.

Additionally, Tor users also need to enable the option to use Snowflake bridges to benefit from this technology.

References:

New sippts released

Sippts is toolset to audit SIP-based software and devices by Jose Luis (Pepelux) Verdeguer. It consists of modules to find SIP services, enumerate SIP extensions, crack extensions, exploit vulnerabilities such as digest leak, RTP bleed and a lot more. While sippts used to be written in Perl, since version 3.0.0 it has been rewritten in Python.

Sippts version 3.2 is out with new modules and features. SipTshark is a new module that allows extracting and analyzing SIP messages from PCAP files. SIPSniff module which was available in Perl version, is also ported to Python. This module allows monitoring and capturing SIP traffic. Sippts also introduced a new module for ARP spoofing. Of course, it helps attackers to perform SIP MiTM scenarios, but does it make sense to have that in a SIP audit toolset?

This version has been released with several improvements and new features in existing tools. A SIP fuzzer, RTP injection tool and a WebSocket module are also under development.

Sippts is free and open source and includes useful tools for SIP and RTP audit. Since its development has become active again, it is worth tracking its updates.

References

Presentation video for Phreaking 2.0, abusing MS Teams Direct Routing is out

Defcon has published the video for the presentation by Moritz Abrell that we covered last month. It is a bit more funny than reading the original article or our coverage last month. Give it a watch here:

https://www.youtube.com/watch?v=LXxcVi2MMe8

Other references:

Talk about telecom signalling threat actors at CTI-Summit

Alexandre De Oliveira from POST Luxembourg gave a presentation at the Cyber and Threat Intelligence Summit on 19th October, called Actors and threats targeting telecom signalling networks. Unfortunately this talk was not recorded and we were not present at the conference. But Alexandre has been kind enough to provide us with the slides. The impression I get is that there are some nasty threat actors out there that are definitely not interested in advancing the state of telecommunications security. I wish I had attended the talk to hear the full details!

The summary of the presentation read as follows:

We are seen in the last few years a democratization of telecom signalling attacks. State actors joining forces with large surveillance companies and rogue operators. Over the last year we have been investigating and trying to retrace who are hidding (sic) behind the malicious nodes we see everywhere attacking our networks. This presentation will retrace a part of this story mixing OSINT and HUMINT.

Reference: https://cti-summit.org/talks/alexandre-de-oliveira.html

Kamailio using OpenSSL (1.0.2k-fips) reportedly crashes under heavy load

A mailing list post by Ihor Olkhovskyi described his experiments with various TLS libraries. What caught our eye is the mention that the OpenSSL library provided Centos 7 leads to a crash on high load. He used @Pepelux’s opensource Sippts, to generate the traffic.

Reference: https://lists.kamailio.org/pipermail/sr-users/2022-October/115636.html

VoIP auditing workshop by Pepelux

Jose Luis Verdeguer, also known as Pepelux, is giving a workshop on VoIP security audits at various locations: Madrid (Spain) this month, in Bogota (Colombia) in November and in Seville (Spain) also in November. He was kind enough to share his slides with us.

The workshop is in Spanish but it definitely touches upon topics that are relevant to anyone dealing with VoIP infrastructure and applications. He covers topics such as RTP Bleed and RTP inject, MITM for SIP, SRTP, attacks involving SIP INVITE as well as product specific vulnerabilities. This seems like a workshop worth attending for Spanish speakers interested in the topic. On top of that, Pepelux is the author of sippts, an open source tool that implements many of the attacks described in his workshop.

References:

Practically-exploitable Cryptographic Vulnerabilities in Matrix

The Blackhat EU conference is bound to happen in December and while skimming through the presentation titles, we noticed the following two:

  • Practically-exploitable Cryptographic Vulnerabilities in Matrix
  • How We Organize Large-Scale DDoS Exercises in the Netherlands

The talk about the Matrix vulnerabilities will cover security issues that have been addressed in an update and described in a write-up on the Matrix blog (mentioned last month). The researchers involved have created a website where they explain the background and provide the associated paper.

References:

Blackhat EU talk about organising large-scale DDoS exercises

The second presentation at the upcoming Blackhat EU that looked interesting is called How We Organize Large-Scale DDoS Exercises in the Netherlands.

The following comes from the session’s description on the conference’s website:

The Dutch Anti-DDoS Coalition will be discussed during the presentation, briefly introducing the various working groups. One of the working groups is organizing large-scale DDoS exercises. The working group organizes large scale DDoS exercises in a RED/BLUE team setting twice a year, currently working towards a PURPLE team environment.

This is a “Lessons Learned” session from members of the Dutch Anti-DDoS Coalition covering technical as well as organisational and legal aspects of organising such an exercise. Although it seems very specific to Dutch online services, would a similar model be useful for the VoIP and the general RTC industry?

Reference: https://www.blackhat.com/eu-22/briefings/schedule/#how-we-organize-large-scale-ddos-exercises-in-the-netherlands-28542

ClueCon 2022 talks of security interest

The following are some talks given at ClueCon earlier this month, that go into RTC security topics:

How Cloudflare does WebRTC with WHIP & WHEP

If you’re interested in learning the actual technical details of Cloudflare’s WebRTC offers, you might need to do a bit of blackbox analysis. Or you could check out what Gustavo Garcia and Philipp (fippo) Hancke wrote on the webrtcHacks website. We quote the text on the topic of security here:

Cloudflare relies on the standard WebRTC encryption based on DTLS for the key negotiation and SRTP for the media encryption.

The server negotiates a “passive” setup attribute which means the browser is the DTLS client. This is typically done to let the server negotiate the more advanced (and less CPU-heavy) GCM SRTP cipher suites, however, we still see the AES_CM_128_HMAC_SHA1_80 cipher.

The article is somewhat entertaining, detailing potential bugs noticed during Wireshark tracing and various other oddities.

Reference: https://webrtchacks.com/how-cloudflare-glares-at-webrtc-with-whip-and-whep/

Jitsi addresses 3 security issues and publishes advisories

The Jitsi project has issued security fixes for jitsi-meet, lib-jitsi-meet, jicofo and jigasi. The fixes for Jitsi-meet address two encryption related vulnerabilities found by some of the same people behind the Matrix cryptographic vulnerabilities:

  • Fail-open media decryption, which results in media being rendered as if it were end to end encrypted (and authenticated), when the traffic is actually not (i.e. an integrity bypass)
  • Misleading cues on unsupported clients, where users would hear an “E2EE is ON” audio when it is actually off

As for the other two advisories, the vulnerabilities affecting Jicofo (the Jitsi conferencing server-side element) and Jigasi (the Jitsi gateway to SIP) are DoS vulnerabilities which affect the conferencing functionality. They are both triggered through specially crafted XML stanzas. These were reported by the Jitsi Team themselves, so it seems like someone fuzzed XMPP and observed the results!

References:

XMPP Stanza Smuggling vulnerability in Cisco Jabber

Back in May 2022, we covered an XMPP Stanza Smuggling vulnerability in Zoom which could lead to RCE. The security researcher that had originally discovered this vulnerability, Ivan Fratric from Project Zero team, has now also reported a critical XMPP Stanza Smuggling in Cisco Jabber.

So what are these security issues in XMPP about? XMPP is an XML-based protocol and an XMPP Stanza Smuggling vulnerability happens when an XML parser fails to parse XML properly. This allows attackers to send arbitrary XMPP stanzas (control messages) which are considered trusted by the XMPP client since they should only arrive from legitimate XMPP servers.

For XML parsing, Cisco Jabber uses a modified version of gloox library, the library that has also been used in Zoom. In this case, this vulnerability happens because of modified functionality in the library that changes <stream:stream> XML tag behavior. The functionality resets the parser state in an inappropriate place which introduces the vulnerability. XMPP Stanzas are very sensitive and running arbitrary Stanzas on a client may lead to unpleasant incidents. What’s the most dangerous thing that can be done by an attacker who has somehow compromised a Jabber/XMPP server and is able to send arbitrary XMPP Stanzas to the clients?

Reference: https://bugs.chromium.org/p/project-zero/issues/detail?id=2319

Short news and commentary

  • Vicidial v2.14-783a - Multiple XSS Web Vulnerabilities

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