Skip to main content

We’re hiring, new SIPVicious PRO tools, advisories and blog post galore

Published on Apr 27, 2022

Welcome to the April edition of the RTCSec Newsletter. We have a lot this month, and this must be the most packed newsletter so far.

In this edition, we cover:

  • We’re hiring!
  • Our blog post explaining how OpenSSL’s CVE-2022-0778 is a problem in WebRTC environments
  • Latest SIPVicious PRO news
  • Various blog and news posts:
    • 3CX pre-auth RCE explanation
    • Open SIP relay abuse ITW
    • How LAPSUS$ probably abused VoIP
    • OpenSIPS’ new TCP module versus DoS attacks
    • Cisco Expressway and Telepresence VCS vulnerabilities
  • A new tool to exploit STUN and TURN servers called stunner, from Firefart
  • Advisories and vulnerabilities fixed (or not) in:
    • FreePBX
    • pjsip
    • Asterisk PBX
    • JunOS
    • WebRTC
    • Cisco Expressway and Telepresence VCS
  • We bring back the Tweet of the month!

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

We’re looking for a Penetration Tester / Security Researcher (advert)

Do you know someone who might be fit? Forward this newsletter or send them to this link: https://hs.enablesecurity.com/join-us/pentester

Exploiting CVE-2022-0778, a bug in OpenSSL vis-à-vis WebRTC platforms

Last month’s newsletter came out with a new video showing exploitation of OpenSSL’s CVE-2022-0778 DoS vulnerability in a WebRTC context. After that, we published a blog post with further details.

The TL;DR is that in the case of WebRTC applications, an outdated OpenSSL may mean that the server is vulnerable to a very nasty DoS, which is easy to trigger once you have the tools (which are not that easy to build). And that you should, in such cases, upgrade your OpenSSL.

Here’s the outline:

  • Background story about how I got lured into looking at this bug vis-a-vis DTLS
  • How bad is DoS in a WebRTC context? Why do we rate it as a critical vulnerability?
  • Exploitation of this vulnerability against our own WebRTC demo server
  • How did we reproduce this in SIPVicious PRO?
  • Which other projects might be impacted?
  • Solution is to upgrade your OpenSSL

Read the full post here: https://www.rtcsec.com/article/exploiting-cve-2022-0778-in-openssl-vs-webrtc-platforms/

SIPVicious PRO next version sneak peak and Docker images

A new version of our toolset is coming out to our members. This one includes the following new experimental tools:

  • rtp fuzz - fuzz RTP packets to discover potential problems in media servers, user-agent clients, and anything processing RTP really
  • sip fuzz server - a SIP server that sends SIP clients (UACs) malformed SIP messages
  • sip utils iterator - if you know Burp Suite PRO, this is very similar to the Intruder tool but for SIP; and if you don’t, think of it as a webapp fuzzer, but for SIP
  • tcp flood - a DoS tool that opens a large number of TCP connections and keeps them open

On top of that, we’re adding experimental features to existent stable tools:

  • STIR/SHAKEN flooding support in sip dos flood
  • STIR/SHAKEN support in sip utils call
  • support for multiple source IPs for sip dos flood

Of course there are quite a few enhancements and bug fixes to the existent tools but we leave that for the actual release notes.

On a related note, we also released a docker image so that SIPVicious PRO can be easily run on various systems, including MacOS M1 machines, without needing to install extra dependencies.

Pre-auth remote code execution in 3CX phone system

Right after we published our March newsletter, @frycos released a post called Pwning 3CX Phone Management Backends from the Internet. It details how vulnerabilities were found in the PBX’s web interface, how the vendor fixed some of the issues, but still had bypasses and then finally addressed the issues found properly.

We love the conclusion:

Finally, the blog post ends, for now. No CVE(s), no logo, no website…just like that. ¯_(ツ)_/¯

At the time, it looks like the blog post got censored with certain parts of the original article marked as Temporary removed. Perhaps the vendor complained about something that they didn’t fix yet. But don’t forget, the Internet doesn’t forget ;-)

Reference: https://medium.com/@frycos/pwning-3cx-phone-management-backends-from-the-internet-d0096339dd88

Open SIP relay abuse in the wild, on the ’net

Our friend, Ivan Kwabena Nyarko, wrote about SIP traffic arriving to his honeypots that was being bounced off open SIP relays. The interesting part was that, upon inspection of over 1000 unique source IPs, he noticed that the traffic was relayed mainly through Ingate’s SBCs.

Here’s a quick summary:

  • how Ivan noticed this behavior and how we (yes, I helped :)) tried (and failed) to work with the vendor to get to the bottom of this
  • an explanation of how an open SIP proxy can be abused and how to prevent this issue
  • details about the actual SIP traffic seen on the honeypots, originating from a VPN provider
  • how to test your SIP proxy for this vulnerability using a free tool from none other than kwancro!

