Fake drug scam hijacks UK college websites

The BBC recently reported that “UK academic institutions have unwittingly become the accomplices of criminals selling fake drugs online.” The article went on to state that this had happened because spammers had “exploited vulnerabilities” in the PHP scripting language. As a PHP programmer I take exception to this claim, as should website owners and web design agencies, for reasons that I will explain later.

The article reported how academic websites with the .ac.uk domain extension were unwittingly forwarding visitors to websites selling fake drugs online. Without going into much detail it was explained that spammers had injected code into the web pages, seemingly exploiting vulnerabilities in PHP, that would make Google and other search engines believe that the pages were relevant for searches related to prescription drugs such as Viagra. When a user searched for those terms and visited the website via the link on the search engine results page (SERP), the injected code would detect this and redirect them to the online pharmacy. When a user visited the website by typing in the URL directly or via a non drug0related search, the normal page is displayed.

Deliberately Targeted

This is not a random attack; the websites had been specifically targeted. Academic institutions rank very well in search engines because, put simply, they are inherently trusted and as such, the .ac.uk domain extension carries a lot of weight.

An attack like this is also clever because it doesn’t place visible links to spammers’ websites or make any obvious changes to the web page that has been compromised. Visitors only get redirected to the online pharmacies if they are actually searching for specific terms. This way the website administrator may never know that their scripts have been compromised and remove the spammers’ code!

One such website that has been affected is Ravensbourne College of Design and Communication. Amazingly, four days after the BBC reported that their website had been compromised (and presumably even longer since they found out), the injection in still in place! If you visit www.rave.ac.uk you will see the college’s official website. If you search for the college and follow the link in the SERP you will also see the college’s official website. However, if you search for Viagra and follow the link in the SERP you will not end up on the college’s website at all, but at a “Canadian online pharmacy”!

What Cost?

This is all very unfortunate for the college. The negative publicity alone would be bad enough, but they will also have to spend time and money removing the injected code and then plugging the holes that allowed an exploit of this type to happen in the first place.

I mentioned earlier that I would object to the reporting of this a PHP exploit. I believe that this is inaccurate and could lead people to believe that PHP is inherently less secure than other scripting languages. In fact I would not call this a PHP exploit at all – it’s slack coding that could have resulted in the same thing happening no matter what scripting language the website was developed in.

From the scant technical details offered in the original article it would appear that the affected websites do not properly validate and filter user input. Of course a website developed in PHP would be vulnerable to rogue code injection attacks if user input is not validated correctly. But for that matter so would any other scripting language!

Aside from my personal objections to the labelling of this incident as a vulnerability within PHP, website owners and web design agencies should also consider the effects of the media when reporting stories like this. If a potential client reads the article and takes from it that “PHP is not secure” or “PHP websites get hacked easily” and then you pitch a PHP-based website to them, how will that affect your chances of winning the contract? And to a lesser extent, how do stories like this affect the public’s perception of your current website? Would they feel safe buying from you online when such high-profile PHP websites fall victim to hacking?

Conclusion

But what can we in the IT community do? It’s not realistic to expect journalists to understand that this was poor coding rather than an insecure scripting language. The best that we can do is be aware of what stories are floating around in the news and be sure that we understand and can explain the real issues!

There are likely to be areas of your website that you don’t want others to be able to access, such as admin areas. Or sometimes you might want to do some quick updates to your code without the website being accessible to the public. If you’re using the Apache web server the hypertext access (.htaccess) file lets you add password protection in a flash!

.htaccess

Apache has a built-in way of protecting entire directories (and sub-directories) from unauthorised users. Let’s assume that you are protecting your /admin/ directory.

If you don’t have an .htaccess file in the admin directory you will need to create one. The .htaccess file then needs just 4 lines of code to turn on password protection:

AuthType Basic
AuthName "Admin Area"
AuthUserFile /system/path/to/.htpasswd
Require valid-user

AuthType

The AuthType directive selects that method that is used to authenticate the user. “Basic” is the most common method and is fine for what we are trying to accomplish.

