Email Injection w/ Out Header?

[xmp333]

Hello,
A spammer is apparently using email injection on my form, however my I
thought email injection requires mainpulation of the headers parameter
in mail() and I'm not using that parameter. My mail call looks like:

mail($to,$subj,$body)

So how is the spammer getting me? Is mail() translating to a raw
stream so that headers can be inserted in the body, or is there some
kind of buffer overflow that can be exploited? Since I'm using dynamic
variables, I can't see how this would occur, but then I'm no PHP
expert.

Any help would be greatly appreciated. I know beefing up input
validation should take care of this, but I want to understand what the
spammer is doing so I can reproduce and validate this fix.

Thanks in advance.

[Erwin Moller]

xm****@yahoo.com wrote:

Hello,
A spammer is apparently using email injection on my form, however my I
thought email injection requires mainpulation of the headers parameter
in mail() and I'm not using that parameter. My mail call looks like:

mail($to,$subj,$body)

So how is the spammer getting me? Is mail() translating to a raw
stream so that headers can be inserted in the body, or is there some
kind of buffer overflow that can be exploited? Since I'm using dynamic
variables, I can't see how this would occur, but then I'm no PHP
expert.

Any help would be greatly appreciated. I know beefing up input
validation should take care of this, but I want to understand what the
spammer is doing so I can reproduce and validate this fix.

Hi,

Log $to, $subj, $body somewhere (flatfile or database).
Check after spamming what the spammer did.

You can probably find many resources on the net adressing this issue, but
first you need to know WHAT you excactly are calling with the mail().

Regards,
Erwin Moller
Thanks in advance.

[Gordon Burditt]

>A spammer is apparently using email injection on my form, however my I

thought email injection requires mainpulation of the headers parameter
in mail() and I'm not using that parameter. My mail call looks like:

mail($to,$subj,$body)

So how is the spammer getting me?

Are the contents of $to and $subj in any way whatever dependent
on form input? Is there any way either of those variables could
be made to contain a newline or carriage return? If so, that's
how they are doing it. Remember, the spammer NEED NOT use your
form so any Javascript checking is useless.

Look at the headers of any mail message, and consider what
happens if $subj = "Make Money fast\r\nCc: sp****@aol.com".

Gordon L. Burditt

[xmp333]

Gordon Burditt wrote:

Are the contents of $to and $subj in any way whatever dependent
on form input? Is there any way either of those variables could
be made to contain a newline or carriage return? If so, that's
how they are doing it. Remember, the spammer NEED NOT use your
form so any Javascript checking is useless.

Look at the headers of any mail message, and consider what
happens if $subj = "Make Money fast\r\nCc: sp****@aol.com".

Gordon L. Burditt

$to is not dependent on form input, but $subj is. This explains it --
I wanted to make sure because all the information I found on email
injection stated the header was used to mainpulate the form. However,
knowing what I know of mail() and Unix in general, it seemed possible
to inject arbitrary headers elsewhere if the parameters were simply
appended and the call translated to a raw text stream anyway, which
looks like the case.

Thanks.

[Kim André Akerø]

Erwin Moller wrote:

xm****@yahoo.com wrote:

Hello,
A spammer is apparently using email injection on my form, however
my I thought email injection requires mainpulation of the headers
parameter in mail() and I'm not using that parameter. My mail call
looks like:

mail($to,$subj,$body)

So how is the spammer getting me? Is mail() translating to a raw
stream so that headers can be inserted in the body, or is there some
kind of buffer overflow that can be exploited? Since I'm using
dynamic variables, I can't see how this would occur, but then I'm
no PHP expert.

Any help would be greatly appreciated. I know beefing up input
validation should take care of this, but I want to understand what
the spammer is doing so I can reproduce and validate this fix.

Hi,

Log $to, $subj, $body somewhere (flatfile or database).
Check after spamming what the spammer did.

And while you're at it, don't forget to include the IP address of the
offender as well (environmental variable REMOTE_ADDR).

