Skip to main content

WebRTC 0day, FreePBX not Asterisk attacks and talks at MCH2022

Published on Jul 29, 2022

It is the end of the week as well as July and the RTCSec newsletter is in your inbox eagerly waiting to give you all the educational entertainment you need throughout the weekend!

In this edition, we cover:

  • Our TADSummit talk and SIPVicious PRO details
  • FreePBX exploitation and confusing reports
  • Remote coverage of the talks at the Dutch hacker camp
  • CVE-2022-2294 - the vulnerability in the WebRTC project
  • Vulnerabilities in Matrix, BigBlueButton, JunOS and more
  • Tweet of the month on VoIP phone hardware hacking

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

The latest

Last month we issued new SIPVicious PRO builds to our members, with new fuzzers and also DoS tools included for extra mayhem!

Speaking of (virtual) destruction, I will be presenting at TAD Summit in Portugal with a talk called “How to bring down your own RTC platform. Running DDoS simulations on your own.”.

Here’s the outline:

  • Why would you want to do such a thing?
  • Preparing for destruction
  • Running the tests - best practices
  • What happens after the fact
  • Moving forward towards more robust RTC

The event takes place on 8/9 November at GoContact’s offices in Aveiro, Portugal.

Changes coming to the SIPVicious PRO membership (sponsored)

We are in the process of making major changes to our subscription offers to provide more value to our members. As a result, we’ll be adjusting the pricing to reflect these updates.

If you were thinking of subscribing for SIPVicious PRO, get in touch to see if the current model still makes sense for you.

What’s happening?

Confusing security reports and FreePBX exploited to install backdoors

Palo Alto’s Unit 42 published about their analysis of exploitation of FreePBX and Elastix systems. What they did inspect is the web shell, a PHP backdoor, that was dropped on these systems. So the post’s main information is around what the compromise does which consists of the creation of system accounts with root privileges, a scheduled task that keep the system infected and the web shell of course.

The authors are clearly not sure which vulnerability was exploited in these intrusions but indicated that it should be CVE-2021-45461 - which we covered back in January 2022 on this newsletter.

Another interesting observation is that exploitation and infection is actually used to check through the configuration of Asterisk, presumably to steal SIP credentials to be used in toll fraud.

Unfortunately, the post by Palo Alto is otherwise quite confusing and the mainstream media covering it exacerbated the effect. The posts and news seem to indicate that Digium’s PBX and/or phones were compromised. Or that Elastix is used in Digium phones. None of these are correct since FreePBX is not required to run Asterisk and is definitely not the same software. FreePBX is essentially a GUI (mostly written in PHP) that makes it easy to run a unified communications system on top of Asterisk.

It is also not clear at all that Elastix is EOL or no longer based on Asterisk or FreePBX since its acquisition by 3CX back in 2016.

This confusion is highlighted in posts on the Asterisk mailing list and the FreePBX forums. In fact, Sangoma issued an official response to try to get the facts straight.

Original article:

News coverage:

Confusion on the forums/lists:

Official statement from Sangoma:

Talks of interest at MCH2022

MCH2022 was an outdoor hacker camp which took place on 22nd to 26th July in the Netherlands. Unfortunately, none of us managed to attend this time but the videos are out and we have watched the ones that have any resemblance to RTC security. Here are a few words about these talks.

Audio networks and their security implications

This talk was about AES67 and its lack of security. AES in this case does not stand for the Advanced Encryption Standard, but rather Audio Engineering Society and AES67 is a technical standard for audio over IP and audio over Ethernet interoperability. It is a layer 3 protocol suite.

Audio networks these days use IP just like anything else, and if they do - they should be using the AES67 standards. They’re found in some very interesting places, such as theatres, live music events, conferences, house of worship, transport hubs (i.e. train stations), supermarkets, campuses and the Olympics!

What could go wrong? The presenter explains that attackers who can get on to a network that is delivering AES67 traffic, should be able to create denial of service or insert their own audio and video streams. This reminds me of the RTP inject attack that we like to abuse in our RTC offensive security exercises. He gave the following as potential attack objectives:

  • damage human hearing
  • damage equipment
  • mass panic
  • reputation / misinformation
  • snooping

