Skip to main content

Kamailio’s exec module, SIPVicious still ringing phones and many vulnerabilities

Published on Jan 31, 2023

This new year starts off with a number of RTC security related news and we have some original content to share with you too!

In this edition, we cover:

  • Our news: The dangers of using the Kamailio exec module and our pentesting schedule
  • Our news: Updates to the awesome RTC hacking list
  • The Threema weaknesses paper from ETH Zurich
  • Presentations of interest from Blackhat and Nullcon Berlin
  • Receiving calls on your deskphone from SIPVicious - still happening!
  • Various vulnerabilities in Cisco products, Juniper and Chrome’s WebRTC

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.enablesecurity.com/newsletter/.

Our news

Penetration testing or security assessment in 2023? (advert)

If you’re subscribed to this newsletter, chances are you’re also thinking about pentesting your RTC products and services in 2023.

At the moment we’re working on filling our work schedule for Q2 2023. If you’d like to be included in our thoughts, reply to me or contact us.

The dangers of using the Kamailio exec module

Kamailio is one of our favorite SIP servers … so we wrote about the most obvious ways that it can be insecurely configured, leading to remote code execution. Our new article is about the exec module.

The summary reads as follows:

  • 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.

Thanks to the Kamailio developers for quickly reviewing and accepting our updated documentation pull request!

Read the entire post here: https://www.enablesecurity.com/blog/kamailio-exec-module-considered-harmful/

Updated Awesome RTC hacking & pentesting resources list

The Awesome real-time communications hacking list has been updated with the following from last year:

  • blog posts related to VoIP and WebRTC security:
    • MSTeams Direct Routing abuse
    • OpenSSL CVE-2022-0778 vs WebRTC applications
    • our latest blog post - Kamailio’s exec module considered harmful
  • VoIP Hopper added to the list of open-source tools

Check it out at https://github.com/EnableSecurity/awesome-rtc-hacking

What’s happening?

Threema weaknesses paper was published and the drama

Security researchers from the Applied Cryptography group at ETH Zurich published a paper outlining 7 attacks that affected Threema, often advertised as the most secure messenger. The paper was published on its own domain, called breakingthe3ma.app and comes together with a logo. The vendor addressed all security issues quickly, within weeks. They also upgraded the protocols involved to address some of the vulnerabilities outlined as well as previously known issues.

Threema also published a blog post which downplays or disputes the claims made on the Breaking Threema website (published by the researchers). They wrote that none of them ever had any considerable real-world impact and that the attacks assume extensive / unrealistic prerequisites such as physical access to an unlocked Android device.

Then, of course, the usual Twitter drama ensued.

Heated online debates aside, it is worth heeding or at least considering the researchers’ lessons, which were the following (quoted):

  1. Using modern, secure libraries for cryptographic primitives does not, on its own, lead to a secure protocol design: libraries such as NaCl or libsignal can be misused while building more complex protocols and developers must be wary not to be lulled into a false sense of security. While the mantra don’t roll your own crypto is now widely known, it should be extended to don’t roll your own cryptographic protocol (assuming one already exists that meets the developer’s requirements). In the case of Threema, the bespoke C2S protocol could be replaced by TLS.
  2. Beware of cross-protocol interactions: even if a protocol on its own is considered secure, there is no a priori guarantee that it will be secure when composed with other protocols. Cross-protocol interactions can undermine the original security guarantees, as we have shown with the vouch box forgery and Kompromat attacks. Such bad interactions can be prevented by following the key separation principle which states that a system should use different keys for different purposes.
  3. Proactive, not reactive security: our inability to find an attack on a protocol does not imply it is secure. New attacks could be found at any moment and known attacks only get stronger over time if left unaddressed. Often, secure systems and protocols follow a design-release-break-patch process (a reactive approach). This is inconvenient for users and often requires the maintenance of backwards compatibility. Developers should instead adopt a proactive approach, where the system or protocol is formally analyzed during the design stage.

The attacks outlined were the following:

  1. Ephemeral key compromise impersonation (network attacker)
  2. Vouch box forgery (network attacker)
  3. Message reordering and deletion (compromised server)
  4. Replay and reflection attacks (compromised server)
  5. Kompromat attack (was actually previously fixed but included because they rediscovered it) (compromised server)
  6. Cloning via Threema ID export (compelled access)
  7. Compression side-channel (compelled access)

Primary references:

Together with the researcher’s website, and Threema’s statement blog post, we recommend those interested in the details to read (or listen to) the following:

Blackhat EU 2022 presentations of interest - slides & paper

The Blackhat EU conference happened in December and it included a two presentations that caught our eye. The first one was about the Matrix vulnerabilities called Practically-exploitable Cryptographic Vulnerabilities in Matrix. We covered this one in the October edition of this newsletter. The related material can now be accessed here:

