The 'feedback.module' seems to be vulnarable for the following method to relay spam:

http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay

I received emails from my 'feedback.module' showing exactly the above mentioned symptoms. Because I do know php-coding little to nothing, I'm unable to check the source code of the 'feedback.module' myself.

Therefor I am asking all coders and security specialists to check the above mentioned URL and its possible impact on the 'feedback.module'.

Thank you all very much.

Comments

kbahey’s picture

kbahey commented
Title: fix for 'feedback.module' to prevent relay spam » Is Feedback module vulnerable to relay spam?
Priority: Critical » Normal

I tried to "break" feedback by entering the following in the From field:

\nBcc: <someemail@domain.com>

Feedback did not allow that, and gave an error. The form was not sent.

I tried doing the same in the Subject field, and it just appeared in the Subject, and did not go out as spam (I checked the mail logs, and there was no such attempt).

So far, my conclusion is that feedback is safe from this attack. There may have been attempts made to exploit your site, but it seems they were unsuccessful.

Norrin’s picture

Norrin commented

I got emails like this (notice the bcc in the faked header):

-- The following message was sent using the feedback page --

plb@my-domain.com


----------------------------------
Site Name       : my-domain.com
Full Name       : plb@my-domain.com
E-mail address  : plb@my-domain.com
Referring page  : plb@my-domain.com
Content-Type: multipart/mixed; boundary="===============1255030556=="
MIME-Version: 1.0
Subject: 1d41ce82
To: plb@my-domain.com
bcc: bergkoch8@aol.com
From: plb@my-domain.com

This is a multi-part message in MIME format.

--===============1255030556==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

hgvtoet
--===============1255030556==--

IP Address      : http://whois.sc/213.155.209.205

My 'feedback.module' uses four visible form-fields, namely 'edit[form_field_name]', 'edit[form_field_email]', 'edit[form_field_subject]', 'edit[form_field_body]' and one hidden field 'edit[form_field_referer]'.

I received _10_ emails, one for checking each form field! So the atacker tried twice to exploit my feedback-form, I presume.

My mail-log shows two outgoing emails to 'bergkoch8@aol.com'. As far as I understand this technique, it would be easy to use 25 to 30 other email addresses in the faked 'bcc' instead of 'bergkoch8@aol.com' and spam would be relayed.

The atacker obviously doesn't use a browser to exploit the feedback-form, because it truely doesn't work using a browser.

kbahey’s picture

kbahey commented
Assigned: Unassigned » kbahey
Priority: Normal » Critical
Status: Active » Fixed

A fix was provided for this.

It is a bit over aggressive, since it forbids any string like "To:", "Bcc:" or "Cc:" from the message, but it is better to be like that, than allow exploits.

Perhaps it should check for a newline before any of those fields?

Norrin’s picture

Norrin commented

In the follow up discussion of the provided article:

http://www.anders.com/cms/75/Crack.Attempt/Spam.Relay

they talk about solutions on how to prevent the exploit. Basicly the solution for all used web2mail forms seems to be:

... you should check and strip fields for carriage return and newline characters used directly in email headers.

So I suppose you're right when you say that your fix is a bit 'over aggressive', but since I lack any knowledge of php-coding I wouldn't even know where to look in the script.

Therefor I thank you very much for responding in such a quick way providing this fix.

Thank you.

kbahey’s picture

kbahey commented

Initially I thought of checking for newlines. However, the body and postal may have legitimate newlines in them. So I checked for the headers.

Since I could not reproduce the original exploit, I took this over aggressive approach since I can test it myself.

I intentionally used a vague non specific message, so as not to give the hacker a clue.

Norrin’s picture

Norrin commented

