I still don't like solaris.

I recently did a pentest. Whilst torturing a webapplication i came across a file-inclusion-vulnerability, allowing me a glance on /etc/passwd via opening http://tortured-site.xx/safe.php?file=/index.php.
I tried /etc/shadow, but no luck, apache was not running as root. I poked around to see that i was on a solaris-machine. F*ck.
I remembered that years ago, when i used to work as a webmaster, they gave me a sun E something. A horrible fast machine, but i had no clue from solaris. After two weeks I gave up with the awful thing and got a copy of the first beta-version of Suse-Linux for Sun. I don't like Suse either, but after installing Linux on it the Sun turned from a constant source of anger and stress into a horrible fast database-machine. I decided that solaris an me will never get friends.
So, what now? I knew i had to come up with something reasonable, not just a list of accounts to make the customers webmasters really aware of the problem. I tried to find other logs - but no way. Solaris' not Linux, and the Apache was homegrown installed in some funny directory i couldn't find.
Finally I came up with a promising solution: I had the accounts from /etc/password, and it was written there, that they all used /bin/bash. I went for /home//.bash_history. No luck on the first two accounts, but then, bingo, there it was: the admin deploying new software-versions, connecting to the database with user and password on the commandline and finally grepping through the apache-logs.
The webapp suffered from another minor vulnerability: All https-transactions were done via GET-Requests. I already pointed this out in my report that it's a really bad idea to transfer bank-account details and creditcard-numbers and cvcs in an URL, even if it is transferred via HTTPS.
From there on stuff was easy: I used the file-inclusion to download a days logfile, filtered the relevant requests via get and had lovely stuff to present:

• A list with thousands of CreditCards with CVC, Dates and Names.
• A nice record of what the various admins did over the last years. Some proved to be knowledgable and exact, even verified md5-sums of uploaded files to ensure their integrity, some proved to be unix-analphabets like me.
• A few passwords for accounts and the locations of ssh-keyfiles i didn't bother to download.

What we can learn from this is:

• It is a nice idea to make sure your webserver can't read anywhere on your partition outside the webroot.
• It is a nice idea to keep your bash_history-file small. Putting "export HISTFILESIZE=0" in your ~/.bashrc will do the trick.
• Consider all user input as dirty.

The vulnerable safe.php proved to be a quick-and-dirty solution: 6 lines of custom code killing an otherwise really good webapp. Safe.php is fixed now, but hey, the site is huge, consists of many servers and I'm still keen on getting access to more user-data. Pentesting sometimes reminds me on an interactive version of mistery-stories and whodunits like "The three investigators" when i was young. I still like this part of my job. And, for i'm using zsh instead of bash, err, anybody can tell me how to disable .zsh_history on my machines?

tom