Formmail und SPAM

[Rolf Rost]

So machen das die Spammer:

Die versuchen auf verschiedenen Servern das Script *formmail.pl* zu starten und schicken die info falls dieses Script vorhanden ist irgendwo (siehe xxxxxxxxxx) hin.

Der string:
email=Checkit%40i%2Dnetlab%2Ede&recipient=xxxxxxxx%40hotmail%2Ecom&subject=www%2Ei%2Dnetlab%2Ede%2Fcgi%2Dbin%2Fformmail%2Ecgi%3F&msg=www%2Ei%2Dnetlab%2Ede%2Fcgi%2Dbin%2Fformmail%2Ecgi%3F

sieht decodiert so aus:
email=[e-mail]&recipient=[e-mail]&subject=www.i-netlab.de/cgi-bin/formmail.cgi?&msg=www.i-netlab.de/cgi-bin/formmail.cgi?

Werden diese Säcke fündig nutzen die dann weiterhin das *formmail.pl/cgi* um ihre geschmacklose Jauche überallhin zu schicken.

In so einem Fall ist der Depp der Betreiber/Webmaster der WebSite.

Jeder Webmaster kann also selbst dazu beitragen SPAM zu vermeiden indem er solche MailerScripts, Scripts in denen der _Empfänger_ der eMail via HTTP Request (POST: hidden-field Mailempfänger, GET: QUERY_STRING) übergeben werden kann, NICHT zum Einsatz bringt.

Rolf

http://i-netlab.de/downloads/notfound.shtml
http://i-netlab.de/article/post.shtml

__END__
Received: from [62.116.166.170] (helo=serv2.h-id.de)
 by mx09.web.de with esmtp (WEB.DE(Exim) 4.95 #31)
 id 18ifhJ-0000T4-00
 for [e-mail]; Tue, 11 Feb 2003 20:04:01 +0100
Received: from serv2.internetx.de (localhost [127.0.0.1])
 by serv2.h-id.de (8.12.2/8.12.2) with ESMTP id h1BJ3xAU029428
 for [e-mail]; Tue, 11 Feb 2003 20:03:59 +0100
Date: Tue, 11 Feb 2003 20:03:59 +0100
Message-Id: [e-mail]
From: [e-mail]
To: [e-mail]
Subject: Deppen am Werkeln
Sender: [e-mail]

REQUEST_URI: /cgi-bin/formmail.cgi?email=Checkit%40i%2Dnetlab%2Ede&recipient=foxxxxxxxx%40hotmail%2Ecom&subject=www%2Ei%2Dnetlab%2Ede%2Fcgi%2Dbin%2Fformmail%2Ecgi%3F&msg=www%2Ei%2Dnetlab%2Ede%2Fcgi%2Dbin%2Fformmail%2Ecgi%3F
REMOTE_ADDR: xxxxxxxxxxxxx
REDIRECT_ERROR_NOTES: script not found or unable to stat: /home/netlab/htdocs/cgi-bin/formmail.cgi
HTTP_REFERER
HOSTNAME: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
EreignisZeit: 11.02.2003 20:03:59

[Ernie]

Hallo,

finde diesen hinweis auch nochmals gut. ich als betreiber eines webserver untersage jeglichen kunden welche bei mir webspace hosten kann, solcher formmailer. werden diese trotzdem genutzt, so darf der kunde sich einen anderen webhoster suchen. ist zwar nicht die feine engliche art, allerdings sollten entwickler sowas wissen.

ok, entwickler lassen wir mal da so hingestellt, meist sind es ja die leute welche design/html umsetzung in einem machen und sich entwickler schimpfen. die setzen meist auch diese/solche formmailer ein. und weil die meist nur bis javascript kommen, benutzen die formmailer welche sie schon 1000 mal eingesetzt haben. und dann schön in den hiddenfielder die empfängerdaten angeben. ist vorallem aber auch ein andere nachteil. es gibt spammer die genau auch nach solchen formularen ausschau halten, sich die angaben (to, subject) herraus ziehen um dann damit unfug zutreiben.

aber jene leute welche so ihre hiddenfielder meinen zufüllen sind es ebend selber schuld.

ich hoffe deinen beitrag haben viele zur kenntnis genommen.

Ernie

[Ernie]

noch ein nachtrag:

viele von solchen entwicklern wissen gerade mal dass der formmailer aufm server noch ausführbar gemacht werden müssen. was chmod ist und warum diese ausführ sein müssen, verstehen sie meist nicht. am besten noch mit chmod 777 ausführbar machen, damit dann alles möglich ist. ist so, als wenn ein bäcker brötchen backen kann und nicht weiss wann sie raus müsssen, damit sie nicht anbrennen.

ich will nicht wissen was es an unsicheren scripten im netz gibt. ich glaube mindestens 40% aller scripte sind gefährlich.

Ernie

[xwolf]

Hi,

ich will nicht wissen was es an unsicheren scripten im netz gibt. ich glaube mindestens 40% aller scripte sind gefährlich.

Das ist noch untertrieben.
Bei einer Analyse der Skripten auf einem ziemlich grossen Skriptarchiv
bin ich auf 90% gekomen bei solchen Skripts, die Datei- oder MailOperationen machen.
Das gilt sowohl fuer CGI, also auch PHP-Skripten.
Nach Gefuehl und der wahnsinnig steigenden Zahl an BUGTRAQ-Meldungen
denke ich, ist die Zahl bei PHP sogar noch größer. (Weil mit PHP lange falsch geworben wurde, dass es immer sicher sei und ideal für Anfänger ist... Nun ja... Wenn einem Anfänger gesgat wird, das PHP ist immer sicher, egal was für einen Nonsense er macht, dann wird der Code auch kaum geprüft...)

CIao,
 Wolfgang

[Ernie]

hallo,

hinter deiner aussage steckt sehr viel. ich hätte allerdings nicht gedacht, dass es bei 90% liegt.

ich selbst betreue ein sehr heickles projekt im internet, welches mit sehr sensiblen daten umgehen muss (name darf ich wohl jetzt nicht nennen). als ich das projekt von meinen vorgänger übernahm dachte ich, ich stehe im wald. sicherheitslöcher on mass. ich glaube da haben selbst die verantwortlichen, denn dass sind die schönen "kundenadmins" gewesen dicke äpfel auf den aufen gehabt.

die vorgänger dieses projekt/portal war eine konkurrenzfirma, welche in der flut der vernichtung am neuen markt vor 2 jahren mit unterging (wahrscheinlich auch gut so)

sicherheit sollte da anfangen wo denken anfängt und nicht später.

ich kenne projektepläne und konzepte ohne sicherheits hinweise; eigentlich habe ich noch nie welche gesehen, wo überhaupt dass thema sicherheit vorkam. das oben beschriebene projekt hatte so gesehen auch keines. es wurde dann im nachhinein nacherfasst und auf bestimmte felder erweitert.

frage mich nur: wie kann man es ändern? wie bringt man die leute zum thema sicherheitsgedanke?

bücher alleine reichen da nicht, erfahrung muss her und dieses kostet meist auch mehr.

mfg

Ernie nicht zuverwechseln mit Bert ;-)