Our News
Newsletter Feedback and a Tip for Procrastinators
Each month, we spend many hours and put considerable effort into working on the RTCSec newsletter to ensure the content is useful. So, I was really happy when, at ClueCon 2025, we received a lot of positive feedback from people who read our newsletter.
Here is one that came from an old friend who sadly could not attend ClueCon:
I am still backlogged to your March mailing list. Always an interesting read, I like to take my time going through them.
Pro tip: Archive the old ones and read this one instead! 😉
ClueCon 2025: Media Security Is Hard: The Many Ways RTP & SRTP Still Fail Us
We gave a presentation at ClueCon 2025 aboutRTP and SRTP security weaknesses, especially focusing on the most common and persistent weaknesses we observe: RTP Bleed, where a victim’s audio and video are sent to an attacker, and RTP Inject, where an attacker adds their own audio packets into a call.
After explaining the security weaknesses and why they occur, we looked at the different ways these security problems have affected rtpengine, FreeSWITCH, and Asterisk, even though they try to protect against these flaws. We focused on rtpengine, which recently released several security fixes in a security update. FreeSWITCH is working on some security fixes, while Asterisk uses RTP flood protection to reduce these problems, which works well against naive, high-speed attacks. Asterisk also correctly puts SDP negotiated sources first, which is an effective way to reduce risk when users are not behind NAT or use STUN.
Finally, we suggested some ways to detect and prevent problems, including a security checklist and a realistic view of these security flaws. I’m sharing the slides while we wait for the video to be published by the ClueCon team.
What’s happening?
WHY 2025 - Die Hardcoded: Unlocking Yealink’s (weakest) secrets
Security experts Jeroen Hermans and Stefan Gloor gave their presentation on Yealink vulnerabilities at the Dutch hacker camp WHY 2025, which took place from August 7th to 12th. You can watch the video of their talk, and it’s 30 minutes well spent if you work with VoIP systems that require many phones.
We already covered the technical details of their findings in June on this newsletter, but the presentation adds much more background information and explains how they did their work, how they worked with the company, and other related topics. The vulnerabilities outlined by the researchers were the following:
- Unauthorized Access to RPS Data (CA Private Key Leak)
- Firmware Encryption (AES Key Obtained)
- Missing Input Validation in RPS
- RPS Serial Number Enumeration / Missing Rate Limiting
- RPS MAC Address Enumeration
- RPS Authentication Bypass
Issues 3 through 6 can all be resolved by the vendor on their servers or by updating the phone firmware.
The second issue, firmware unpacking, is less critical in practice, since secure boot mechanisms matter more than firmware secrecy. As a phone user, what you want from a security standpoint is proof that the firmware is genuine (meaning it hasn’t been changed) rather than keeping it secret.
The first issue regarding the authentication and authorization system for the Redirection and Provision Service (RPS) is what worries us most, because this system is essential for setting up every single Yealink phone. The presentation explains how the researchers were able to obtain the Certificate Authority certificate and key from one of their phones, and then create their own signed client certificate to log into the RPS servers. Basically, it seems that the CA private key is included in all phones so that each phone can create its own login certificate when it first starts up. This is a feature, but also a major security vulnerability. The security implications of this are that attackers may retrieve someone else’s phone configuration - which includes sensitive details such as SIP credentials.
We contacted Yealink for their comments, and they provided this response:
Yealink has successfully addressed the reported RPS security vulnerability and completed internal verification testing. Our findings confirm that access to the RPS service via Yealink’s new device models remains unaffected by this vulnerability.
To further ensure the security and reliability of our systems, we will engage a professional third-party security laboratory to conduct a comprehensive penetration test on our RPS servers.
Yealink has published several advisories related to these RPS issues, including this one on certificate validation, this one on serial number enumeration, and this one on missing rate limiting.
Yealink states that only older devices are affected and that new device models remain secure. The researchers, however, demonstrated otherwise during their presentation, highlighting a clear discrepancy between vendor claims and independent findings.
According to Yealink’s public documentation, the RPS is primarily a redirection service. Authentication mechanisms include serial-number-derived codes, which researchers demonstrated can be brute-forced.
I think many phone provisioning systems, including this one by Yealink, have a chicken and egg problem. To automatically set up phones whenever needed, how do you verify that phones are who they claim to be, especially the first time they start up, in a way that doesn’t allow everyone else to pretend to be real too? And how do you make that work for many phones while keeping costs low?
Ultimately, phone provisioning systems often do this via MAC address and perhaps a second factor, neither of which may be strong authentication mechanisms.
Provisioning remains a weak link in many VoIP ecosystems. The Yealink case is a reminder that trust bootstrapping is hard to solve - but also critical, since it forms the foundation of every phone’s security. The answer is to look at what other vendors have done to secure provisioning protocols.
And for VoIP admins, the lesson is: don’t assume vendor provisioning systems are inherently secure - apply your own hardening and demand transparent disclosures.
FreePBX 0day vulnerability in the EPM module exploited (CVE-2025-57819)
Phone systems that use FreePBX versions 15, 16, and 17 are actively under attack and being exploited in the wild (ITW). These attacks target systems where the admin control panel (ACP) can be reached from the internet. The vulnerability is in the endpoint module, which is a paid add-on. Unfortunately, even if you don’t use this module, it might still be installed on your system, making the problem more severe than it initially appears.
What vulnerability is being abused? Public technical information is still scarce, but it is definitely leading to remote code execution, with attackers leaving backdoor code on compromised FreePBX systems. In the meantime, Sangoma has worked out a fix which can be installed by running fwconsole ma upgradeall on the system.
We took a quick peek at the fix (because we’re the curious types) and noticed that the solution involves input validation, adding a sanitizerequest PHP function which allows only alphanumeric, underscore, and dash characters in strings. Based on this, we have a rough idea of how this is being exploited.
Most discussion about this is happening on the official community forum, Reddit and BleepingComputer has covered this news. FreePBX also issued an advisory on Github and assigned this the ID CVE-2025-57819. And there’s YouTube video from Crosstalk Solutions: Your FreePBX Server Might Be Compromised – Here’s How to Check.
Asterisk security updates - CVE-2025-49832 / CVE-2025-1131 / CVE-2025-54995 / CVE-2025-57767
This month, Asterisk PBX fixed four security issues, each of which has its own advisory.
Clint Ruoho reported a vulnerability in the STIR/SHAKEN validation code in Asterisk that leads to a remote denial-of-service and potentially remote code execution. For this to be exploitable, Asterisk needs to be configured to validate STIR/SHAKEN headers, and the attacker needs to be able to send SIP messages with the Identity header.
The Asterisk developers fixed another potential security issue which affected the safe_asterisk script used to start the Asterisk daemon. This is a local privilege escalation (LPE) vulnerability. The attack can be mounted by non-root users with write access to /etc/asterisk who could place scripts in the startup.d directory that would be run as root the next time Asterisk is started. This is a privilege escalation issue for attackers stuck with asterisk user privileges.
The third issue that was fixed involved situations where RTP ports weren’t being released, causing possible resource exhaustion issues. The solution involved upgrading the bundled version of PJSIP.
The last one is actually the only security vulnerability that the Asterisk team rated as high severity, reported by Pascal Cadotte Michaud. The vulnerability is related to Asterisk receiving a SIP request with an Authorization header that has a realm not present in a previous 401 response’s WWW-Authenticate header, or if an Authorization header with an incorrect realm is received without a prior 401 response. In such cases, the get_authorization_header() function in res_pjsip_authenticator_digest would return a NULL value. This NULL value was not being checked before attempting to retrieve the digest algorithm from the header, which causes a crash. In the commit comment from one of the Asterisk developers, we get the impression that this is difficult to reproduce:
In the highly-unlikely event that get_authorization_hdr() couldn’t find an Authorization header in a request, trying to get the digest algorithm would cauase a SEGV. We now check that we have an auth header that matches the realm before trying to get the algorithm from it.
The vulnerabilities have been fixed in the latest versions of Asterisk, refer to the advisories 1, 2, 3 and 4 for the correct versions.
DEF CON 33: Journey to the Center of the PSTN
This presentation by Enzo Damato is like a love letter to old-fashioned telephone systems and phone hacking. Notably, he became a phone company owner at age 19. The talk focuses on the US phone system, but he shares some great stories about telephone company weaknesses that people took advantage of over time.
The following exploits and misuses were covered:
- Access Stimulation: Exploiting the “calling party pays” model to generate revenue by enticing long calls, initially through dial-up ISPs (which the FCC killed in 2001) and later through free conference call lines. Recent loopholes involved rural access collectors and IPES providers, which have largely been closed, but the “free money glitch” persists. This also explains why attackers brute-force SIP PBXs for high-rate international calls.
- Robocall Evasion (TDM Shuffle): Robocallers bypass the STIR/SHAKEN cryptographic signature (mandated by the FCC to verify caller ID) by routing calls over the legacy TDM network, which strips the signature. When the call re-enters the IP network, it receives a low-attestation level (C) or a misconfigured high-attestation, making the spoofed caller ID appear legitimate and untraceable.
- Snowshoe Spamming: A technique where spammers use multiple shell companies, each signing up with numerous small VoIP providers that lack proper KYC (Know Your Customer) and caller ID filtering. They distribute spam call volume across these accounts and frequently rotate cheap numbers to avoid detection, making caller ID filtering ineffective.
- Other Abuses: Includes local number portability abuse (fake LOAs), vulnerabilities in un-pentested SS7 devices and 20-year-old hardware (5ESS, DMS100s), manipulating ANI (calling party number), and hijacking number blocks.
Then there’s also the part about the CLEC formation process, i.e., becoming a telephone company, which is worth watching for its own sake.
His recommendations and concluding comments were:
- Monitoring: Carriers and PBX owners should monitor call and SIP logs for unexpected usage (e.g., unusual international destinations), detect DID rotation (a sign of spam), and know their customers.
- Public Policy: Recommendations include requiring ILECs to support IP interconnection (to combat TDM shuffle), mandating out-of-band STIIR/SHAKEN support, implementing end-user SHAKEN (to trace calls to originators), and better enforcement against criminal Telcos.
- Disclaimers: The talk explicitly states it is not legal advice, not a comprehensive course on voice network design, not a guide to state regulations, and specifically not about PBX hacking, but rather focuses on the carrier side. Attendees are advised to always check actual state rules.
- Enzo Damato invited anyone with old telecom equipment (e.g., 5ESS, step-by-step, mainframe gear) or other carriers/ISPs/EXCs to peer with him, offering a new home for “unloved equipment”. He also encourages people to contact him to discuss phone-related topics.
TURN Server Abuse: ‘Ghost Calls’ C2 Evasion Technique
Praetorian’s “Ghost Calls” research, published in two blog posts and at Black Hat USA 2025, details a novel Command & Control (C2) technique that leverages standard web conferencing infrastructure, specifically Zoom and Microsoft Teams TURN servers, for covert data exfiltration and interactive C2 tunnels. The method exploits the inherent design of these platforms, which prioritize performance and resilience in varied network environments, often leading to relaxed security controls (e.g., bypassing TLS inspection, split-tunneling VPNs). The developed tool, TURNt, demonstrates how to establish low-latency, high-bandwidth communication channels using the TURN protocol, operating under the guise of legitimate web conferencing traffic to evade detection.
This connects to our earlier published work on TURN security problems, especially when we participated in the Slack bug bounty program in 2018, which we published in 2020. See our previous blog post called “How we abused Slack’s TURN servers to gain access to internal services”. While we use this weakness to connect to internal services (such as a poorly protected admin interface running on localhost) or external trusted services, Praetorian discovered that it works well as a communication channel for Command & Control activity after a system is compromised. In our work, we often pointed out configuration vulnerabilities (open relays with no peer access controls), while Ghost Calls takes advantage of the intended design (legitimate TURN credentials used for unintended peer-to-peer tunneling).
Interestingly, Zoom is said to have pushed a fix to their TURN infrastructure that prevents peer-to-peer connections. We presume that the TURN servers now allow only traffic to the media servers-which could indeed prevent abuse of TURN servers but also remove the advantages of P2P traffic. This will likely push Command & Control developers to send their traffic through RTP instead of simply misusing TURN servers. We will see what happens.
The presentation was also given at DEF CON 33 and is available on YouTube.
August: The month of hacker conferences: DEF CON 33 and WHY 2025
I’ll start by pointing out that we have not been to any of the hacker conferences this summer. Instead, we chose to attend ClueCon. But that does not mean we cannot cover some of the important events, especially those that affect the VoIP and WebRTC security community!
On the US side:
The main topic of interest at Black Hat USA and DEF CON in Las Vegas was the misuse of TURN servers for command-and-control (C2) and evading detection. We have included that talk in a dedicated section of this edition.
DEF CON 33 also featured some other interesting talks. My personal favorite is the one called “Journey to the Center of the PSTN” by Enzo Damato, so we’ve included that talk as a separate article in this newsletter. Other presentations that seem worthy of someone with a focus on RTC security were the following:
- Hacking Hotspots: Pre-Auth RCE, Arbitrary SMS & 5G/4G LTE Router Attacks
- Detecting Fake 4G Base Stations for $20 (Rayhunter)
- Gateways to Chaos - Modems Are a Ticking Time Bomb
- ONI: Shadow Surveillance via VoLTE Malware
- Anatomy of Telecom Malware
- Malware in the 5G Core
On the EU side:
WHY 2025’s main topic of interest was the Yealink vulnerabilities, which also has its own section in this newsletter.
Additionally, WHY 2025 set up their own temporary phone network for the event. This was handled by the Payment and Phone Operation Center, a team of 20 members. The system was based on 1 main PBX and 4 Voicehubs. This worked with DECT handsets and SIP and had 1837 registered phones in total.
What’s interesting is that they had a toll fraud incident, where someone had an IP Phone, a SNOM phone by the looks of it, that was connected to both the WHY 2025 Internet and also to the phone system. This phone had no password set on it (I assume on the admin interface), so it was quickly used to make outbound unauthorized calls that cost several hundred euros.
The presentation about their work can be seen here.
BT Home Hub 2006: DSL and SIP Reverse Engineering Analysis
In the second part of “From E-waste to Dial Tone”, Adam from theuplinkport.co.uk worked a bit more on an old BT Home Hub to make its phone call feature work again. This time he got a lot of help from the community, which helped him succeed in what he wanted to do. He says that “this is not simple”, which is how we often feel when working with VoIP, even after all these years. At the 25th minute, he actually gets an incoming phone call to work through his BT Hub. He set up the system manually using Asterisk software and an old Sipgate account. The look of pride and happiness on Adam’s face when he achieves a working phone ring is priceless.
Security Updates and Vulnerability News Round-Up
Matrix recently implemented a major security update. This comprehensive update addresses critical vulnerabilities, most notably CVE-2025-49090 and CVE-2025-54315, which posed significant risks to the platform’s integrity. These vulnerabilities could potentially allow malicious servers to disrupt chatroom states without actually compromising user data. The primary concerns centered around chatroom state corruption and loss of control over rooms, which could have severely impacted user experience and room administration capabilities.
Original content here.
This academic paper introduces VWAttacker, a comprehensive security testing framework designed to identify vulnerabilities in Voice over WiFi (VoWiFi) user equipment. The research leverages LLM-based semi-automatic test case generation to probe for security weaknesses in VoWiFi implementations. The framework focuses on discovering cryptographic vulnerabilities that could potentially compromise the security of voice communications transmitted over WiFi networks.
Original content here.
A certificate validation vulnerability has been discovered in Cisco Webex Meeting Client that could allow attackers to intercept and manipulate meeting connections. The vulnerability requires a man-in-the-middle (MITM) attacker to position themselves between the client and Webex servers to intercept network traffic. Once positioned, the attacker can exploit the certificate validation weakness to perform unauthorized actions, including potentially joining meetings without proper authentication.
Original content here.
The article explores essential security protocols including DTLS (Datagram Transport Layer Security) for secure peer connections and SRTP (Secure Real-time Transport Protocol) for encrypted media transmission. It also addresses significant vulnerabilities such as IP leakage concerns, where users’ real IP addresses can be exposed despite VPN usage.
Original content here.
This security guide from Ecosmob addresses the critical threats facing PBX systems today, including toll fraud where unauthorized users exploit phone systems for expensive international calls, voicemail hacking that can lead to data breaches, and Denial of Service (DoS) attacks that can cripple communication infrastructure. The article provides a top 10 list of security best practices specifically tailored for VoIP implementations, covering everything from strong authentication protocols to network monitoring strategies. It concludes by highlighting the substantial benefits organizations gain from implementing robust PBX security measures, including cost savings, regulatory compliance, and maintaining business continuity.
Original content here.
Various Grandstream phone vulnerabilities reported and fixed
References to advisories from the security researcher:
