Question about abuse of a CGI script

A

A. Sinan Unur

A. Sinan Unur wrote :

Yes, I guess you are talking about the part which suggests to post a
small but working script which can be copied and pasted and which
demonstrates the problem.
Yes.

....


Then the mail which is sent to the reciever of the email contains some
additional sendere:
(e-mail address removed), (e-mail address removed) and (e-mail address removed)

Are you purposefully being dense here? \n is a newline. OK, I forgot to
type the Bcc: before the second address but still, the point I was
trying to make should have been obvious. See:

D:\Home\asu1\UseNet\clpmisc\mail> cat m.pl
#!/usr/bin/perl

use strict;
use warnings;

use Mail::Mailer;

my $from = <<'FROM';
(e-mail address removed)
Bcc: (e-mail address removed), (e-mail address removed), (e-mail address removed)
FROM

my $mailer = Mail::Mailer->new('testfile');

$mailer->open({
To => '(e-mail address removed)',
From => $from,
Subject => 'Test',
});

$mailer->close;


D:\Home\asu1\UseNet\clpmisc\mail> cat mailer.testfile

===
test 1 Sun Feb 5 19:33:35 2006
to: (e-mail address removed)

Subject: Test
To: (e-mail address removed)
From: (e-mail address removed)
Bcc: (e-mail address removed), (e-mail address removed), (e-mail address removed)
Yes, is this relevant?
I didn't think so but I might be wrong.

It is, because that was your excuse for not using CGI.pm

Sinan
 
T

Tintin

Martin Kissner said:
It might have been wrong not to use CGI.pm for this case, but I decided
not to use CGI.pm for several reasons. The website is presented in
several languages, uses databases and many templates (with
HTML::Template). Also I use CSS very much.

Which doesn't preclude CGI.pm at all.
After I had read perldoc CGI I did not like the syntax
and felt like it might be not so easy to combine all the things I
mentioned above. (Maybe it is for an expierienced perl programmer which I
am not.) To me it looked like the HTML/CSS is not well enough divided
from the perl code (for my needs).

Most people don't use the CGI module to generate their HTML. In fact, one
of the big complaints about CGI.pm is the fact it tries to do too much
outside the scope of CGI parsing.

CGI module works very well with most templating systems (or even hand coded
ones).
 
M

Martin Kissner

Gunnar Hjalmarsson wrote :
What would happen if $userinput{name} consists of the string that this
expression results in:

qq|faked\@example.com\nCc: victim1\@example.com, victim2\@example.com,|

Then some more people will get mail than intented.
My question is: How did they do it?
I tryed on my local webserver evereything I can think of, but the only
result I get is a few additional senders.

Best regards
Martin
 
G

Gunnar Hjalmarsson

Martin said:
Gunnar Hjalmarsson wrote :

Then some more people will get mail than intented.
My question is: How did they do it?

Either they used an own, modified form, or - more likely - a script that
emulates a form submission. With Perl you can write such a script using
e.g. the LWP family of modules.
 
A

A. Sinan Unur

Gunnar Hjalmarsson wrote :

Then some more people will get mail than intented.

You are missing the point. The spammer does not type these things in by
hand.
My question is: How did they do it?
I tryed on my local webserver evereything I can think of, but the only
result I get is a few additional senders.

Submit the form using WWW::Mechanize.

At this point, I would recommend that you give up. Don't put a mail form
on the web. Just put your mom's email address there, and tell your mom
to use a spam filter[1].

You do not realize the harm you are doing to hundreds of thousands of
people being targetted by the spammer. In fact, I sense from you an
attitude of "who cares" regarding the victims.

[1] Yes, I am dead serious. Maybe after a few months of spam, you
realize the harm you are doing.

Sinan
 
M

Martin Kissner

A. Sinan Unur wrote :
Are you purposefully being dense here? \n is a newline. OK, I forgot to
type the Bcc: before the second address but still, the point I was
trying to make should have been obvious.

To me it is obvious *what* can be done but not *how* it is done.
Of course I tried
(e-mail address removed),\nBcc:[email protected]
but I didn't recieve a Bcc mail to myotheraddress.
I recieved mail to the address coded in the script with some "weired"
looking senders.

I also trid the code you posted below. Here is my result:
|
| ===
| test 1 Mon Feb 6 02:30:09 2006
| to: (e-mail address removed)
|
| Subject: Test
| To: (e-mail address removed)
| From: (e-mail address removed) Bcc: (e-mail address removed), (e-mail address removed),
| (e-mail address removed)
|

The Bcc does not skip to the next line. (???)
I have no idea why but I will test this on a different computer with
FreeBSD on it.
This is Mac OS X / Darwin.

[...]
It is, because that was your excuse for not using CGI.pm