I just encountered another try to abuse my feedback form this morning. The provided fix seems to work perfectly. (c:

kc’s picture

kc commented

Where is the latest code for the fixed? I downloaded the CVS dated August 29th i think and still getting those spam emails.

Please help.

Thanks
KC

kbahey’s picture

kbahey commented

I just clicked and downloaded the 4.6 version, and the fix for this issue is indeed in there (despite the fact that it is dated March).

Maybe you are facing another spam issue? If so, please open a separate issue and describe in full detail what you are seeing.

spazfox’s picture

spazfox
Location Olympia, WA
commented

I applied the fix, as well, but am also still getting the spam emails. The form of the emails I get are identical to the one presented earlier in this thread. I'm getting up to a dozen of the spam emails per day, too.

kbahey’s picture

kbahey commented

That is very weird.

Norrin said that it prevented spam after the fix.

Maybe it is just a bot that keeps sending to the feedback form, and not relay spam?

Can you post here the raw headers of the email? (replace any private parts with zzzzzzzzzzzzz or something)

Norrin’s picture

Norrin commented

This is what happens:

Some bot(s) is/are still trying use the feedback-form to relay spam. But there is definitly no relay of spam according to my email-logs.

The bot(s) is/are checking each form-field for vulnerability. The fix doesn't validate the hidden field (referer) so I applied the following code to the function feedback_validate_data()

  if (feedback_check_exploit($referer)) {
    $error_msg .= t("Error: invalid data in referer") . "<br/>";
  }

This reduces the spam that you would get to one mail per try instead of one mail for every form-field not validated.

So what's the thing with the last mail? I haven't found out yet. When analysing the spam mail the 'From:'-field in the mail-header shows, that according to the feedback-script $name- and $email-variable were identical.

So I guess a check for $name- and $email-variable being the same or a check for $name-variable containing the '@'-character would at least avoid the last spam mail.

Hope this wasn't too confusing. But remember: There is no mail being relayed. That's the main thing for the time being.

Norrin’s picture

Norrin commented

Sorry, I forgot:

You also need to apply 

  $referer = $edit["form_field_referer"] ;

to the same function.

kbahey’s picture

kbahey commented

I committed an additional check for referer. That should take care of all the fields in the form.

Regarding that one last email, I am not sure if I want to check more for content of name and email and make sure that they are different. This is too artificial, and anyone who reads the source or CVS can get around it easily.

So, until a more elegant suggestion comes up, I am not doing it.

P.S. Maybe we could prevent X accesses in Y minutes from the same IP address. We need to save that somewhere (via get_variable()?) But that would not work if multiple users are sending feedback (A would overwrite B, and C would overwrite C, ...etc.)

Anonymous’s picture

(not verified) commented
Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)
David Lesieur’s picture

David Lesieur commented
Status: Closed (fixed) » Fixed

Kbahey,

Thank you for these patches. However, I think you do not have to check the message body for exploits, because RFC 822 says that anything after the headers (anything after a blank line following the headers, that is) is treated as the message body [and is not interpreted by mailers].

David Lesieur’s picture

David Lesieur commented
Priority: Critical » Minor
Status: Fixed » Active
faenor’s picture

faenor commented

One possible approach to make feedback.module permanently immune to being used as a spam relay is to put all data collected by the form in body of the message.

I understand that prevents having the convenience of using the user-supplied Subject:, From: address, and From: name... but there is a way to preserve that functionality by using a "Content-Type: message/rfc822" formatted MIME-compliant attachment. In other words - the attachment of the message sent would be formatted as a RFC 822 compliant message - and that message could be sent to the recipient in the body of a message that is system generated - using system-supplied From:, To:, and Subject:, headers...

Then the user data collected in the feedback form becomes nothing more than the payload of an attachment - which avoids the whole question of whether or not feedback.module could be used as a spam relay.

It's not a perfect solution - but I think when a RFC 822 attachment is sent - it certainly seems to lock out those looking for a spam-relay system, while providing a somewhat protected copy of the original, intended message in a useable format (most current e-mail programs should be able to open the attachment as an e-mail message - both for the purposes of reading the attached message and replying to the attached message)...

MerlinAbraxas’s picture

MerlinAbraxas commented
Version: » 4.6.x-1.x-dev
Component: Code » User interface
Priority: Minor » Critical

I had to take the Feedback form down again after being badly attacked again and received massive complains from AOL and other providers.

I'm currently in a large project and don't have the time to look into this issue nor have time for coding on this module ... but my approach would be to integrate "captcha" in the form and in the form processing to make it water tight ...

Thanks, I somebody can take this on ;-)

kbahey’s picture

kbahey commented

The spam proofing will prevent relay spam via feedback. It will not prevent spam to YOU.

- Which version of feedback are you using (the number in the $Id at the top).

- When you say complaint by AOL, what complaint? Emails in your name sent to others? Or is it simply spammers sent spam from your address (faked)?

- Have you verified that these are sent via feedback?

- Is your web host vulnerable and hence people sending spam from your account via other means?

rubicon-1’s picture

rubicon-1 commented

During the last 7-10 days my feedback form was relaying spam. I upgraded the feedback.module today and hopefully stopped it. Unfortunately my Drupal log is filled with "attempt to relay spam" notices.

I upgraded feedback.module on another site I run and failed to checkmark "Validate sender's email address" and it looks like one spam got through. I'm not sure if this field matters but I checked it. I haven't received any further relay attempts (yet).

I second the motion for integrating captcha in the feedback module. kbahey, thanks for the excellent module and I hope you don't abandon it due to this spam issue.

