It is the end of November and with it, we bring some of our own publications and coverage of various advisories, papers and news items in the VoIP and WebRTC security world.
In this edition, we cover:
- How to simulate DDoS attacks on your own
- Details about the new WebRTC IP leak issue
- Coverage of interesting talks at Blackhat and TADSummit
- Advisories concerning Sofia-SIP, Drachtio, PJSIP and more
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 me know if we should include or cover any RTC security news.
To view past issues, please visit our website at https://www.rtcsec.com/newsletter.
We are hiring freelance pentesters
Last month we announced that we are looking for persons who are do security testing services on a freelance basis. Our hiring process involves video calls to get to know each other and to understand if we can work together. Then we have the chance of doing a simulation of a penetration test, which allows both parties to experience how an actual engagement would look like and everything that it involves. This includes documentation (reporting), typical challenges involved in pentesting, research and development and discussions that are mostly done over asynchronous chat.
We had a number of very interesting applications but we are looking for more than just one person. Therefore the hiring page will remain open. If you know someone who might be interested and happens to be a freelancer, do send them to this page: Penetration Testers - Freelancer/Contract-based & Remote.
Simulating DDoS attacks: our talk and blog post are out
We published various materials detailing how to simulate DDoS attacks:
- Video of the talk at TADSummit: https://www.youtube.com/watch?v=gaVBOuwyON0
- Slides for the presentation: https://www.slideshare.net/sandrogauci/tadsummit-2022-how-to-bring-your-own-rtc-platform-down
- Article for those who prefer to read: https://www.rtcsec.com/article/how-to-perform-ddos-simulation/
TL;DR: A DDoS simulation is a practical exercise that various organisations are capable of doing. Understand the reasons why you would want to do this, then combine custom with off-the-shelf attack tools. Follow the best practices, apply solutions and mitigation; and you can finally answer: what if we got attacked?
New WebRTC IP leak discovered and fixed
Except that someone figured that the reference libwebrtc implementation for computing foundations returns a random looking string that is calculated as follows:
CRC32(baseaddress, protocol, relayprotocol). This
baseaddress is actually the IP address that the mDNS technique tried to hide. Trackers could then make use of this hash with a pre-computed lookup table to get the original IP address again. For those familiar with offline password cracking, this is very similar to the rainbow table techniques used to crack MD5 hashes and various other schemes. There is a nifty demo of this by the original reporter on a Github page.
Fear not, however, because our friend Philippe Hancke (and various others) has been on it making sure that a fix is out there. The solution involves seeding the CRC32 with a random 64 bit integer.
At the time, the official Chrome release build does have a fix and this no longer works since Chrome 107. So, we are once again safe from the IP trackers out there.
- Demo: https://niespodd.github.io/webrtc-local-ip-leak/
- Repository for demo: https://github.com/niespodd/webrtc-local-ip-leak
- Fixes: https://chromiumdash.appspot.com/commit/08b882d762edadb9797334859d915c5c1e34896b
- “No longer works” ticket: https://github.com/niespodd/webrtc-local-ip-leak/issues/3
- About mDNS fix: https://bloggeek.me/psa-mdns-and-local-ice-candidates-are-coming/
- Talk about fixing WebRTC IP leaks: https://www.youtube.com/watch?v=SqcW8kJAMJg
- General information about IP leaks in WebRTC: https://getstream.io/blog/webrtc-ip-leaks/
XMPP Stanza Smuggling presentation video
The video of the talk given by Ivan Fratric at Black Hat about “how he hacked Zoom” is now out. We have previously linked to blog posts and bug reports related to this but the talk is what you want to watch if you want to be entertained.
Talks of interest at TADSummit 2022
I’m writing this almost 3 weeks after returning from TADSummit 2022 in Portugal. Here are some comments about presentations that caught my attention:
- Title: Welcome to vCon! The next leap forward in the programmable communications industry. Thomas Howe
- Why is this interesting? Although not actually a security technology, this open format is there for privacy and tracking purposes, to track content and purpose of the various parts of a conversation, especially personal information. It comes with security properties such as digital identity and tamper proof features. The nice thing about vCon is that this could allow the transfer, sharing and tracking of such information since it is a standard.
- Title: What Everyone Needs to Know about Protecting the CPaaS Ecosystem from Unlawful Robocalls. Gerry Christensen, VP YouMail.
- It talks about limitations of STIR/SHAKEN and alternative approaches to prevent unlawful calls.
Videos for both days:
- Day 1: https://www.youtube.com/playlist?list=PLO-gJ4-4x_IKOzIplTKPU-B_vWzCKzVab
- Day 2: https://www.youtube.com/playlist?list=PLO-gJ4-4x_ILsSmIWu6w8iBVfvxUSAe6g
Sofia-SIP STUN overflow
A Janus user posted on the Sofia-SIP bug tracker asking about a heap-buffer-overflow issue that he is experiencing. The error indicates that the library was compiled using the AddressSanitizer. Further down in the ticket, a security researcher from Zoom, Qiuhao Li, mentioned that this particular flaw (and others) was found during a recent security test. He also published their own report which includes full details useful for the developers to address the issue and made a pull request with the fix.
The security researcher asked about having a security advisory for this issue but there is none yet at the time of writing. In the meantime, anyone concerned should use the open PR until it makes it to the master branch.
Note that the issue affected the Janus user because of the SIP plugin that depends on the affected library.
Drachtio security advisories and fixes
Drachtio is a Node.js framework for SIP server applications. It has two main components:
drachtio-serverwhich is the SIP server and is written in C++.
drachtio-srfwhich is the Node.js part that connects to
drachtio-serverand has described as “signaling resource framework”.
Agostino Sarubbo has reported two vulnerabilities on
- Use-After-Free in
event_cbfunction when receiving a call
- Wrong file mode which allows unauthorized users to read log file
Both vulnerabilities has been fixed in version 0.8.19-rc12 in less than a week.
Additionally, Drachtio has also applied the fixes for the overflow in Sofia-SIP that was reported by Qiuhao Li.
PJSIP advisories issued in October
During October, the PJSIP project released two advisories. One concerned a critical SRTP/RTP downgrade vulnerability which affects PJSIP version from 2.11 until 2.12.1. While there is no write-up about the vulnerability, we look forward for it as it seems to be an interesting vulnerability.
The second advisory is about a buffer overflow in pjlib scanner and pjmedia which is marked as moderate in terms of severity.
Sippts v3.3 released with new tools
Last month we covered Sippts version v3.3, which is a toolset to audit SIP-based software and devices by Jose Luis (Pepelux) Verdeguer. As we mentioned, its development has become active again and it is worth tracking these updates.
Sippts v3.3 is now out with several performance improvements, bug fixes, and new tools.
The new tools are the following:
- sipping: To check if a SIP server/device is alive
- rtpbleedinject: To inject RTP frames when RTP Bleed vulnerability is present
- wssend: To send SIP messages over WebSockets
- sipfuzzer: To perform SIP fuzzing using radamsa. (This tools doesn’t seem to be working on UDP, and it needs improvements)
DONAR: Anonymous VoIP over Tor
The TOR network is not ideal for typical VoIP communications due to latency and unreliability of the network. During 19th USENIX Symposium on Networked Systems Design and Implementation, four academic researchers presented Donar, a system enabling VoIP over Tor with good quality.
We present DONAR, a system enabling anonymous VoIP with good quality-of-experience (QoE) over Tor. No individual Tor link can match VoIP networking requirements. DONAR bridges this gap by spreading VoIP traffic over several links. It combines active performance monitoring, dynamic link selection, adaptive traffic scheduling, and redundancy at no extra bandwidth cost. DONAR enables high QoE: latency remains under 360 ms for 99% of VoIP packets during most (86%) 5-minute and 90-minute calls.
The paper’s abstract
VoIP call surveillance research paper
During SOSR (Symposium on SDN Research) ‘22, which was an ACM SIGCOMM virtual event, a paper submitted by five academic researchers from ETH Zürich and Princeton University. Title of the paper is: Mass Surveillance of VoIP Calls in the Data Plane.
This paper has introduced DELTA, a network-level side-channel attack that can efficiently identify VoIP calls in-path, in real-time, by tracking connections and not traffic.
DELTA differentiates from traffic analysis approaches by merely tracking connections instead of examining traffic. More specifically, DELTA leverages the VoIP signaling mechanism used for peer discovery and call setup: VoIP callers and callees first connect to a publicly known central application server shortly before communicating directly with each other. This fundamental call bootstrapping mechanism, used by prominent VoIP platforms, leads to a triangular connection pattern. DELTA takes advantage of this pattern by storing the signaling connections and linking the candidate call flows to these stored addresses. More precisely, DELTA continuously keeps track of the client IP addresses in recent signaling connections. Then, for each arriving flow, DELTA checks the flow address tuple against the stored IP addresses. This mechanism reveals the participating addresses of a call and identifies the facilitating application service without examining the traffic.
From the paper
Recovery of Wire’s deleted messages
Secuvera has published an advisory for Windows version of Wire and showed that deleted messages are recoverable from log files and reported the finding to the vendor and:
vendor replied that there will be no change in the method of storing messages in Wire
From the advisory
And after three months Secuvera, registered a CVE (CVE-2022-43673) and published the advisory.
Since Wire considers itself as the “Most Secure Collaboration Platform”, it’s strange that it has resistance to change. The effect of the vulnerability seems obvious - recovery of deleted messages on compromised endpoints.
Robocalls up in October
TransNexus have a report indicating that there was a sharp rise in robocalls in the U.S. in October. They hint that this is because call authentication is not yet effective enough to prevent such calls, especially because of the third-party signing exploit and non-IP SHAKEN exemption.
Telecoms fraud catalog published
The Risk and Assurance Group has published a catalog listing types of fraud that affect telecommunications. It is called the RAG Fraud Catalogue and includes hundreds of risks organized under twelve categories of crime:
- Charging Fraud
- Commercial Fraud
- Corporate Fraud
- Equipment Fraud
- Financial Services Fraud
- Payment Fraud
- Privacy Violation
- Sales Fraud
- Service Disruption
- Subscription Fraud
- Wholesale Fraud
- Unauthorized Access
Dinstar FXO Analog VoIP Gateway DAG2000-16O Cross Site Scripting
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