Skip to main content

DDoS workshop at TADSummit, toll fraud via MS Teams Direct Routing and WebRTC news

Published on Sep 30, 2022

This month brings us yet another crammed newsletter all about real-time communications security. So without further ado, welcome to the RTCSec newsletter for September 2022!

In this edition, we cover:

  • An upcoming open position at Enable Security and what we’re brewing for 2023
  • Our talk at TADSummit 2022 and the DDoS workshop
  • Commentary about OpenSIPS Summit and Kamailio World
  • Details about how MS Teams Direct Routing may lead to toll fraud
  • Abuse of the exec modules in Kamailio and OpenSIPS
  • WebRTC related news, about CVE-2022-2294, coturn, Scanbox malware and Cloudflare
  • And much much 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.rtcsec.com/newsletter.

Our news

Upcoming open position at Enable Security

If you are passionate about cybersecurity, have an interest in RTC (thus subscribe to this newsletter!) AND see yourself joining the founding team at Enable Security, send us some details: https://hs.enablesecurity.com/join-us/new-role.

We will provide more information in the coming weeks.

Brewing for 2023 at Enable Security (advert)

Our schedule for Q4 2022 is practically fully, but we have great plans for 2023. We’ll still be pentesting your VoIP / WebRTC applications and platforms but we will also be expanding on our paid membership offers.

If your organisation would benefit from getting dedicated help from us, we will soon have some news for you. From the next year we’ll be offering a combination of security testing software (SIPVicious PRO), offensive security applications and infrastructure (the Attack Platform) and dedicated assistance in the form of consultancy and ad-hoc training. Our aim is to complement security teams that greatly benefit from RTC security expertise. Get in touch if this sounds interesting: https://enablesecurity.com/contact.

What’s happening?

TADSummit talk and workshop in November

I’ll be presenting at TADSummit 2022 in Portugal. The title of the presentation is How to bring your own RTC platform down. Running DDoS simulations on your own.

Then, there is the DDoS workshop which will be coordinated with Alan Quayle, covering:

  • Distinguish between volumetric and application-level DoS
  • Why volumetric/bandwidth saturation is so effective
  • Application-level DoS, appreciate the complexity of the topic
  • Round Robin share on detection, resolution, economics, long term challenges
  • Consensus recommendations

While the presentations at TAD Summit will be streamed, the workshop will be a private session, i.e. offline. We hope that participants can open up and share gems that would otherwise be kept hidden. This is definitely one good reason to meet in person at an event such as TADSummit!

SIP scans coming from VyprVPN / Powerhouse

Ivan from Kwancro wrote a new blog post about what he’s seeing lately on his SIP honeypots. Fred Posner had also been writing on Twitter about distributed SIP malicious traffic coming from VyprVPN.

In this article, Ivan walks us through this thought process as he was investigating these scans in particular. Check it out here: https://www.kwancro.com/post/massive-use-of-vpn/

Additionally, Fred Posner and #APIBAN have been commenting about this on Twitter.

Kamailio World 2022

Earlier in September, Kamailio World for 2022 took place online which was streamed over Youtube over two days. We skimmed through the videos and found the following topics relevant to the audience of this newsletter:

  • Kamailio’s latest versions added support for STIR/SHAKEN, JWT support and a module that’s used to help with OSS-Fuzz troubleshooting
  • A new TLS module for Kamailio called tls_wolfssl, the author, Richard Chan, had a presentation about this

Reference:

OpenSIPS Summit 2022

The OpenSIPS summit happened this week in Greece as well as online. The following were some notes I took while glancing through the online recordings:

  • During his keynote, Bogdan Andrei-Iancu mentioned our work on the OpenSIPS Security Audit
  • Anti-fraud revisited - The new TFPS talk by Flavio E. Goncalves is relevant to many people in the VoIP world and worth a watch
  • Open Source Telecom Survey 2022 by Alan Quayle which touches on a number of security-relevant topics
  • Maksym’s talk called Continuous Integration for the OpenSIPS Project which mentions fuzzing of a few APIs in OpenSIPS, and also mentions our work
  • Various other talks mentioned the importance of the OpenSIPS Security Audit

References:

Abusing Microsoft Teams Direct Routing

Moritz Abrell from SySS gave a presentation at Defcon 2022 called Phreaking 2.0 - Abusing Microsoft Teams Direct Routing. While I did not yet manage to watch this presentation, he also wrote a blog post which explains his findings with regards to MS Teams Direct Routing.

What is MS Teams Direct Routing? It is one of the ways that MS Teams can be configured to interact with your organisation’s VoIP infrastructure, giving MS Teams users access to their organisation’s PBX and also the ability to make calls over PSTN. MS Teams Direct Routing is configured to work with the organisation’s Session Border Controller (SBC). This SBC needs to be configured to allow calls from the Microsoft Teams infrastructure.

The problem that Moritz highlighted is that, when configured according to the official documentation, SBCs end up allowing inbound calls without any actual authentication. The author specifically looked at the AudioCodes SBCs since they are some of the most commonly used products when integrating with MS Teams.