The second presentation of interest was called How We Organize Large-Scale DDoS Exercises in the Netherlands and describes the Red/Blue team efforts of the Anti-DDoS Coalition. We especially like the slides about the attack infrastructure; taking note that in their exercises, based on the slides at least, they seem to be using well known tools such as the thc-ssl-dos.

On the other hand, the presentation is much more than that. It describes the different phases of the exercise, the organisational (and legal?) aspects and more. We hope to watch the presentation itself in the near future.

Friendly reminder about friendly scanners calling in the middle of the night

Google’s alert service sent us a notification about a forum post where someone was asking about incoming calls on their Grandstream phone. In this case, the CLID display was sometimes showing “SIPVicious”. This is usually the result of the SIP phone being exposed to the Internet and simply ringing whenever anyone from anywhere sends it a SIP INVITE message.

Back in 2012, we had published a post about this very topic called If SIPVicious gives you a ring…. It is a recommended read and answers many of the questions that people have when facing this issue.

Read the forum post here: https://forums.thinkbroadband.com/voip/4729179-aa-voip-settings-for-grandstream-ata.html?fpart=all&vc=1

VoIP hopper still maintained and up on Github!

Our friend Jason Ostrom still maintains VoIP hopper, which is a penetration testing tool for jumping from one (voice) VLAN to another. This tool was first published back in 2007!

You know that WiFi network called Company voice or those desk phones connected to the same network as the PCs? The problem with many voice networks is that they are often on the same physical network as the data network, but simply use a different VLAN. Since such phones are often not making use of network transport encryption, and are exposed in various other ways, they can be easily compromised. In such cases, the main protection mechanism tends to be network access control, in part through the use of VLANs. This tool makes it easy to get to the juicy voice networks. It is maintained at the following address:

I tried to compile it on the latest Fedora. This unfortunately failed due to a dependency that requires a specific RPC library that seems missing in the Fedora ecosystem. On the other hand, on an old Ubuntu 18, it compiled just fine. The best way to run VoIP Hopper is probably on Kali Linux but that might miss the latest and greatest updates.

webrtcH4cKS interviews coturn’s new project leads

The new project leads for coturn, Gustavo Garcia and Pavel Punsky, participated in an interview by Chad Hart. They talked about how and where coturn is used and the fact that its usage seems to actually be growing. The most interesting part of this interview for us is the focus on security issues. In fact, this has been one of the important topics and in 2022 they helped address the following in coturn:

  • Multiple memory issues (use after free, memory overwrite)
  • Multiple memory leaks (allows for DoS)
  • Crashes that can be easily triggered externally (resulting in DoS)
  • STUN buffer that may include data from other allocations

The developers spoke about how they would like to handle security vulnerabilities better and notify the user-base more promptly in the future:

webrtcHacks: Do you do anything different for critical security and maintenance issues?

Pavel: There is no precisely defined and spelled out policy. The last issue that was raised (that had a smell of security and widespread impact) was discovered and immediately addressed by a contributor. We released a new version ASAP but did not notify anywhere. We should have done that - this is something we should work on (establishing communication practices) in 2023.

That issue was a memory corruption-related issue this past December.

This is definitely positive progress for a project that is quite critical for anyone developing a WebRTC solution or needing a STUN and TURN server. We hope to contribute to the project later this year through more security vulnerability reports.

Check out the full interview here: https://webrtchacks.com/coturn-no-time-to-die-qa-with-new-project-leads/.

Upcoming talk at Nullcon about Intercom hacking

The Nullcon Berlin conference has a talk by Vera Mens from Claroty with the title of The Silent Spy Among Us - Modern Attacks Against Smart Intercoms. This sounds very interesting and we’re told that the details will be published after the talk has been delivered.

Here is the excerpt:

Recently our company had to move to a new office. When we came in the morning, at the entrance, we noticed a new shining smart intercom device equipped with a built-in camera. Intrigued, we decided to dive in and see how (in)secure it is.

This talk will explore how we hacked smart cloud-based intercoms. We will explain how modern intercoms operate and how they leverage new technologies and protocols related to VOIP communications - the delivery of voice communications and multimedia sessions over the internet. SIP, SDP, STUN, and RTP are just some examples.

In the end, we found multiple vulnerabilities in the device itself and in the connectivity with the cloud platform. Exploiting the vulnerabilities enabled us to gain pre-auth remote code execution, see images from all cloud-connected devices, and silently open remote video streams.

This is in line with what we have observed in our research. These intercom systems have gone full IOT mode, which means running well-known SIP stacks on top of Linux or in some cases, Android. They are often not too well audited and therefore, upon a little bit of prodding, a lot of fun is to be had!

