February 2025: VoIP phones join botnets, and vulnerabilities in Cisco, Twilio, Asterisk, AudioCodes and more

We might have gotten a little carried away this time… but we think this is worth the read if you’re interested in the wild world of VoIP and WebRTC security.

In this edition, we cover:

• Reddit post about the WebRTC DTLS handshake security
• Twilio Serverless exposed by default
• Vulnerability coverage of Asterisk, AudioCodes, Mitel, Cisco phone systems
• And more security fixes in F5 BIG-IP, OpenH264 codec and WebRTC
• International IP-Based SIP network security
• Robocallers vs FCC vs Telnyx summary

The 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 determines if you can safely communicate in real time - whether it be with other humans or machines.

You may sign up to receive the RTCSec newsletter here. If you like what we’re doing, you’re most welcome to:

• Forward it to those who may find this newsletter particularly fruitful.
• Let us know if there are any RTC security news items we should cover.

To view past issues, please visit our website at https://www.enablesecurity.com/newsletter/.

Our news

Reddit: ICE can’t protect the DTLS handshake

Our friend Philipp Hancke directed us to a Reddit post by Evan Brass about the DTLS HelloClient vulnerability from last year. We had previously discovered this vulnerability, blogged about it, and published a paper on it a few months ago.

Here’s how we had described it in our original blog post:

A critical denial-of-service (DoS) vulnerability has been identified in media servers that process WebRTC’s DTLS-SRTP, specifically in their handling of ClientHello messages. This vulnerability arises from a race condition between ICE and DTLS traffic and can be exploited to disrupt media sessions, compromising the availability of real-time communication services. Mitigations include filtering packets based on ICE-validated IP and port combinations. The article also indicates safe testing methods and strategies for detecting the attack.

To be direct, while the attack vector described on Reddit is valid, I don’t believe the concerns raised in the post are critical.

The main points of the Reddit post were the following:

1. The core issue is that ICE (Interactive Connectivity Establishment) is a multiplexed protocol that doesn’t adequately protect the DTLS handshake packets. The ICE password only protects the connection tests but not the DTLS handshake itself.
2. The author identifies a security vulnerability that is not addressed by our proposed solution where an attacker on a local network could potentially:
   • Perform a MITM (Man-in-the-Middle) attack by replaying ICE connection tests
   • Exploit the lack of replay protection in ICE
   • Manipulate DTLS handshakes to cause Denial of Service to that particular media stream
3. The author suggests that the only current solution would be to perform the entire WebRTC handshake using TURN+TLS candidates and then do an ICE restart after DTLS is finished, but this would effectively eliminate purely peer-to-peer WebRTC connections.

The author then expresses frustration with WebRTC’s design choices, specifically:

• The use of DTLS
• ICE’s multiplexed nature
• The combination of multiple protocols without coherent layering
• Inconsistencies in certificate lifetimes between WebRTC and WebTransport

The main point of the author is that the current implementation of WebRTC has fundamental security vulnerabilities in its handshake process, and the author advocates for a new, more secure peer-to-peer API with better message authentication and a cleaner protocol design.

Here’s what we think:

When we were looking for solutions to the issue, we were not concerned about man-in-the-middle (MITM) in the sense that it was not something that the threat model is able to handle. Here is what we said in our blog post about MITM scenarios:

In such cases, various other methods can cause DoS due to the design of the involved protocols. Therefore, MITM scenarios are beyond the scope of this threat model, which aims to prevent attacks from remote attackers without access to the network traffic of the victim client and server.

When working on this research, we were primarily concerned about how easy it is to exploit this Application Denial of Service vulnerability from any remote location, i.e., over the Internet, to attack vulnerable WebRTC media servers. An attacker could target all of the service provider’s media servers, potentially disrupting media processing and delivery across the entire infrastructure. This is quite different than the attack scenario described by Evan Brass, which targets specific individual WebRTC media streams rather than all media streams being handled by vulnerable media servers.

Not ready for a full penetration test?

That’s why we offer flexible consultancy services tailored to your specific needs. Whether you’re looking for focused guidance on particular aspects of your RTC applications or a broader overview, we are there to assist. This option is particularly beneficial for companies without a large security budget (e.g., startups), allowing you to leverage our expertise without breaking the bank.

Get in touch with us through our online contact form or schedule a meeting directly.

What’s happening?

The security of Twilio Serverless