The interaction between the Microsoft SIP proxies and the SBC is done using SIP over TLS. The recommended configuration, according to the documentation, was as follows:

  • the SBC’s FQDN (hostname) must be set as the destination host in the SIP message
  • the string pstnhub.microsoft.com must be included in the host part of the Contact header in the SIP message

When an attacker sends a specially crafted SIP message that fulfills these criteria, the SBC will threat it as a SIP message that is coming from MS Teams, even if it is not actually the case. The author provides a SIPp scenario file and example command to reproduce this issue in the article.

Users of SIPVicious PRO should be able to do the same by making use of the following INVITE template:

INVITE {{.RequestURI}} SIP/2.0
Via: SIP/2.0/{{.AddrFamily}} {{.LocalAddr}};rport;branch=z9hG4bK-{{.Branch}}
Max-Forwards: 70
From: sip:{{.FromUser}}@sip.pstnhub.microsoft.com:{{.LocalPort}};tag={{.FromTag}}
To: {{.ToVal}}
Call-ID: {{.CallID}}
CSeq: {{.CSeq}} INVITE
Contact: sip:{{.FromUser}}@pstnhub.microsoft.com:{{.LocalPort}}
Content-Length: {{.Body | len}}
Content-Type: application/sdp

{{.Body -}}

The command should be something like the following:

sipvicious sip utils call tls://target:5061 --from victim-phone-number -e dest-phone-number --srtp sdes

So what could be done using this attack? Two things mainly:

  • Toll fraud by causing the SBC to make calls over PSTN when the destination phone number is an international or premium number
  • caller-ID spoofing to call internal users on the PBX phone system, which is useful for social engineering attacks

The authors of this research contacted AudioCodes with a vulnerability report. The vendor got back to them with the following recommendations:

  • IP filtering for 52.*.*.*, which includes more than just Microsoft’s IP addresses (e.g. AWS EC2 instances can get such an IP)
  • mutual TLS by trusting the public certificate authorities used by Microsoft, being DigiCert Global Root G2 and Baltimore CyberTrust Root, both of which are widely used and might be signing more than just Microsoft’s certificates

Neither of these solutions actually address the underlying issue, which is the lack of authentication and both of them can be bypassed. So the researcher contacted AudioCodes again and they responded with:

The AudioCodes Configuration Guides are focused on interworking and only describe the basic security rules.

They also recommended filtering the incoming party number, which is obviously something that tends to be public information and certainly should not be used as a secret to prevent toll fraud.

Finally, AudioCodes added an additional section to their hardening guidelines to add firewall filtering rules that only allow TCP traffic from MS Teams SIP proxies. This solution actually works, even if it is marked as optional (which tends to annoy security researchers but not real attackers).

Naturally, this issue is not only affecting AudioCodes SBCs but also SBCs by other vendors when one follows the official documentation on how to set them up to work with MS Teams. Therefore Microsoft were also contacted but nothing seemed to have been done from their side.

The author of the research recommends the use of the new firewall rules that are provided in the hardening guide and when possible, filtering for certificates that have the SAN of sip.pstnhub.microsoft.com.

Thanks to Moritz for telling us about his research!

References:

Abuse of the Exec module in OpenSIPS and Kamailio

The OpenSIPS users mailing list had a post that captured my interest with the subject of Best practices regarding exec module command injection.

In our work, we have reviewed Kamailio configurations that made use of the exec module incorrectly. This can lead to command injection, which results in remote code execution and remote compromise through SIP. OpenSIPS has a similar module too, and the same vulnerabilities apply. Essentially, if one makes use of attacker controlled variables within any of exec functions, they are exposing their SIP proxy to command injection. And filtering to protect against this can be tricky.

This is the subject of a long blog post or two, but if anyone is looking for a solution, the original mailing list poster seems to have found a decent solution in his later replies. The solution involves using environment variables when passing user controlled arguments safely. We have not tested such a solution although it does sound plausible.

Reference: https://www.mail-archive.com/users@lists.opensips.org/msg44120.html

Coturn 4.6.0 released and its security updates

Coturn is often a critical part of the WebRTC infrastructure, serving as a STUN and TURN server. A new version of coturn was released this month and it included a number of fixes. None of them seem to be particularly security specific, although there are some memory related fixes. But there was one change that we have been keeping an eye on. The changelog reads as follows:

- Try to mitigate STUN amplification attatck
	* Add new option --no-rfc5780
	to force disable RFC8750
	* Add new option --no-stun-backward-compatibility
	Disable handling old STUN Binding requests and disable
	MAPPED-ADDRESS attribute in binding response (use only the
	XOR-MAPPED-ADDRESS)
	* Add new option --response-origin-only-with-rfc5780
	Add RESPONSE_ORIGIN attribute only if rfc5780 is enabled
	* Don't send SOFTWARE attribute if --no-software-attribute
	set on (BREAKING CHANGE)