We very much look forward to the talk which will be given in March.

Reference: https://nullcon.net/berlin-2023/the-silent-spy-among-us

Unauthenticated SSRF on Cisco BroadWorks CommPilot (CVE-2022-20951)

Cisco BroadWorks, the cloud calling and collaboration platform, has a management application called CommPilot, which was vulnerable to a high severity SSRF.

“This application exposes a servlet that allows the application to be used as an HTTP proxy server”, explained the vulnerability researchers. The security issue is a result of the lack of URL validation, which empowers attackers to access internal assets and send GET, HEAD, and POST requests.

While the Cisco advisory says that exploitation requires authentication, the team behind the discover says otherwise, calling it an unauthenticated vulnerability. The confusion might be in the interpretation of authentication, since the researchers found that the authentication protection could be easily bypassed. They published a write-up on this finding which contains technical details of the vulnerability which is linked below.

References:

SQL injection in Cisco Unified Communications Manager (CVE-2023-20010)

A high severity (CVSSv3.1: 8.1) authenticated SQL injection vulnerability has been discovered in Cisco Unified Communications Manager. Cisco has published the advisory on January 18th and has suggested updating as below:

  • From 11.5(1) you need to migrate to a fixed release
  • From 12.5(1) update to 12.5(1)SU7
  • From 14 update to 14SU3 (Mar 2023)

So if you use Unified CM or Unified CM SME, you should update. However, if you run Unified CM version 14, there is no workaround, and no released fixes yet; so it might be good to monitor users’ behavior or turn off the servers ;)

Reference: https://securityaffairs.com/141039/security/cisco-unified-communications-manager-cve-2023-20010.html

Critical heap overflow on Sofia-SIP (CVE-2023-22741)

In November 2022 we covered this heap-overflow vulnerability in Sofia-SIP. Last week the Freeswitch team published an advisory for this vulnerability with the details that Qiuhao Li the researcher behind this discovery had posted to the GitHub issue of this bug.

This vulnerability happens due to the lack of length check on message and attribute when the library handles STUN packets. This vulnerability affects Sofia-SIP <= 1.13.10.

Since network users control the overflowed length, and the data is written to heap chunks later, attackers may achieve RCE by heap grooming or other exploitation methods.

From the advisory

Stay safe by updating to v1.13.11 or a newer version.

Reference: https://github.com/freeswitch/sofia-sip/security/advisories/GHSA-8599-x7rq-fr54

Junos OS SIP ALG vulnerabilities fixed

Four high severity CVEs have been published for SIP ALG of Juniper Networks Junos OS. These vulnerabilities allow unauthenticated users to cause DoS. SIP ALG probably reminds you of the NAT Slipstream research by Samy Kamkar et al. A glamorous history of vulnerabilities and problems has encouraged people to turn SIP ALG off. A simple search will reveal a number of articles and blog posts suggesting disabling this option. In this newsletter, we have also often suggested a similar solution.

These CVEs are assigned to the following vulnerabilities:

Based on the advisories, this issue affects Juniper Networks Junos OS on MX Series and SRX Series:

  • 20.4 versions prior to 20.4R3-S5
  • 21.1 versions prior to 21.1R3-S4
  • 21.2 versions prior to 21.2R3-S2
  • 21.3 versions prior to 21.3R3-S1
  • 21.4 versions prior to 21.4R3
  • 22.1 versions prior to 22.1R1-S2, 22.1R2
  • 22.2 versions prior to 22.2R1-S1, 22.2R2

Authentication Bypass in Cisco IP Phone 7800 and 8800 Series Web Management Interface (CVE-2023-20018)

An authentication bypass vulnerability has been discovered in Cisco IP Phone 7800 and 8800 series. Vulnerable versions allows attackers to exploit the vulnerability to access the web management sections which require authentication.

To protect against this vulnerability you need to update the firmware as below:

  • With IP Phone 7800 and 8800 Series (Except Wireless IP Phone 8821) earlier than 14.1(1)SR2 update to 14.1(1)SR2.
  • With Wireless IP Phone 8821 earlier than 11.0(6)SR4 update to 11.0(6)SR4.

Reference: https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-ip-phone-auth-bypass-pSqxZRPR

CVE-2023-0472 - use after free in Google Chrome WebRTC

Google Chrome has been updated to fix a number of security issues, including CVE-2023-0472 which affects WebRTC. There is very little public information at the moment other that this is a use after free vulnerability in WebRTC that’s been reported by Cassidy Kim (@cassidy6564) and that the reporter was awarded $3000 for this.

Does this also affect other browsers that use the WebRTC project? We look forward to answers.

Reference: https://chromereleases.googleblog.com/2023/01/stable-channel-update-for-desktop_24.html

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