The talk explains how in AES67, the audio receivers rely on the Precise Time Protocol (PTP) to get the timing right. Attackers who disrupt this, get to cause problems related to alignment (I guess between audio and video streams?). This protocol has no builtin authentication mechanism thus anyone on the network can become the main PTP server. The presenter shares two ways to achieve this - one by rigging PTP elections and the other is through IP traffic flooding while setting the right DSField IP header.

He also explained how to hijack the audio streams using either of two methods. The first one involves sending Session Announcement Protocol packets with a Session Description Protocol SDP body, to the multicast address. The second one involves sending RTP packets and taking over the RTP stream by setting the timing of the RTP packets in a specific way.

Audio engineers, similar to PBX administrators of old, are not used to having IP-based security threats. Traditionally, their security threats were physical in nature. By putting these devices on the IP networks, the sort of security issues that we all know and love (or hate), become accessible to live audio systems too. But, there are proposals for usage of SRTP and improvements on PTP.

All in all, this seems like a very interesting and fun area to look into from a security perspective. And it includes protocols that are very familiar in the RTC space.

RE-VoLTE: Should we stop the shutdown of 2G/3G to save lives??

This one was a talk about how right now, VoLTE over 4G or 5G often does not work when roaming. In such cases, phone handsets fall back to 2G and 3G where roaming actually works pretty well. This is especially important because being able to make emergency calls to 911 or 112 phone numbers is priceless at the time of need.

So, what happens when 2G and 3G are switched off, as just happened with AT&T this month? Then, it seems, roaming callers are not allowed to make emergency calls. This talk is a call-to-action to fix this.

OpenRAN – 5G hacking just got a lot more interesting

The presentation by Karsten Nohl made sense to me even if not everyone I spoke to is convinced. Nohl’s main point is that because OpenRAN is mostly on Kubernetes (cloud), it inherits problems of IT systems rather than just traditional Telco-specific vulnerabilities. This is why mobile networks or 5G hacking becomes more interesting and accessible to mere mortal security researchers like ourselves. So you might have developers who mess up and expose some vulnerable system on the Internet that gives access to the Kubernetes infrastructure where the 5G components exist. And any other number of potential entry points - phishing for example - become a major problem for telcos. Finally, he talks about patch management and all the usual security solutions that apply to cloud-based platforms.

Thanks to Alan Quayle for pointing me towards this one!

This presentation is given by the Dutch duo, Daan Keuper and Thijs Alkemade from Computest who used a 3-bug chain to exploit Zoom messenger and won 200k USD at Pwn2Own last year.

So they examined the XMPP traffic that Zoom uses in its chat protocols and found the advanced chat encryption setting that is sort of hidden since it is only available for paid accounts. This functionality was vulnerable to a buffer overflow that was triggered by.. quote:

sending a ResponseKey message with an AES-encrypted <encoded> element of more than 1024 bytes

The presentation was almost 50 minutes long but they still did not cover all the details that are available in their blog post from last year. If you are interested in the full details, look at https://sector7.computest.nl/post/2021-08-zoom/.

Someone from the audience asked them how long the whole work took them. Their answer sounded right to me - 2 weeks to find the vulnerability and one and a half months to develop the exploit for the competition.

The smart home I didn’t ask for

The smart home made use of XMPP which is what caught my attention. There is no mention of RTC and the presenter’s focus was on the smart home controller (which is an Android tablet), the mobile app and the XMPP traffic. The talk is quite interesting and I thought the most entertaining highlight is the part where he found how to open the front door of his apartment building by simply sending an HTTP GET request.

This also got me thinking that there is an RTC component because it seems that you can speak through the microphone on the tablet to anyone outside of your house, with the video intercom feature. XMPP is useful for setting up calls between clients so it is very likely that RTC security issues apply here.

We have not yet tested any such systems but I’m sure it would be a lot of fun!

Other talks

There were a few other talks that I went through. There was one about Signal the secure messenger, called Signal: you were the chosen one! It is ranty and not technical but can be interesting if you care about messaging, federation and other topics that get geeks passionate. Here: https://media.ccc.de/v/mch2022-196-signal-you-were-the-chosen-one-

Security issue in WebRTC project abused to deliver spyware