This is trying to mitigate some malicious traffic that we have seen on our TURN server too. TURN servers were (or still are) abused in a reflection attack as part of DDoS attacks against Discord servers and so on. Some months back, Philipp Hancke had in fact pointed us to some mailing list posts that complained about this traffic. It seemed like a very strange way to abuse coturn simply because the amplification factor of the packets was minuscule compared to that of other protocols such as DNS, NTP or SNMP.

It is definitely something that we should look into again in the future, but if anyone else has any new information about this, please do get in touch by replying to this newsletter.

Reference: https://github.com/coturn/coturn/blob/master/ChangeLog

Updates to the heap buffer overflow in WebRTC

Last month we covered short news about heap buffer overflow in WebRTC (CVE-2022-2294) which has been exploited in-the-wild. Natalie Silvanovich from Project Zero has now published the root cause analysis (RCA) about the WebRTC vulnerability that’s been found in the wild. The author points out that CVE-2021-4079 is somewhat similar and that this vulnerability was probably identified through manual code review.

As a bonus, we now get proof of concept sample code that demonstrates the issue. Technical explanation:

When a LocalConnection is created in WebRTC, it creates a vector that contains supported encodings. If the supported encodings are changed due to munging, a second vector is created with the current encodings. These vectors are then reconciled, which involves copying encoding properties between the vectors. If one is shorter than the other, due to the number of encodings supported being changed, a vector will be written out of bounds.

‒ from the RCA

The Avast Threat Labs has also published a report about the malware that was exploiting this vulnerability. Based on the report, the exploitation was detected in the Middle East, and Lebanese journalists were among the targeted parties.

References:

Watering Hole attacks push ScanBox keylogger which uses WebRTC

ScanBox, the JavaScript malware seems to make use of WebRTC!

This allows ScanBox to connect to a set of pre-configured targets.

- Proofpoint’s Threat Research Team

References:

An audit of Skype for Business

Frycos has published two blog posts about his code audit journey that led to the discovery of a pre-auth SSRF vulnerability on Skype for Business 2019 which isn’t patched yet. This vulnerability is easily exploitable and its payload will be something like this:

https://host.tld/lwa/Webpages/LwaClient.aspx?meeturl=BASE64_ENCODED_URL

References:

Cloudflare announced a WebRTC service

Cloudflare just announced Cloudflare Calls - where they are exposing a APIs for developers to set up WebRTC services.

Being Cloudflare, they emphasise privacy and security. In their blog post, they focus on the IP leakage privacy risk associated with WebRTC. The example of therapists and patients hiding their IP address from each other seems confusing. Patients often need to expose more than just their IP addresses! It is more likely that gamers will find the hiding of their IP useful in protecting themselves against DoS attacks.

Finally, their offers reminds us a lot of Subspace’s, before they shut down. We look forward to more details about this service as using Cloudflare’s infrastructure for WebRTC - and its security implications - is certainly an interesting topic.

Reference: https://blog.cloudflare.com/announcing-cloudflare-calls/

Various updates for Matrix’s various components

This month, Matrix has published a number of new security releases and advisories:

Some of these issues are considered high or critical severity, especially those that are related to identity verification.

Two CVEs also assigned for two non-disclosed vulnerabilities on Matrix JavaScript and React SDKs (CVE-2022-36059, CVE-2022-36060) and as both of them are high severity vulnerabilities, Matrix has published a blog post and has announced security releases for both projects.

To summarize: update all the things!

Further references:

Mitel MiVoice abused for ransomware

In the previous months, we have covered the Mitel MiVoice Connect remote code execution vulnerability, tracked as CVE-2022-29499. The vulnerability consisted of a bug in its PHP application which has been abused by Lorenz ransomware as its initial entry point. Following that, the attack would lead to further compromise to perform data encryption. This vulnerability has been patched on April 2022, but the exploit was publicly available and nearly 20,000 Mitel VoIP products were internet-exposed.

This is not the first blog post about this vulnerability leading to ransomware. Back in June we covered Crowdstrike’s report on this topic.

References:

Short news and commentary

  • WhatsApp released advisories for CVE-2022-36934 and CVE-2022-27492
    • https://www.whatsapp.com/security/advisories/2022/
    • These are critical severity vulnerabilities, one of which is particularly interesting in terms of RTC security because it abuses an established video call. Is this exploitation of a video codec? No real details are available yet.
  • STIR/SHAKEN statistics from August 2022
    • https://transnexus.com/blog/2022/shaken-statistics-august/
    • Transnexus released their STIR/SHAKEN statistics from August 2022. One thing that is interesting is the “third-party signer exploit” where robocalls get signed by a downstream intermediate provider using their own SHAKEN certificate.
  • ENISA Telecom Security Incidents 2021
    • https://www.enisa.europa.eu/publications/telecom-security-incidents-2021
    • In July this year, ENISA has published a report on the 2021 Telecom security incidents. Based on the report, 59% of telecom security incidents were due to system failure, 23% due to human errors, 8% due to malicious actions, and 10% due to natural phenomena! The report also contains further statistics and charts on root causes and user hours lost.

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