Skip to main content

SIP ALG exploit hits Realtek SDK, our Attack Platform and holidays

Published on Aug 31, 2022

In the summer time, the weather is hot … August is usually a slow month in our part of the world and a good time to take a holiday and relax a bit. We tried that for ourselves and found out that the rumors are true, holidays are not overrated. But, we didn’t stop for too long because, actually, we have news!

In this edition, we cover:

  • Our news about the Enable Security Attack Platform and Gasoline v2
  • Buffer overflow in Realtek’s SIP ALG affecting many many routers (CVE-2022-27255)
  • More router exploitation leading to SIP credentials leakage (Arris / CVE-2022-31793)
  • TLS ALPN identifier for SIP
  • SELinux policies and Kamailio/OpenSIPS
  • And 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

Enable Security’s Attack Platform being used by customers

One of our primary internal projects at Enable Security has been what we call the Attack Platform. We built this for ourselves to run many of our security tests and especially for DDoS simulations. Although this is not the first time that we built something like this, one clear difference is that the Attack Platform is actually useful to our customers.

After a penetration test or Denial of Service simulation, we can now make the platform available to our customers to run their own tests and consistently reproduce the issues that we found. Because it is a platform, the infrastructure needed for such tests is taken care of. And, yes - we had our first customer actually using this without any hand-holding. That’s definitely what I call a win! (or at least a very decent start)

I know that I’m not giving away enough information in this short piece but if you want to learn more, do get in touch by replying to this newsletter or here.

Gasoline v2 giving us decent results

One other tool that has been in active development is Gasoline v2. Our Chief Demolition Officer, Alfred has been busy trying to fulfil some of his most wicked dreams with this piece of software. While version 1 of Gasoline was mainly a tool for SIP and RTP fuzzing, version 2 is protocol-agnostic. Instead, it is focused on speed optimization, network throughput and supports DoS and fuzzing tests for generic, templatable protocols. In terms of speeds, we’re seeing some amazing numbers that are useful for our DDoS simulation tests.

So far, we have used it for SIP flooding and fuzzing, RTP flooding, HTTP API flooding and fuzzing and done samples showing that it can be used for various other protocols.

What’s happening?

Buffer overflow in Realtek SDK affects SIP ALG (CVE-2022-27255)

Realtek have fixed a stack overflow vulnerability in their SDK for eCos OS which affected the SIP ALG. Since the vulnerability is in an SDK which is used in various (third-party) routers, it seems that a large number (millions?) of devices might be vulnerable. At the time of writing, the researchers list 30 different devices that they say are vulnerable. So how bad is it?

The security issue was reported by the Faraday Security team and they presented this at the Defcon conference this month. Long story short - they got remote code execution on the vulnerable routers.

Exploitation requires the attackers to send a SIP message with a malformed SDP body to the vulnerable device, which triggers a stack buffer overflow that seems pretty exploitable. In their Defcon presentation, they explain that it can be triggered on the WAN interface too. This being SIP over UDP, it is easy to imagine attackers randomly spraying the Internet with a payload that triggers the vulnerability.

We seem to cover vulnerabilities in SIP ALG implementations every month or two on this newsletter. As we always say:

disabling SIP ALG will reduce your attack surface

In this case, exposure to this vulnerability would depend on the how the SDK is implemented (i.e. SIP ALG being enabled) and in many cases, also the ISPs configuring these devices. This means that many end (home) users probably have little say about this feature being enabled. And patching this stuff will probably take a long time because of the various parties involved.

That said, this is certainly impressive work and the research team released their tools and presentation on Github. Gracias for that!

Further reading:

SIP now has a registered TLS ALPN identifier

This one came in very late, so I’ll just paste Olle E. Johansson’s post about it:

Hi!

I’ve successfully registred a TLS ALPN identifier for “SIP/2” with IANA

https://www.iana.org/assignments/tls-extensiontype-values/tls-extensiontype-values.xhtml#alpn-protocol-ids

The ALPN identifier is used to identify “next protocol after TLS handshake is complete” to the server. This means that a server that serves multiple protocols on the same port, like a SIP server with support for both SIP/TLS and HTTPS can serve both protocols without algorithms to guess which protocol that is used.

For this to be successful, implementers need to start supporting it in SIP user agents :-) and servers, like Kamailio and others, will need to implement support.

Cheers, /O

Arris routers path traversal and more

Arris Routers are used by various ISPs as their customer premises equipment solution. The vendor patched a number of vulnerabilities, one of which was a path traversal issue in the web interface tracked as CVE-2022-31793.