AuthName

The AuthName directive sets the Realm that will be used during authentication. The Realm has two uses. Firstly, the web browser often presents this information to the user as part of the password dialogue box. Secondly, it is used by the web browser to determine which password to send for a given authenticated area. Once a user has authenticated in one Realm, the web browser will automatically retry the same password for any area on the same server that is marked with the same Realm. This means that a user will not be prompted for a password more than once if multiple restricted areas share the same Realm.

AuthUserFile

The AuthUserFile directive sets the path to the password file that stored usernames and encrypted passwords for your users. This is the system absolute path and not the path within your web space.

Require

The Require directive provides the authorisation part of the process by specifying the user that is allowed to access this area. You can specify a single user or “valid-user” to allow anyone in that is listed in the password file, and who correctly enters their password.

Set Up A .htpasswd User List

Once the .htaccess file has been set up, we need to create the .htpasswd file so that Apache knows which users should be granted access to our admin area.

.htpasswd files are text files that list each user and their encrypted password on a new line like so:

admin:PAzNeZcFJV3Vk
bob:oRCu8rlaPEaTs
frank:1VhSkx7Q37ZYQ

(Passwords are encrypted with a one-way algorithm, so you can’t decrypt the password even if you know the encrypted value.)

Apache comes with a utility that will generate your .htpasswd file and add users with encrypted passwords that you specify. However, we will assume that you don’t have shell access, which is needed to use Apache’s htpasswd utility.

An easier way to generate your .htpasswd file is to use one of the many online .htaccess password generators that will pretty much do everything for you.

One such website is Dynamic Drive’s .htaccess password generator, which provides the code needed in both your .htaccess and .htpasswd files.

Turn Password Protection On

Once you have generated your .htaccess and your .htpasswd files you simply upload them to the directory that you wish to protect. Take care not to overwrite an existing .htaccess file, or you will lose the functionality that it added. If an .htaccess file already exists you should simply add your new code to it.

Conclusion

Apache comes with methods of setting up basic authentication in minutes, so you no longer need to worry about unauthorised users accessing parts of your website that you want to keep private!

Form spam is a growing problem for webmasters. Through our “contact us” feedback forms we’ve all received the ubiquitous emails advertising everything from the little blue pill to cut-price designer timepieces. Bloggers will also be used to receiving lots of comments linking back to the poster’s own website or advertising various wares. The vast majority of this form spam is automated, meaning that a bot comes along and submits the form rather than a human being.

Blocking spambots with a CAPTCHA

Probably the most popular way to protect feedback forms from being spammed it to install a CAPTCHA. A CAPTCHA is a Completely Automated Public Turing test to tell Computers and Humans Apart. There are many different types of CAPTCHAs, but the most common is a distorted image containing a word or phrase that the visitor submitting the form must correctly enter into one of the form fields. Bots cannot “see” the image so they cannot enter the correct word or phrase and submit the form.

Hate them as much as you want, but spammers aren’t stupid. As the use of CAPTCHA images increased, spammers started to defeat them by employing ORC technology that could actually “read” the images (a bit like scanning a document and using OCR software to turn it into editable text again). Unless a spammer really wants to submit your web form, it’s unlikely that a bot of this sophistication will be unleashed on your website. So whilst CAPTCHA images are still a good deterrent, they aren’t the last word in form spam prevention.

There are also other reasons why an image CAPTCHA might not be suitable for your website:

• CAPTCHA images may make it harder for a visually impaired visitor to contact you.
• Visitors don’t like having to decipher CAPTCHA images!
• CAPTCHA images won’t stop human spammers filling your form in manually.

That’s not a definitive list of reasons why you might not want to use a CAPTCHA, but the point is that reasons do exist!

How to block spam without using a CAPTCHA

I have had great deal of success in blocking feedback form spam by filtering user input to identify spam. Spambots appear to operate in a similar way, and patterns can be identified and used to block their form submissions. By scanning input for certain words, phrases or patterns you should be able to virtually eliminate feedback form spam without inconveniencing genuine visitors.

