So my inbox lit up today with a Full Disclosure note about a vulnerability in Trustwave's WebDefend. The thing is, while it's an interesting way to get a shell on the box, it's really not "Privilege Escalation" as the poster describes. Here's an excerpt:
The operator account 'bgoperator' is used to perform system maintenance functions. This account accesses the appliance via ssh. It is important to note that the operator account has a default password that has been provided in the 'Getting Started' manual.
Then the interesting part happens when the researcher breaks out of more using vi:
When viewing log files the shell uses the 'more' command. When using 'more', pressing 'v', will start the file in 'vi' text editor. From 'vi' it is possible to read and write to any file on the system as root. By modifying the operator account's login script we are able to gain access to a root shell.
Clever stuff, but the context in which this is occurring makes all the difference between whether this is a "neat trick" or a "security advisory". If the 'bgoperator' account was something with limited privileges, then absolutely, we could call our newfound access "escalated privileges". But 'bgoperator' is the big one, the highest-level account in WebDefend, with the ability to 'sudo' commands and privileges that include rebooting, changing the IP address, managing log files, and even re-imaging the box. It's also important to note that this account can only login to the box from the management port, which should be accessible only to the internal network.
This type of activity is actually more like unlocking a smartphone, or getting into "developer mode" -- you can turn your WebDefend box into your own webserver or even run FreeCiv on it. It's your box, after all. But all things considered, the menu that 'bgoperator' is presented with is pretty handy, arguably better than typing shell commands. Ok, not much is better than typing shell commands, but you get the picture.
SpiderLabs has worked with many security vendors on advisories over the years, and we're no stranger to publishing advisories for our own products. We have even published advisories from this researcher in the past, and certainly welcome findings from those who practice responsible disclosure. In this case, however, if you're already the boss, there's really nowhere to go from there.
This example proves why we believe responsible disclosure is important. Without a dialog, it's sometimes hard to keep these issues in their proper context. We've stepped away from our own reported advisories after working with the vendor and being shown other mitigating factors that we may not have considered. We owe it to the security community to flesh these things out before rushing a statement onto Full Disclosure, or Twitter, or any other medium that we use to get security information. Otherwise, we do this thing, which just confuses everyone involved and makes nosteve a sad panda.
