Skip to main content
RTC Security Newsletter

Curated VoIP and WebRTC security news, research and updates by Enable Security.

Subscribe

March 2023: Trojan 3CX Client, CRA talk, OpenSIPS audit report and much more

Published on Mar 31, 2023

Welcome to the end of March, and this month’s edition of the RTCSec Newsletter. A lot has accumulated in March on the VoIP and IP Communication security front. In fact, this one is packed!

In this edition, we cover:

  • Our news, involving CI/CD automation of VoIP security testing with SIPVicious PRO
  • More news from us, including the OpenSIPS security audit report and a chat about the Cyber Resilience Act
  • 3CX Phone Client turned into a trojan
  • Critical vulnerabilities affecting Samsung and Pixel phones via VoLTE and 5G
  • Silent fix in Kamailio gets a CVE, vulnerable door phones and various other security reports

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 us 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

Gitlab CI/CD examples with the latest SIPVicious PRO update

On the first week of March, we released a new version of SIPVicious PRO to our customers which makes the toolset more feature-complete. For example, we added new SIP methods to the SIP Flood tool, SRTP support for the RTP fuzzer and the ability to set the RTP payload ID and SSRC for the RTP inject tool.

There were a couple more new features and a number of bug fixes (naturally) - but the main highlight for us was the documentation, actually! The update includes practical examples of how SIPVicious PRO integrates with Gitlab CI/CD pipelines and a live example of SIPVicious PRO running on the public Gitlab CI/CD.

Read all about this on our blog post: SIPVicious PRO incremental update - and Gitlab CI/CD examples, or get in touch for more details.

Full OpenSIPS Security Audit Report is published

The OpenSIPS Security Audit was a very important project that we worked on with the OpenSIPS developers during 2021 and 2022. The report is now fully public and we wrote about this in a post which included the following details:

Something that we’ve been trying to get an answer for in the past days is the question about Kamailio. The answer has proven to be more elusive that originally thought but we’re getting closer to a proper answer.

TADSummit Special: The EU Cyber Resilience act

The CRA (Cyber Resilience Act) is new legislation that is coming to the EU that enforces a certain level of security for products in the market. Together with Olle E. Johansson, I was invited to talk about how this relates to the IP Communications world. The session was split as follows:

  1. Olle first gave an excellent introduction about the Cyber Resilience Act.
  2. I presented my mindmap which shows VoIP & WebRTC vulnerabilities in relationship with the CRA’s requirements.
  3. Olle gave a presentation of how this all applies to IP Communications.

It was not a short session and packs a lot, taking an hour and a half in total. If you are involved in VoIP and IP Communications, then you should be interested in the CRA - please do watch the whole thing. Alan Quayle did the important job of summarizing the session and included our presentation materials for download on the TADSummit blog. He also linked back to our blog and this very newsletter which covers a lot of the vulnerabilities that were talked about during the session.

Reference: https://blog.tadsummit.com/2023/03/21/eu-cyber-resilience-act/

What’s happening?

3CX Phone Client used to distribute malware

Anyone monitoring either VoIP or cyber-security news, could not miss the news that 3CX started distributing a trojanized version of their 3CX Client software. Being a major PBX vendor means that such an incident must have had a wide reach at the level of other incidents such as the one involving SolarWinds.

In preparing this newsletter, I tried to figure out what happened based on the publicly available information. This is also the reason why this edition is particularly late. Anyway, here is my take.

The following is a timeline of what appears to have happened, based on various reports and articles:

  • 2022-02-XX: earliest indication of adversary’s infrastructure that was part of this incident was registered
  • 2022-12-07: presence of a Github repository used to host icon files with encoded malware; used in stage 2 of the infection
  • 2023-03-08: Telemetry from SentinelOne indicated this is the earliest infection attempt for the MacOS infected components
  • 2023-03-13: 3CXDesktopApp.exe malicious binary signed by 3CX
  • 2023-03-16: compilation date of the infostealer DLL used in the second stage of the infection
  • 2023-03-22: SentinelOne began to see a spike in behavioral detections of the 3CXDesktopApp; 3CX users began discussion of (assumed false-positive) malware detection of 3CXDesktopApp
  • 2023-03-29: various blog posts and analysis published about this - SentinelOne, Sophos, Crowdstrike
  • 2023-03-30: Mac version is confirmed to also be infected
  • 2023-03-30:
    • SentinelOne confirm that the MacOS installer is also trojanized
    • 3CX CEO and CISO posts on their website about the infection, apologizing for the incident and providing some details about affected versions etc
    • US CISA, German BSI issued alerts about the incident
  • 2023-03-31: Mandiant appointed to help review 3CX’s security incident