I didn't feel like I have to excuse myself, I was just explaning my
reasons for my decison.
Actually the website on which the script runs contains about 300 pages
generated by my cgi skript. The HTML email was not the reason to use
HTML::Template and also it was not the reason for not using CGI.pm
Also it doesn't even make sense to generate the mail with
HTML::Template. I was just curious if I could combine Mail::Mailer and
HTML::Template. This also shows that the overhead of CGI.pm is not the
reason for not using it ;-)

If I had known that this is important I had explained this mor
thouroughly.

Best regards
Martin
 
M

Martin Kissner

Tintin wrote :
Which doesn't preclude CGI.pm at all.

I do not deny this.
I myself, however, didn't feel comfortable with it.

[...]
CGI module works very well with most templating systems (or even hand coded
ones).

Maybe I will take another look at it after this.

Best regards
Martin
 
M

Martin Kissner

Gunnar Hjalmarsson wrote :
Either they used an own, modified form, or - more likely - a script that
emulates a form submission. With Perl you can write such a script using
e.g. the LWP family of modules.

Okay.
Am I right if I suppose that such a script contacts the form on my
website, fills in some values into my fields and then submits the form?
 
A

A. Sinan Unur

A. Sinan Unur wrote :

I have taken this from a book. The book says it saves cpu time because
the pattern is only compiled once. It suggests to always use it in
loops unless the pattern changes.

Read the docs, and throw that book out.

Also, involving the Regex engine is completely unnecessary here.

#!/usr/bin/perl

use strict;
use warnings;

my $s = q{This+is+a+test};
$s =~ tr/+/ /;

print "$s\n";
__END__
 
M

Martin Kissner

A. Sinan Unur wrote :
You are missing the point. The spammer does not type these things in by
hand.

Next time I will use some irony tags ;)
My question is: How did they do it?
I tryed on my local webserver evereything I can think of, but the only
result I get is a few additional senders.

Submit the form using WWW::Mechanize.

At this point, I would recommend that you give up. Don't put a mail form
on the web. Just put your mom's email address there, and tell your mom
to use a spam filter[1].

No, I won't (sorry);
You do not realize the harm you are doing to hundreds of thousands of
people being targetted by the spammer. In fact, I sense from you an
attitude of "who cares" regarding the victims.

Not at all, but if I give up I will not be able to learn how to do it
right.
Maybe you missed the fact that I have changed my script so the actual
spammer is not able to use it any more.
Also I am here mainly to get an idea how people can abuse scripts which
are so - I admit - poorly written as mine in order to avoid this in the
future.
As I mentioned before, I am an autodidact and sometimes I will some
time to understand how things go but I have decided to master this.

Best regards
Martin
 
G

Gunnar Hjalmarsson

Martin said:
Gunnar Hjalmarsson wrote :

Okay.
Am I right if I suppose that such a script contacts the form on my
website, fills in some values into my fields and then submits the form?

No. Such a script doesn't care about your form. It passes the values
directly to your script.
 
M

Martin Kissner

Gunnar Hjalmarsson wrote :
No. Such a script doesn't care about your form. It passes the values
directly to your script.

In this case it must be different.
I renamed the form but not the script.
Then I duplicated the form, changed the action in the <form> tag and
saved it under the original name.
The new action script only counts the hits by saving the IP addresses used by
the spammer but doesn't send any mails. It doesn#T even look at the
fields.
 
M

Martin Kissner

A. Sinan Unur wrote :
Read the docs, and throw that book out.

Guess what! I already did.
Also, involving the Regex engine is completely unnecessary here.

#!/usr/bin/perl

use strict;
use warnings;

my $s = q{This+is+a+test};
$s =~ tr/+/ /;

Thank you for this hint.
 
G

Gunnar Hjalmarsson

Martin said:
Gunnar Hjalmarsson wrote :

In this case it must be different.
I renamed the form but not the script.
Then I duplicated the form, changed the action in the <form> tag and
saved it under the original name.
The new action script only counts the hits by saving the IP addresses used by
the spammer but doesn't send any mails. It doesn#T even look at the
fields.

The spammer needs to know what to submit and whereto, and that info he
reasonably grabs from your form. Then, when actually abusing your
script, he most likely bypasses your form.
 
M

Martin Kissner

Gunnar Hjalmarsson wrote :
The spammer needs to know what to submit and whereto, and that info he
reasonably grabs from your form. Then, when actually abusing your
script, he most likely bypasses your form.
Okay; wherto would be the script, right?

but how can he find out about the script's name? The script lies in
/cgi-bin/ and the scripts name does not appear in the form or any other
file which is accessible directly via HTTP. The action in the html form
is a html filename which is redirected via .htaccess/mod_rewrite to the
cgi script. This filename I have changed.

Is there a chance somone could find out where to submit the data?
I don't think the spammer can use my script right now.
I have added some additional code to inform me but up to know I have not
noticed him back on the main script (based on some pattern matching and
content length restrictions). Additionally I removed the variables in the header
part of the script.

