Tags › TURN Security

TURN Security Threats: A Hacker’s View

TURN servers are meant to relay media traffic for WebRTC, but they’re also powerful proxies that hackers have been abusing since at least 2017. We break down three critical threat categories: relay abuse, Denial of Service, and software vulnerabilities, with real-world examples from our research and pentesting.…

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

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.

Bug bounty bout report 0x01 - WebRTC edition

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!

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

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.

…