--- title: DVRTC v0.2.0: pbx2 and SIP SQL injection date: 2026-04-21 url: /blog/dvrtc-v0-2-0-adds-pbx2-and-sql-injection.md --- ## TL;DR We just released [DVRTC v0.2.0](https://github.com/EnableSecurity/DVRTC/releases/tag/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. [![DVRTC pbx2 homepage showing the OpenSIPS and FreeSWITCH vulnerable VoIP lab](pbx2-homepage.png#center)](https://github.com/EnableSecurity/DVRTC/) ## Why this release matters When we first introduced [DVRTC](https://www.enablesecurity.com/blog/introducing-dvrtc-damn-vulnerable-real-time-communications.md), 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: 1. INVITE-based SIP enumeration 2. Traffic analysis and packet capture 3. Online SIP credential cracking 4. SIP digest leak 5. Offline credential cracking 6. RTP bleed 7. RTP flood / recording growth 8. SIP flood 9. FreeSWITCH Lua SQL injection 10. 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](https://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: ```text 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:5060` over UDP or TCP - SIP/TLS: `pbx2.dvrtc.net:5061` - HTTP: [https://pbx2.dvrtc.net](https://pbx2.dvrtc.net) - RTP recordings: [https://pbx2.dvrtc.net/recordings/](https://pbx2.dvrtc.net/recordings/) Start with the [pbx2 exercise index](https://github.com/EnableSecurity/DVRTC/blob/main/docs/pbx2/exercises/README.md) 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: ```bash 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: ```bash ./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](https://github.com/EnableSecurity/DVRTC/blob/main/docs/pbx2/exercises/09-freeswitch-lua-sqli.md) - [Exercise 10: Automated FreeSWITCH Lua SQLite Exfiltration with sqlmap](https://github.com/EnableSecurity/DVRTC/blob/main/docs/pbx2/exercises/10-sqli-automation.md) ## 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](https://www.enablesecurity.com/voip-penetration-testing.md) skills, we'd love to hear about it. That's exactly what we built it for. ## Further reading - [DVRTC v0.2.0 release notes](https://github.com/EnableSecurity/DVRTC/releases/tag/v0.2.0) - [DVRTC on GitHub](https://github.com/EnableSecurity/DVRTC/) - [Introducing DVRTC: a vulnerable lab for RTC security](https://www.enablesecurity.com/blog/introducing-dvrtc-damn-vulnerable-real-time-communications.md) - [SIPVicious tutorial: testing VoIP security with DVRTC](https://www.enablesecurity.com/blog/sipvicious-tutorial-voip-security-testing-with-dvrtc.md)