I recently had the (undesired) opportunity to learn about HTTP and SQL injection attacks. It took a great deal of effort to diagnose and clean up, but hopefully what I learned from the experience may help you prevent these attacks on your own site or clean up after such an attack.
I first found out my site had been compromised because one of the subdomains started displaying "403" errors (permission denied) and one of the users notified me that the site could no longer be reached. At this time, the rest of the site seemed fine, so I had not noticed anything was wrong with it myself.
On examining the subdomain files, it turned out that the .htaccess file had some new directives written into it, which had the effect of blocking all access to the site. When I further examined the file, it appeared that the actual intent had been to redirect only the users that arrived at the site through a search engine, while allowing direct visitors to see the site as usual.
Ads by Google
Posted by ellen at September 14, 2008 07:38 PM
The redirected users would be sent to a malicious php page hidden elsewhere on my site. Fortunately, the new directives in the .htaccess file were not correctly written, so the net effect was to block the site completely. If it had been correct done, it would have taken much longer for me to notice the hack, because I don't go through a search engine to look at my own sites. So now I check my site every so often by searching for one of the articles on Google, and clicking through.
The vulnerability that allowed this hack was probably an obsolete version of Movable Type, which I had not kept up to date.
Using this port of entry, they were able to write to the .htaccess files, add the malicious files to obscure directories elsewhere on the site, and write javascripts to miscellaneous existing files.
According to one site "the first step in such an attack is to insert an MD5 checksum which alerts the bot controllers that the pages are vulnerable to attack, which then occurs at a later stage. " In my experience the checksums and directives show up at the same or very near the same time in the .htaccess files.
An example of an MD5 checksum from the corrupt .htaccess file:
# a0b4df006e02184c60dbf503e71c87ad
After the checksum there are URL rewrite conditions which are followed only if the browser arrives from a search engine.
RewriteEngine OnRewriteCond %{HTTP_REFERER} ^http://([a-z0-9_\-]+\.)*(google|msn|yahoo|live|ask|dogpile|mywebsearch|yandex|rambler|aport|mail|gogo|poisk|alltheweb|fireball|freenet|abacho|wanadoo|free|club-internet|aliceadsl|alice|skynet|terra|ya|orange|clix|terravista|gratis-ting|suomi24)\. [NC]
RewriteCond %{HTTP_REFERER} [?&](q|query|qs|searchfor|search_for|w|p|r|key|keywords|search_string|search_word|buscar|text|words|su|qt|rdata)\=
Next came the actual redirection directive:
RewriteRule ^.*$ /path-to-theinsertedfile/axorak/ex3/t.htm [L]
Step 1 was to clean up all the bad code from the .htaccess files. The directives were somewhat hidden from view by having hundreds of spaces inserted at the beginning of each line, so you could not see them in a code editor unless "word wrap" was turned on.
Movable Type has permissions to write static files to the server, so I'm guessing they used SQL injection or http injection to somehow take advantage of that feature to write to the .htaccess files. So the first order of business to fix this mess, after deleting all the spurious directives from the .htaccess files, was to install the very latest version of Movable Type.
Step 2 was to download a copy of the entire site and do text searches for suspicious items and clean them all out. My webhost's support team did some a lot of cleanup using phpshell, but even they missed some of the hidden files that I managed to find this way.
Some search terms to use:
"yandex|rambler|aport|"
"e0fa4c4356551c94"
"document.getElementById('hr').click()"
The malicious javascripts were either inserted into existing files, or in newly added HTML files which were buried deep within many nested folders. It is crucial to find every single one.
Step 3. I added my own directives to the .htaccess files per the suggestion of this page and other similar ones:
7 tips to optimize Joomla! security and prevent getting hacked
Step 4: I went through my entire site and removed or moved out of web accessible folders anything that didn't absolutely have to be there, including old backups, draft versions of scripts, test versions, etc.
Since then, things have settled down, although on checking logs I've noticed plenty of attempts to hack the site. If you notice entries that include something like:
"GET /pathto/somefile.php?p=-1+UNION+SELECT+426001,426002,426003,426004,426005,426006/*
then your site is being scanned for a possible sql injection attack, often to attempt to retrieve administrator passwords or bypass them entirely.
Another site recommends modifying the php.ini (and Apache httpd.conf file if applicable) to set allow_url_fopen to off. (The default is on).
Useful Resources:
Update
Xandroid on Slashdot makes this suggestion to set up an automatic check for .htaccess hacks:
Something you may consider: make a backup of a known-good .htaccess, and set up a cronjob to `diff --brief` the two frequently and email you if they're not the same. I've done this with a list of all the PHP files in my account on a shared server:
7 */4 * * * cd $HOME; find . -name *.php >tmp.phpfiles.txt; if [[ -n "$(diff --brief tmp.phpfiles.txt phpfiles.txt)" ]]; then diff tmp.phpfiles.txt phpfiles.txt | mail -s "new PHP files" YOUR@EMAIL.ADDRESS; fi; rm tmp.phpfiles.txt
Ads by Google
Thanks so much for sharing your knowledge!
There is a php application that will scan all files for any changes using a unique hash total, and can email you if the totals do not match, meaning a files has been altered.