Spam "Artists" Can Trick A Non-Spamming Website To Send Spam Emails

It was the evening of Friday 16th June 2006, and I was rounding up the updates on my websites, when I decided to search online for and install another site recommendation script on my website in place of the one that for some reason I could not fathom, continued to return a "500 - Internal Server Error" error. The Google search results page threw up a slew of referral scripts offering from various authors - some free, others for sale.

At this time I was just keen to test and see if I could get one to work on my site. Soon I settled for one called "The PCman Website Refer a Friend" Within minutes, I had it installed and running. One thing I did not do, and which I would advise (based on the benefit of painful hindsight) ANYONE who uses third party scripts on his/her site to do, is to check and confirm the programmer has taken pains to secure the script code against exploitation (Specific details/links to URL resources on how to go about this provided further down).

Note: It was only after the event, and following prompts from my hosts that I checked and found the PCManrefer script had inadequate security written into the code. The resulting "security hole" was what the hacker later exploited remotely to launch a massive spam attack.

On Tuesday 20th June 2006 a.m, I tried to log into my web hosting account to upload files, but noticed the ftp tool I was using kept returning an "incorrect password" message. After trying repeatedly, and confirming I was using the correct password, I decided to try logging in to my webmail - so as to send an email to the support department for assistance. This presented a problem as well. Each time, I tried, I got a message like "Dropped by ISMAP server". Now quite alarmed, I decided to type the URL to my website - http://www.spontaneousdevelopment.com. My worst fears came to pass - The browser printed a "Page Not Found" message in bold!

At this point, I promptly went to my host's website and initiated a chat session with the operator. The following chat conversation took place:

-----start of chat session------

: Hello! How may I help you?

: hi

Visitor42152: Hi

Visitor42152: I cannot login to my webmail or access my entire website

Visitor42152: MY reg no is

: We are writing to inform you that during the past 30 minutes your web hosting account (username = deleted) has sent 625 messages to the email subsystem of the hosting server. This is in violation of our terms of services, and as such, any websites

: belonging to that account have been taken offline.

: In order to reactivate your account you will need to contact our support department and agree not to abuse our servers again. Any further incidents like this will cause our system to remove your account completely and without warning

Visitor42152: I am working from a cyber cafe I normally do not use though it's close to my home

Visitor42152: I am certain this is due to activities of email hackers who use the same ISP as these guys

: send an email to

Visitor42152: How long will it take to resolve this?

: 6 -12 hours

---End of chat session------

Well, I did not get it resolved in 12 hours. In fact, by the time I was finished exchanging emails with the support department, I learnt my account would be suspended for 7 days, with the warning that if it happened again, my account would be reconsidered for termination without notice.