The blog post explains how these devices acted as SIP open proxies and if you’re managing a SIP proxy, what to look for so that it doesn’t relay illegitimate traffic. The author gives the example of how Kamailio has a default check to avoid this behavior, which if removed, would also exhibit similar vulnerable behavior.

Together with this blog post, Ivan also published a new free online tool to test your SIP proxy for this behavior.

The blog post can be read here: https://www.kwancro.com/post/open-proxy-abuse/

The SIP open relay test can be tried here: https://kwanlabs.com/

ps. if you know anyone with access to such devices from Ingate, please do get in touch so that we can try to reproduce this issue and issue a proper advisory.

New tool out called stunner by Firefart

Christian Mehlmauer (firefart) released a new tool which he called stunner (see note below). It helps testers exploit STUN and TURN servers and is meant to replicate the vulnerabilities that he found and reported in vulnerable Cisco Expressway systems.

It has the following features:

  • information gathering
  • range-scan which tries to determine if the TURN server allows connections to private IPs
  • socks server, which starts a socks5 server and relays traffic through the TURN server
  • brute-transports that helps enumerate transports supported by the server (not entirely clear what this is)
  • memory leak exploit of the TURN server found on the Cisco devices
  • udp-scanner that can scan private IP ranges and send SNMP and DNS requests
  • tcp-scanner that can do the same but over TCP and sends out HTTP requests

The tool is at https://github.com/firefart/stunner.

The related blog post and vulnerabilities found are covered in this newsletter too.

About stunner

Just in case anyone noticed, the tool is given the same name as our internal tool that we talk about on our blog posts and in our reports: https://www.rtcsec.com/tags/stunner/. We never actually published our tool by the name of stunner.

This is not the same tool, the author was not very creative when naming this particular tool.

LAPSUS$ probably used VoIP for their social engineering attacks

The hacker group LAPSUS$ caused a lot of trouble lately, breaching companies such as Microsoft, NVIDIA, Okta and Samsung. What caught our attention in this case is the mention of VoIP services by Brian Krebs while reporting about advanced persistent teenagers.

The interesting part is that for their intrusions, they used vishing or voice phishing that involves calling people and trying to social engineer them into doing your bidding. For this, they probably used VoIP services to call their victims from spoofed numbers and hide their tracks.

The techniques sound like a mixture of old school (gives me flashbacks of the Hackers movie from 1995) together with the 2022 realities of remote work. But sticking to our favourite topic - VoIP security. Their abuse of VoIP services is what could be expected since spoofing phone numbers is often a feature rather than a bug. Unfortunately, this allows adversaries to create very convincing scenarios so at least one victim in large organisations will very likely fall prey to their plot and open up the virtual gates.

Reference: https://krebsonsecurity.com/2022/04/the-original-apt-advanced-persistent-teenagers/

OpenSIPS fine-grained TCP configuration

OpenSIPS 3.3 introduces a new module which offers full control over the configuration of individual TCP connections. From filtering by the employed TCP-based protocol (e.g. BIN, TLS, MSRP, SMPP, etc.), all the way down to specific combinations of remote and local IPv4 or IPv6 addresses, OpenSIPS platform developers now have the ability to cherry-pick and fine-tune any of the TCP connections taking place on their OpenSIPS server.

This sounds useful, and it is of interest to us because in our SIP DDoS simulation work, we often find problems that are specific to TCP connections.

It is often the case that legitimate users/customers need specific settings (such as specific timeouts) that increase the exposure of the target system to DoS vulnerabilities. Therefore, having fine-grained TCP configuration possibilities seems like a really useful feature in environments where one single configuration won’t cut it.

We look forward to learning how this new module might be helpful in creating solutions that are less susceptible to DoS.

Reference: https://blog.opensips.org/2022/04/20/fine-grained-tcp-configuration-using-the-tcp_mgm-module/

FreePBX potential RCE

Yet another potential remote code execution in FreePBX was fixed. No proper details were published about this but it is considered a major vulnerability.

A quick check of the latest changes shows that the developers added file format validation for a CSV file upload. This issue requires normal (non-admin) privileges for exploitation and affects the voicemail, core, sms, and pms modules.

Read the original advisory here: https://wiki.freepbx.org/display/FOP/2022-04-12+SECURITY%3A+Potential+RCE+Issue

Thanks to Võ Văn Thông who originally reported this issue and answered our questions! And also Rob Thomas for this tips ;-)

New Asterisk PBX advisories

The Asterisk PBX project released 3 security fixes, two of which affect their STIR/SHAKEN implementation and one which affects a function that’s meant to prevent SQL injection. They’re the following:

The main problem with STIR/SHAKEN implementations is that the Identity header needs to reference the location of the public certificate which leads to SSRF-like functionality. This leads to all sorts of security implications.