A heap buffer overflow vulnerability was fixed in the WebRTC project used by all web browsers. It is being tracked as CVE-2022-2294. The vulnerability report is not yet public, but will be published at https://crbug.com/1341043 at some point.

Here’s a timeline of what we know:

  • 2022-07-01: Avast Threat Intelligence informed Google about the WebRTC vulnerability and exploitation
  • 2022-07-04: Google Chrome released a critical security fix for a heap overflow in WebRTC tracked as CVE-2022-2294
  • 2022-07-06: Microsoft adopted patch by Chromium and issued a fix in MS Edge
  • 2022-07-20: Apple released a patch for Safari
  • 2022-07-21: Avast actually released a blog post about their side of the story

The post from Avast is well written and although it does not detail the vulnerability at all, it does go well into how it was abused by a spyware vendor from Israel known as Candiru. The targets were in Lebanon and included journalists’ Windows computers which, upon successful exploitation, would be fully compromised (at system level).

The attack makes use of an exploit chain that includes CVE-2022-2294 (the WebRTC buffer overflow) as the entry point, then a sandbox escape in Chromium, then delivery of the spyware (DevilsTongue) and finally a signed (i.e. legitimate) kernel driver which allows an exploitation technique known as Bring Your Own Vulnerable Driver. The sandbox escape was not captured by the Avast team so it is likely that this vulnerability will exist for a longer time.

Given that the WebRTC project is used in all web browsers that support WebRTC, this vulnerability affected all web browsers. Exploitation will need to cater for any extra protection mechanisms which will differ from one web browser to another. That said, it is clear that the exploit developers are able to bypass these as they did with the Chrome sandbox escape.

There’s a bright side here, maybe. As an end user, no worries - just restart your web browser to apply the latest updates!

References:

Matrix Synapse DoS due to URL preview

On 28th June, the Matrix project issued a fix for a DoS vulnerability tracked as CVE-2022-31052. The vulnerability involves nested nodes which, when abused, leads to memory exhaustion.

Advisory: https://github.com/matrix-org/synapse/security/advisories/GHSA-22p3-qrh9-cx32

BigBlueButton security vulnerabilities fixed

BigBlueButton is an open-source web conferencing system often used in education to deliver virtual classrooms. They recently fixed a number of high severity security issues:

The attack surface of such systems is quite large since they have so many components put together into a complete platform. It tends to be an interesting exercise to contemplate the impact of the vulnerabilities above. For example, proper abuse of DoS vulnerabilities would mean that classes get postponed, affecting the students’ schedule and progress.

The security researchers who reported the username XSS vulnerability also issued a blog post with details and animations showing exploitation here: https://pentests.nl/pentest-blog/stored-xss-in-bigbluebutton/

A brand new JunOS SIP ALG DoS has been fixed

Tracked as CVE-2022-22204.

Juniper issued a new fix on the 13th July for Junos which addresses a “partial DoS” in their SIP ALG functionality. What they mean by partial is that exploitation only affects SIP traffic and does not bring down the entire network device. This means that the severity rating is medium rather than high.

The advisory from the vendor also includes a note saying that the issue was seen during production usage and that they’re not aware of malicious exploitation of this vulnerability.

Our comment: given the amount of SIP ALG DoS vulnerabilities that we have been noticing from various network equipment vendors and if such things are coming out in production usage, a good question is - are they not fuzzing this stuff?

We know someone who can help!

As usual, our recommendation (similar to the vendor’s incidentally):

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

Vendor advisory: https://supportportal.juniper.net/s/article/2022-07-Security-Bulletin-Junos-OS-MX-Series-and-SRX-Series-When-receiving-a-specific-SIP-packets-stale-call-table-entries-are-created-which-eventually-leads-to-a-DoS-for-all-SIP-traffic-CVE-2022-22204?language=en_US

Short news and commentary

Tweet of the month

Security research on an old VoIP phone:

@frycos tweeted:

Wanted to do some research on an old VOIP phone. Forgot web UI password, reset didn’t work

  1. Desoldered the flash (heat gun)
  2. Fixed pin outs with a scalpel
  3. Dumped flash with xgecu
  4. strings + _reverse.py
  5. Got password 💪
  6. Realized that I destroyed the device 🤦

Image included in original tweet: https://twitter.com/frycos/status/1544422201549619200

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