PHP mail() security fix needed

Spammers exploited our script, and need some fix suggestions

[Internet Engineer]

Hello, all! Have been reading and searching, but haven't found an exact fix for my problem.

On our new web site, we found ourselves unexpectedly suspended because of "spam violations." After a frantic morning trying to reach a person who could help, I finally found someone who explained that our mail scripts on our new site were being exploited by spammers to send mail via our mail server.

First, the structure: We use a "shopping cart" solution that uses the PHP mail() function to send a notice that an order has been placed. I took that code, and modified it to send us alerts and form data from a number of different forms, depending on what the site visitor was looking to get from us, (i.e. request for quote, comment on site, etc.) In each that I modified, I designate a variable - $mymail - to hold the destination email address. For example:

$mymail = "[e-mail]";

At the end, it sends via PHP the following command:

mail($mymail, $mysubject, $themessage, "From: $mymail")

I have read on other threads on this forum, that if I "hard code" the email address, I will eliminate users from exploiting this command to send spam via our mail server, because what was once $mymail - and could probably be modified by a spammer/hacker - is now "hard coded" to, for example, [e-mail]. The execution command would then be:

mail("[e-mail]", $mysubject, $themessage, "From: [e-mail]")

What're some ideas on the feasability of this? Will it eliminate spammers using our site's mail server, by restricting delivery to just me? Or is it a wasted-time fix?

I have also been pointed to a formmail-type script which provides more security. Is that a better option? (Probably this will be my implementation in the long run, but I'm looking at a quick fix for today and the next day or two until I re-configure for the advanced fix.)

Thotz, anyone?

Dan Ford

[hakre]

dear dan ford,

for your specific problem,

$mymail = "[e-mail]";

hardencoded is safe. the send-to adress can't be modified any longer. this is the highest security you can establish.

-hakre

[bcolflesh]

mail("[e-mail]", $mysubject, $themessage, "From: [e-mail]")

This will fix your immediate problem - do it.

<edit> hakre beat me to it! </edit>

[Timotheos]

Hmmm... while this will fix the immediate problem there must be something else going on. Under normal conditions having
$mymail = "[e-mail]";
mail($mymail, $mysubject, $themessage, "From: $mymail")
should not be exploitable.

[Internet Engineer]

Thanks guys - to all who responded!

I would've thought it "secure" too - until this morning! It's the reason that the tech rep pointed to: He asked, "Do you have mail scripts on your site?" and I replied, "A lot of them," and he said, "They'll have to be removed." I, of course, said, "OK," and did. The only thing all these have in common was the way they handled traffic.

See, we had been seeing the "Returned mail: User unknown" for a day or two, but chalked it up to our mail server catching people who were trying to get away with it. Unbeknownst to us, they HAD succeeded, and when our hosting service saw the bonceback messages from AOL, preemptorily shut us down. THAT was bad, and I need a fix to get us up and running again.

Again, thanks. I also found a PHP version of FormMail, which I think will work for me for security.

Wish me luck!

Dan sends...

[lorax]

>> should not be exploitable

Or at least not easily. They'd have to be pretty determined to 1. determine the actual var name and 2. focus on hacking you when there are so many open mail servers out there.

[bcolflesh]

I find PHPMailer to be the nicest class for this type of thing:

phpmailer.sourceforge.net/

I'm wondering if your host didn't jump the gun - anyone can forge headers to make any email appear (on the surface) to come from somewhere else - I get hundreds of kickbacks from AOL and angry user emails because of spam sent with forged RETURN-PATH. If your host responded to a complaint w/out real evidence of error in your site, then your host is the problem, not your script.

[coopster]

I'm trying to figure out how they could exploit that variable, even if they knew the name of it -- after all, it's hard-coded.

I guess the biggest vulnerability would be if register_globals [php.net] is ON. That's about the only way the variable value could be compromised. One option/consideration may be to change the variable to a constant [php.net] so that the value cannot change during the execution of the script.

Other thoughts, anyone? Rebuttal? :)

[jatar_k]

or put the assignment statement for $mymail the line before the mail call.

even with globals on, if those 2 lines are in the same script it won't reassign the value.

If you are passing it from many forms/actions to one mailer that takes it as a posted argument then I can see that being the point of exploit.

When I need a multiple email mailer I use a switch inside the mail script that accepts a number or form name which tells it which address to assign.

[coopster]

even with globals on, if those 2 lines are in the same script it won't reassign the value.

I think you meant ...are not..., as in:

even with globals on, if those 2 lines are not in the same script it won't reassign the value.

Right?

You make a very good point. I assumed from Dan's comment ...In each (script) that I modified... that the variable was in the same script as the mail() function itself.

[hakre]

register_globals = on

even if some people say, that using register_globals=on can (not must) be a security risk, it's not the truth.

the risk is not to switch register_globals on or off the risk is not to check the validity of any input.

if you hardencoded the mailaddy into it - with a variable or as string in the mail() command - an 'incomming' var while having register_globals=on won't overwrite your hardencoded value - it's the other way round: your assignment to the variable will overwrite the incomming value. that's it.

if the mailaddy was hardencoded in your script and you just simply used the php mail function, then i think no one hacked your script at all.

do they use sendmail?

anyway, phpmailer is really great! thumbs up.

[g1smd]

Can someone summarise the loopholes that should be avoided / not created when making this type of script, and what should be done instead?

[daisho]

I still cant figure out how he's being exploited. If he has the php statement

$mymail = "[e-mail]";

and passes that to the mail() function I can't see how it could be exploited. Even with register globals on the above statement would override it.

Now if this variable is being passed in via a form that's a different story.

Also where does the "$mysubject" variable get populated? that variable may be able to be stuffed with extra headers but I'm unsure since I haven't looked at the implementation of mail()

daisho