How They Did It (i.e. Hijacking My Website Referral Script's Form Post)

Below, I reproduce the exact text of the explanation given by my host's Abuse Department, when I requested for details that could help me understand how the problem had occurred, and what I could do to prevent a re-occurrence. You will notice that the Perl script I installed (i.e "pcmanrefer.pl") some days before the problem, was identified by the administrator as one of three found to have poor security built into their code.

--- "Aplus.Net Abuse Department" wrote (I have re-arranged - but NOT edited - the text for readability): > Hello,

> Basically the attack is performed on scripts that trust the information that the submitter enters and are therefore easily exploitable. You can refer to these two documents that describe in details this very specific attack:

# http://www.anders.com/projects/sysadmin/formPostHijacking/
# http://www.nyphp.org/phundamentals/email_header_injection.php

I have reviewed the spam evidence sent to us and in the headers the subject is different every time which means the script used is taking the input data from the visitor and doesn't edit it at all:

Subject: Incredibly undervalued, you'll not want to miss this opportunity the protracted I have found several such scripts in your FTP space:

# /cgi-bin/mailer/simplemail.pl
# /cgi-bin/mailer/mailer.pl
# /cgi-bin/pcmanrefer.pl

There might be others that are compromiseable too but you know better the structure of your website and which exactly script is sending the data unchanged. The bottom line is to filter out all input data as suggested in the two articles above.

Thank you,

Clues Left Behind By The Hacker In My Server Space

When I eventually gained access to my server space, I found confirmation that it was indeed the "pcmanrefer.pl" script that had been exploited: Its referral log file (refer-log.txt), had grown to a massive 11.1 Megabytes size(many million bytes up from its 0 bytes size when I uploaded it less than 9 days before)! Opening the file revealed huge volumes of email addresses and message contents, originating from bogus "addresses" at my sub domain e.g. InvestorsWeekly@spontaneousdevelopment.com; my@spontaneousdevelopment.com; stephannie@www.spontaneousdevelopment.com ("who is SHE??", I said to myself) - and many, many more!

The Attack Had A Negative Multiplier Effect - Which Is Why You Would Be Wise To Prevent It Happening

When my hosting account was suspended, my websites could not be visited, nor could I access mails sent to my webmail account at my domain during that seven day period. But that was just one side of it. ALL the short URLs that I had created to point to various sub domains on my main website were put up for removal by the service provider, who placed a bookmark update link on a page leading the to home page - with the following message:

"Due to enormous phishing spam with our sub domains () we will close this short url re-direction. Please update your bookmarks. "

One example of short URL that was affected by this problem is http://www.cbsolutions.v27.net, which points to cbsolutions.spontaneousdevelopment.com - the mini site for my Creative Business Solutions(CB Solutions) delivery service.

My mind raced back to all the articles I had published at the Ezine articles directory, in which I had used the short URL addresses in the resource boxes invitation to readers(at the end of the article). A number of those articles carrying the short URLs had been syndicated on other websites, where I would not have access to make changes to them. I realised that it would only be a matter of time before readers of some of my articles would find themselves confronted with a "Page Not Found" browser error, or a general advert page for domain names sales etc - instead of my site: Definitely not good for the image I was trying to build online!

I provide the above details to give you an idea of just how bad this can be - so you can really understand why it would be in your best interest to make sure you never leave yourself open to the extent that this type of problem can affect your website.

Taking Action To Prevent (Future) Attacks

I deleted the "pcmanrefer.pl" script and the other two that were identified by the hosting provider's administrator (see email above). I also removed another mailing list managment CGI script that I installed a month before. In a way, I felt like I was taking medicine after death. :-) But at least by this time, I actually had a better idea of WHAT had happened, HOW, and WHY - and what I could do to protect myself for the future. Next, I visited the URLs emailed to me by my web host. Out of curiosity, I also did a number of searches on Google, to see what else I could learn about "form post hijacking", and spamming in general. Below, I provide links to some useful resources I found. If you own a website, I think you will want to spend some time studying them.

IMPORTANT NOTE:

1. It would interest you to know that I no longer use a site referral script on my wesbsite. Instead I have developed a simple email recommendation template that anyone who is so keen to tell another about my site can use. Visit http://www.spontaneousdevelopment.com/referus.htm to see what i mean. There are many other effective ways to get marketing exposure for a website, and I am currently modifying my website design/marketing strategy to accommodate them. As time goes on, visitors to my website will see ample evidence of this.

2. Some of the resources whose URLs are listed below, were published as far back as 2002, so they might not exactly offer relevant or effective remedies that can be successfully applied today. However, the educational value they offer towards understanding the problem(s), in my opinion, would still make them worth a visit.

So, with that note of warning, I wish you happy reading and good luck in your fight to protect your website against exploitation.

Useful Learning/Problem-Solving Resources

1. Using Apache to stop bad robots evolt.org - by Daniel Cody http://www.evolt.org/article/Using_Apache_to_stop_bad_robots/18/15126/

2. Why Some Scripts are dangerous to use on your Website - http://webnet77.com/help/dangers.html

3. http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay - By Anders Brownworth Interesting Crack Attempt to Relay Spam (Comment: this is actually a precursor to the full article referred to me by my web host titled "Form Post Hijacking - How to solve the problem.")

4. By Anders Brownworth - Form Post Hijacking - How To Solve The Problem article author

http://www.anders.com/projects/sysadmin/formPostHijacking/

5. http://handsonhowto.com/cgi101.html - A Hands-On How-To(Securing the CGI script section - useful) - from Brass Cannon Consulting

6. WWW Security FAQ: CGI Scripts - http://www.w3.org/Security/Faq/wwwsf4.html -by Lincoln Stein (lstein@cshl.org) and John Stewart (jns@digitalisland.net) - hosted by the World Wide Web Consortium (W3C) as a service to the Web Community.

7. Stopping Spambots: A Spambot Trap - http://www.neilgunton.com/spambot_trap/

8. How to block spambots, ban spybots, and tell unwanted robots to go ... Spamming of referer logs is a growing nuisance,

http://diveintomark.org/archives/2003/02/26/how_to_ block_spambots_ban_spybots_and_tell_unwanted_robots_to_go_to_hell

Self-Development/Performance Enhancement Specialist - Tayo Solagbade - devotes his time to exploring new frontiers of Self-Development Education, especially as it relates to showing people what they can do by themselves, for themselves to achieve their set goals - DESPITE the limitations of their circumstances or environment.

Download FREE demos of customisable Excel-VB driven spreadsheet application such as (1) an Automated Invoice, And Delivery Note Generator (2). a Personal Bank Deposits/Withdrawals Monitor™ (3) a Church Records Manager™ or (4) an Article Readers' Interest Index(RII)™ analyser from http://www.excelheaven.spontaneousdevelopment.com

How To Pull Massive Traffic To Your Website With Dynamic Content

I see many new webmasters throw up websites with a few words about what they are offering and call it a day. Months later, these new webmasters find that they haven't seen more than a few visitors and they are wondering what went wrong. The fact is, they could have helped themselves a lot more had they been using dynamic content on their websites.

You Are Competing For Eyeballs

The sorry state of the matter is that nowadays, you've got billions of other websites competing for a limited number of eyeballs. You've not only got to stand out from all of those static webpages, but you've got to find a way to get your visitors to return again and again.

It's Not 1996 Anymore

Many new webmasters think that if they build it, the traffic will come. But, although it may have been that way in 1996, it's not anymore. (1996 was the year I put up my first niche website, way before they were called niche websites. I went out one evening after posting it, and three hours later I came home to find it had been visited more than 101,000 times.) Those were the days!

PHP and Perl CGI Scripts To Your Rescue

If you want to make your site really pull massive amounts of visitors and have them return again and again, you need to make your website "sticky". What this means is that you've got to make a website that your visitors will want to return to again and again-like flies to a streetlight. (Just don't zap your visitors because you want them to return!) To do this, you need to stand out from the rest of the pack. There are several steps you are going to want to take. I'll explain each one and how static pages compare to dynamic pages in each area.