Also I have added another script which gets executed when the server is
accessed via the original html filename. This script gets executed
several times an hour, but it does not process the input.

Did I miss anything? Can someone unnoticedly get arround this setup?
 
A

A. Sinan Unur

Gunnar Hjalmarsson wrote :
Okay; wherto would be the script, right?

"Where to" is whatever is in the action attribute of the form you are
using.
but how can he find out about the script's name? The script lies in
/cgi-bin/ and the scripts name does not appear in the form or any
other file which is accessible directly via HTTP. The action in the
html form is a html filename which is redirected via
.htaccess/mod_rewrite to the cgi script. This filename I have
changed.

Is there a chance somone could find out where to submit the data?

I don't know what you are talking about, but that's irrelevant. Web
server configuration is off-topic here (well, so was CGI. Forgive me for
I have sinned).

Sinan
 
M

Matt Garrish

Martin Kissner said:
Gunnar Hjalmarsson wrote :
Okay; wherto would be the script, right?

but how can he find out about the script's name? The script lies in
/cgi-bin/ and the scripts name does not appear in the form or any other
file which is accessible directly via HTTP. The action in the html form
is a html filename which is redirected via .htaccess/mod_rewrite to the
cgi script. This filename I have changed.

But a request is a request, whether it comes from a browser or is created
manually by a program. The spammer's request gets forwarded the same way the
browsers request gets forwarded. You should really take some time to look
over the LWP modules and what they can do (specifically posting data), as
well as read up on how http requests work. Without more fundamentals in how
the Web operates, you'll have a very hard time writing secure scripts.

Matt
 
M

Martin Kissner

A. Sinan Unur wrote :
"Where to" is whatever is in the action attribute of the form you are
using.

Then it is a nonexisting html filename he tries to access now which is
not processed by the script in the way he relies on.
I don't know what you are talking about, but that's irrelevant. Web
server configuration is off-topic here (well, so was CGI. Forgive me for
I have sinned).

Forgive me, too. I have asked about how my perl CGI skript, which is
running on a web server, could have been hacked by a spammer in a perl
newsgroup.

But wait - I have decided to ask here because I was
interested in what _perl_code_ the spammer might have passed to my
_perl_script_. My original question was not about CGI and and not about
web server configuration but about perl code.

But you are right. The last question is off-topic here. I should have
asked it in a web server related group.

Best regards
Martin

btw: I have tested the script you gave me in the other post on a FreeBSD
machine. There I get the same result as you do (Bcc addresses in a
newline).
 
M

Martin Kissner

Matt Garrish wrote :
But a request is a request, whether it comes from a browser or is created
manually by a program. The spammer's request gets forwarded the same way the
browsers request gets forwarded.

Yes, I know.
But doesn't the program of the spammer have to passuse an URI as the browser
does?
And now he keeps on passing an URI which doesn't make my script send mail.

The spammer requests a file on the webserver and sends some data to its
stdin. The filename (which is part of the URI) and the data are passed
to my cgi script but when the script "sees" the URI, it refuses to read
the data but only hits a counter and exits. In my case I don't think
the spammer accesses the script itself and if he does, he has to pass
the URI which triggers the script to send mail.

Isn't this right?

If it is, I think changing the filename which makes the script send mail
was not that bad and also I have changed the script to take a closer
look at the data provided by the user (for the new filename in the form
action attribute).
You should really take some time to look over the LWP modules and what
they can do (specifically posting data), as well as read up on how
http requests work. Without more fundamentals in how the Web operates,
you'll have a very hard time writing secure scripts.

Yes, thank you. I have bought the book "Network Programming with perl"
by Lincoln Stein, which I think is a good choice.

Best regards
Martin
 
A

A. Sinan Unur

A. Sinan Unur wrote :

Then it is a nonexisting html filename he tries to access now which is
not processed by the script in the way he relies on.

That sentence makes no sense. If a visitor can submit the form using a
web browser, then a simple script using LWP, or the command line wget
program can also submit to the same target specified in the action
attribute of the form element you are using.

Your confusion arises from the fact that you don't seem to understand how
HTTP and CGI work, and you confuse the issue by adding in all sorts of
web server configuration issues.

In summary:

Q1) How do I save the full query submitted to my CGI script.

A) Look into methods provided for this purpose by CGI.pm and CGI::Minimal

Q2) How do I prevent a spammer from using my script to send email to
thousands of people?

A) The safest way is to prevent a web site visitor from being able to
enter any email address. Short of that, look at CGI::ContactForm to see
how to make sure the submitted parameter only contains a single email
address.

There seems to be nothing else that is remotely Perl related to discuss.

Sinan
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,768
Messages
2,569,574
Members
45,050
Latest member
AngelS122

Latest Threads

Top