[wikka-community] Baby hacker on the loose

[Marjolein Katsma]

Hi All,

Last night, I was looking at our access stats and happily concuded that 
traffic was gradually picking up again after our outage; Dario went looking 
at the referrers and spotted a weird referrer string in the global 
referrers for wikkawiki.org, with no less than 2313 hits! It looked like a 
hacker attempt, except you can't really hack by means of a referrer string 
(certainly not when, as was the case here, the referrer is  an external 
URL). Example:

http://www.edhelper.com/cgi-bin/phf?Qalias=x%0a/bin/cat%20/etc/passwd

That had the 2313 hits; there were a few more with the same type of query 
but for different domains, including one referencing webcrawler, a major 
meta-search engine.

So I plugged the query string into Yahoo! and it came up with 826 
references... turns out it's an old, old hack, found in the classic hackers 
guides - see 
http://www.windowsecurity.com/whitepapers/The_Unofficial_Web_Hack_FAQ__Section_02.html?printversion 
for example - except it won't work as a referrer string. It clutters up the 
referrers stats with useless entries though; but it isn't really referrer 
spam either.

What to do? The first idea was to blacklist the referrer. Oops - bad idea: 
blacklisting bans the *domain*: we don't want to ban a major (meta) search 
engine do we? The other domains were equally harmless. Next idea: just ban 
by referrer in the .htaccess file. So, off I went and edited our .htaccess 
file so any access with "cgi-bin/phf" in the referrer string would be 
denied access. But when did this start?

So, I loaded the access log and did a search for the query string. It turns 
out the first access was yesterday (the 20th of November - and in the US at 
least, Thanksgiving holiday has just started...). What was worse, was that 
the hackish query string was not just in the referrer, but in the actual 
request as well. Of course, it doesn't work on our server - and it won't on 
most: it's such a classic from around the turn of the century that hardly 
any system will actually still have the 'phf' script sitting on their 
servers. But our baby hacker made things easy for us: he was pounding our 
server from the same IP address (69.34.126.203 - it seems the kiddies in 
NYC have too much time on their hands!), and with the same User Agent 
string: 'WWW-Mechanize/1.30'. So I added a few more lines to the .htaccess 
file ensuring that anything even smelling like this will get denied.

1. After the SetEnvIfNoCase (in our standard .htaccess file) I added:

SetEnvIfNocase Referer "/cgi-bin/phf\?" BadReferrer
SetEnvIfNoCase Request_URI "/cgi-bin/phf" BadBot
BrowserMatch "WWW-Mechanize/1.30" BadBot

2. After order deny,allow I added lines to ban both the IP address and the 
"BadBot" and "BadReferrer"

So, the start of a (standard) .htaccess file (disregarding the old 
SetEnvIfNoCase which is hardly relevant anymore and I've commented out) 
would now look like this

SetEnvIfNocase Referer "/cgi-bin/phf\?" BadReferrer
SetEnvIfNoCase Request_URI "/cgi-bin/phf" BadBot
BrowserMatch "WWW-Mechanize/1.30" BadBot

order Deny,Allow
deny from env=BadReferrer
deny from env=BadBot
deny from 69.34.126.203

See http://httpd.apache.org/docs/1.3/mod/mod_access.html#order (Module 
mod_access) for an explanation of how this is processed; in short, the 
default is Allow (second directive) but any deny directives are processed 
first. See http://httpd.apache.org/docs/1.3/mod/mod_setenvif.html (Module 
mod_setenvif) for more on the SetEnvIfNoCase and BrowserMatch directives.

Needless to say, make sure you don't have the 'phf' script in your cgi-bin: 
if you do, it's a major security hole. Even if it's from the hackish middle 
ages, it's worth a quick check.

Unfortunately, I'm now left to conclude that a good chunk of our 
"improving" traffic was thanks to this baby hacker. We'll keep watching and 
hoping for better results...

Happy Thanksgiving!

Cheers,
Marjolein

--
JavaWoman
Web Standards Compliance Officer, Wikka Development Crew
http://wikkawiki.org/JavaWoman
Skype: callto://goneagain