May 2024: Presenting on DTLS WebRTC DoS and the latest VoIP vulnerabilities

It is already the end of May, and we have a packed newsletter this month!

In this edition, we cover:

• Our upcoming presentation about the DTLS ClientHello DoS vulnerability
• Vulnerabilities fixed in Asterisk, ALU and Cisco phones and more
• RCS phishing attempts and a Pre-War Reality Check and VoIP resilience
• New features from Kwanlabs SIP Open Relay tester
• A talk about STIR/SHAKEN privacy concerns
• Short news covering fax, physical access control vulnerabilities and honeypots

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 is what 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 that 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.rtcsec.com/newsletter.

Our news

Upcoming presentation on the DTLS ClientHello DoS vulnerability

Last year, our Chief Demolition Officer, Alfred Farrugia, discovered a potential vulnerability in WebRTC environments that could lead to a denial of service during media setup. This security issue arises from a race condition in the DTLS setup process, allowing attackers to prevent vulnerable media servers from accepting incoming media streams, such as voice and video.

We identified this vulnerability in several proprietary solutions as well as in popular open-source VoIP solutions like Asterisk, FreeSWITCH, and rtpengine. After reporting the issue to the respective developers, we ensured that appropriate security fixes were implemented before publishing the advisories.

While the attack is easy to execute, the vulnerability itself is quite complex due to various caveats. Nonetheless, I will demonstrate it at the upcoming WarCon security conference happening in June in Warsaw, Poland.

What’s happening?

Kwanlabs SIP Open Relay tester has new features

Ivan Kwabena NyarkoIvan shared that he added the following features to his Open SIP Relay tester:

• Testing on any port
• TCP and TLS support
• Scheduled (daily/weekly/monthly) scans for peace of mind after doing configuration updates

If you’re running SIP servers on the Internet, using this service can help ensure you avoid accidentally creating new open SIP relays. While the basic tests remain free, the new features require a monthly subscription. Learn more at kwanlabs.com.

Asterisk vulnerable to Unauthorized SIP Requests Matching (CVE-2024-35190) - or is it?

The Asterisk PBX project recently issued an advisory about a potential security issue introduced by two pull requests from a GitHub user. These pull requests, after several changes and discussions on GitHub, were eventually accepted and merged by the Asterisk team. The advisory claimed that these changes introduced a security vulnerability.

However, we are not convinced that this advisory is valid, as we could not reproduce the behavior described in the advisory. Instead, it appears that the issue stems from incorrect configuration in the advisory itself. The misconfiguration allows authentication from any IP address, regardless of whether the Asterisk version is supposedly vulnerable.

Specifically, the identify_by setting should not be in the type=identify section of the pjsip configuration; it should be in the type=endpoint section. When placed correctly, the configuration works as expected, authenticating by IP regardless of the software version.

Additionally, the configuration in question tries to match its own IP address, which is unusual. However, since the configuration is in the wrong section, this point seems irrelevant.

A Pre-War Reality Check and VoIP resilience

Bert Hubert posted a long read based on a talk he gave at the ACCSS/NCSC/Surf seminar ‘Cyber Security and Society’. The title is Cyber Security: A Pre-War Reality Check, and he made sure to warn the audience that this was not a happy presentation. However, I think this presents a realistically stark view on the state of telecommunications resilience.

In a chaotic situation (e.g. war), Bert suggests that you want your communications to have:

1. Infrastructure that is robust and does not fall over by itself.
2. Limited and known dependencies.
3. The ability to improvise and fix things when things go wrong.

With the first point, he highlights how the communications systems we use, such as MS Teams, fall over by themselves every now and then.

On the second point, the author describes phone systems that work regardless of electricity or the national telephone network remaining functional. He points out how sound-powered phones are still in use on US military vessels. A resilient system was the Dutch Emergency Communication Network (Mini-noodnet), which is no longer in use and has been replaced with Noodcommunicatievoorziening (NCV), a modern Dutch emergency communication network. NCV VoIP is susceptible to the complexity and fragility of most VoIP systems, depends on KPN infrastructure, and lacks full redundancy.