kbahey’s picture

kbahey commented
Status: Active » Fixed

The "attempt to relay spam" means that it DID work, and did not send the relay spam.

So that is good news.

If there are too many messages of that sort, then go ahead and comment out/remove that part from the module.

I gave reason why captcha are not a good option.

fago’s picture

fago
Primary language German
Location Vienna
commented

i would suggest to further check for for "\n" and "\r" inside all header variables.
even much better would be a whitelist of characters for the name, too.

wosonj’s picture

wosonj commented

Hi guys,
I am new to Drupal but I have fixed this SPAM problem several times before:

There are two tasks to do:

1) prevent relying of SPAM
- strip all new lines from all HEADER fields. That means $to, $subject. If any user header is passed to the mail() function (like setting the From: header), this must be checked too.
- moreover, it is theoretically possible to use coma separated list of recepients, so check for commas if this is the case.
- you do not need to perform any checking in the message body, as it does not affect the headers. I am not sure about multipart messages, (some spambots are obviously trying to use them), but this was not my case.

2) prevent the bots to use the form (this is the SPAM feedback YOU are receiving)
This is somewhat harder to fix. One possbility is to use the referer check, but I am personally not into that as some browsers do not send the referer in the HTTP request for privacy reasons, e.g. some configurations of Opera and it is not really hard for the bots to provide it as well.

This is what I used:

include a 1px hidden picture in the form, which source is acually a PHP script (blank.php)

in the blank.php:
- set some session variable, which flags that the file has been downloaded
- set headers to return a image/gif and pass through a blank GIF89 image.
- do not forget to send headers that prevent cacheing

when processing the form, you simply check for the session variable set in blank.php and refuse to send the post if there is not any.

This fix works for all bots comming to my sites, as they do not request any pictures, nor they are able to handle cookies to allow sessions to work. Bad thing is, that it still prevents few users from sending the form - those that do not download pictures (very few) and those that have disabled temporary cookies (still very few)

A very similar approach would be to use client side JavaScript to perform some sort of simple calculation and include the result in a hidden filed of the form.

hpn’s picture

hpn commented

Looks like the issue's still there. Some of the attempts do get recorded on watchdog, but some don't and get relayed.

Look at this message that was sent from the contact page running on the latest feedback module checked out from cvs:

===========================================
first
Content-Type: multipart/alternative;
boundary=455a7cef3e6e39389ba25c9a61b1249c
MIME-Version: 1.0
Subject: aughter, and the hum
bcc: frekiforbes@aol.com

This is a multi-part message in MIME format.

--455a7cef3e6e39389ba25c9a61b1249c
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit

enjoyed our care and happy days. hen saw her at oeskelde she was far
--455a7cef3e6e39389ba25c9a61b1249c--
===========================================

kbahey’s picture

kbahey commented

This does not mean that relay is successful. It means that they are attempting to probe your Drupal feedback form and see if it can relay spam. You will get a message, but no relay should happen.

I get a few of these, and always check the mail server logs, and do not find anything sent out, except to me.

AltaVida’s picture

AltaVida commented

Had my feedback form attacked last night (4.6). The spam came fromover 20 different IP's and attempted to relay hundreds of messages to aol users. At first it was successful but after receiving a bunch of bounce messages from Aol I quickly logged in and disabled the feedback module. I also used the troll module to block the IP's.

One thing I noticed was that Drupal is still processing data POSTed to /feedback even though I had the module disabled and /feedback didn't even exists as far as drupal is concerned. I don't think it was sending the mail but I was getting the "Terminated request because of suspicious input data" messages in the watchdog.

I'm going to implement the patch but my question is - shouldn't Drupal automatically ignore or reject data POST'ed to a non-existant URL? Or, is this possible with the dynamic nature of Drupal's 'clean' URL's?

kbahey’s picture

kbahey commented

Which version of the feedback module are using?

I mean the line starting with :

//$Id

I get some spam relay attempts but they are unsuccessful.

AltaVida’s picture

AltaVida commented

khalid,

I had an older version (d/l'ed about 4-5 months ago), not sure which b/c my local CVS install had overwritten the $id tag with new version numbers (I need to learn more about how this works - CVS is a bit new to me).

Anyways, I've installed the latest version now and so far so good. I'll be keeping an eye on it.

Thanks for the follow up.

AltaVida’s picture

AltaVida commented

Ok, just looked a little closer at a few things: the new feedback module is indeed stopping new relay attempts because I'm getting the "Attempt to relay spam using" messages in the watchdog now.

Kudos!

Anonymous’s picture

(not verified) commented
Status: Fixed » Closed (fixed)