This spring, I had the opportunity to teach Network Security at a local university. As one would expect, I chose to teach the course from the perspective of a pentester. One of the challenges I’ve faced is setting up vulnerable systems for my students to attack. We’ve also started using the boxes internally to training new hires and test certain exploits and techniques (the Domino server I put together recently has been particularly useful and will probably end up in a tutorial at some point).
Obviously, best practices dictate that as vulnerabilities are discovered, software gets patched, default credentials disappear, and holes are paved over. This means that a lot of the vulnerable instances I’d like to test (which are still alive in the wild), are difficult to create from scratch. I’ve decided to spend a few posts documenting some of the more challenging or interesting setups. Today, we’re going to explore an Elastix server which happens to be vulnerable to an unauthenticated remote code execution vulnerability and straightforward privilege escalation to root.
Note: In order to create most of my vulnerable boxes, once I got through the usual suspects (Default Creds for Apache Tomcat, MS08-67…), I simply browsed to the Exploit Database and searched for previously verified exploits with downloadable software. This helps streamline the process a bit, at least initially. This was not the case with Elastix (I stumbled across it here in an Offensive Security write-up). Each of these builds assumes the installer is running VMWare is some form. My current solution is to build them in VMWare Workstation and then upload individual VMs in .ovf format to my own portable ESXi server for use in class or in the office.
What is Elastix?
Though the term was first applied to switchboard operations, private branch exchange (PBX) solutions have come a long way. The modern, web-based PBX package typically includes a variety of functions including multi-phone support, fax capabilities, email, and instant messaging. Elastix is a commonly deployed, opensource software solution. Elastix users have access to all the previously mentioned functions and more. The solution includes a web management interface with username/password based authentication. Elastix is largely based on other open source projects (Asterisk, HylaFAX, Openfire and Postfix). An older version of one its sister projects, FreePBX, also happens to suffer from the same vulnerability.
The Setup
The first step is finding the vulnerable version of Elastix. As I mentioned at the top, sometimes, Offensive Security is kind enough to host the software for you, but that is not the case for Elastix. According to comments in the exploit, Elastix 2.2.0 is the specific version for which we are looking. A quick glance at the website shows that only the most recent versions (2.5.0 and 3.0.0) are available for download. Rather than install it and spend time figuring out whether this version is still vulnerable to the same exploit, let’s take a look at another potential source.
Download and VMWare Stuff
SourceForge is fairly hit or miss. Fortunately for us, however, older versions of Elastix are being archived on the site. A quick Google search for “Elastix 2.2” drops us onto the appropriate download page. Both the 32 and 64 bit builds are vulnerable to this particular exploit, so download either. Both are somewhere in the vicinity of 700 megabytes in size, so start the download and then spin up your favorite hypervisor.
Elastix is really just a special build of CentOS, so it’s a fairly straightforward installation. VMWare will try to get you to use its “Easy Install” process. I would avoid that whenever possible, and Elastix is no exception. Just put garbage values in for the Full Name, User Name, etc. when VMWare asks for them. Be sure to uncheck the box labeled “Power on after creation” before you click “Finish.” Since Elastix will, presumably, be the only thing running on this machine, go as small as you’d like. Finally, I would switch over from NAT to Bridged, as long as you’re on a protected network. Before you power on the system manually, edit the VM’s settings and remove the CD/DVD drive with the autoinstall.iso attached to it which will let you manually install everything.
Installing Elastix
The installation process is pretty much like any other OS install. Make sure to enable IPv4 support for your eth0 device as this will save you significant headaches and potential rebuilds later. Since this machine is intended to be attacked, set your root password to whatever you deem appropriate. You don’t want your students/trainees to be able to bypass the Elastix exploit by guessing a weak password and ssh-ng into the box. Same thing goes for the MySQL password you will be asked to enter. I would, however, recommend you set a reasonably easy-to-guess password for the admin web management interface user. While not required for our intended exploit, giving students a view of the console from the interior affords them a little perspective on how and why it works.
Once the installation process finishes, you’ll be dropped into a login prompt. Enter your root credentials and check that the box is pulling an IP address. Once you’ve confirmed it, open up a your favorite browser and surf to Elastix’s web management console. Use your not-quite-default credentials to log into the interface.
Ensuring Vulnerability
Once inside the console, you’ll see that there are tons of options. The only tab that really matters to us is the PBX tab. Feel free to mess around with other settings as you see fit, however.
If we take another look at the exploit, it is apparent that in order to function, Elastix has to be set up with a valid extension. Browsing to the PBX tab in the web interface, conveniently, drops us right in the “Add an Extension” page.
The “User Extension” field is what is referenced by the exploit. If you would like the default script to work, enter “1000”. If you would prefer your target audience to get access to the system and browse for a legitimate extension (or hunt and peck), enter in a different number. A lot of the fields are not required, so I’m just going to touch upon those that are. As you will see in a little bit, the exploit we’re going to use depends on a valid extension (and will actually make a call when run). It will only work if a user picks up or the call goes to voicemail. Follow the simple steps below to create a valid extension that will default to voicemail.
- Type in a display name. Something like John Doe or Joe Hackme would be appropriate.
- Scroll down to the “secret” field. This will be used to register an actual client if you choose to use a second VM witha VoIP client.
- Under the “Voicemail & Directory” section, change the status to “Enabled.” Now, Elastix will send calls to the extension right to voicemail, assuming you haven’t set up a legitimate client.
- You’ll be taken back to the “Add an Extension” page. Be sure to select “Apply Configuration…” (highlighted in pink) or your addition will be lost.
Exploitation and Storage
To test your setup, simply change the parameters of the exploit to match your environment. Make sure to change the extension in the script if the extension you created in Elastix is not 1000. If everything is right, you should see something similar to the screenshot below.
As you build out your vulnerable environment, I would recommend spinning up an ESXi server. A dedicated laptop (big hard drive, decent RAM) makes for a platform with good mobility. Simply turn on the VMs you want and revert them when you’re finished. Just export each VM as a .ovf file and upload it to the server, and you’re good to go.
There are all kinds of other interesting systems we’ve encountered in the wild that are tricky to recreate in a lab. At some point, they’ll make they’re way onto the blog as well.