Our friends at Relay Hawk published a blog post about the security of Twilio Serverless Functions and Assets. By default, both functions and assets are exposed publicly, thus requiring no authentication. The only protection mechanism is the uniqueness of the generated URLs, which is considered as security through obscurity. This is far from ideal. Since this is the default, it is therefore likely that a number of systems out there that are built on top of Twilio Serverless are set to public and yet are performing security or privacy sensitive operations.

What could go wrong? It really depends on what your serverless functions are doing, or what is stored in the assets. For example, if a serverless function is meant to share sensitive data such as customer details when they are calling in from PSTN, an attacker that (somehow) gains access to the URL, might be able to retrieve that information. Similarly, in the case of assets such as call detail records (CDR), such sensitive data could be accessible publicly.

Again, the main problem is that the default is insecure, probably to facilitate development and application design. To help anyone building on top of Twilio Serverless, the authors not only published a blog post but also released a python-based tool on Github that’s able to detect misconfigurations and security risks such as:

• Public serverless functions and assets
• Unencrypted HTTP webhooks in phone numbers and messaging services
• API keys older than 90 days

They also pushed a PR to Twilio’s Serverless Toolkit so that assets and functions that are deployed publicly are shown in the output of the toolkit.

Give the blog post a read here.

Potential vulnerability in Asterisk (CVE-2024-57520)

A GitHub account by the name of hyp164D1 published an advisory as a GitHub Gist with the complex title of: Insecure Permissions vulnerability in asterisk v22 allows a remote attacker to execute arbitrary code via the action_createconfig function. Back in October, we had observed other advisories being similarly published by hyp164D1.

In the comments, Josh Colp from the Asterisk project asked the researcher to get in touch but it is not clear as to what happened after that. We should note that Josh and his colleagues from the Asterisk project have always been very forthcoming when it comes to security reports. We highly recommend security folks to go through the advertised channels to report and get security issues in Asterisk fixed.

We did a few tests and my understanding is that empty configuration files can be created through the Asterisk Management Interface (AMI) by making use of the CreateConfig action.

This action, unlike others such as UpdateConfig and GetConfig, misses the is_restricted_file() check and seems to be vulnerable to path traversal. Thus attackers could possibly:

• Create numerous files to consume disk space or inodes, leading to resource exhaustion (which does not require path traversal).
• Create blank configuration files that could affect system behavior when loaded.

Of course, attackers first need access to the AMI, which is problematic in itself. We’ll get in touch with the Asterisk developers to get some updates on this, although I would rate it as medium severity (CVSS 4.9) due to the authentication required for AMI access.

Securing International IP-Based SIP Networks: Key Takeaways from P1 Security’s Webinar

P1 Security, focused on mobile security, had a webinar about a topic that is very interesting to us. Here are the key takeaways from our point of view:

1. IMS roaming presents significant security challenges:

• Complex interconnections: IMS roaming involves complex interconnections between different networks (home and visited), increasing the attack surface.
• Legacy vulnerabilities: Fallback mechanisms to 2G/3G can expose networks to older, well-known vulnerabilities.
• Encryption is not guaranteed: While IPsec should be used for NNI (Network-to-Network Interface) connections, it’s not always enforced, leaving traffic vulnerable. The NULL encryption is a risk.
• SIP and RTP are targets: Attackers can exploit vulnerabilities in SIP and RTP protocols for various purposes, including fraud, disruption, and eavesdropping.
• Information disclosure: Sensitive information such as the IMEI can be retrieved in those attacks.

2. Proactive security (Defense in Depth):

• Don’t rely solely on firewalls/SBCs: While firewalls and SBCs (Session Border Controllers) are important, they are not sufficient. They often have limitations, and a proactive approach requires more.
• IDS/IPS is important: An Intrusion Detection System (IDS) and, ideally, an Intrusion Detection and Prevention System (IDPS) are strongly recommended to monitor traffic and detect anomalies.
• Network segmentation is key: Proper network segmentation limits the impact of breaches and prevents attackers from moving laterally within the network.

3. Specific recommendations and best practices:

• Enforce encryption: Prioritize strong encryption (IPsec, TLS for SIP, SRTP for media) on all NNI connections, and avoid NULL encryption.
• Address legacy risks: Manage fallback mechanisms to older networks and address known vulnerabilities.
• Monitor for SIP/RTP anomalies: Use IDS/IPS to detect flooding, tampering, unauthorized access, and other suspicious SIP/RTP behavior.
• Protect sensitive information: Implement measures to prevent the leakage of sensitive subscriber information (IMEI, location data, etc.).

