The 2010/2011 cybercrime season has been one of the most prolific I remember. There have been the usual script-kiddie attacks, wasting bandwidth. These largely consist of morons trying to guess passwords using an automated script, and they’re doomed to failure because no serious UNIX administrator would have left guessable passwords on proper accounts. And besides which they’re guessing system account names you only find on Windows or Linux.
What seems to be a bigger feature this year is compromised “web developer” software written in PHP. This is set up by designers, not systems people, and they really don’t understand security – hence they’re a soft target.
This year it appears that phpMyAdmin has been hit hard. This seems to be a vulnerability caused by poor installation (leaving the configuration pages up after use) and using a weak version of the code that was actually fixed a year ago. When I looked I found several copies of the old version, still active, and dating from the time when the web designer had initially commissioned the site.
The criminals appear to be using a mechanism that’s slightly different from the original exploit documentation, but is fairly obvious to any programmer looking a the setup.php script. It allows arbitary uploads to any directory that Apache has write access too.
The nature of the attacks has also been interesting. I’ve seen scripts dropping .htaccess files into all likely directories, redirecting accesses elsewhere using the mod_rewirte mechanism. This appears to intended as a simple DoS attack by overloading target servers (homelandsecurity.gov and fbi.gov being favourite targets).
That this is the work of script kiddies there is no doubt. They’ve left botnet scripts written in perl and python all over the place on honeypot machines. Needless to say this makes them really easy to decode and trace, and you can probably guess which part of the world they seem to be controlled from.
My advice to users of phpMyAdmin (a web based front end for administering mySQL) is to learn how to use SQL properly from the command line. If you can’t do that (or your hosting company won’t let you, which is a problem with low-cost web hosts), at least secure it properly. Upgrade to the latest version, keep it upgraded and remove it from the server when not in use. If you don’t want to remove it, at least drop a .htaccess file in the directory to disable it, or make it password protected.