This is the second part in a two part blog.  In the initial installment, I illustrated how vague configuration settings and default and hardcoded credentials could lead to tragedy.  In this installment, I will show you that tragedy.  Armed with a dash of Google, a hearty helping of telnet, and a smidgin of echo along with some LUA trickery, I was able to roll through a misconfigured installation of FreeSWITCH.

As I mentioned in my initial post, this scenario was blackbox, meaning zero knowledge of the device and configuration.  My approach here is simple.  First, I plug the device in to the network, and then perform nmap to identify any interesting ports or communication channels.  When Nmap completed the port scan, I noted standard ports 80 (http) and 53 (DNS), but then I noticed some other ports such as 8021.  I actually chose to dig deeper into the purpose of 8021, which meant I needed to probe it with a socket.

Generally, connecting to and probing sockets can be done with tools such as netcat or socat, I usually opt to use IPython, a nice Python Command Interface and use a basic socket.  In this case, I basically connected to the port and received whatever data was sent.  In this case, I received an interesting message, seen below in the image.

Using IPython to connect to port 8021 and identify the service.

My initial assertion was that this was a strange HTTP header, but given the vague context, I turned to Google.   I used the following search query “port 8021 Content-type auth/request”, which in turn gives FreeSWITCH.  After a few minutes of quickly reviewing the results and documentation, I found that FreeSWITCH has a default password, ClueCon and a command interface.

From here, I downloaded the source, compiled a sample client, and then I connected to FreeSWITCH.  Generally, I enjoy adventure and discovery, so rather than read the documentation to see that there was a system command in the interface, I stumbled on to it.  Whenever I am presented with a command interface, I like to play around with the commands and look at the help I am presented with either from error messages or from help menus.

Once I found the system command, my initial reaction was to perform commands such as whoami, ps, pwd, cd, etc., but when I executed the command with the aforementioned commands as arguments, I received no result.  Filled with a little frustration, I decided to try ping against my host and that frustration melted away and turned into school girl giddiness (yay!).

OS ping command is executing via FreeSWITCH. Note the ARP for 172.*.*.2

My next thought from here was if I can ping, can I telnet?  Yes, yes, I can.  After this finding, it only took me a few minutes to figure out how to redirect stderr and stdout to a listening port on my host.

Piping OS command output and errors through telnet to my host.

At this point, I simply opened a port open on my machine, and telnet’ed command results back to host.  Once I had command access on the device, the first check was to identify my privileges, which turned out to be root.

After this moment, the game changed significantly.  First, the client I had to use was great, but it was not an attacker’s client.  So rather than playing fairly, I created my own rules and in the process my own client.  I basically wrote a command shell that wrapped FreeSWITCH command with telnet and echo to execute, write, or read the files from the remote host.  Game on.

After I finished my basic client, I went through and enumerated file mounts, directory structures, and executables on the system.  My next step was to look at binaries and see what they could offer in the form of intelligence and stuff like that, but there were no tools on the host to perform these tasks, and a knowledgeable person would observe that telnet and echo are not ideal for moving binary files back and forth across the network, so I surveyed the host for any viable interpreters and shell functionality.  I tried several shell ninja hacks, but no progress was made.

Then I found a LUA interpreter, and the game got more fun.  In order to support binary file transfers, I simply converted the binary file to ACII hex strings, and then I could transfer the binaries using my established methods.  Again, I augmented my attacker’s shell.  Game on.

While I was on the device, I also identified several block devices of interested that I wanted to pull data from.  To access these data points, I used dd if=<device> of=/dev/null bs=1 to get the devices size.  Then performed dd into a writeable temporary file, hexlified the data, and sent it across the network.  I repeated this process until I reached the size of the file.  Game Over!

Below is an image of my FreeSWITCH attacker client.  Its hacker quality code, so mileage will vary.  Also below are a few of the LUA scripts that I used to facilitate the file transfer and hexlification process.

Attack client developed to facilitate the 0wning of the FreeSWITCH installation.

Show me some codez:

FreeSWITCH Command interface:  cmd_interface.py

Hexlified Image Capture Server:  mini_image_cap_server.py

(Un)Hexlify LUA Script:  hexlify.lua

DD to Hexlify to Echo to Telnet Madness: dd_remote.lua