VoIP and WebRTC
Security Articles and News

Awesome RTC hacking list published on Github

We have been collecting lists of resources related to RTC security, namely VoIP, WebRTC and VoLTE which we just made available on our Github. Please contribute and share!

So far, the list contains awesome links for the following topics:

• Presentation Slides
• Videos
• Advisories
• Open-source tools
• Papers
• Blogs
• Notable blog posts and articles
• Books
• Commercial tools
• Vulnerabilities
• Related lists

So, what are we missing? Get in touch on Twitter or submit a pull request.

Jitsi Meet on Docker default passwords - how bad is it, how to detect and fix it

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

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.

…

What’s up with SIPVicious PRO?

In the past 3 years we have been working on developing SIPVicious PRO during our work as penetration testers and in between engagements. Since our chief demolition officer, Alfred joined up with Enable Security, the development has had a much-needed push so that we started making it available to a limited number of companies that happen to be our clients.

Today, we’re making version 6.0.0-alpha.4 available to our clients which includes Opus support, further support for SRTP and of course, a number of bug fixes. Our release notes can be read at the support site.

SIPVicious OSS 0.3.0 released

It’s been a few years since we released a new version of SIPVicious. Truth is, we were working on SIPVicious PRO which we started making available to some of our clients. Many people still use the open-source version of SIPVicious and it is included in various pentest Linux distributions, and definitely is useful to a number of people (especially after they change the user-agent string). And so, with the impending Python2 apocalypse, we decided to make a new release, porting SIPVicious OSS to Python 3 and including various updates that happened since 2015 in the master branch.

If SIPVicious gives you a ring…

Note: SIPVicious version 0.28 is out, go get it.

I like to keep an eye on the social media and Google alerts for SIPVicious and in the last few months I noticed a rise in mentions of the tools. Specifically, a number of Korean twitter users (who have their service with KT, a VoIP service provider) complaining about receiving a call from a caller-id showing ‘SIPVicious’.

Using XSS to switch off dotDefender 4.0

AppliCure’s dotDefender version 4.0 had a security flaw in the log viewing feature of the administrative interface. We just published an advisory for this vulnerability. Here’s the interesting part:

“The log viewer facility in dotDefender does not properly htmlencode user supplied input. This leads to a cross site scripting vulnerability when the log viewer displays HTTP headers.”

The following video shows how an attacker can make use of cross site scripting to get the system administrator to automatically switch off dotDefender. This effectively disables the WAF, leaving the web application exposed to any attacks that said WAF was supposed to protect against.

Setting the secure flag in the cookie is easy

TechRepublic had an interesting article about the Surf Jack attack. Many people commented, some giving their own solution to the problem. However many of these solutions do not prevent the attack because they do not really address it. Of course, who ever missed the details should check out the paper.

The attack has been addressed quite a while ago, and the solution is easy to implement in many occasions. So no need to reinvent the wheel or create a new solution which has not been peer reviewed yet. Here I’ll indicate how to set the secure flag in various languages / web application technologies. The idea is that besides making use of HTTPS instead of HTTP, one needs to set a flag in the cookie so that it cannot be leaked out in clear text.

Surf Jack - HTTPS will not save you

Say hello to a new security tool called Surf Jack which demonstrates a security flaw found in many public sites. The proof of concept tool allows testers to steal session cookies on HTTP and HTTPS sites that do not set the Cookie secure flag. I’ve been working with two banks and some of the vulnerable sites to get this fixed before publishing my research. Mike Perry gave a talk at Defcon involving the exact same vulnerability - so there is no point in keeping this from the public.