Protecting your STUN/TURN Services

Hi Jitsi Family!

For those managing their own STUN/TURN services - here’s another open source project to test and protect your services.

3 Likes

thanks for the link.
Here are a few tips to use it with Jitsi-meet.

First download the tool from GitHub - firefart/stunner: Stunner is a tool to test and exploit STUN, TURN and TURN over TCP servers. you can use the binary directly under Linux, just uncompress it. Or you can build it with the go toolchain. I’ll be no help about that.

When you have a binary called ‘stunner’, you can test it with

./stunner --help

Should display basic use.

If it works, test against your server. I’ll assume that you have your own Jitsi-meet at example.com and you installed a turn server accessible on the 443 (classic https) port at turn.example.com.

→ Note: you should really only use this with your own server ! You will entirely be responsible for what happens to you if you don’t follow my advice.

./stunner info -d -s turn.example.com:443 --protocol tcp --tls
(...)
ERROR-CODE: Error 401: Unauthorized
(...)
	SOFTWARE: Coturn-4.5.1.1 'dan Eider' Padding: 2 
(...)

Next to test your server you need a username and a password.

Note: these values are specific to Coturn (it’s not the user names you setup in Prosody for example), and are generated randomly for each access. These values are not long lived, you can’t use them next week or even next hour.

To grab a user name and a password, I used the Chrome debugger. Access your site with Chrome(ium) and open the debugger (Ctrl Shift I).
Open the strophe.jingle.js file.
In the onReceiveStunAndTurnCredentials routine, set a ‘logpoint’ (right click) on the line:
this.p2pIceConfig.iceServers = iceservers;
near the end.
Set the log value to:

'the password',this.jvbIceConfig.iceServers[0].username,this.jvbIceConfig.iceServers[0].credential 

The ‘logpoint’ will be set on the following line:
return iceservers.length > 0;
I don’t know why, maybe it’s a Chromium bug.
The ‘logpoint’ will appear in red. It’s normal.

Then, filter the message in the console windows on ‘password’
in a console window, prepare your command:

./stunner range-scan -s turn.example.com:443 -u username -p password --protocol tcp --tls

and restart Jitsi-meet.
In the console window, you should see appear a line like:

the password 1650314409 GoQZrOrlH5qsTVkw7A1xMvpLdC4=

The first value is the user name, the second the password.
In the command line, replace user name and password and send the command.

./stunner range-scan -s turn.example.com:443 -u 1650314409 -p GoQZrOrlH5qsTVkw7A1xMvpLdC4= --protocol tcp --tls

You should then get a pageful of tests against the private IP addresses for your server, such as:

UDP 172.16.0.1: error on CreatePermission: Error 403: Forbidden IP

Note that errors are good, it’s the normal answer.

If you get something like:

UDP 10.0.0.1 was successful!

This is NOT good. It means that the range can be accessed from the Internt.
Note that such a line for UDP is not a very threatening problem because it’s very difficult to use.

BUT, if you get something like:

TCP 10.0.0.1 was successful!

then you have a very pressing security problem. The range 10.0.0.0 can probably be accessed as if it was directly exposed on the Internet. If you have unprotected services (without password), they can be used immediately.

At the very least, you can provide a stop gap by disabling TCP. Normally you don’t have to use tcp for relaying, since coturn changes TCP to UDP and as such talks to the videobridge using UDP.
So your turnserver.conf should always have a line with:

no-tcp-relay

(uncommented)

Ideally all lines returned by the stunner utility should display ‘forbidden’, but if you can’t fix the relaying immediately, at least disable TCP.

If you disable TCP, you will get
TCP Transport is not allowed by the TURN Server configuration
for all TCP address ranges.

2 Likes