These tips should work using any programming language, whether your website is programmed in PHP, ASP, Coldfusion etc…, as most (if not all) have functions to identify a text string within a larger text string.

Things to look for in user input

Spambots change their behaviour all the time. The items below do not constitute a definitive list of things to check for, but if you look for these you should greatly reduce the amount of form spam that you receive.

PHP-specific hijacking

PHP has the mail() function that allows the webmaster to send email through his website. It is possible for a spammer to craft his form input so as to inject additional headers into the webmaster’s email and thereby add new recipients to the message. If he successfully accomplishes this he can send large volumes of spam through the victim’s website. Many times this type of hijack will contain the phrase MIME-Version: and/or Content-Type. As these are not phrases that genuine visitors are likely to be using, we can assume that any input that includes these phrases is spam.

Email addresses at your website

A lot of the time spambots will use an email address at your website when filling out your form. So if the visitor has used an email address at your website (e.g. sales@your-domain.com) when submitting the form, you can assume that it is spam. Look for @your-domain.com (replacing your-domain.com for your own domain!).

HTML links/code

Spammers often try to submit lots of HTML links in the hope that your form sends you an HTML formatted email and you’ll visit their links. Unless you’re expecting your visitors to be sending you HTML code you can filter out any messages containing a href= as spam.

BBCode

