Actually, your hosting company may be correct. There is a well-known "security hole" in Matt's FormMail script.
Check out the following text from my hosting company's support page:
Closing the Spam Exploit of FormMail.pl, FormMail.cgi and
Webform.cgi on Hostcentric Unix Servers
The first hint that your web site is being hacked through port 80 (the http port) and that
FormMail.pl is being exploited as a spam engine is that your master mailbox will start to fill
up with bounced email messages from ISP's.
The exploit permits the spammer to falsify his email headers but all of his rejected spam
lands back in your master mailbox because he uses your websites copy of FormMail.pl,
FormMail.cgi or Webform.cgi, which executes using your master username because you
"Own" the script in your cgibin. The other email servers of the world come to associate your
master username and your virtual servers name with the spam and that is the address they
use to send their reject messages to, because that is what gets listed as the return path in
the email headers.
So the spammer gets to abuse your web form to spam with and you get to take all of the
grief when the bounced message delivery status notices start to come back at the
originating mail server. (Yours)
Such abuse can be difficult to detect by the client because there are no tell tale signs of
what is happening to your web site except for two distinct clues.
1.Your master mailbox will start to fill up with reject messages from other mail servers
and there seems to be a pattern to them, example... all the rejected messages come
from hotmail accounts and the email aliases seem to follow an alphabetical order.
2.If you examine your raw log files and look at the http transactions you see something
like :
64.68.236.8 - - [05/Sep/2001:14:23:30 -0400] "GET/cgi-bin/formmail.cgi?email=qhoaa@aol.com
&recipient=chief784@hotmail.com,chief789@hotmail.com,chief79@hotmail.com,chief8@hotmail.com,
chief800@hotmail.com&subject=FINALLY!!!!%20FREE%20XXX%20PASSWORDS!!!%20%20%
20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%20%20[rnum&=%3CHTML%3E%3CBODY+BGCOLOR%3D%22
%2 etc...etc...etc..etc......
Which is one really long Get or Post request to paste in to an address bar so they are
probably running a script to do it. Typically they can run several lines longer and the
spamvertisement is html coded after "&subject". The recipients of the junk mail are all
specified one after the other using commas to delineate them. The subject is typically for
pornography.
Notice that they do not have to know your pop email passwords to relay this spam through
your web site because they are not relaying the mail through your pop accounts using the
"pop before send" method of authentication. They are sending it though the Http port 80
and then using your username and your FormailMail.pl to generate and send original
messages because you own the script formmail.cgi in your cgibin :
"GET/cgi-bin/formmail.cgi?email=qhoaa@aol.com&recipient=chief784@hotmail.com,chief789....
So what is the solution?
1.You could block the Ip address that identifies their dial up access to the internet from
visiting your web site but that won't work for long what with the dynamic Ip address
assignment that is typical of most ISP's. To get a new Ip address all they really need
to do is log off and then back on and the spammer has a new Ip address. That's a
chore to keep ahead of.
2.You could stop using FormMail.pl and its' derivatives formail.cgi or webform.cgi and
switch to another solution for getting the form field data to your mailbox. But that's a
lot of work that will require you to rewrite your html pages create new form pages and
so forth.
3.You could visit http://www.worldwidemart.com/scripts/formmail.shtml and download
the latest version of FormMail 1.9 untar it, ftp it to your cgibin and configure it to
match the variables for referrers, the location of sendmail, and the location of Perl as
you see it configured in your old script. About a ten minute job for someone with some
Perl experience.
Or you can take advantage of the spammers own method of operation and use it against
him, stop the spam and cause them to waste a lot of logon time.
Notice that the key to this method is the spammers use of multiple email aliases delineated
by a simple comma. That is the Achilles heel we will use to put the spammer out of
business with a minimum of hassle and work for you. Basically it calls for the client or the
technician to open FormMail.cgi, formmail.pl or webform.cgi and add a few lines of extra Perl
code that will cause the script to exit the script instead of running it if it detects multiple
email recipients delineated by a comma.
If you decide to go with solution 3 from above the new version of FormMail stops this
spamming by only permitting the form to email to aliases that specify your own domain
name. If you need your forms to email to multiple email aliases, that would be an
appropriate solution.
Also you could use the following solution and have the form mail to a mailbox where you
have configured multiple forwards, which is probably easier to manage than having to
rewrite your form html when you need to switch addresses.
So here we go:
1.Shell to your web site and then your local cgibin in your root directory. If you don't have
or want shell access FTP to your web site and open FormMail.pl, formail.cgi or
webform.cgi in the simplest test editor you have. (notepad,wordpad or simpletext on
the Mac environment.)
2.If you are shelling to the file open it with pico, the unix text editor.
3.Search for the part of the Perl script that looks like
# For each name-value pair: #
foreach $pair (@pairs) {
# Split the pair up into individual variables. #
local($name, $value) = split(/=/, $pair);
4.Between these two parts of the script insert the following:
# Get spam hack
if($pair =~ /recipient/){
if($pair =~ /,/){exit;
}
}
5.So the end result appears like so:
# For each name-value pair: #
foreach $pair (@pairs) {
# Get spam hack
if($pair =~ /recipient/){
if($pair =~ /,/){ exit;
}
}
# Split the pair up into individual variables. #
local($name, $value) = split(/=/, $pair);
6.Save the resulting modified script back to its' original location in your cgibin and your
done.
Now the spammer can hammer away at your formail.cgi all day and even though you'll still
see the GETS and POSTS coming to your web site your form will not send his emails.
Eventually you'll waste a few hours of his time for a change before he realizes his spam is
going no where and he starts looking for another victim. The form will still work fine for you
especially if you are emailing your form to only one listed recipient.
If you need to email more than one recipient at your domain name then follow the
instructions listed in #3 above under "what is the solution?" or email to one of your domain
names recipients and forward from that mailbox via pop mail.
The "hacker" is probably using the FormMail.pl or FormMail.cgi script in your server account or in another account in the server where your web site is hosted to exploit your account and send out a bunch of bounced messages that is negatively impacting your reserved disk space.
========================================
Buh Bye!
Cheers,
Me
Check out the following text from my hosting company's support page:
Quote:
Closing the Spam Exploit of FormMail.pl, FormMail.cgi and
Webform.cgi on Hostcentric Unix Servers
The first hint that your web site is being hacked through port 80 (the http port) and that
FormMail.pl is being exploited as a spam engine is that your master mailbox will start to fill
up with bounced email messages from ISP's.
The exploit permits the spammer to falsify his email headers but all of his rejected spam
lands back in your master mailbox because he uses your websites copy of FormMail.pl,
FormMail.cgi or Webform.cgi, which executes using your master username because you
"Own" the script in your cgibin. The other email servers of the world come to associate your
master username and your virtual servers name with the spam and that is the address they
use to send their reject messages to, because that is what gets listed as the return path in
the email headers.
So the spammer gets to abuse your web form to spam with and you get to take all of the
grief when the bounced message delivery status notices start to come back at the
originating mail server. (Yours)
Such abuse can be difficult to detect by the client because there are no tell tale signs of
what is happening to your web site except for two distinct clues.
1.Your master mailbox will start to fill up with reject messages from other mail servers
and there seems to be a pattern to them, example... all the rejected messages come
from hotmail accounts and the email aliases seem to follow an alphabetical order.
2.If you examine your raw log files and look at the http transactions you see something
like :
64.68.236.8 - - [05/Sep/2001:14:23:30 -0400] "GET/cgi-bin/formmail.cgi?email=qhoaa@aol.com
&recipient=chief784@hotmail.com,chief789@hotmail.com,chief79@hotmail.com,chief8@hotmail.com,
chief800@hotmail.com&subject=FINALLY!!!!%20FREE%20XXX%20PASSWORDS!!!%20%20%
20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20
%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%2
0%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%20%
20%20%20%20%20%20%20%20%20[rnum&=%3CHTML%3E%3CBODY+BGCOLOR%3D%22
%2 etc...etc...etc..etc......
Which is one really long Get or Post request to paste in to an address bar so they are
probably running a script to do it. Typically they can run several lines longer and the
spamvertisement is html coded after "&subject". The recipients of the junk mail are all
specified one after the other using commas to delineate them. The subject is typically for
pornography.
Notice that they do not have to know your pop email passwords to relay this spam through
your web site because they are not relaying the mail through your pop accounts using the
"pop before send" method of authentication. They are sending it though the Http port 80
and then using your username and your FormailMail.pl to generate and send original
messages because you own the script formmail.cgi in your cgibin :
"GET/cgi-bin/formmail.cgi?email=qhoaa@aol.com&recipient=chief784@hotmail.com,chief789....
So what is the solution?
1.You could block the Ip address that identifies their dial up access to the internet from
visiting your web site but that won't work for long what with the dynamic Ip address
assignment that is typical of most ISP's. To get a new Ip address all they really need
to do is log off and then back on and the spammer has a new Ip address. That's a
chore to keep ahead of.
2.You could stop using FormMail.pl and its' derivatives formail.cgi or webform.cgi and
switch to another solution for getting the form field data to your mailbox. But that's a
lot of work that will require you to rewrite your html pages create new form pages and
so forth.
3.You could visit http://www.worldwidemart.com/scripts/formmail.shtml and download
the latest version of FormMail 1.9 untar it, ftp it to your cgibin and configure it to
match the variables for referrers, the location of sendmail, and the location of Perl as
you see it configured in your old script. About a ten minute job for someone with some
Perl experience.
Or you can take advantage of the spammers own method of operation and use it against
him, stop the spam and cause them to waste a lot of logon time.
Notice that the key to this method is the spammers use of multiple email aliases delineated
by a simple comma. That is the Achilles heel we will use to put the spammer out of
business with a minimum of hassle and work for you. Basically it calls for the client or the
technician to open FormMail.cgi, formmail.pl or webform.cgi and add a few lines of extra Perl
code that will cause the script to exit the script instead of running it if it detects multiple
email recipients delineated by a comma.
If you decide to go with solution 3 from above the new version of FormMail stops this
spamming by only permitting the form to email to aliases that specify your own domain
name. If you need your forms to email to multiple email aliases, that would be an
appropriate solution.
Also you could use the following solution and have the form mail to a mailbox where you
have configured multiple forwards, which is probably easier to manage than having to
rewrite your form html when you need to switch addresses.
So here we go:
1.Shell to your web site and then your local cgibin in your root directory. If you don't have
or want shell access FTP to your web site and open FormMail.pl, formail.cgi or
webform.cgi in the simplest test editor you have. (notepad,wordpad or simpletext on
the Mac environment.)
2.If you are shelling to the file open it with pico, the unix text editor.
3.Search for the part of the Perl script that looks like
# For each name-value pair: #
foreach $pair (@pairs) {
# Split the pair up into individual variables. #
local($name, $value) = split(/=/, $pair);
4.Between these two parts of the script insert the following:
# Get spam hack
if($pair =~ /recipient/){
if($pair =~ /,/){exit;
}
}
5.So the end result appears like so:
# For each name-value pair: #
foreach $pair (@pairs) {
# Get spam hack
if($pair =~ /recipient/){
if($pair =~ /,/){ exit;
}
}
# Split the pair up into individual variables. #
local($name, $value) = split(/=/, $pair);
6.Save the resulting modified script back to its' original location in your cgibin and your
done.
Now the spammer can hammer away at your formail.cgi all day and even though you'll still
see the GETS and POSTS coming to your web site your form will not send his emails.
Eventually you'll waste a few hours of his time for a change before he realizes his spam is
going no where and he starts looking for another victim. The form will still work fine for you
especially if you are emailing your form to only one listed recipient.
If you need to email more than one recipient at your domain name then follow the
instructions listed in #3 above under "what is the solution?" or email to one of your domain
names recipients and forward from that mailbox via pop mail.
The "hacker" is probably using the FormMail.pl or FormMail.cgi script in your server account or in another account in the server where your web site is hosted to exploit your account and send out a bunch of bounced messages that is negatively impacting your reserved disk space.
========================================
Buh Bye!
Cheers,
Me