Tags › Webrtc Security
Exploiting CVE-2022-0778, a bug in OpenSSL vis-à-vis WebRTC platforms
Published on Apr 8, 2022 in denial of service, demo server, freeswitch, asterisk, webrtc security, kamailio, sipvicious pro
Executive summary (TL;DR)
Exploiting CVE-2022-0778 in a WebRTC context requires that you get a few things right first. But once that is sorted, DoS (in RTC) is the new RCE!
How I got social engineered into looking at CVE-2022-0778
A few days ago, Philipp Hancke, self-proclaimed purveyor of the dark side of WebRTC, messaged me privately with a very simple question: “are you offering a DTLS scanner by chance?”
He explained how in the context of WebRTC it would be a bit difficult since you need to get signaling right, ICE (that dance with STUN and other funny things) and finally, you get to do your DTLS scans. He added that he hopes that these difficulties raise the bar for exploiting latest OpenSSL CVE.
…
Details about CVE-2020-26262, bypass of Coturn’s default access control protection
Published on Jan 11, 2021 in webrtc security, bug bounty, research, TURN security
Video demonstration
The following demonstration shows the security bypass of the default coturn configuration on IPv4:
Heads up
Turn on the captions by clicking on the CC button and watch on full screen for optimal viewing experience.Background: why does coturn have default access control rules in the first place?
TURN servers are an important part of many WebRTC infrastructures because they make it possible to relay the media even for hosts behind restrictive NAT. We wrote about this extensively in the post called How we abused Slack’s TURN servers to gain access to internal services. To summarize: from the perspective of a pentester, a TURN server is very similar to a proxy server, allowing relaying of TCP connections and UDP packets. One somewhat obvious problem is that attackers can abuse these TURN servers to connect to network services behind the firewall, such as those on the TURN server itself. To address this problem, coturn prevents connections to loopback IP addresses 127.0.0.1 on IPv4 and [::1] on IPv6. This default protection mechanism has been there since coturn version 4.5.1.0 ‘dan Eider’ which was released back in November 2018.
RTC Security chat at Kamailio World Online with Daniel and Olle
Published on Oct 5, 2020 in conferences, kamailio, voip security, webrtc security, sip security testing
It’s been a month already since the Kamailio World RTC security chat! The conversation included Daniel-Constantin Mierla and Olle E. Johansson from the Kamailio project and myself. Daniel is the lead developer of Kamailio, can be found at ASIPTO while Olle is behind Edvina.net.
If you don’t have time to watch the entire conversation, the following is my summary of this discussion:
…Kamailio World Online SIP and VoIP Security Panel
Published on Aug 27, 2020 in sip security, conferences, webrtc security, voip security, kamailio
On 2nd September, 14:00-14:30 Berlin time, the author of this post is joining Olle E. Johansson to chat at Kamailio World online about (guess what?) SIP and VoIP security, and recommendations on how working from home impacts security. I very much look forward to our discussions that will be streamed live on the Kamailio World youtube channel!
My arguments will likely be turned into an opinion piece later on, but they’ll likely steer towards the following thoughts:
…Bug bounty bout report 0x01 - WebRTC edition
Published on Jun 16, 2020 in webrtc security, bug bounty, TURN security
Read the full report here.
In April 2020, in between SIPVicious PRO development and VoIP Pentesting and WebRTC, we dedicated some days to bug bounties and vulnerability disclosure programs to see what comes out of it. Our focus was on those that have WebRTC infrastructure in scope. In the end, we reported 3 vulnerabilities to 4 different vendors, for 6 different products. So finally, after making sure that the affected vendors have addressed these security issues and have agreed with publication, we are putting out a compiled report!
…Jitsi Meet on Docker default passwords - how bad is it, how to detect and fix it
Published on Apr 20, 2020 in xmpp security, jitsi meet, research, webrtc security, default passwords
Executive summary (TL;DR)
Jitsi Meet on Docker contained default passwords for important users, which could be abused to run administrative XMPP commands, including shutting down the server, changing the administrative password and loading Prosody modules. We also provide instructions on how to check for this issue if you administer a Jitsi Meet server.
Background story
A few days ago we noticed a tweet by @joernchen mentioning something that sounded familiar, Jitsi. He recommended that people using the docker image for Jitsi meet set secure passwords.
…How we abused Slack’s TURN servers to gain access to internal services
Published on Apr 6, 2020 in webrtc security, bug bounty, research, TURN security
Executive summary (TL;DR)
Slack’s TURN server allowed relaying of TCP connections and UDP packets to internal Slack network and meta-data services on AWS. And we were awarded $3,500 for our bug-bounty report on HackerOne.
A very brief introduction to the TURN protocol
The Wikipedia page for this protocol is somewhat handy because it explains that:
Traversal Using Relays around NAT (TURN) is a protocol that assists in traversal of network address translators (NAT) or firewalls for multimedia applications. It may be used with the Transmission Control Protocol (TCP) and User Datagram Protocol (UDP). It is most useful for clients on networks masqueraded by symmetric NAT devices. TURN does not aid in running servers on well known ports in the private network through a NAT; it supports the connection of a user behind a NAT to only a single peer, as in telephony, for example.
…