Similarly, spammers often try to submit lots of BBCode links. So unless you’re expecting your visitors to be sending you BBCode you can filter out any messages containing [url as spam.

URLs

Along the same lines as the two points above, spambots often try to submit lots of plain URLs. This is a little more complicated than the former two examples of spam because you might want allow genuine visitors to include URLs in their message. My approach has been to count the number of times http:// appears in the user input and flag any message with more than 2 URLs as spam.

Short messages

Spammers will sometimes test your form for things that they can exploit. Typically they’ll just enter a short message such as “Nice site!” or something similar. You can check the length of the message and flag messages shorter than 11 characters as spam. After all, what genuine visitor would send a worthwhile message that contained fewer than 11 characters?

Common spam email subjects

Spammers often use the same subject line when completing web forms. I have seen a lot of form spam with the subject “some sites“. It’s not a subject that I would expect any genuine visitors to be using so any form submissions with that subject can be marked as spam.

Source email address

I have also seen a large number of spambots use hotmail.ru email addresses. Unless you expect any Russian visitors to be contacting you, you can flag any form submissions using this domain for the email address as spam.

Random spam email subjects

Something that I have started to see more of is the subject containing a random string such as fXNmOtGchIdBGvA. OK so if every spam submission subject is random, how do you block it? Well that string is 15 characters long. How many times would the subject of a genuine form submission be 15 characters long with no spaces? That would require the genuine visitor to be using a single word of 15 characters or more, which seems highly unlikely to me.

Filter out this form of spam by checking the length of the subject line. If it’s 15 characters or more, check for the existence of a space. If none exists then it’s likely that the message is spam.

This type of spam is usually accompanied by the existence of one or more URL in the message. So if we want to be so as not to block legitimate visitors’ messages, we can check the subject line and then also check if the message contains a URL. If both conditions are fulfilled then it’s a pretty safe bet that the message is spam.

Safeguards

Although unlikely, it is possible that a genuine user might trigger one of the spam filters above. Whenever I implement these measures I also assign a useful error message to each filter to that when one is tripped, the user is told exactly why their message has not been accepted. They can then change the offending text. Perhaps you won’t want to reveal your exact phrases or limits just in case a human spammer is accessing your web form, but providing users with an explanation of how to amend their input to pass your filters is a good idea.

Conclusion

By filtering visitor input using these 9 tips you should be able to virtually eliminate form spam. However, as webmasters find new ways to stop spambots, the spammers find new ways to get past our filters. As such user input filtering is an ongoing process and more filters must be added over time. Luckily for the webmaster, spambots’ submissions usually have some discernible pattern that a human can identify and filter out.

Identify the traffic source

We soon identified that large numbers of page views were being generated from a Google AdWords campaign that was no longer active. Naturally this aroused our suspicion, because an inactive pay per click (PPC) campaign should not be generating any traffic at all!

Our next course of action was to analyse the website’s server logs in order to further identify the source of the traffic. We quickly isolated the page views as being generated by a bot. A bot is a software application that runs automated tasks over the Internet. The largest use of bots is in web spidering by search engines and the like.

The bad bot

This is exactly what the bot in question was doing: loading our client’s page an average of once every 10 minutes 24 hours a day. A page load every 10 minutes isn’t a problem for server load, however this bot was also requesting all of the page media such as images and JavaScripts, and therefore wasting our client’s resources.

We then had to choose the most appropriate way to ban the bot.

Banning the bad bot

Our client’s website is built in classic ASP and hosted on a Microsoft IIS/6.0 machine, so that dictated the methods that we could use to ban the nuisance bot.

robots.txt

We assumed from the start that the bot would not obey any exclusion set up via the robots.txt file, so we ignored that option completely.

ASP code at page level

It would be possible to insert ASP code into individual pages in order to stop the pages loading if they were requested by the bot in question. However, this would mean editing multiple existing pages and then monitoring the website to check whether further pages started being affected by the bot. There are more suitable ways of achieving our goal using the IIS/6.0 web server itself.

global.asa

IIS/6.0 allows for an optional file called global.asa that can include scripts that can be accessed by every page in an ASP application. If we edit our global.asa file to block the bot then it’ll be immediately banned from every page on the website. (Note that this does not include content such as images or JavaScripts.)

Identify the bad bot

There are two main ways in which a bot can be identified: by its IP address and its user-agent. (A user-agent is a text string that identifies the client application making the request.) Normally it’s considered best practice to identify and ban a bot based on its IP address rather than its user-agent, because a user-agent can be easily spoofed. Bad bots often originate from one or a small number of IPs or networks and identifying these is usually the preferred method of blocking.

However, in this case our client’s website logs showed us that the bot came from a wide range of IP addresses on different networks, but as far as we could see it did always identify itself correctly with a legitimate user-agent string. We therefore decided that the best way to combat this particular bot would be to ban it based on its user-agent.

Code to ban the bad bot using global.asa

Banning the bad bot using the global.asa file is fairly straightforward. The global.asa file has 4 events: Application_OnStart, Session_OnStart, Session_OnEnd and Application_OnEnd. By adding bot blocking code to the Session_OnStart event it will be executed whenever a user (including the bot) starts a session. We used the following code:

If request.ServerVariables("HTTP_USER_AGENT") = "insert bad bot user-agent here" Then
Session.Abandon
Response.End()
End If

What this code does is identify the bot based on its user agent and then drop the session with Session.Abandon and stop the script execution with Response.End()

If we didn’t drop the session then the bot could accept the session cookie and request the page again. If it did this the page would be served normally, as the bot blocking code is only executed when a new session is started. By dropping the session for the bot we ensure that a new session is started every time that it requests a page.

Using Response.End() means that no HTML ever reaches the bot. This serves two purposes: it reduces bandwidth by not sending unnecessary HTML code; and it means that the bot does not receive the locations of other resources within the HTML response.

As mentioned earlier, images and JavaScripts etc… can still be requested. However, if the bot receives no HTML from its initial request it shouldn’t know where to find those resources.

Conclusions

Initial indications show that the bot ban has worked very well, with our client’s bandwidth coming back down to normal levels. The bot banning code could be further refined and extended:

• We could look for specific keywords or phrases within the user-agent string rather than checking the whole string
• We could send a “403 Forbidden” HTTP response rather than “200 OK”, which would be the technically correct thing to do when banning a visitor
• We could have a list of bad bots that should be banned, rather than just identifying one bot
• We could ban bots based on both their user-agents and IP addresses

Perhaps we’ll investigate these possibilities in another post!