Finally, with the third point, it is clear that we often rely on communication systems that we do not own. If, as a nation, you depend on WhatsApp for emergencies, what will you do if that platform goes down or the country is disconnected from the rest of the world?

The main points that Bert makes are that, if we’re serious about cyber resilience, we need to focus on:

• Simplicity and Robustness
• Technical Expertise and Ownership
• Regulatory and Policy Changes
• Resilience in Crisis Situations
• Critical Assessment of Modern Solutions
• Awareness and Preparedness
• Investment in Local Solutions

Local security issues fixed in ALE desktop phones

Two advisories were published for Alcatel-Lucent Enterprise desktop phones, specifically the models ALE-300/400/500 NOE & SIP, ALE-20/h, ALE-30/h, and Noe-3G EE: 80x8s - 8088. Security researcher Moritz Abrell of SySS discovered two vulnerabilities.

The first vulnerability (CVE-2024-29149) allows authenticated attackers to install malicious firmware on these phones. Although there is protection against malicious firmware, it can be bypassed using a time-of-check-time-of-use attack (race condition). This involves replacing the verified firmware with malicious firmware during the update process.

The second vulnerability (CVE-2024-29150) is a local privilege escalation issue. Authenticated attackers with admin access can read files owned by the root user, which could be used to obtain sensitive information.

The advisory from Alcatel-Lucent (ALU) states that exploiting these vulnerabilities requires physical access to the USB port. However, advisories from the security researchers suggest that exploitation could also be possible via SSH. We contacted the security researcher for clarification, and he explained that a low privileged shell, such as UART or SSH, is required to trigger the update. Nonetheless, since the update must be uploaded via USB drive, physical access is ultimately required.

Cisco fixes vulnerabilities in IP Phone 6800, 7800, and 8800 Series

Cisco issued an advisory for three different, unrelated vulnerabilities that affected some of its IP Phones:

• CVE-2024-20376: Cisco IP Phone DoS Vulnerability
• CVE-2024-20378: Cisco IP Phone Information Disclosure Vulnerability
• CVE-2024-20357: Cisco IP Phone Unauthorized Access Vulnerability

The information disclosure vulnerability (CVE-2024-20378) is particularly concerning because it allows the recording of user credentials and traffic to and from the affected device, including VoIP calls that can be replayed. According to the official report, the debugging functionality (such as packet sniffing) does not require proper authentication.

The Cisco IP Phone Unauthorized Access Vulnerability (CVE-2024-20357) is similar but affects the XML service, which is not enabled by default. This service is used to trigger IP Phones to initiate calls. I recall my colleague Sn0rky demonstrating this service in 2009, turning Cisco IP Phones into spy devices in conference rooms. It’s noteworthy that this service has an authentication bypass.

RCS phishing attempts

We are noticing some tech news articles about phishing and spam attempts using Rich Communication Services (RCS), which is end-to-end encrypted and might be hard for providers to block in the traditional way. RCS is meant to replace SMS and MMS, and those conducting these phishing scams traditionally over SMS (called smishing) are now also switching to RCS. Here are some interesting articles or posts on the topic:

• RCS spam texts being sent to Google messages users
• Reddit: Received an Encrypted text message
• Google has a drastic solution for RCS spam
• Google Messages users are getting spam-like encrypted RCS messages
• New Darcula phishing service targets iPhone users via iMessage
• This new phishing attack targets iPhone and Android alike via RCS

STIR/SHAKEN: a talk about privacy at the Real World Crypto Symposium

STIR/SHAKEN: A Looming Privacy Disaster is a talk presented at RWC (Real World Crypto Symposium) 2024, organized by the International Association for Cryptologic Research (IACR). The presentation is available on YouTube. The authors, Josh Brown and Paul Grubbs, also discussed their research on the Security Cryptography Whatever podcast.

