OSNews

I raised a support call with BT OpenWorld a few years ago, about the free web-hosting I got with the account. I wanted access to the access_log's from the site.
The CSR told me that the logs aren't availble "but it can be done... I've said too much, bye".
So I played around - chuck a PHP script on there, see what happens (nothing); create a "/cgi-bin" and chuck a shell script into it (nothing); create an SSI html page, chuck it in - aha!
So I played a little bit more with SSI, and found that they even supported #exec (!!)
It was a bit of hassle (create a page, upload it, view it), but I ascertained it was a Sun server; readers who know Sun software will understand what follows: I looked at /opt/SUNWexplo/output, got a bit more detail, looked at httpd.conf, learned a bit more, looked at /etc/passwd, (I deliberately avoided /etc/shadow, but I'd learned more than enough from /etc/passwd); then I started looking around /net. Wow! Access to BT's internal network - available for all BT customers (BT are the UK's main telco/ISP).
I raised a new support call, asking them to remove #exec support (I even pointed out the line in httpd.conf which needed changing). No comphrendo. Kept chasing them.
I created a page which used /net to grab config details of a firewall; its location in the datacentre; the physical location of that datecentre; etc...
A month later, I got a phone call, from somebody to whom it had been escalated, who actually understood the severity of the problem.
Gasping thanks - "it's been shut down immediately."

Unfortunately, they disabled SSI entirely, not just the "NoEXEC" flag - so I can't even #include on that webspace anymore :-(

It was fascinating to see the difference in interest between the CSR's who didn't understand what was going on, from the admin who actually found out - he must have been shocked - not just that the exploit existed, and hadn't been discovered (or reported) before, but also that a customer had been honest enough (in my own self-interest) to report it.