Skip to main content

Tags Bug Bounty

Details about CVE-2020-26262, bypass of Coturn’s default access control protection

Published on Jan 11, 2021 in , , ,

Video demonstration

The following demonstration shows the security bypass of the default coturn configuration on IPv4:

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.

Read more about Details about CVE-2020-26262, bypass of Coturn's default access control protection

Bug bounty bout report 0x01 - WebRTC edition

Published on Jun 16, 2020 in , ,

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!

Read more about Bug bounty bout report 0x01 - WebRTC edition

How we abused Slack’s TURN servers to gain access to internal services

Published on Apr 6, 2020 in , , ,

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.

Read more about How we abused Slack's TURN servers to gain access to internal services