hijacked forms sending spam

spam from forms

[solarider]

I host several web sites with "Comments" forms where typically there are several fields for sending information to me. I have detected that a few of these forms are being hijacked and used to send spam. I noticed this when I started receiving returned emails that couldn't be delivered due to incorrect addresses. In the bcc field of these returned email messages is several hundred aol.com email addresses. The email seems to contain some sort of style sheet information regarding Adobe Pagemaker. I did find a company name entry containing Interstallar Alliance, but that is probably not correct.

The form submit button activates a dll in my scripts directory that controls the specifics of sending the message. I have renamed that file, yet the spam still continues. I have read several posts regarding how to make forms pages more difficult to highjack, but I haven't seen any suggestions as to how to stop the current attack. The dll is a homegrown file created by our developers. It seems to me that if the spammer got a copy of the dll file he could use it at will regardless of what I do at my site. Is this possible? I am fairly experienced with using web servers, email servers etc. but this is my first experience with being attacked like this. Not sure where to start troubleshooting this kind of a problem. The web server is IIS 5.0 and my email server is Communigate Pro.

Any ideas?

TIA,
Ken

[jimbeetle]

Hi solarider,

Welcome to Webmaster World.

Are you absolutely sure the spam e-mail is originating with the forms? I have a similar situation, many bounce backs from AOL, but it's because the spammer spoofed one of my domains in the e-mail addy ([e-mail]).

Haven't been able to trace anything back because it seems like everything else in the headers is also spoofed.

[Yidaki]

Disable relay mail at your mailserver. I use the SIMS mail server (same company as Communigate) and i only let authorized accounts send mail. I'm sure, Communigate Pro provides the same features. It's called pop before smtp. This means, before you can send an email through the server, you first have to login / do a pop3 session. You can then specify a period how long the client is "known" to your web server and authorized to send mail.

[solarider]

Thanks for the responses Kim and Yidaki,

I'm convinced either the forms are being used or the dll has been grabbed and is being used from the spammers computer (if that's possible. Have to check with the developer to determine if the dll can run standalone). The reason is that the dll contains some text that is places in the mesage body that is showing up in the returned email ("Guestbook submissions form your web site!")

We have the relay turned of like you mentioned Yidaki. Currently I have a computer checking some utility accounts 24x7. It is one of these accounts that has been used. I changed the password on the account several days ago, but that didn't stop it. What I am doing now is setting the computer to check the accounts less frequently than the pop-before-smtp setting. This way the pop will require password authentication each time. As long as the spammer doesn't have the account password, then that should cut down on the available window that the account can be used without password authentication. Is that what you were talking about?

Thanks for the quick replies!

Ken

[Yidaki]

Hm, i guess you did set up an allow entry within Communigate for the machine that sends out emails. You have it in the allowed clients (ip) list, right!? What about temporarily changing the sendmail form action to another server? If you then change the client list within Communigate you should be able to cut down *all* mail from the hijacked server ...

[solarider]

It seems that I left my own back door open!

I found that the default Enabled Settings for all accounts in Communigate were to allow the Mobile option. What this setting does is to allow an authenticated account to continue to send and receive for 15 minutes (configurable) after the account has been authenticated and to recognize any ip address from such an authenticated client as an allowed client ip. Since I have a machine running 24x7 to continually check that account every 5 minutes, the email server has not required authentication for that account in who knows how long. The spammer has been able to use this account and not have to worry about authentication or the ip address it was sending from.

I am in the process of correcting this for all accounts that don't need the Mobile option configured.

Thanks for pointing me in the right direction.

Ken