What happened?

According to 3CX, their 3CX Client Update 7 for Windows, version numbers 18.12.407 and 18.12.416, and Electron Mac App version numbers 18.11.1213, 18.12.402, 18.12.407 and 18.12.416, included malicious software. This included two malicious DLL files in the case of the Windows version. The first file was d3dcompiler_47.dll which was actually digitally signed by Microsoft but altered to include encrypted payload at the end. The second file was the ffmpeg.dll that included malicious code, apart from the legitimate FFMPEG code.

Additionally, the Mac version was also compromised - which is something relatively unusual and considered new by the security community!

Execution of the malware meant that, while the phone client worked just fine, it would also be loading further code that would do things like checking the browser history and so on - typical infostealer behavior and connecting to command-and-control (C2) servers for further control.

How did this happen?

Various reports indicate that it is very likely that 3CX’s build pipeline was compromised. The adversaries appear to have learned and observed 3CX’s build development processes. The way that the malicious software was included as an update for 3CX’s customers would have meant that the threat actors needed to understand how to best inject their malicious code and how to properly digitally sign the binaries so as not to trigger security alarms.

Who did this?

The reports out there mostly point towards LABYRINTH CHOLLIMA, Lazarus group, a North Korean threat actor. This claim relies on the fact that the PE shellcode loader has unique characteristics only seen in past malicious code by this particular group.

Where can I find more about this?

References:

The security community has published a large number of reports on this topic. The following blog post has a section called Appendix A – Third-Party Reporting which we highly recommend: https://www.volexity.com/blog/2023/03/30/3cx-supply-chain-compromise-leads-to-iconic-incident/

VoLTE and 5G RCE in Samsung and Pixel phones

The Google Project Zero team have published an advisory on 18 vulnerabilities in Exynos Modems (chipset) produced by Samsung Semiconductor. These vulnerabilities affected Voice-over-LTE (VoLTE) component of the modems. Based on a cursory analysis of the public advisories, it looks like the security researchers found vulnerabilities in the following areas:

  • the decoding of the following types of 5G Mobility Management protocol messages (IEIs):
    • Emergency number list
    • Extended emergency number list
    • Operator-defined access category definitions
    • Service Area List
    • Extended protocol configuration options
  • processing of SDP (session description protocol) for the following:
    • video resolution attribute
    • video configuration attribute (2 vulnerabilities reported here)
    • RCS chat
    • accept-type attribute

This is certainly an excellent research topic and the fact that the baseband handles all the signalling and media makes VoLTE and VoWiFi a very interesting target for well-funded adversaries. The impact of such vulnerabilities is high because the baseband does not have the level of security protection mechanisms that the OS (e.g. Android) can afford. Additionally, parsing and processing protocols like SDP is not an easy task and doing so at baseband level is extra risky.

The following products are known to be or have been affected:

  • Mobile devices from Samsung, including those in the S22, M33, M13, M12, A71, A53, A33, A21s, A13, A12 and A04 series;
  • Mobile devices from Vivo, including those in the S16, S15, S6, X70, X60 and X30 series;
  • The Pixel 6 and Pixel 7 series of devices from Google; and
  • Any vehicles that use the Exynos Auto T5123 chipset.

Four vulnerabilities out of these eighteen vulnerabilities lead to remote code execution as described below:

Tests conducted by Project Zero confirm that those four vulnerabilities allow an attacker to remotely compromise a phone at the baseband level with no user interaction, and require only that the attacker know the victim’s phone number. With limited additional research and development, we believe that skilled attackers would be able to quickly create an operational exploit to compromise affected devices silently and remotely.

And fourteen vulnerabilities require either a malicious mobile network operator or an attacker with local access to the device.

Google has patched the vulnerabilities and released updates for Pixel phones, but Samsung and other vendors did not.

As a workaround for vulnerable devices Project Zero team suggests to turn off Wi-Fi calling and Voice-over-LTE (VoLTE) which will make the mobile devices useless for many users:

Users with affected devices can protect themselves from the baseband remote code execution vulnerabilities mentioned in this post by turning off Wi-Fi calling and Voice-over-LTE (VoLTE) in their device settings, although your ability to change this setting can be dependent on your carrier.