Get your traffic by getting listed in search engines based on good content.
PHP and Perl CGI scripts can help you do this.
Static pages can do this well.

This is an area where static content actually performs well. Search engines love wordy websites that make sense. If you've got access to a lot of original information on a particular topic, you've got the beginnings of a good static content site. A good dynamic method of getting free content on your website is to allow your visitors to leave a message on a guestbook. Even if they are simply advertising their own sites, they are still adding content to your website that the search engines will love. There are many PHP and Perl guestbooks available.

Keep your traffic by making a part of your website something that is so useful that it is addictive or "sticky".
PHP and Perl CGI Scripts can help you do this.
This would be difficult to do with a static website.

The ultimate sticky website is the search engine. To deny this is to lie about the fact that you use one just about every time you are online. Most people think that it's impossible to get started in this area now that Google seems to have firmly implanted itself as number one. This is simple not true since there are many niche areas that could still be dominated. There are many PHP and Perl search engine scripts available.

Multiply your traffic by encouraging word of mouth advertising.
PHP and Perl CGI scripts can help you do this.
This would be difficult to do with a static website.

Another good method of promotion is to have your visitors (who keep coming back because of your search engine or other dynamic content) refer their friends so that they can visit your site over and over. It is said that birds of a feather flock together so if your visitor liked your website, it's a good bet they know other people who would like it too. There are many PHP and Perl refer-a-friend scripts available.

Pull your traffic back again by reminding your visitors (and their friends) about your website, and subsequently any products that you are selling.
PHP and Perl CGI scripts can help you do this.
Static pages can't do this at all.

Once you've got your content, visitors, and their friends, it's time to get them to subscribe to your mailing list. Once they are reading your mailing list (make it something they'll be interested in or they'll unsubscribe just as fast) you can squeeze in an ad or two for products that you are either selling or are an affiliate for. This is where the traffic can really start to snowball! There are many PHP and Perl mailing list scripts available.

Protect your e-mail address from spam robots.
PHP and Perl CGI scripts can help you do this.
Static pages can't do this at all.

Make sure that you are not leaving bait for spam robots. If you've got your e-mail address displayed on your website in plain view, you're probably getting a great deal of spam from sites you've never even visited. Don't think that putting the word 'at' instead of an '@' symbol is going to stop them…any programmer worth their salt could write a robot that could beat that "security". The only secure way to allow your visitors to e-mail you without making it easy for spammers to harvest your e-mail address is to use a website contact form. There are many PHP and Perl contact form scripts available.

Static Pages Will Be Outperformed By Your Dynamic Website

Out of our five methods for driving massive traffic to your website, we've just seen that only one of them is easily achievable with static webpages. Which brings us back to our original topic. Why are so many new webmasters still putting together static webpages and wondering why they aren't getting any visitors? Dynamic content is definitely the way to get lots of traffic to your website.

Yes, every website needs it's fair share of static content because as we've seen, this is how the search engines find and list your website. But that's only effective for attracting and keeping the search engines' attention. To attract and keep your visitors' attention, and to truly drive massive traffic to your website over and over again, you're going to need some dynamic content to keep them coming back. And that's exactly the type of work that PHP and Perl cgi scripts are really good at.

Thomas J. Delorme has been designing websites and PHP and Perl cgi scripts since 1996.

He runs many successful websites, including his custom website design site, and his affiliate link protection service.