--
Kim André Akerø
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)

[Justin Koivisto]

xm****@yahoo.com wrote:

A spammer is apparently using email injection on my form, however my I
thought email injection requires mainpulation of the headers parameter
in mail() and I'm not using that parameter. My mail call looks like:

mail($to,$subj,$body)

So how is the spammer getting me? Is mail() translating to a raw
stream so that headers can be inserted in the body, or is there some
kind of buffer overflow that can be exploited? Since I'm using dynamic
variables, I can't see how this would occur, but then I'm no PHP
expert.

Any help would be greatly appreciated. I know beefing up input
validation should take care of this, but I want to understand what the
spammer is doing so I can reproduce and validate this fix.

Some things that I like to do when processing forms...

On the page that has the form, generate some kind of token, store and
send with request:

<?php
session_start();
$token = md5('my secret'.microtime().'other secret');
$_SESSION['token'] = $token;
echo '<input type="hidden" name="token" value="',$token,'" />";
?>

on the receiving page...

<?php
session_start();
if(isset($_POST['token']) && $_SESSION['token']==$_POST['token']){
// this POST request should be a submission of my form, not a spoof
}else{
// the form submission was spoofed...
}
?>

In addition to that, I also do some flat-out rejection stuff as well...
Since I know the fields and what to expect, I run this test on all
fields that should NOT contain a line break of any type:

if(preg_match('`[\r\n]`',$_POST['fieldname'])){
// here, we found a newline or carriage return
// corrupted data should be set to empty string
$_POST['fieldname']='';

// decide how to handle this condition...
}

Most of the time if I find this, I'll report an error and ask for
resubmission, but in some cases (depending on the application) I will
simply kill execution.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Gordon Burditt]

>> Are the contents of $to and $subj in any way whatever dependent

on form input? Is there any way either of those variables could
be made to contain a newline or carriage return? If so, that's
how they are doing it. Remember, the spammer NEED NOT use your
form so any Javascript checking is useless.

Look at the headers of any mail message, and consider what
happens if $subj = "Make Money fast\r\nCc: sp****@aol.com".

Gordon L. Burditt
$to is not dependent on form input, but $subj is. This explains it --
I wanted to make sure because all the information I found on email
injection stated the header was used to mainpulate the form.

The subject *IS* a header. If it's not in the body of the
message, it's a header.
However,
knowing what I know of mail() and Unix in general, it seemed possible
to inject arbitrary headers elsewhere if the parameters were simply
appended and the call translated to a raw text stream anyway, which
looks like the case.

Mail is always transmitted as a text stream. That's what mail is.

You cannot inject headers after the first blank line (which separates
the headers from the body). $to, $subj, and $additional_headers
are headers.

Go to the page for the mail() function on php.net. Note that the
subject parameter is described as "This must not contain any newline
characters, or the mail may not be sent properly". Consider this
as something you *MUST ENFORCE*. Not mentioned are carriage return
characters, which also need to be eliminated. And don't remove the
offending characters. DON'T SEND THE MAIL, PERIOD. Provide the
user a nice message that he's a spammer and he's going to burn
in hell for a googol eternities.

If your ISP does not run *OUTGOING* mail through SpamAssassin and
an antivirus program, YOU should before sending it.

Gordon L. Burditt

[I Hate Stock Spams]

This question has also come up recently in news.admin.net-abuse.email so I
have cross posted the following excellent answer to nanae.

In response to a question about the recent control character/bcc: injection
epidemic in web mail forms, Justin Koivisto <ju****@koivi.com> posted in
comp.lang.php and php.general:

Some things that I like to do when processing forms...

On the page that has the form, generate some kind of token, store and
send with request:

<?php
session_start();
$token = md5('my secret'.microtime().'other secret');
$_SESSION['token'] = $token;
echo '<input type="hidden" name="token" value="',$token,'" />";
?>

on the receiving page...

