Our news
Announcement: Upcoming presentation at Kamailio World 2025 in Berlin
In May, I’ll be presenting at the Kamailio conference with a talk titled “Kamailio Configuration Security: From Real-World Vulnerabilities to Proactive Defense”. Here’s the synopsis:
While Kamailio’s remarkable flexibility is one of its key strengths, it can become a double-edged sword when it comes to security. This presentation takes you beyond theoretical concepts, straight into real-world security issues discovered during actual penetration tests and security assessments.
You’ll be taken through a journey of vulnerable configuration patterns, focusing on Kamailio configuration pitfalls that could compromise your systems. Through practical examples based on actual real configurations seen out there, we’ll demonstrate how these vulnerabilities can be exploited and, more importantly, how to effectively mitigate them.
But we don’t stop at quick fixes. This presentation then moves on to discussing strategic thinking, offering innovative approaches to break free from the endless cat-and-mouse game of security fixes. Join us to learn about proactive security strategies that will help you leverage Kamailio’s flexibility while maintaining robust security posture.
Whether you’re a seasoned Kamailio administrator or just getting started, this session provides actionable insights and practical solutions to stay ahead of potential threats in your Kamailio infrastructure.
Looking forward to meeting a number of you in Berlin!
We’re also presenting at OpenSIPS Summit in Amsterdam!
In addition to Kamailio World, I’ll be presenting at the OpenSIPS Summit in Amsterdam this May. The presentation details aren’t published yet, but it will complement my Kamailio World talk with greater depth. Will any of you be attending?
Video: Are you overlooking WebRTC vulnerabilities?
Back in September last year, I gave a talk called “Web Security Experts: Are you overlooking WebRTC vulnerabilities?” at the OWASP Global AppSec in San Francisco. The presentation video is finally out.
The synopsis:
As the web evolves, so do the complexities of securing it. WebRTC (Web Real-Time Communication) is a powerful technology embedded in every modern web browser, enabling audio, video, and data sharing. While WebRTC offers tremendous advantages for real-time communication, it introduces a unique set of security challenges that many web and API security professionals may overlook.
This presentation aims to bridge the knowledge gap between traditional web/API security and the specialized realm of WebRTC. Designed for OWASP attendees ranging from novice to advanced practitioners, it will provide a comprehensive overview of WebRTC security concepts, common vulnerabilities, and practical testing methodologies.
I hope this serves as a great introduction for fellow security professionals and inspires new research in the area. Watch it here: https://www.youtube.com/watch?v=g-rtvp6CXeI
RFC 9725 WebRTC-HTTP Ingestion Protocol (WHIP) is published & our little contribution
The WHIP protocol defines how to use WebRTC to ingest media streams into media servers. It’s excellent for streaming applications that broadcast content, potentially replacing RTMP, SRT, and other similar solutions. Since WHIP is built on WebRTC, it’s easy to implement in web browsers. Notably, it has now been published as an official standard.
We had previously contributed by suggesting built-in protections against potential vulnerabilities including resource exhaustion, flooding attacks, and insecure direct object references (IDOR).
What’s happening?
Security Updates and Vulnerability News Round-Up
Asterisk has added support for RFC 8760, which modernizes SIP authentication by replacing the outdated MD5 algorithm with more secure alternatives like SHA-256 and SHA-512/256. The feature has been anticipated for some time and was previously tested during OpenSIPIt in 2021 to validate interoperability and compliance.
Original content here
A newly disclosed vulnerability highlights a hash-based Denial-of-Service (DoS) attack that affects multiple QUIC protocol implementations. This is particularly relevant to real-time communications (RTC) developers, as QUIC is increasingly considered for its low-latency benefits in RTC applications.
Original content here
End-to-end encryption (E2EE) is officially being added to the RCS (Rich Communication Services) standard, marking a significant step forward for secure mobile messaging. With the standard now published, the next critical phase is widespread implementation, particularly by handset manufacturers like Google and Apple. This update promises more secure conversations over mobile networks, regardless of the carrier.
Original content here
TWINFUZZ introduces a differential fuzzing approach that leverages a white-box software video decoder to guide fuzzing efforts and detect inconsistencies in the output of black-box hardware-accelerated decoders. This method enables the identification of subtle vulnerabilities in hardware video decoding stacks. Although not strictly focused on RTC security, the research is relevant given the use of video codecs in real-time communications and the importance of ensuring their robustness.
Original content here
CVE-2025-1921 is a medium severity vulnerability in Google Chrome categorized as an “Inappropriate Implementation in Media Stream.” According to the available information, it could allow a remote attacker to gain information about a user’s peripheral devices via a specially crafted HTML page. While technical details are still scarce, the issue appears to touch on the complexities of enforcing same-origin policy in the context of media capture - an area of critical concern for browser-based WebRTC applications.
Original content here
There is an article on Forbes about securing VoIP. Who would have guessed?
Original content here
Cryptex: Completely Encrypting RTP Header Extensions and Contributing Sources - now part of libsrtp - RFC 9335
Sergio Garcia Murillo has merged cryptex support into libsrtp, implementing RFC 9335 in this widely used library for server-side applications. Since libwebrtc doesn’t currently support this feature, it’s unavailable in web browsers. As a result, projects like Jitsi only support cryptex for traffic between SFUs.
This is a valuable addition, as a common criticism of SRTP has been its transmission of metadata in plain text. This feature helps address that concern.
Comments about “On the Insecurity of Telecom Stacks in the Wave of Salt Typhoon” and FreeSWITCH security
On March 12th, a security researcher who goes by the nickname of Soatok published a blog called “On The Insecurity of Telecom Stacks in the Wake of Salt Typhoon”. The main focus of this article is FreeSWITCH, where, back in January, the security researcher discovered what looks like a classic buffer overflow in the XML-RPC interface.
Then the author went on to report the vulnerability to FreeSWITCH, who issued a fix in the master branch. However, they also responded that they will not create a tagged release until the summer of this year. Most of the article is about how the telecom industry’s security practices are lacking and that this is indicative of the industry as a whole. There is also the claim that there are 8,300 hits on Shodan for FreeSWITCH, implying that they’re all exposed to this vulnerability.
I have a few comments about this:
- I’m not too sure that the vulnerability has been reproduced by the researcher; there is not even any mention of a crash. We don’t need a full remote code execution; a crash is just fine for such vulnerabilities. Just because a tool or a pair of eyeballs reports a classic buffer overflow, it does not necessarily mean that malicious user input can reach that code. A very quick glance gives the impression that it would be reachable, but I was personally unable to reproduce the issue and I suspect that it is because the path requested needs to actually exist.
- XML-RPC in FreeSWITCH is not on by default, and exposing it asks for trouble since it is an administrative interface. So this particular security issue will be limited in production environments. Yet, yes there are a number of FreeSWITCH instances indexed by Shodan that are exposing it - 280 of them.
- If one were to look at the commits in the master branch, one would notice a number of similar fixes marked by the “Coverity” message, indicating fixes that have security implications. Coverity Scan is a static analysis tool for finding security issues in the code.
In a way, I do find it annoying that security issues in FreeSWITCH do not get a new tagged version so that people can just upgrade to that version. On the other hand, I understand that the devs from FreeSWITCH will not be issuing a new version for every Coverity fix. In the past, when we did send advisories to the FreeSWITCH developers, which included proper reproduction steps and explanations, they issued security fixes in timelines that, to us, seemed very acceptable.
In fact, with open source VoIP software developers (FreeSWITCH, Asterisk, Kamailio and OpenSIPS), we have had great results in terms of coordinated disclosure. It is with the proprietary vendors that we had very little to no success in reporting the vulnerabilities that we came across. But that is another post for another day ;-)
Cisco Webex for BroadWorks Credential Exposure Vulnerability affecting SIP
Cisco released an informational advisory with the following description:
A low-severity vulnerability in Cisco Webex for BroadWorks Release 45.2 could allow an unauthenticated, remote attacker to access data and credentials if unsecure transport is configured for the SIP communication.
Using SIP without TLS should clearly offer no expectation of confidentiality or integrity for signaling data. Surprisingly, it appears that Cisco had configured Webex for BroadWorks without TLS by default. They have now implemented a customer-wide configuration change, requiring users to simply restart their Cisco Webex application to apply the security update.
New Rock VoIP Devices: Critical Command Injection (CVSS 9.8)
Tomer Goldschmidt of Claroty Team82 has reported two vulnerabilities in New Rock Technologies’ cloud-connected VoIP devices, with one command injection vulnerability rated at a critical 9.8 CVSS score. The vulnerabilities have been responsibly disclosed to the vendor and CISA, indicating potential widespread security risks for VoIP communication infrastructure.
The following versions of New Rock Technologies Cloud Connected Devices are affected:
- OM500 IP-PBX: All versions
- MX8G VoIP Gateway: All versions
- NRP1302/P Desktop IP Phone: All versions
The vulnerabilities are described as follows:
- OS Command Injection (CVE-2025-0680)
- Improper Neutralization of Wildcards or Matching Symbols (CVE-2025-0681)
Unfortunately, the vendor did not respond to CISA, so users of the affected devices have no security updates that address these vulnerabilities at the time of writing.