Unfortunately this is not very practical. In fact, people have been pointing out on social media that it no longer possible to do so with certain service providers who rely solely on VoLTE and VoWiFi.

References:

Old Kamailio vulnerability gets a CVE

Back in October 2020, Roberto Natella, the author of StateAFL, opened an GitHub issue for kamailio with this title: Crash on qm_debug_check_frag() on INVITE

In that issue he explains that he has fuzzed kamailio and has found a vulnerability in qm_debug_check_frag() function. The issue contains config files, crafted request, backtraces and also links to a repository which contains his setup for fuzzing kamailio using AFLNet.

That vulnerability was fixed very quickly, on the same day, but without publishing any advisory or assigning any CVE. Thus many instances might have stayed vulnerable. Silent security fixes do not promote upgrading because people are not given any incentive to do so. Even if they have internal security policies that mandate keeping up to date with the latest security patches, the right people will miss silent security fixes.

This month an advisory was published on GitHub and addressed the vulnerability, and Linux distributions updated Kamailio packages. Now people know that they need to update!

References:

Nullcon Berlin talks - the many vulnerabilities in an Intercom system from Akuvox

There were a number of great talks at NULLCON Berlin which happened in March - but my favourite was Vera Mens’s presentation about the fun they had with an Intercom system from Akuvox. Vulnerabilities ensued that involved typical default password issues, to web application vulnerabilities to attacks over VoIP (SIP)!

Ars Technica published a great article about this with the title of Go ahead and unplug this door device before reading. You’ll thank us later.

Akuvox’s response to the security reports from the researchers was really lacking, with the researchers having to contact the CERT Coordination Center to help out with getting the devices fixed. This was also unsuccessful and so, they disclosed the vulnerabilities in their presentation. The vendor issued an apology on March 13, explaining that they comply with all regulations in the countries that they operate and so on. They also should have issues security fixes by the 20th of March.

ps. I’m pretty sure there’s more security issues in such devices, and this one seems like a treasure trove!

Further references:

Talk about Security, High Availability, Scaling with Kamailio

Astricon 2023, the Asterisk PBX conference happened in February and the main talk that seemed to cover our audience’s favorite topic, security, was Fred Posner’s. The title was “Security, High Availability, Scaling” and Fred goes through useful topics such as:

  • Using Kamailio for SIP-TLS termination
  • the PIKE module for protection against SIP flood attacks
  • the SECFILTER module that does a number of security checks based on user-agent strings, IP addresses and also has some detection of SQL injection attacks
  • the sanity module which checks for malformed SIP requests
  • scaling your IP Communications system by offloading authentication and SIP registration to Kamailio

In the Q&A, he recommended the following:

  • do not do deep packet inspection or use an application layer gateway (ALG) for real-time applications, especially for RTP
  • he does recommend using hardware firewalls but making sure that SIP inspection is not used
  • handling DDoS incidents by doing IP-level filtering, and how Kamailio can be useful when trying to build an allow list for customer IPs

All in all, it is a great introduction if you need ideas about how Kamailio can be useful in making your VoIP infrastructure more robust and secure.

Reference: https://www.youtube.com/watch?v=o8_UE1b46vs

Telco Security Landscape for 2023 by ETIS

https://cdn.ymaws.com/www.etis.org/resource/resmgr/docs/telco_sec_landscape_2023.pdf

The Telco Security Landscape for 2023 was published by ETIS - the community for telecom professionals, which is based in Europe. The landscape, according to this report includes the following top 10 points:

  1. Scarcity of cyber security talent
  2. Migration to public cloud
  3. Cloud native infrastructures
  4. Geopolitical tension
  5. Third party dependency
  6. Supply chain integrity concerns
  7. Widening of telco eco-system
  8. Increased security regulation
  9. Limitations of legacy equipment
  10. Automation and orchestration

We’re most excited about the last one - automation and orchestration - which is the main (potential) opportunity in this list. The rest are actually threats and certainly real concerns.

Cisco IP Phone web UI unauthenticated RCE

Cisco published an advisory to address two critical vulnerabilities in IP Phone devices which lead to unauthenticated remote code execution in the web-based management interface of the devices.

Affected devices are as below:

  • IP Phone 6800 Series with Multiplatform Firmware
  • IP Phone 7800 Series with Multiplatform Firmware
  • IP Phone 8800 Series with Multiplatform Firmware

The vulnerabilities have been found by Zack Sanchez of the Cisco Advanced Security Initiatives Group (ASIG) during an internal test.

Cisco have released fixes for the vulnerable devices and they can receive the fixes via updates.

References:

CoreDial’s sipXcom sipXopenfire RCE vulnerability

sipXcom is a PBX server by CoreDial. The project provides an XMPP server called sipXopenfire. This month a team called Systems Research Group, have published an advisory on seclists and provided details on two vulnerabilities in the software which can be chained to achieve an RCE. These are the vulnerabilities:

  • CVE-2023-25356: OS Command Argument Injection
  • CVE-2023-25355: Weak Service File Permissions

The first vulnerability allows attackers to pass arbitrary arguments to curl, which leads to arbitrary file read/write since curl send read files to any given URL and also may responses to files. This vulnerability allows you to read sensitive files such as /etc/passwd, and also writing files in arbitrary paths like /usr/bin/bash or ~/.bashrc. The curl option -o which is used for this purpose, overwrites files. It is enough to get remote code execution, but the advisory suggests using the second vulnerability to gain full root access by overwriting /etc/init.d/openfire. The explanation in the advisory is as follows:

The /etc/init.d/openfire service file is owned by the daemon user and group, but runs as the root user. This gives a relatively clear path to privilege escalation.

Is there any patched version available? No, the latest version which is vulnerable was last updated on November 16, 2021.

At the end of the advisory, the research team has explained that they have never received a response from the company:

After a few weeks with no response from the sipXcom/eZuce contact forms, I tried to make direct contact on Twitter. I also included the CoreDial account in this, and all subsequent tweets. I also tried to email CoreDial directly. My first attempt to contact CoreDial directly was December 1st 2022.

At the time of this disclosure, I have sent several emails to, and tweets directed at, CoreDial. In each of the tweets, CoreDial untagged themselves, and never responded.

I consider all these reasonable attempts to get the attention of CoreDial. I would have much preferred that they fix the issues in sipXcom before this disclosure. However, I encountered an active lack of interest, so am also comfortable in this case fully disclosing technical details without any public fix.

References:

PJSIP heap buffer overflow when parsing DNS packet

PJSIP has published a new advisory for a critical heap buffer overflow in its DNS packet parsing part of pjlib-util. This vulnerability, which is tracked as CVE-2023-27585, is very similar to a vulnerability from the last year (CVE-2022-24793); the difference is that the new one occurs when parsing resource records (RR) using the parse_rr() function, while the old one occurs when parsing the query using parse_query() function.

The vulnerability has been discovered through fuzzing by Arjun Singh, the researcher who implemented OSS-Fuzz support for the PJSIP project. We covered the news about PJSIP’s OSS-Fuzz support in the December 2022 issue.

Based on the advisory, this vulnerability affects you if you have configured pjsua_config.nameserver or UaConfig.nameserver in PJSUA/PJSUA2.

And doesn’t affect you if you:

  • did not configure nameserver in PJSUA/PJSUA2, so the library will use the OS resolver such as via getaddrinfo()
  • are using an external resolver implementation, i.e: configured using pjsip_resolver_set_ext_resolver().

The vulnerability has been patched, and the patch has been committed to the master branch. A patched stable version hasn’t been published yet.

The following is a suggested mitigation technique:

A workaround is to disable DNS resolution in PJSIP config (by setting nameserver_count to zero) or use an external resolver implementation instead.

References:

Drachtio and the incomplete fix for CVE-2022-45474

In November 2022 we covered a use-after-free vulnerability (CVE-2022-45474) in Drachtio, the Node.js framework for SIP server applications.

This month Agostino Sarubbo , the researcher behind that finding has opened a new issue with this title:

Use-after-free in event_cb (Incomplete fix for CVE-2022-45474 ?) Github Issue

It does not seem that vulnerability has been fixed correctly yet. The issue is still open and we’re told that this was not yet fixed.

References:

WebRTC Use-After-Free vulnerability fixed (CVE-2023-1218)

Last month we covered a high severity use-after-free vulnerability in WebRTC in Chrome/Chromium. This month we also have a similar one, with almost the same CVE description:

Use after free in WebRTC in Google Chrome prior to 111.0.5563.64 allowed a remote attacker to potentially exploit heap corruption via a crafted HTML page.

The Chrome release note also contains this note:

[$3000][1413628] High CVE-2023-1218: Use after free in WebRTC. Reported by Anonymous on 2023-02-07

These are the only details that we know about the vulnerability.

References:

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