<?php
session_start();
if(isset($_POST['token']) && $_SESSION['token']==$_POST['token']){
// this POST request should be a submission of my form, not a spoof
}else{
// the form submission was spoofed...
}
?>

In addition to that, I also do some flat-out rejection stuff as well...
Since I know the fields and what to expect, I run this test on all
fields that should NOT contain a line break of any type:

if(preg_match('`[\r\n]`',$_POST['fieldname'])){
// here, we found a newline or carriage return
// corrupted data should be set to empty string
$_POST['fieldname']='';

// decide how to handle this condition...
}

Most of the time if I find this, I'll report an error and ask for
resubmission, but in some cases (depending on the application) I will
simply kill execution.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

-=-
This message was sent via two or more anonymous remailing services.

[I Hate Stok Spammers]

This question has come up in news.admin.net-abuse.email so I have cross
copied your answer there.

Thank you for some excellent suggestions.

In response to a question about the recent control character/bcc: injection
epidemic in web mail forms, Justin Koivisto <ju****@koivi.com> posted in
comp.lang.php and php.general:

Some things that I like to do when processing forms...

On the page that has the form, generate some kind of token, store and
send with request:

<?php
session_start();
$token = md5('my secret'.microtime().'other secret');
$_SESSION['token'] = $token;
echo '<input type="hidden" name="token" value="',$token,'" />";
?>

on the receiving page...

<?php
session_start();
if(isset($_POST['token']) && $_SESSION['token']==$_POST['token']){
// this POST request should be a submission of my form, not a spoof
}else{
// the form submission was spoofed...
}
?>

In addition to that, I also do some flat-out rejection stuff as well...
Since I know the fields and what to expect, I run this test on all
fields that should NOT contain a line break of any type:

if(preg_match('`[\r\n]`',$_POST['fieldname'])){
// here, we found a newline or carriage return
// corrupted data should be set to empty string
$_POST['fieldname']='';

// decide how to handle this condition...
}

Most of the time if I find this, I'll report an error and ask for
resubmission, but in some cases (depending on the application) I will
simply kill execution.

--
Justin Koivisto, ZCE - ju****@koivi.com
http://koivi.com

[Java Boy]

REMOTE_ADDR will only show the proxy IP use X-Forwarder for that matter.

--
Geeks Home
www.fahimzahid.com

"Kim André Akerø" <ki******@NOSPAMbetadome.com> wrote in message
news:40*************@individual.net...

Erwin Moller wrote:

xm****@yahoo.com wrote:

Hello,
A spammer is apparently using email injection on my form, however
my I thought email injection requires mainpulation of the headers
parameter in mail() and I'm not using that parameter. My mail call
looks like:

mail($to,$subj,$body)

So how is the spammer getting me? Is mail() translating to a raw
stream so that headers can be inserted in the body, or is there some
kind of buffer overflow that can be exploited? Since I'm using
dynamic variables, I can't see how this would occur, but then I'm
no PHP expert.

Any help would be greatly appreciated. I know beefing up input
validation should take care of this, but I want to understand what
the spammer is doing so I can reproduce and validate this fix.

Hi,

Log $to, $subj, $body somewhere (flatfile or database).
Check after spamming what the spammer did.

And while you're at it, don't forget to include the IP address of the
offender as well (environmental variable REMOTE_ADDR).

--
Kim André Akerø
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)

[Kim André Akerø]

Java Boy wrote:

REMOTE_ADDR will only show the proxy IP use X-Forwarder for that
matter.

Of course, it's just a matter of checking whether the X-Forwarder
header is being used. The X-Forwarder header can be forged, though.
REMOTE_ADDR is harder to forge, especially if the originator is seeking
feedback on the successful execution of the script.

Even so, REMOTE_ADDR will give you a starting point when reporting
abuse.

--
Kim André Akerø
- ki******@NOSPAMbetadome.com
(remove NOSPAM to contact me directly)