Hacking Linux Exposed

About
Authors
Contents
Reviews
Foreword
Purchase

Articles
Books
Sourcecode
Tools
Errata

Home

 


Every now and then we get bored and look through our Apache access and error logs. Curious to see some of the things we've found?

Who got copies of the book first?

If we assume that only folks who own a copy of the book have found the necessary password information to properly authenticate and view the sourcecode we have available here, then the first people to get a copy came from the following areas cronologically:

  • .aol.com (one of the folks at McGraw-Hill)
  • .army.mil (this was before the authors had recieved a copy)
  • .bigpond.net.au (a kangeroo or two, t'would seem)
  • .kcom.edu (The Kirksville College of Osteopathic Medicine in Missouri)
  • .nb.ca (the book took a trek up north mighty quick too)
  • terra.com.br (brazil joins the gang)
These entries are only the ones from the first few days that the book was publicly available. Nice to see that the book has been circulated so far physically. Or at least that folks are finding unsecured HTTP proxies off of which they are bouncing their connections. (You did read Chapter 12, didn't you?)


What browsers are folks using?

This is the Hacking Linux Exposed website, right? Presumably folks are interested in Linux security. I'd hope that some of these folks were using systems that were, well, secure. Heck, I'd prefer Linux. But seems that reality is much different.

Not counting our own hits, here's the breakdown of the top user agents for the first month of this website:

58.17% MSIE 5
26.22% Mozilla/4
 5.80% Mozilla/5
 2.58% MSIE 4
 2.25% (assorted search engine spiders)
 1.04% Konqueror/2
 1.03% MSIE 6
 0.80% Wget/1.5.3

And the operating system breakdown is as follows:

73.12% Windows
18.30% Unix variant
 3.63% Macintosh
 2.80% (undefined)
 2.25% (assorted search engine spiders)

So it seems that most people that are interested in security are sitting on Windows desktops. How paradoxical.


Amusing error logs

Some folks are obviously annoyed that we don't have directory listings available on the server, and try to get around it with some of the following attempts:

GET /sourcecode/r/.
GET /sourcecode/r/1/*
GET /sourcecode/r/3/revealing.txt.bak
GET /sourcecode/r/5/lilo.conf.*
GET /sourcecode/r/10/evil.suid.c.orig

At least they used wget, rather than a browser, to make the attempts. That earns them a bit above script kiddie.


Attempted breaches

Sorry. We don't have any CGIs on this site. No mod_perl, no embed perl, certainly no ASP. All our content was written with WML in vim, synced off a CVS repository. But that doesn't stop folks that want to find programs anyway, or break out of the web root. Boring attempts include:

GET /.. HTTP/1.1
GET /index.cgi
GET /index.php
GET /cgi-bin/nph
GET /scripts/../../../../../../winnt/system32/cmd.exe

But then there were those who launched automated scans at us, requesting the following pages amongst many others:

/search97.vts /search.vts /search97cgi/s97_cgi /reviews/newpro.cgi /piranha/secure/passwd.php3 /srchadm /users/scripts/submit.cgi /session/admnlogin /ss.cfg /ncl_items.html /test/test.cgi /mlog.phtml /mylog.phtml /HyperStat/stat_what.log /easylog/easylog.html /hitmatic/analyse.cgi /hyperstat/stat_what.log /logs/access_log /ministats/admin.cgi /scripts/weblog /super_stats/access_logs /w3perl/admin /webaccess/access-options.txt /access-log /access.log /awebvisit.stat /dan_o.dat /hits.txt /log.htm /log.html

Well this looks like a straight-forward Whisker scan. The only confusing bit being this: Whisker is a smart CGI scanner -- it doesn't bother looking for NT things if the machine doesn't look like an NT box. Some of the hits included:

/scripts/webbbs.exe /scripts/perl.exe /scripts/testcgi.exe /scripts/cgitest.exe /scripts/rguest.exe /scripts/cgimail.exe /scripts/get32.exe

These are all specifically tagged by Whisker as Windows-specific programs. Thus they shouldn't have been tried. (Unless the 31337 h4x0r used the -S option to force a particular server string.) But, more confusing, is the fact that /scripts/ wasn't even a directory on our server. Whisker does a check first to see if the parent directory exists first (return code that isn't 404) so it shouldn't have tried these.

So why do we still think it was a Whisker-based scan? It still tries them in the same order Whisker generally uses. So it looks like someone may have taken a great program and has removed all that made it superior to other scanners and turned it back into a generic brute-force tool. How sad.

 


About

Sample Chapter
A PDF of Chapter 1.

Appendix A
Available on LinuxWorld

Why did we pick Linux?

Why Linux is Secureable

Linux Overview

Hackers vs Crackers

Doesn't this book apply to all Unix-like systems?

'HLE' or 'HEL'?

HLE Translations

Tidbits gleaned from our Apache logs

Windows vs Linux Security Challenge