Naturally, P1 Security emphasized on the critical role of an IDS, since this is one of their main products. That said, it is certainly an important element in securing SIP and RTP in an IMS environment.

In terms of specific SIP and RTP attacks and vulnerabilities, they listed the following:

1. NULL encryption: A major concern is the possibility of IPSec NULL encryption for the SIP and RTP traffic. While IPsec should secure the connection, in practice, some deployments might not enforce encryption. This allows attackers to eavesdrop on the content of the media (voice, video) or control plane traffic.

2. Legacy vulnerabilities (due to fallback): When 4G or 5G networks fall back to 2G/3G, legacy vulnerabilities associated with those older technologies (like those in SS7 and SIGTRAN) can be exploited.

3. Flooding attacks: The audio mentions flooding attacks, which could target the P-CSCF or other IMS components. These are a type of denial-of-service (DoS) attack.

4. SIP tampering/injection: The presenters highlight the risk of SIP tampering, where an attacker modifies SIP messages in transit. This could involve altering call flows, potentially for fraud (like altering billing information) or for tracking/disruption. Related to this is the risk that an attacker could inject SIP messages.

5. Information disclosure: Certain responses can leak sensitive information, such as the IMEI (International Mobile Equipment Identity) or IMSI (International Mobile Subscriber Identity). This can be used for tracking or to facilitate further attacks.

6. Network segmentation bypass: Attackers might attempt to bypass network segmentation, potentially gaining access to core network components like the HSS (Home Subscriber Server) from a roaming perspective.

7. Man-in-the-Middle (MITM) attacks: Although IPsec should protect against MITM, the lack of enforced encryption opens up this possibility.

The speakers provide a summary-level presentation rather than deep technical specifics of each vulnerability. They focus on the types of vulnerabilities and how IDS/IPS systems can help mitigate them.

Give it a watch here.

Mitel Phones are being actively exploited by Aquabot variant

The Aquabotv3 malware exploits CVE-2024-41710, a command injection vulnerability, to infect Mitel SIP phones. This vulnerability affects Mitel 6800, 6900, and 6900w series SIP phones, including the 6970 Conference Unit through R6.4.0.HF1 (R6.4.0.136). We had previously covered this vulnerability in the September issue the RTCSec newsletter.

Here’s how the exploit works:

• The vulnerability lies in an input sanitisation flaw, which can lead to root access on the device.
• Attackers send a specially crafted HTTP POST request to the “802.1x Support” endpoint (8021xsupport.html) to bypass sanitisation checks.
• By sending the byte value “%dt”, the linemgrSip web application interprets it as a line ending character “%0d”.
• This is leveraged during the boot process, where the contents of /nvdata/etc/local.cfg are read and used for startup actions.
• The application overwrites the targeted hostname entry in the device’s local configuration.
• The hostname entry is then used during boot and executes a prepended shell script.
• The shell script fetches and executes the “bin.sh” script, which in turn downloads and executes Mirai malware on the target system. The malware has support for various architectures, including x86 and ARM.

The Akamai SIRT observed active exploitation of this vulnerability in January 2025, using a payload almost identical to the proof of concept (PoC). The payload targets the URI “/8021xsupport.html” and spreads malware in the wild.

Akamai have published a blog post with all the details.

AudioCodes OVOC and Mediant SBC: Update to Version 8.4.582 to Patch Critical Flaws

Back in August 2024, the security researchers at SySS took a look at AudioCodes One Voice Operations Center (OVOC) and Mediant Session Border Controller (SBC). This resulted in 4 advisories and CVEs being published earlier this month. Most notably, they found a path traversal vulnerability that allows access to files that include encrypted passwords of various devices. Combined with other password encryption vulnerabilities, network access to the administrative interface could lead to remote compromise.

Specifically, the path traversal vulnerability (CVE-2024-52883) can be chained with the hardcoded key vulnerability (CVE-2024-52881). The path traversal vulnerability allows an attacker to access sensitive information such as encrypted passwords from the topology file. Then, by exploiting the hardcoded key vulnerability, the attacker is able to decrypt the extracted passwords, potentially gaining administrative rights on assigned devices.