Running a CGI Script on a Web Server

For many years I have been writing Perl scripts to process ASCII files of one sort or another on my computer. I typically do this when I need to reformat or tidy up a series of HTML pages, for example.

To run a Perl script that is installed on your computer, which needs to process one or more files on your computer, and where the Perl interpreter is also installed on your computer, is very simple - you just need to double-click the perl script and it does the business - assuming that everything is set up correctly of course, for example, the location of the perl.exe program is defined in your path. You can also open a DOS window and type perl perlfile.pl to run a script (where perlfile.pl is the name of the Perl script you want to run).

However, when it comes to running a Perl script, or CGI script, on a web server, things can be a bit trickier - not too tricky, but a bit trickier.

In this article I'll look at two versions of the same script: one that will run quite happily on a local machine (by double-clicking the script, for example), and one that will run on a web server.

The script itself is very simple - it opens a file, changes some text inside the file, and then saves the file under a different name.

Version 1 - the local version

Here is version 1 of the script. This is the version that will run locally on a computer, without a web server is sight. Note that I've inserted spaces at appropriate places to prevent the code from being processed by your browser. I've done this wherever necessary in this article.

localScript.pl

$name = "before.htm" or die "cannot assign to variable: $!";
rename $name, "$name.bak" or die "cannot rename: $!";
open (IN, "<$name.bak") or die "cannot open: $!"; open (OUT, ">$name") or die "cannot create: $!";
undef $/;
while ($line = <>) {
$line =~ s/hello world/goodbye cruel world/s;
(print OUT $line);
}
close (OUT);
close (IN);
rename "before.htm", "after.htm";
rename "before.htm.bak", "before.htm";

This script opens a file called before.htm, uses a regular expression to change the string 'hello world' to 'goodbye cruel world', and writes the contents to a file called after.htm. If after.htm does not exist, it is created.

The file before.htm simply contains one line - hello world. So it's not even a proper HTML file in fact, but that doesn't matter for this exercise as it's the script that's important, not the file that's being processed.

Version 2 - the web server version

Here's the web server version of the script. It contains everything that's in version 1, plus a bit more. Again, I've inserted spaces where appropriate to ensure that the code displays correctly in your browser.

webScript.cgi

#!/usr/bin/perl -w
use CGI qw(:all);
use CGI::Carp qw(fatalsToBrowser warningsToBrowser);
warningsToBrowser(1);
use strict;
print header;
my $name = "before.htm" or die "cannot assign to variable: $!";
rename $name, "$name.bak" or die "cannot rename: $!";
open (IN, "<$name.bak") or die "cannot open: $!"; open (OUT, ">$name") or die "cannot create: $!";
undef $/;
my $line;
while ($line = <>) {
$line =~ s/hello world/goodbye cruel world/s;
(print OUT $line);
}
close (OUT);
close (IN);
rename "before.htm", "after.htm";
rename "before.htm.bak", "before.htm";

A couple of initial points to note:

1. Why does the script have a .cgi extension instead of a .pl extension? CGI is an abbreviation for Common Gateway Interface, which is a specification for transferring information between a web server and a CGI script. So CGI iteself is not a language, but CGI scripts can be written in a number of languages of which Perl is one. If you write a Perl script with a .pl extension, and then change that extension to .cgi, the script becomes a CGI script, and providing it conforms to the CGI specification, it will run on a web server.

2. If you call this script webScript.pl it will run without any problems on a local disk - just as version 1 did. That's to say, all the extra code will not prevent it from running locally.

Ok, lets go through the script line by line to see what's going on.

Running the script

To run the script you need to first upload the script and the file before.htm into the cgi-bin directory on your web server. On your web server the cgi-bin directory might be called something else, but it will probably be recognizable as the place where cgi scripts need to be located.

By default, when you upload a file onto your web server it will probably have permissions of 644. You need to change these to 755 so that the script can be run by anyone. Your ISP should provide you with a way to do this. If not, contact me at john@dixondevelopment.co.uk and I'll send you a script to change the permissions for you.

Once you have uploaded the files and changed the permissions, all you need to do is browse to the script in your favorite browser. If the browser window is blank, then everything has probably worked OK. Check in your cgi-bin directory to see if the file after.htm has been created and that it contains the words 'goodbye cruel world'.

About the Author: John Dixon is a web developer working for MyQuestionsMatter, a company that helps users of the health service to ask the right questions in their dealings with health professionals. For example, if you have an appointment with your doctor to discuss your illness, how do you know what questions to ask. MyQuestionsMatter will generate a list of questions specific to your profile. You can then print out the questions and take them along with you to your appointment.

Go to My Health Questions Matter to view the company's web site and learn more about how the site can help you.