TL;DR
We just released DVRTC v0.2.0. DVRTC is our intentionally vulnerable VoIP and WebRTC lab for hands-on security training, and the big news in this release is that it now ships two first-class scenarios: pbx1, built around Kamailio, Asterisk, rtpengine, and coturn, and pbx2, built around OpenSIPS, FreeSWITCH, and rtpproxy. The new scenario brings a fresh stack to attack, new exercises to work through, and a particularly entertaining FreeSWITCH Lua SQL injection path to play with. If you want to get your hands dirty with VoIP security, this release should give you a few more reasons to do so.
Why this release matters
When we first introduced DVRTC, the idea was simple enough: give people a proper place to practice VoIP and WebRTC security without having to build the whole lab themselves.
DVRTC now covers two setups. pbx1 runs Kamailio and Asterisk with rtpengine and coturn. pbx2 runs OpenSIPS at the edge, FreeSWITCH behind it, rtpproxy handling media, exposed recordings, and a set of intentionally vulnerable behaviours that are useful for training and experimentation.
One might ask why bother with a second scenario at all. Because real systems differ, attack surfaces differ, and the details matter. If you’ve spent time testing Kamailio and Asterisk, the same ideas carry over to OpenSIPS and FreeSWITCH, with enough differences to keep things interesting. Similar concepts, different behaviour, different mistakes, different fun.
What’s new in pbx2
The new pbx2 scenario comes with its own architecture, services, docs, and exercises. The current exercise set covers:
- INVITE-based SIP enumeration
- Traffic analysis and packet capture
- Online SIP credential cracking
- SIP digest leak
- Offline credential cracking
- RTP bleed
- RTP flood / recording growth
- SIP flood
- FreeSWITCH Lua SQL injection
- Automated SQL injection with
sqlmap
So no, this isn’t “pbx1 with different software names”. It’s a different lab with its own attack surface and its own personality.
The public deployment is at pbx2.dvrtc.net, and the current pbx2 stack looks like this:
- OpenSIPS as the public SIP edge
- FreeSWITCH as the back-end PBX
- rtpproxy as the media relay
- Nginx exposing the landing page and the recordings directory
Do keep in mind that pbx1 and pbx2 share overlapping ports, so when you run DVRTC locally you should run only one scenario at a time.
The SQL injection path is especially fun
Two words: SQL injection. And yes, the injection point is a phone number.
The pbx2 scenario includes a FreeSWITCH Lua script behind extension 2001 that builds a SQLite query unsafely from the called SIP URI user part. A normal call to 2001 reaches the public HAL-style service. An injected called URI changes the database result and redirects the call to a hidden internal-only 9000 path.
For pentesters used to web app targets, that’s part of what makes this fun. The transport is SIP, the vulnerable code is Lua, the backend is SQLite, and the oracle is the call outcome. It’s an unusual SIP security bug, and exactly the kind of thing a lab is good for.
The exercise docs include a working payload. The injected user part looks like this:
2001'/**/AND/**/0/**/UNION/**/SELECT/**/target,scope/**/FROM/**/did_routes/**/WHERE/**/did='9000
A direct call to 9000 doesn’t work. A normal call to 2001 reaches the public path. The injected version pivots the lookup and reaches the hidden path instead. It works pretty well.
And yes, you can automate this. pbx2 also ships a sip-sqlmap-harness workflow that bridges sqlmap to the SIP injection point, so you can infer and dump the vulnerable SQLite-backed route table without writing each probe by hand.
Seriously though, this is the sort of thing that makes a lab worth running. Reading that something is vulnerable to SQL injection is one thing. Seeing a SIP URI steer a call through a hidden FreeSWITCH path is something else.
How to try it out
Option 1: try pbx2 on the live instance
The easiest way is to use the public deployment:
- SIP:
pbx2.dvrtc.net:5060over UDP or TCP - SIP/TLS:
pbx2.dvrtc.net:5061 - HTTP: https://pbx2.dvrtc.net
- RTP recordings: https://pbx2.dvrtc.net/recordings/
Start with the pbx2 exercise index and work through the exercises at your own pace.
Warning
This is a shared public lab. Please be considerate of other people using it, and remember that DVRTC is intentionally vulnerable by design.Option 2: run pbx2 locally with Docker
If you want a private playground, clone the repo and start pbx2 locally:
git clone https://github.com/EnableSecurity/DVRTC.git
cd DVRTC
# initial setup
./scripts/setup_networking.sh
./scripts/generate_passwords.sh
./scripts/init-selfsigned.sh
# start pbx2
./scripts/compose.sh --scenario pbx2 up -d
You can then verify the scenario is up with:
./scripts/testing-smoke.sh --scenario pbx2
If you want to jump straight into the SQL injection exercise, the upstream docs show both the direct exploit flow and the sqlmap-driven one:
- Exercise 9: FreeSWITCH Lua SQL Injection
- Exercise 10: Automated FreeSWITCH Lua SQLite Exfiltration with sqlmap
Go try it and have some fun
If you’ve been meaning to spend more time on VoIP security, consider this your excuse.
Pick a quiet hour, open a terminal, and point it at pbx2.dvrtc.net. Enumerate the extensions. Crack the weak password on 1000. Capture some traffic. Poke at RTP. Then go call 2001, inject a little SQL through the SIP URI, and see where the call actually ends up.
If you end up using DVRTC for training, internal labs, or just to sharpen your VoIP penetration testing skills, we’d love to hear about it. That’s exactly what we built it for.