The fixes were released on 2024-10-20 (for OVOC vulnerabilities) and 2025-02-03 (for the SBC vulnerability). So be sure to upgrade your AudioCodes equipment!

The advisories can be found at the following locations:

• SYSS-2024-075 (CVE-2024-52883)
• SYSS-2024-076 (CVE-2024-52882)
• SYSS-2024-078 (CVE-2024-52884)
• SYSS-2024-079 (CVE-2024-52881)

Story of an OpenH264 vulnerability (CVE-2025-27091)

The OpenH264 codec library just fixed a vulnerability that could allow remote, unauthenticated attackers to trigger a heap overflow.

While the most obvious way that this could be exploited is when viewing a malicious video file, it might be also triggered through WebRTC, especially in the case of Firefox which bundles an outdated OpenH264 for WebRTC video support. That said, Firefox runs the plugin in a sandboxed environment making exploitation far from trivial.

Few exploitation details were published, and the security fix in the code doesn’t clearly indicate the actual attack vector. Apart from web browsers, we would be concerned about media servers that have H.264 decoding capabilities that rely on OpenH264.

The advisory can be found here.

Timeline of Events

• Prior to OpenH264 2.5.0: OpenH264 versions 2.5.0 and earlier are vulnerable to a heap overflow. Both Scalable Video Coding (SVC) mode and Advanced Video Coding (AVC) mode are affected.
• December 19, 2024: Benzheng Zhang merges a commit (“fuzzy”) into the cisco:master branch, likely related to addressing the decoder.cpp bug fix.
• February 12, 2025: OpenH264 2.6.0 released, addressing this vulnerability.
• February 20, 2025: Advisory released with some details about the security fix.

Security Updates and Vulnerability News Round-Up

WebRTC Use-After-Free in Chrome details public, fixed back in October 2024

A WebRTC use-after-free vulnerability in Chrome, tracked as CVE-2024-10488, was reported by security researcher Cassidy Kim (@cassidy6564) on October 18, 2024. The issue, stemming from an incomplete fix for a previous vulnerability, was addressed in October 2024. Details of the bug report were publicly disclosed at the end of January 2025.

Original content here.

Cisco Video Phone 8875 and Desk Phone 9800 Series Information Disclosure Vulnerability

A vulnerability in the debug shell of Cisco Video Phone 8875 and Desk Phone 9800 Series could allow an authenticated, local attacker with administrative credentials and SSH access to retrieve sensitive information from the affected device. This issue arises due to insufficient validation of user-supplied input.

Original content here.

F5 Networks’ BIG-IP SIP Vulnerabilities: A Deep Dive into CVE-2025-22846, CVE-2025-20045, and More

F5 has identified two vulnerabilities in the SIP application layer gateway (ALG) profile of BIG-IP devices. One issue arises when Passthru Mode is enabled alongside SIP ALG, while the other vulnerability is present when SIP ALG is simply enabled. Passthru Mode allows traffic to bypass processing such as load balancing and SSL offloading. Both vulnerabilities were discovered internally by F5, suggesting they are actively fuzzing their SIP implementations.

Original content here.

Robocallers posing as FCC fraud prevention team call FCC staff using Telnyx, FCC issues Telnyx a fine, Telnyx fights back

The FCC has proposed a $4.5 million fine against Telnyx, alleging the company failed to prevent robocallers from using its network to impersonate the FCC and target its staff. The agency argues Telnyx did not properly vet new customers, allowing accounts with suspicious details to operate freely. Telnyx, however, is fighting back, asserting that it took swift action to stop the calls and that the FCC is applying vague rules retroactively. The company claims the FCC is engaging in “regulation by enforcement” and has not provided clear guidance on compliance expectations. Telnyx also points out that the FCC itself was the intentional target of the robocall scheme, yet the agency downplayed the security implications. The case has sparked debate about whether voice service providers should bear full responsibility for customer vetting and whether the FCC is acting within its authority. Commissioner Nathan Simington dissented, citing legal concerns, while some suggest the FBI should investigate potential insider involvement. The controversy hinges on whether Telnyx took adequate “know your customer” precautions and whether the FCC is fairly enforcing its rules.

Original content on Tcpaworld, Bleeping Computer, Fred Posner’s blog, the FCC and Telnyx.

This newsletter was prepared by Sandro Gauci and the Enable Security team for RTCSec newsletter subscribers. If you have someone in mind who would benefit from our content, please share.

To subscribe: here