Thursday, August 30, 2007

donations and raisins...

for somebody asked for an adress to donate: i have a paypal-account, its thomas.springer@gmail.com.

i'd be glad for anything i can get - it will be spent on hardware, connectivity and electricity anyway.

tom

back online again


the domain-database took almost two days outtime - and its back online again. a few scripts like ip-info are still down, but will be online again soon.

i did not only rebuild the database, but also rewired the whole thing and drilled loads of wholes throughout my house to do the network. things take time here, for its not only the network that needs some attention, but also the kids and them.

tom

Wednesday, August 29, 2007

downtime

The domain-database is currently unavailable for i pulled the plug accidentally. I'm on my way to rebuild the db - and i used the opportunity to triple the server's ram. Maybe stuff gets faster this way.

tom

Monday, August 27, 2007

SEO with serversniff

Search-Engine-Spammers discovered that Serversniff.net is a lovely site where they can produce a page with links to their pages to be optimized. How does this work?

If you call a page like FileInfo you get an output with a link to your page or at least with a http://somedomain/file, that google will interpret as link to follow. The spammer do exactly this.

Serversniff uses google-adds to get at least a few bucks supporting the servercosts. Google-Bot does follow every customer, indexing the called page a few seconds later. The spamers use serverfarms or, more likely trojanized machines to call their page 5 times in a row from different machines all over the world. Crazy.

I dropped the links on some pages, and I will put on a noindex-Header in the metatags of all relevant Serversniff-pages, hoping to stop these totally useless crapsters from abusing my machine. Seems like nothing is too crazy on the internet.

tom

Sunday, August 19, 2007

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