During a recent external penetration test, one of the many servers listening on the default HTTP port 80 caught my eye. The web server threw a HTTP Basic Authentication login prompt immediately upon viewing it, which was unique amongst this particular target network.
Some time was spent trying to fingerprint the device and nmap did most of the heavy lifting for me by simply adding the “-sV” switch to my nmap command. “-sV” probes open ports to determine the service/version information. I learned later that nmap provided me the wrong model of the device but it was still enough to get my research started.
Research on this gadget lead me to a document, which is the manual for an Edgewater Edgemarc model that is sold with custom firmware by 8×8 Business VoIP. The contents of the manual told me the default username and password for the device, so I decided to try them out.
At this moment things started to look up; I was in! I began doing reconnaissance on the configuration, ultimately trying to learn the purpose of this contraption and why it needed to sit, exposed, at the edge of large corporate network. It appeared this specific device was branded as a Shoretel VPN Concentrator and its purpose is simply to securely connect remote VoIP phones to the rest of the internal network over VPN. Quite a juicy find during external penetration test. It has internal network access to at least the VoIP network, assuming there’s some sort of network segmentation (there wasn’t).
The interface looked ancient and the web server did not even support SSL. How secure could it be? (Note: SSL is now available across all vendor firmware’s for the Edgewater Edgemarc appliances). After finding over 10 instances of reflective cross-site scripting, I was convinced there was something more significant left to uncover.
The URL of all the configuration pages were formatted in the following manner:
http://(Edgemarc IP)/cgi-bin/config?page=XX
“XX” in this case is a direct object reference for every configuration page. I saw that the pages appeared quite sporadic. One page would be 23, the next 53, and next 7. I realized pretty quickly that with the available menu options that I certainly did not have access to 53 different configuration pages, figuring it was firmware based, so I proceeded to brute-force this number with Burp Intruder.
After going through 50 of them, not finding anything of particular interest, I uncovered a page titled “User Commands”. The description of the page was as follows:
“The User Commands page is used to enter specialized commands or enable features that are not available through other GUI pages. User commands are stored in the file /etc/config/user_defs.conf. They are automatically executed when Submit is pressed on the page, whenever the system starts, or a network restart is performed. User commands are commonly used to create user specific firewall and routing rules.”
Interesting. Clicking on the “Help” hyperlink in the top right, I was shown what appeared to be direct iptables and ifconfig configuration examples, just as you would enter them in the command line.
Entering a few simple commands yielded no feedback to whether the commands ran. No output from the commands were presented. Hoping this might be a blind OS command injection flaw, I issued some simple ping commands to an internet-facing attacking box and sure enough, I was receiving incoming ICMP packets from this device!
At this point, I tried using several tools that come pre-built in most Linux operating systems so that I could escalate this command injection into a full-blown shell. I set up a listener on my attacking box for port 80 and attempted to use wget to make a request to my attacking web server. I received the request which gave me everything I needed to pull a malicious payload and execute it.
I generated a payload for a Linux reverse TCP meterpreter shell (I found that the “mettle reverse TCP” payloads were much more stable during post exploitation and pivoting) and served it up, then used wget on the Shoretel appliance to pull it down and drop the binary in to the /tmp/ directory. I chose this directory because it’s commonly a world-writeable directory for all users.
Soon after, I was convinced that I had a payload on disk and all I had left to do was execute it. So naturally I gave it a shot.
And shortly after, I looked at my Metasploit handler, only to find:
I received a shell from the device and quickly dropped to command line to find I was running as the root user!
http://cve.mitre.org/cgi-bin/c…
Disclosure Information:
Edgewater has confirmed that this vulnerability is present on all Edgemarc devices, regardless of vendor specific firmware. They also informed me that this is expected to be fixed in an upcoming release but did not specify a date. I can confirm that the default root password to log in to the interface requires the password to be changed upon first log in, in all devices produced or updated within the last year, effectively mitigating the vulnerability.
Disclosure Timeline:
Feb 8th – Reached out to Shoretel, discovered this was an Edgewater issue.
Feb 15th – Disclosed vulnerability to Edgewater. Received case number.
March 6th – Update email sent. Was told there are plans to remove all un-used configuration pages.
April 17th – Update email sent. Was advised it is on the roadmap to be fixed in an upcoming version, no set date.
May 11th – Update email sent. Informed Edgewater that blog post will be live on the 15th unless otherwise requested. Sent a copy of the post to them as requested.
May 15th – Requested date for patch to be released. No response.