Forum Moderators: phranque
But I wonder if it will stop or is it there any other option.
I saw logs and has different ips and countries :(
Any ideas?
If the old system is still accessible, even if it is not visible, you will continue to get spam indefinitely. If it was as simple as an email address published on a page and that mailbox is still open, spam will continue - all you can do is close the mailbox.
Kaled.
I don't think that is your problem, just something to bear in mind. If your form goes to an email, there's nothing for it but to change the email destination.
I'm also getting an increasing amount of spam from my forms. Although none of mine go to emails, I get a lot that look like they are attempts to send blank emails. Once you have changed the email, you might also consider custom word filters, and filter out anything that mentions mime types etc, as well as the usual medication, porn and blog spam. That should cut down on some annoyances.
Título: hyhwirkt@mydomain.com
Url: hyhwirkt@mydomain.com
Content-Type: multipart/mixed; boundary=\"===============0116206311==\"
MIME-Version: 1.0
Subject: 475cb0d2
To: hyhwirkt@mydomain.com
bcc: jrubin3546@aol.com
From: hyhwirkt@mydomain.com
This is a multi-part message in MIME format.
--===============0116206311==
Content-Type: text/plain; charset=\"us-ascii\"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
gsuiwum
--===============0116206311==--
Link hacia nuestro site: hyhwirkt@mydomain.com
Categoría:
País: hyhwirkt@<snip>.com
E-mail: hyhwirkt@<snip>.com
Nombre del contacto: hyhwirkt@<snip>.com
----------Información Remota----------
212.202.160.25
The IP I could be forged too? They claim to be from different countries...
any ideas on blocking the abuse?
[edited by: trillianjedi at 1:17 pm (utc) on Sep. 14, 2005]
[edit reason] You'd missed a couple ;-) [/edit]
Any help?
Remote information indicates different ip each time they come.
In outlook express I see no sender.
If I am able to kill specific characters in the form input, will that stop this type of attack?
What info are the spammers able to get from this? As far as I can tell they are able to grab the name of the script that submits the form, and then set up direct access to that script so they can send spam. But that is the limit to what they are able to gain, right?
Wish people had something better to do than cause people grief...low-life's...
For every sting in form , before sending Email - I call ( PHP ):
function TrimFalseEmailHeaders($s)
{
$s = ereg_replace("Content-Type:", "Content-Type;", $s );
$s = ereg_replace("MIME-Version:", "MIME-Version;", $s );
$s = ereg_replace("To: ", "To; ", $s );
$s = ereg_replace("From: ", "From; ", $s );
$s = ereg_replace("bcc: ", "bcc; ", $s );
$s = ereg_replace("Subject: ", "Subject; ", $s );
return $s;
}
Also you may block it by empty HTTP_USER_AGENT
if ( isset($HTTP_USER_AGENT ))
{
$to = "nomal@email.com";
}
else
{
$subject = "probably spam - ".$subject;
$to = "spam@email.com";
}
in
anders.com/cms/75/Crack.Attempt/Spam.Relay
I'm seeing an interesting new attack on my website where the attacker is hoping to exploit unchecked fields in a "web to email" form. The attack works by assuming a field used in an email header (such as the "From:" address or the "Subject:") is passed unchecked to the mail subsystem. Appending a newline character and a few more carefully crafted header lines with a BCC list and a spam message body might trick the underlying mail system into relaying spam for the attacker. An initial test sending a BCC copy to killerhamster@punkass.com has been used on most forms on my site to phish for vulnerable scripts. I had an old perl script which didn't check for new lines in the "email" field which alerted me to the problem and allowed me to quickly fix it. If you run a site, you should check and strip fields for carriage return and newline characters used directly in email headers
I anybody has a good solution, very appreciated.
if ( isset($HTTP_USER_AGENT ))
{
$to = "nomal@email.com";
}
else
{
$subject = "probably spam - ".$subject;
$to = "spam@email.com";
}
And what about the risk of being blacklisted? If that happens will your domain be in trouble or just the server where you are hosted?
I don't understand clearly but I guess if relay is being abused, you could move to another hosting, a more secure hosting.
Will that help?
Other scary notice: I saw googlebot come and craw for documents that don't exists, with garbage names like
/iykhzrlzhsyy.html
/ornyzyyvmkx.html
/qbgyvvpu.html
/scxlolrcpxslocm.html
Those docs of course doesn't exists and they are not in sitemap.xml either...
?
From what I can glean,
1. This is not executed from your form. Get that well: this is NOT executed from your form. It's either sent directly from the command line or from some program. They may initially visit the form to get the field names being submitted, but after that they're working on their own, probably from a compromised server they've hacked.
2. They can use **ANY** field your mailers process. Many solutions talk about screening the email field, but it doesn't matter. The most common approach I see is they use the Subject field to insert newlines and a bcc field. They then use the bcc field they create to dump hundreds of aol addresses, usually followed by a multipart mime message, complete with their own boundaries.
3. Given the above info, you would think you could stop them by removing any newlines in the mail headers. If you have success at this, great, but for whatever reason my attempts at this method have failed.
4. Important point to be learned from #2 and #3: even if you disable the "customer copy" and hard-code a mailer just to send to ONE address, it doesn't matter. They can use your subject, message, or other submitted field to create the BCC and spam addresses.
The only solution I have found is to screen ALL incoming data. ALL. If the following patterns are found
/b*cc\s*:/i ## BCC or CC
/content\-type/i ## This has no place in an email
Log it and immediately exit the program. This avoids other parts of your program being abused.
I put this trap directly into any read/parse routine.
The downside, of course, is if someone enters into the body of the message, "please send a cc: to....." the mailing will fail. But it's a good tradeoff because there should be a email field for a legitimate email reply address.
I'm sure there are holes in my logic and welcome any comments, but according to my logs this has effectively stopped this attack, at least for now.
The only solution I have found is to screen ALL incoming data. ALL. If the following patterns are found/b*cc\s*:/i ## BCC or CC
/content\-type/i ## This has no place in an emailLog it and immediately exit the program. This avoids other parts of your program being abused.
I put this trap directly into any read/parse routine.
I don't understand really. Can you explain for non programmers, if there is something we can do?
I'm worried about what can we do after you are aware your site or form or whatever was abused.
Does that mean your domain will send spam forever?
If you patch your site or forms, can they still send spam as it were you?
Normally when spammers use their own script to abuse your form they are not logged into your website.
On my sites if a member is logged in there is a row in a database table for them. If a member is not in that table they can't access any page with a form on it. Other than the login page of course! :)
By using this method I avoid the usability issues imposed by using a Captcha approach. And I also avoid privacy-related issues like refusing access to the form due to blocked referrers.
Also, rather than filter for specific words that might cause false positives I instead decide which characters are acceptable for any given form field. For an e-mail address field I use regular expressions to check for and reject any character that's not valid in an e-mail address. For name fields I only permit certain characters. No control characters (< ASCII #32) are allowed in any form field.
if (eregi("mydomain.com",$email)){die("DIE spammer!");}
It stops those but now I'm getting hundreds of blank ones. So if what I read above is correct once they have the info it doesnt matter what you do with the form or script?
Is creating a new email account that the form sends to and deleting the old one a viable option?
It seems to me that the worst case scenario is junk being sent to configured/hard-codes addresses (unless the datasend() function can be used to specify recipients).
use Net::SMTP;$from = 'your@localemail.com';
$to = 'someone@else.com';
$subject = 'Test Email';$smtp = Net::SMTP->new('localhost');
$smtp->mail($from);
$smtp->to($to);$smtp->data();
$smtp->datasend("To: $to\n");
$smtp->datasend("Subject: $subject\n");
$smtp->datasend("Testy\n\n-bye");
$smtp->dataend();$smtp->quit;
Kaled.
Buksida:
That's a question I'm trying to answer here precisely, I have the same problem. You can do some tweaks but I'd like to determine what to do exactly. If you read the whole thread you will notice there is no straight answer of what to do.
My assumption is:
1) You must protect your code and implement a more secure form
2) Protect your own inbox to avoid the bothering
3) Ask your hosting provider for a solution since seems to be a security problem
4) I don't know what happens once you were hijacked, nobody answered that and that's the most important question.
Can someone tell what to do now or explain what is an opened or abused relay and how to deal with?
If that's not the case experieces will help too.
blocking empty user_agent is not 100% solution. hackers can emulate any user_agent. this is temporary solution. Blocking email from your domain in the from files temporary solution too. There no such requirements for this type of hacking. Email may be any valid string and any user_agent.
function that disable all possible mail headers in each line of the form, is much more useful.
On my sites if a member is logged in there is a row in a database table for them. If a member is not in that table they can't access any page with a form on it. Other than the login page of course! :)
So folks have to login to send you a message. Hmmm...
I just got a rash of these from my four websites. (First time!) I was wondering if something was going around. So what I'm hearing is that once it begins, it won't end without great effort. Yes? No?
don't understand really. Can you explain for non programmers, if there is something we can do?
Without a painfully long post - basically it's the form processor - a CGI script, php script, asp anything that performs the server-side mailing function from a form - that is vulnerable. Data comes to these scripts in an encoded ("webalized," to use Matt's term) format. It must be split up into plain-English key/value pairs. This is called parsing and is the first step in receiving any form data. So wherever your program parses incoming data, that's where you catch them. My example was a perl script.
I'm worried about what can we do after you are aware your site or form or whatever was abused.
Does that mean your domain will send spam forever?
If you patch your site or forms, can they still send spam as it were you?
That's a different issue, but yes, they can. Google for "joe job." This is to stop them using YOUR mail server and domain to do it on.
I have found a lot of them are from randomletters@mydomain.com so by adding this line to the php mail script:
if (eregi("mydomain.com",$email)){die("DIE spammer!");}
Funny you mention it, I tried that approach too when I first noticed this. :-) Obviously it didn't work because that's just their program or method of "sniffing" out the form fields. Also the problem there is it only checks the $email variable.
So if what I read above is correct once they have the info it doesnt matter what you do with the form or script?
Form no, script yes it does matter. That's the point of entry. Remember, they are querying your SCRIPT directly, and not even from a browser.
Is creating a new email account that the form sends to and deleting the old one a viable option?
Whatever account your script is pointed at it will use, so this won't help a bit.
Assuming the following, is there still a vulnerability?....
I don't know, it depends on what those modules are doing to clean up the data. The point is, it doesn't MATTER that you hard code the recipient. Whatever incoming data is available, they try (and often succeed) in perverting that field to add a BCC, and it's the BCC that does the harm. Here's one good test: Telnet or SSH somewhere and execute this line. Be sure you have your mailer logging somewhere to see the result:
curl -d 'Subject=your_address@example.com%0ASubject:Hack%20Subject%0Abcc:another_address,this_is@where_they_spam.com%0A
content-type:multipart/mixed;%20boundary=b1;%0A--b1%0Acontent-type:text/html%0A%0A<b>This%20is%20my%custom%20message.</b>%0A
%0A--b1%0Acontent-type:text/html;name=attachment.html;%0Acontent-transfer-encoding:8bit%0Acontent-disposition:attachment%0A
%0A<b>This%20is%20a%20file</b>%0A%0A--b1--%0A' http://www.example.com/your_mailer.cgi
To the mail experts out there-this may fail in actual mailing, but it's enough to show what damage cam be done if formatted correctly.
This is but one of the ways. :-) The above attempt results in this, in my custom mail log:
Time: September 16, 2005 13:17:12
REMOTE HOST: www.example.com
REMOTE ADDRESS: 123.456.789.12
Subject your_address@example.com
Subject:Hack Subject
bcc:another_address,this_is@where_they_spam.com
content-type:multipart/mixed; boundary
Using Subject
==== end ===
See how the actual subject is munged and they add their own and a bcc to boot?
EVIL! :-)
The last line, "Using Subject" I've added just to tell me what field is getting whacked.
For you hackers that are reading this, you should be ashamed of yourselves. So much talent, gone to waste. But thanks for educating me, at least a little. :-)
[edited by: phranque at 8:58 am (utc) on Aug. 21, 2008]
[edit reason] added line breaks to "curl" argument to fix sidescroll [/edit]