php mail() header injection and mod_security

WholesaleDialup

WholesaleDialup

Verified User
Joined
Sep 25, 2004
Messages
178
Location
San Antonio, TX
We are seeing some issues on one of our servers where SPAMMERS are taking advantage of some of the php forms using mail() to send SPAM.

I have been reading about this for days and I am stuck on a few things.

First, I need to know how to re-create the issue before I can test to see if I stopped it.

I have read this article here for example:
http://securephp.damonkohler.com/ind...mail_Injection

which is a great article.

Thing I don't get is this, it shows that the SPAMMER could enter a string like this in the "From:" field of your form:
"[email protected]%0ACc:[email protected]%[email protected],[email protected]"which would send out his SPAM.

Thing that has me stuck is this, everytime I try to punch this string into a sample "From:" field on a test form, when I print the string to the screen it comes out exactly like that with the "%0A" and all. The "%0A" is suppose to be converted into a "\n" which is needed of for the exploit to work. Problem is that POST data does not get unencoded like GET data on the other end and the PHP mail() just barfs.

If I try to send the same string with plain old "\n" then it ends up looking like this "\\n" on the other side because Magic Quotes is escaping my backslash.

I am confused as to how the SPAMMERS have been able to successfully pass the "\n" which is needed in a POST when I can't do it myself.

I know they are doing it because I have seen the SPAM go through the machine and I know if came from a FORM pretty much identical to my test form.

Any ideas? This is driving me seriously buggy..
 
Hi we had the same issues on a number of servers.

We have written a simple php script for our end users to use instead of their current exploitable script.

It's a basic mail script that strips the code from the form fields before mailing. It has stopped this particular spam exploit dead.

The end user must post the contact form direct to this script.

In the script you will need to change the email address it mails the form to, the email subject line and the return or 'thank you' page.

It's only simple but it works.

Rob
 

Attachments

Thanks for the replies..

I do know how to stop this by writing or requiring my users to write the php scripts correctly, I guess I was looking for a server wide solution that would protect us even when the users didn't do what they were suppose to.
 
We also had that issue. All spam mails were send to @aol.com.

We have protected all php forms by filtering "bcc" and blocked *@aol.com in mailscanner

Franky
 
WholesaleDialup said:
Thanks for the replies..

I do know how to stop this by writing or requiring my users to write the php scripts correctly, I guess I was looking for a server wide solution that would protect us even when the users didn't do what they were suppose to.
Click to expand...

I suppose the harsh truth is your users have got insecure scripts on their site.

Our terms and conditions do not allow people to keep scripts on their site if they are exploitable / being exploited.

When we had a problem the bottom line for us was looking after the integrity of the servers - this includes doing as much as we could to prevent any of them getting onto the blacklists.

We went out of our way to find insecure scripts - our resellers did their own clients - 99% of clients were updated in just a few days. Only 1 client had to have their page deleted as they didn't know what to do and refused to pay for someone else to do it.

Rob
 
I don't disagree but, if I am able to secure this server wide, that is a better solution.

I know it can be done using mod_security for example.

I already installed mod_security, I just need a little help duplicating and re-creating the exploit so I know when I have actually fixed it.

Telling users to behave is something we do all the time but anything we can do to reduce the manual babysitting makes life that much easier.

Additionally, we have businesses for example who may have had someone setup their site and are no where to be found now. They just glaze over when you start talking to them about insecure scripts.

Expecting users to do the right thing is a fantasy, you have to watch them. I have enough things to watch already without leaving things wide open that have known fixes.

Either way, the feedback is always appreciated.
 
WholesaleDialup said:
I don't disagree but, if I am able to secure this server wide, that is a better solution.
Click to expand...

Definately

WholesaleDialup said:
I just need a little help duplicating and re-creating the exploit so I know when I have actually fixed it.
Click to expand...

We struggled to recreate it, BUT what we did find out was that the spammers seemed to by-pass the form on the webpage completely and just use the script the form posted to.

Hope this helps a bit - I know when a server-wide solution does come along we will be relieved!

Rob
 
Last edited:
Anton, are you sure that you won't have any problems with phpMyAdmin under DA when using your script?

I'm not, because DA runs its own webserver only for the control panel itself; it runs phpMyAdmin under the normal default httpd daemon.

Jeff
 
Hi,
Yes, I can say that we had no problems with users using phpMyAdmin, that comes with DirectAdmin. We have put it to most of our servers with different control panels and for now all we get is only benefits. Noone has complained until now (for about month now).

Anton.
 
You must log in or register to reply here.
Back
Top