At Enable Security, STIR/SHAKEN is of particular interest due to the new complexities and increased attack surface it introduces. This is primarily due to the various technologies it uses, such as JWT, PKI, and HTTP within the SIP INVITE call-setup mechanism. While we may not agree with all the privacy concerns raised, some certainly resonate with us as real-world issues. Here are the main concerns highlighted in the presentation and podcast:

• Deniability Issues:
  • The STIR/SHAKEN protocol creates cryptographic evidence of calls that can be used to prove a call was placed. This is similar to the issue with DKIM in emails. The metadata and passport are cryptographically signed but sent in the clear, allowing intermediary providers to access this information and prove a call was made.
• Metadata Exposure:
  • Clear Transmission: The metadata, including the caller and callee numbers, is transmitted in the clear through the telephone network, making it accessible to all intermediary providers. This exposure could increase if proposals to include more detailed metadata (e.g., physical addresses, birth dates) are implemented.
  • Third-Party Involvement: Many originating and destination providers use third-party authentication and verification services, meaning additional parties have access to the metadata and can correlate it with cryptographic evidence. Providers like TransNexus have a significant view into the telephone ecosystem’s metadata.
  • Increased Logging: The protocol encourages or necessitates logging of call data and signatures to facilitate spam reporting. This increases the retention and availability of metadata for extended periods.
• Legal and Compliance Concerns:
  • Centralization of metadata with third-party services could make it easier for law enforcement to obtain call logs and metadata through subpoenas. The distributed logging and third-party involvement potentially lowers the threshold for legal access to call metadata.
• PKI Issues:
  • Opaque PKI: The STIR/SHAKEN ecosystem’s PKI is opaque and lacks transparency features such as certificate transparency logs. The certification authority (CA) system is rooted in a single point of failure, with a self-signed certificate that is not publicly verifiable.
  • Certificate Misissuance: There are issues with certificate misissuance, including malformed certificates and incorrect extensions, which could compromise the security and trustworthiness of the system.
• Out-of-Band STIR/SHAKEN:
  • The proposed out-of-band STIR/SHAKEN solution involves uploading call passports to a national network of Call Placement Services (CPSs). This system replicates passports across multiple nodes, potentially increasing the risk of unauthorized access and privacy breaches.

The authors also discuss potential solutions, such as blind signing and blind verification, to address the concerns raised.

Even if you’re not interested in the privacy aspect of STIR/SHAKEN, this 20-minute presentation is worth watching because it gives a great overview of the solution, technology choices, and intricacies surrounding the topic.

Short news

• YouTube video: Call the compiler, fax it your code
  • Lex Bailey from Computing: the Details posted a very cool video of a fax machine sending code to be compiled remotely, over fax, of course, with the output of the code faxed back to the fax machine. Oh, the things you can do these days are amazing! Also, this brings a new twist to remote code execution via fax. The source code is on GitHub.
• Firefox fixed CVE-2024-4764: Use-after-free when audio input connected with multiple consumers, which affected WebRTC
  • No further details were released other than Multiple WebRTC threads could have claimed a newly connected audio input leading to use-after-free. The vulnerability was reported by Jan-Ivar Bruaroey, one of the main people behind the Firefox WebRTC efforts.
• Plaintext SIP credentials stored in a physical access control system (CVE-2024-4425)
  • The SIP credentials used for intercom integration in the CemiPark software, an access control system, are stored in plaintext. This vulnerability makes these credentials susceptible to unauthorized access. The issue affects CemiPark software versions 4.5, 4.7, and 5.03, and potentially other versions. The vendor has not disclosed the complete list of affected products. Additionally, the software stores other integration credentials, such as FTP, in plaintext, posing further security risks.
• T-POT Mobile published as open source
  • Deutsche Telekom Security has published a new project called T-Pot Mobile. According to its author, Marco Ochse, “T-Pot Mobile is powered by a Raspberry Pi 4, features a 4.3” touch display, and is housed in a self-designed 3D-printed case." If you missed our previous newsletters, the T-POT multi-honeypot platform is noteworthy because it includes built-in VoIP components.

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 it.

To subscribe: here