Since these routers often have phone calling/VoIP functionality, the path traversal vulnerability gives easy access to the SIP configuration files on the router. This includes SIP credentials - which means, stolen SIP accounts for toll fraud.

The security researcher’s report helpfully explains that:

there are at least 19,000 Internet-facing likely vulnerable routers exposed directly to the Internet

References:

SELinux policies and Kamailio/OpenSIPS

Someone posted on the Kamailio users mailing list asking about “confined processes”. It seems that the poster is concerned about this due to a scan by a security tool that identified Kamailio as running as an unconfined process. Henning Westerholt, core Kamailio developer, explained that there is no publicly available SELinux policy for Kamailio. His suggestion is to create their own policy and to share it with the community.

I would suppose that any SELinux policy for Kamailio or OpenSIPS will need major customisation, since their configuration is typically quite custom. A blog post on Computing for Geeks about installing Kamailio Rocky Linux, AlmaLinux or CentOS suggests setting SELinux to permissive mode or to disable it. That said, given the importance of such SIP entities, it seems like a worthwhile effort in trying to harden them with SELinux.

Did any of the RTCSec readers create any SELinux policy for Kamailio or OpenSIPS? What has been your experience? Do write back and let us know!

Reference: https://lists.kamailio.org/pipermail/sr-users/2022-August/115245.html

Presentation about XMPP stanza smuggling given at BH2022

Back in the May edition of this newsletter, we covered Ivan Fratric’s research on XMPP stanza smuggling. He gave a presentation at the Blackhat USA briefings titled “XMPP Stanza Smuggling or How I Hacked Zoom”.

The presentation material is available: https://www.blackhat.com/us-22/briefings/schedule/index.html#xmpp-stanza-smuggling-or-how-i-hacked-zoom-26618. And he just made a video of his demo available on Youtube, where he shows the full exploit chain to get RCE and run, of course, calc.exe.

Watch that here: https://www.youtube.com/watch?v=mnCpFy_-fCc.

Remote code execution in Discord and Element

Discord and Element desktop clients run on top of Electron, and both have had vulnerability details published in the past month. The research was presented at Defcon by Max Garrett formerly of Cure53 and Aaditya Purani.

In the case of Discord, the bug was reported back in June 2021. It started with a cross-site scripting vulnerability, not in Discord itself but rather in one of the trusted third-party sites, Vimeo. The video sharing platform does not make it so easy to exploit XSS since it implements a restrictive content-security-policy (CSP) and disallows external scripts. But the Discord client uses a Chromium version that was actually vulnerable to a CSP bypass, so the researchers chained the bypass and the XSS to achieve the classic JavaScript alert box. A sandbox bypass for busting the iframe sandbox security feature and finally, a V8 exploit (CVE-2021-21220) led to a proper RCE with the calculator being popped.

How would this be normally exploited? An attacker would need to send a link to their malicious website that embeds a Vimeo link through a Discord chat message. The victim, it seems, needs to actually try to play the video and perhaps click on a button for the iframe sandbox bypass to work.

With Element, well - it has a feature where it supports external Jitsi calls, on custom self-hosted servers. This obviously seems like a bad idea so Element enables full sandbox to avoid trouble. The researchers, again, were able to bypass the sandbox using various techniques - this time to send inter-process communication (IPC) commands, with another V8 exploit (tracked as CVE-2021-37975) and lots of l33tness.

The vulnerability in Element was fixed back in Jan 2022 and is tracked as CVE-2022-23597. In the advisory, the developers note that exploitation requires clicking on a malicious link, followed by another button click and that the attacker does not have the ability to specify program arguments.

References:

Coturn causing port scans?

Philippe Hancke pointed me to an issue on the coturn project with the title of Provider detects a lot of port scans in private IP range.

As Philippe explains in his reply:

This is not a port scan and your provider is misclassifying this. ICE is attempting to create a pair between the relay port opened on the server and the local IP address of the peer. This is unlikely to work.

Blocking those ranges (as suggested by this great post) should work but you might want to monitor P2P connectivity establishment rates in your app before and after to verify this.

It is a feature not a bug!

Reference: https://github.com/coturn/coturn/issues/932

Short news and commentary

Tweet of the month

The tweet of the month award goes to Ivan Fratric / @ifsecure for properly filling in the HackerOne Customer Satisfaction Survey for the Zoom vulnerability.

To appreciate this, once has to see the screenshot on Twitter: https://twitter.com/ifsecure/status/1560722669074493443

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