These are the sorts of things that we were reporting in the past OpenSIPit as well as SIPit events with regards to STIR/SHAKEN implementations. Unfortunately, even though the Asterisk developers did participate in OpenSIPit, their implementation at the time was not entirely ready to be tested for this issues. We did, however, report very similar issues in other projects and made the information public. We’re glad that they got to fix these issues at this stage.

References to our past work on this topic:

With regards to the SQL injection fixes, it seems that this is very specific to one’s database configuration and the official resolution is to use a new dialplan function SQL_ESC_BACKSLASHES in such cases.

Thanks to Ben Ford from Sangoma and Clint Ruoho for reporting and fixing these issues!

CVE-2022-22198 SIP ALG Junos DoS

The description for this advisory reads as follows:

An Access of Uninitialized Pointer vulnerability in the SIP ALG of Juniper Networks Junos OS allows an unauthenticated network-based attacker to cause a Denial of Service (DoS). Continued receipt of these specific packets will cause a sustained Denial of Service condition. On all MX and SRX platforms, if the SIP ALG is enabled, an MS-MPC or MS-MIC, or SPC will crash if it receives a SIP message with a specific contact header format. This issue affects Juniper Networks Junos OS on MX Series and SRX Series: 20.4 versions prior to 20.4R3; 21.1 versions prior to 21.1R2-S1, 21.1R3; 21.2 versions prior to 21.2R2. This issue does not affect versions prior to 20.4R1.

We reported something similar in February’s edition of this newsletter about BIG-IP SIP ALG support. The recommendation that we gave in that case still stands:

If you’re running anything like a stateful firewall, disabling SIP ALG will reduce your attack surface.

References:

CVE-2022-1133 WebRTC use after free

Chromium fixed a high severity vulnerability in their WebRTC stack. No details were published yet and the bug report will become available at https://crbug.com/1305776 once published.

It gets the ID of CVE-2022-1133.

References:

More pjsip vulnerabilities fixed

C0ss4ck has been busy fuzzing pjsip and reporting vulnerabilities found. All the past month’s fixes were due to C0ss4ck’s work, except for GHSA-f5qg-pqcg-765m which was reported by Arash Taheri and David Lie.

Further details from C0ss4ck, in Chinese, can be seen here: https://cossack9989.github.io/vuln/2022/04/24/research-on-sip-record-1.html

Great to see an important project such as PJSIP get proper attention, well handled vulnerability reports and official security fixes!

Cisco Expressway and Telepresence VCS vulnerabilities not fixed

Christian Mehlmauer of WienCERT-IT-Security published a blog post about vulnerabilities found in Cisco Expressway’s. One of the main issues that he found was that the TURN server on these devices does not restrict relaying at all, thus exposing internal and localhost services. So this exposed a local web interface that gave read access to a system snapshot which, among other things, contains password hashes which should give access to the underlying system.

TURN servers are required for many WebRTC applications since they allow users to communicate with other users behind NAT. We have published about this in the past on our blog:

Neither the TURN relay abuse nor access to the snapshot were deemed to be security vulnerabilities worthy of a CVE for Cisco. Instead they issued an advisory which informs users that by enabling TURN servers, they might expose internal services such as this web server exposing the snapshot. They add that attackers need TURN credentials to abuse this issue but fail to highlight the fact that, on vulnerable systems, TURN credentials can be retrieved by calling an API that requires no authentication.

On top of that, the researcher found that the TURN server had a memory exposure vulnerability, a bit similar to OpenSSL’s Heartbleed. This particular issue seems to only leak the previous packet so Cisco, again, decided that it is not a valid vulnerability. What is not clear is if the leaked data is always from the attacker or if it could potentially leak normal (victim) user’s data instead in cases where both the attacker and a legitimate user are using the TURN server.

So no patches. Instead, if you have Cisco Expressway Series on your infrastructure, the TURN server should be switched off or at least not exposed to the Internet. This makes little sense to me as the point of Expressway is to allow mobile remote access to to Cisco telephone services and Cisco Jabber.

These issues also affect Cisco TelePresence VCS but this particular product is no longer sold, since 2020 and will stop being supported at the end of 2023.

Read the blog post here: https://firefart.at/post/multiple_vulnerabilities_cisco_expressway/

Tweet of the month!

Tim Panton posted:

Half the security talks at @nullcon have mentioned webRTC. A symptom of #webrtc’s success. A far cry from 4 years ago when I tried to persuade researchers in @BerlinSides audience that there was fun to be had hacking webRTC.

So I asked for more details. After a few tries, he got back to me :-) It wasn’t exactly half the talks but 3 presentations, which is definitely greater than the usual null (pun intended).

So these 3 are the ones that I was talking about:

Possibly not the story that you are looking for, but it does mean that webRTC is at least on the infosec radar at last.

It is great to see that people are starting to look into our favourite topic! From our side, we have seen an uptick of people posting new research that is specific to RTC, such as firefart’s stunner and C0ss4ck’s pjsip advisories. Looking forward to more!

Reference: https://twitter.com/steely_glint/status/1512369456231731204

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