Missbrauch von newsletter.php
Hallo Tom,
das Problem an dem Code der c\'t ist, dass es zu spezifisch auf den einen Fall gemacht ist. Das Script für die newsletter kann man universell einsetzen, d.h. etwaige Zeilenumbrüche müssen erlaubt bleiben. Die Prüfung der übergebenen Werte auf Cc:, BCc: usw. müsste eigentlich reichen, um den Missbrauch zu verhindern. Bisher hat sich auch niemand mehr beschwert, das das Script missbraucht wurde.
Wenn du die Sache aus der c\'t einbauen willst, dann musst du dich mit Scriptprogrammierung auskennen. In die Funktion CheckEMail() baust du die Prüfung mit preg_match auf \'absender\' => \'/^[\\w.+-]{2,}\\@[\\w.-]{2,}\\.[a-z]{2,6}$/\' ein. In die beiden Schleifen unter ##################################### Spam test
while (list ($key, $val) = each ($_GET)) { und while (list ($key, $val) = each ($_POST)) { die Prüfung preg_match auf \'text\' => \'/^[[:print:][:space:]]{10,}$/\' . In den beiden Schleifen muss man $key==\'EMail\' ignorieren, da die Prüfung bereits in der CheckEMail() Funktion gemacht wird.
das Problem an dem Code der c\'t ist, dass es zu spezifisch auf den einen Fall gemacht ist. Das Script für die newsletter kann man universell einsetzen, d.h. etwaige Zeilenumbrüche müssen erlaubt bleiben. Die Prüfung der übergebenen Werte auf Cc:, BCc: usw. müsste eigentlich reichen, um den Missbrauch zu verhindern. Bisher hat sich auch niemand mehr beschwert, das das Script missbraucht wurde.
Wenn du die Sache aus der c\'t einbauen willst, dann musst du dich mit Scriptprogrammierung auskennen. In die Funktion CheckEMail() baust du die Prüfung mit preg_match auf \'absender\' => \'/^[\\w.+-]{2,}\\@[\\w.-]{2,}\\.[a-z]{2,6}$/\' ein. In die beiden Schleifen unter ##################################### Spam test
while (list ($key, $val) = each ($_GET)) { und while (list ($key, $val) = each ($_POST)) { die Prüfung preg_match auf \'text\' => \'/^[[:print:][:space:]]{10,}$/\' . In den beiden Schleifen muss man $key==\'EMail\' ignorieren, da die Prüfung bereits in der CheckEMail() Funktion gemacht wird.
Hallo Mirko,
nun bin ich der nächste Betroffene - mir wurde das Script auch nach massivem Spam Angriff gesperrt. Hatte die \"alte\" Version im Einsatz, habe mir aber vorgestern ein neues Script mit Double Opt In erstellen lassen und upgeloaded.
Mein Hoster hat es probiert und gesagt er könne sich immer noch selbst angreifen, also natürlich auch andere. Er hat mir einen Artikel aus der ct gemailt - http://www.heise.de/security/artikel/66815
Das hört sich recht fundiert an - ich weiß nur nicht wo man den Code einfügt..
Habe jetzt das Script jetzt erstmal bei dir abgelegt, aber da ich es mehrmals nutze für mehrere Newsletter - keine echte Lösung.
Brauchst du noch irgendwas um zu helfen?
Tom
nun bin ich der nächste Betroffene - mir wurde das Script auch nach massivem Spam Angriff gesperrt. Hatte die \"alte\" Version im Einsatz, habe mir aber vorgestern ein neues Script mit Double Opt In erstellen lassen und upgeloaded.
Mein Hoster hat es probiert und gesagt er könne sich immer noch selbst angreifen, also natürlich auch andere. Er hat mir einen Artikel aus der ct gemailt - http://www.heise.de/security/artikel/66815
Das hört sich recht fundiert an - ich weiß nur nicht wo man den Code einfügt..
Habe jetzt das Script jetzt erstmal bei dir abgelegt, aber da ich es mehrmals nutze für mehrere Newsletter - keine echte Lösung.
Brauchst du noch irgendwas um zu helfen?
Tom
Die geänderte Variante des Scripts newsletter.php (mit/ohne Double-Opt-In) ist jetzt eingespielt. Man muss sich das Script natürlich neu erstellen lassen und wieder auf den eigenen Webspace einspielen.
Ab sofort dürfen als Feldnamen die Bezeichner:
from
to
cc
bcc
multipart
nicht mehr verwendet werden.
Die beiden Scripte besitzen auch eine nochmalige Anpassung an PHP5, da die Variable $REMOTE_ADDR nicht immer definiert sein muss. Ist diese Variable undefiniert, dann wird keine IP-Adresse übermittelt.
Ab sofort dürfen als Feldnamen die Bezeichner:
from
to
cc
bcc
multipart
nicht mehr verwendet werden.
Die beiden Scripte besitzen auch eine nochmalige Anpassung an PHP5, da die Variable $REMOTE_ADDR nicht immer definiert sein muss. Ist diese Variable undefiniert, dann wird keine IP-Adresse übermittelt.
Man sollte zwischen SuperMailer und dem Script unterscheiden, bevor man behauptet \"SUPER-MAILER ist SUPER-UNSICHER!\" . Die Scripte, die es bei mir gibt, haben mir dem Programm selbst überhaupt nichts zu tun, das ist eine KOSTENLOSE Beigabe. Wer mit den Scripten nicht zufrieden ist, darf sich gern eigene Scripte entwickeln, die seiner Meinung nach sicherer sind.
-
- Beiträge: 1
- Registriert: 18.09.2005, 11:13
Wir erhalten Hunderte von Mails, die \"zurückkommen\", obwohl wir sie natürlich nicht versandt haben. Offenbar taugt das Programm nichts, diese Unsicherheit ist nicht akzeptabel!
Beispiele:
-----Ursprüngliche Nachricht-----
Von: yyy[mailto:yyy]
Gesendet: Freitag, 16. September 2005 14:41
An: yyy
Betreff: yyy
Return-Path: <yyy>
X-Original-To: yyy
Delivered-To: yyy
Received: (CEST)
To: yyyy
Subject: yyy
From: yyy
X-Mailer: SuperMailerScript http://www.supermailer.de/
Message-Id: <20050916124104>
Date: Fri, 16 Sep 2005 14:41:04 +0200 (CEST)
X-UIDL: 8`+\"!Jeh!!BFP!!<0e!!
Status: U
hier noch ein Beispiel:
-----Ursprüngliche Nachricht-----
Von: xxxx[mailto:xxx]
Gesendet: Freitag, 16. September 2005 14:41
An: xxx; xxx
Betreff: xxx
Return-Path: <wwwrun@xxx
X-Original-To: xxx
Delivered-To: xx..com
To: abo@xxx
Subject: wzmq@xxx
From: wzmq@xxx
Content-Type: multipart/mixed; boundary=\"===============0797369631==\"
MIME-Version: 1.0
Subject: 178531fa
To: wzmq@xxx
From: wzmq@xxx
Message-Id: <20050916124057>
Date: Fri, 16 Sep 2005 14:40:57 +0200 (CEST)
X-UIDL: VYE\"!jLi!!PXa\"!X2P!!
Status: U
SUPER-MAILER ist SUPER-UNSICHER!
Manfred Plinke
etwaige E-Mail-Adressen vom Admin entfernt.
Beispiele:
-----Ursprüngliche Nachricht-----
Von: yyy[mailto:yyy]
Gesendet: Freitag, 16. September 2005 14:41
An: yyy
Betreff: yyy
Return-Path: <yyy>
X-Original-To: yyy
Delivered-To: yyy
Received: (CEST)
To: yyyy
Subject: yyy
From: yyy
X-Mailer: SuperMailerScript http://www.supermailer.de/
Message-Id: <20050916124104>
Date: Fri, 16 Sep 2005 14:41:04 +0200 (CEST)
X-UIDL: 8`+\"!Jeh!!BFP!!<0e!!
Status: U
hier noch ein Beispiel:
-----Ursprüngliche Nachricht-----
Von: xxxx[mailto:xxx]
Gesendet: Freitag, 16. September 2005 14:41
An: xxx; xxx
Betreff: xxx
Return-Path: <wwwrun@xxx
X-Original-To: xxx
Delivered-To: xx..com
To: abo@xxx
Subject: wzmq@xxx
From: wzmq@xxx
Content-Type: multipart/mixed; boundary=\"===============0797369631==\"
MIME-Version: 1.0
Subject: 178531fa
To: wzmq@xxx
From: wzmq@xxx
Message-Id: <20050916124057>
Date: Fri, 16 Sep 2005 14:40:57 +0200 (CEST)
X-UIDL: VYE\"!jLi!!PXa\"!X2P!!
Status: U
SUPER-MAILER ist SUPER-UNSICHER!
Manfred Plinke
etwaige E-Mail-Adressen vom Admin entfernt.
Zuletzt geändert von Autorenhaus Verlag am 18.09.2005, 15:41, insgesamt 1-mal geändert.
Hallo,
das muss noch etwas rein
nach dem Kommentar
##################################### Spam test
sollte dieser Code noch ins Script
das muss noch etwas rein
nach dem Kommentar
##################################### Spam test
sollte dieser Code noch ins Script
Code: Alles auswählen
if ( !( ($Action == "subscribe") || ($Action == "unsubscribe") || ($Action == "edit") || ($Action == "confirmation") ) ) {
print "Error processing form data";
exit;
}
-
- Beiträge: 4
- Registriert: 27.06.2005, 11:39
hallo,
wir haben in diesem zeitraum das gleiche problem.
ich habe jetzt das skript nach diesen vorgaben geändert und hoffe auf besserung.
leider ist es immer ein katz und mausspiel mit den spammern :-/
hier eine anleitung wie e-mail injection funktioniert.
http://securephp.damonkohler.com/index. ... _Injection
leider hab ich es nicht ganz begriffen, um das selber zu testen.
wie kann man das jetzt testen?! :-/
dank und gruss
marcus
wir haben in diesem zeitraum das gleiche problem.
ich habe jetzt das skript nach diesen vorgaben geändert und hoffe auf besserung.
leider ist es immer ein katz und mausspiel mit den spammern :-/
hier eine anleitung wie e-mail injection funktioniert.
http://securephp.damonkohler.com/index. ... _Injection
leider hab ich es nicht ganz begriffen, um das selber zu testen.
wie kann man das jetzt testen?! :-/
dank und gruss
marcus
Hallo,
wer mag kann sein Script newsletter.php modifizieren, ob das aber wirklich etwas nützt, weiß ich nicht genau. Einfach mal ausprobieren. Folgende Änderungen sind durchzuführen:
Im Script befindet sich die function CheckEMail($email), die sieht so aus:
nach dem schließenden } der Funktion eine neue reinkopieren, diese sieht so aus:
jetzt findet man weiter unten im Script, die Angabe
davor diesen Codenblock einsetzen:
Das Script speichern und auf den Server übertragen.
Im offiziellen Script ist dies bisher nicht enthalten, wäre nett wenn es jemand, der von diesem Problem stark betroffen ist mal nach meinen Vorgaben ändert und es einige Zeit beobachtet. Kommt es nicht mehr zu den Spam-Problemen, dann ist es erstmal eine Lösung, wobei die Formular-Spammer sich natürlich immer wieder was neues ausdenken.
wer mag kann sein Script newsletter.php modifizieren, ob das aber wirklich etwas nützt, weiß ich nicht genau. Einfach mal ausprobieren. Folgende Änderungen sind durchzuführen:
Im Script befindet sich die function CheckEMail($email), die sieht so aus:
Code: Alles auswählen
function CheckEMail($email) {
if (strpos($email, "@") === False)
return 0;
$s = substr($email, strpos($email, "@"), strlen($email));
if (count(explode(".", $s)) < 2)
return 0;
return 1;
}
Code: Alles auswählen
function CheckForSpam($str) {
if ( eregi("from:",$str) || eregi("to:",$str) || eregi("multipart",$str) || eregi("cc:",$str) || eregi("bcc:",$str) )
return 1;
return 0;
}
jetzt findet man weiter unten im Script, die Angabe
Code: Alles auswählen
if ($Action == "subscribe") {
Code: Alles auswählen
##################################### Spam test
$teststring="";
reset ($_GET);
while (list ($key, $val) = each ($_GET)) {
$teststring .= "$key=$val";
}
reset ($_POST);
while (list ($key, $val) = each ($_POST)) {
$teststring .= "$key=$val";
}
if (CheckForSpam($teststring) == 1) {
print "Error processing form data";
exit;
}
#####################################
Im offiziellen Script ist dies bisher nicht enthalten, wäre nett wenn es jemand, der von diesem Problem stark betroffen ist mal nach meinen Vorgaben ändert und es einige Zeit beobachtet. Kommt es nicht mehr zu den Spam-Problemen, dann ist es erstmal eine Lösung, wobei die Formular-Spammer sich natürlich immer wieder was neues ausdenken.
Hallo Mirko
Danke für die schnelle Antwort.
Mir fällt auf, dass ich täglich mit diesen E-Mails belästigt werde. Und jeden Tag werden es mehr... Das filtern von richtigen und falschen Abmeldungen ist so recht mühsam!
Das mit der email-injection habe ich nicht ganz begriffen, scheint bei Deniem Script aber sowieso nicht zu funktionieren, richtig?
Danke und Gruss
Martin
Danke für die schnelle Antwort.
Mir fällt auf, dass ich täglich mit diesen E-Mails belästigt werde. Und jeden Tag werden es mehr... Das filtern von richtigen und falschen Abmeldungen ist so recht mühsam!
Das mit der email-injection habe ich nicht ganz begriffen, scheint bei Deniem Script aber sowieso nicht zu funktionieren, richtig?
Danke und Gruss
Martin
Hallo,
das hat nichts mit SuperMailer zu tun, sondern es gibt Programme die durchsuchen Internetseiten nach Scripten und deren Eingabefeldern. Die Eingabefelder werden mit unsinnigen Müll ausgefüllt und danach wird das Script mit Zusatzfeldern z.B. \"BCC\"-Angabe aufgerufen. Es soll damit getestet werden ob man die Scripte sinnvoll für den Versand von Spam-Mails verwenden kann oder auch nicht. Das Anmelde-Script kann man dafür nicht verwenden, da es nur in der Lage ist eine Bestätigungs-E-Mail zu versenden aber keinen beliebigen Text.
Tun könnte man folgendes, beim Aufruf des Scripts den Referer prüfen zumindest beim Versuch der Anmeldung. Beim Klick auf den Bestätigungs-Link oder bei Abmeldung vom Newsletter darf man diese Prüfung aber wiederum nicht machen. Problem bei der Referer-Prüfung ist aber blockt der Eintrager den Referer d.h. es wird eine falsche Seite übermittelt, funktioniert die Anmeldung nicht = nicht kundenfreundlich.
Wenn ich mir die E-Mail anschaue, dann denke ich aber eher das nur die Angabe \"X-Mailer: SuperMailerScript www.supermailer.de\" übernommen wird, der Rest wird durch den Spammer selbst generiert oder durch einen Wurm/Virus, den irgendwer auf dem PC hat. Sehen kann man das an der Angabe \"Subject: dcc32142\", den Betreff der E-Mail kann man über den Script-Aufruf überhaupt nicht setzen, der ist fest im Script hinterlegt je nach dem ob eine Anmeldung/Bestätigung/Abmeldung erfolgt.
das hat nichts mit SuperMailer zu tun, sondern es gibt Programme die durchsuchen Internetseiten nach Scripten und deren Eingabefeldern. Die Eingabefelder werden mit unsinnigen Müll ausgefüllt und danach wird das Script mit Zusatzfeldern z.B. \"BCC\"-Angabe aufgerufen. Es soll damit getestet werden ob man die Scripte sinnvoll für den Versand von Spam-Mails verwenden kann oder auch nicht. Das Anmelde-Script kann man dafür nicht verwenden, da es nur in der Lage ist eine Bestätigungs-E-Mail zu versenden aber keinen beliebigen Text.
Tun könnte man folgendes, beim Aufruf des Scripts den Referer prüfen zumindest beim Versuch der Anmeldung. Beim Klick auf den Bestätigungs-Link oder bei Abmeldung vom Newsletter darf man diese Prüfung aber wiederum nicht machen. Problem bei der Referer-Prüfung ist aber blockt der Eintrager den Referer d.h. es wird eine falsche Seite übermittelt, funktioniert die Anmeldung nicht = nicht kundenfreundlich.
Wenn ich mir die E-Mail anschaue, dann denke ich aber eher das nur die Angabe \"X-Mailer: SuperMailerScript www.supermailer.de\" übernommen wird, der Rest wird durch den Spammer selbst generiert oder durch einen Wurm/Virus, den irgendwer auf dem PC hat. Sehen kann man das an der Angabe \"Subject: dcc32142\", den Betreff der E-Mail kann man über den Script-Aufruf überhaupt nicht setzen, der ist fest im Script hinterlegt je nach dem ob eine Anmeldung/Bestätigung/Abmeldung erfolgt.
Hallo
Ich hab dieses Problem ebenfalls (etwa seit dem 3.9.2005). Bitte unbedingt eine Lösung finden!
Das Script habe ich bei einem Politiker am laufen und wenn der als Spammer in die Pfanne gehauen und durch sämtliche Medien geschleift wird.
Danke, ich möchte mir das lieber nicht weiter verstellen.
Also, GANZ GROSSE BITTE
Kann jemand einen BUGFIX bereitstellen? Ansonsten müsste ich auf den Einsatz von Supermailer verzichten!
Danke und Gruss
Martin
Ich hab dieses Problem ebenfalls (etwa seit dem 3.9.2005). Bitte unbedingt eine Lösung finden!
Das Script habe ich bei einem Politiker am laufen und wenn der als Spammer in die Pfanne gehauen und durch sämtliche Medien geschleift wird.
Danke, ich möchte mir das lieber nicht weiter verstellen.
Also, GANZ GROSSE BITTE
Kann jemand einen BUGFIX bereitstellen? Ansonsten müsste ich auf den Einsatz von Supermailer verzichten!
Danke und Gruss
Martin
Hallo Mirko,
Deine Aussage \" Also für den Spammer nicht zu gebrauchen.\" stimmt scheinbar nicht wirklich! Ich habe das Problem nun genauer untersucht und es handelt sich doch um Spammer, die das Script missbrauchen. Sie benutzen dazu die sogenannte Email Injection um eigene Daten in einer einzigen Zeile durch das Fremd-Formular, in diesem Fall des Supermailers, zu versenden. Die Zeilenumbrüche werden dabei entsprechend maskiert. Das PHP-Skript will nun die Nachricht versenden und übernimmt an der Stelle, an der es die Formulardaten in den Header eintragen will, die \"feindlichen\" Headerdaten, die aber auch gleich den Text der Email enthalten. Die eigentlichen weiteren Headerdaten und der ursprüngliche Text wird nach der Spam-Mail als einfacher Text angehängt. Dies kann der Angreifer aber auch noch durch weitere Tricks unterbinden, indem er die eigentliche Spam-Mail beispielsweise MIME-codiert.
Das Script newsletter.php enthält keine Routine um dies zu verhindern!?
Möglich wäre dies wenn man z.B. die Captcha-Methode verwenden würde, oder zumindest die maskierten Zeilenumbrüche vor dem Mailversand entsprechend filtert.
Es wäre ratsam sich diesem Problem zu stellen, anstatt es einfach zu ignorieren.
Greetz Daniel
Deine Aussage \" Also für den Spammer nicht zu gebrauchen.\" stimmt scheinbar nicht wirklich! Ich habe das Problem nun genauer untersucht und es handelt sich doch um Spammer, die das Script missbrauchen. Sie benutzen dazu die sogenannte Email Injection um eigene Daten in einer einzigen Zeile durch das Fremd-Formular, in diesem Fall des Supermailers, zu versenden. Die Zeilenumbrüche werden dabei entsprechend maskiert. Das PHP-Skript will nun die Nachricht versenden und übernimmt an der Stelle, an der es die Formulardaten in den Header eintragen will, die \"feindlichen\" Headerdaten, die aber auch gleich den Text der Email enthalten. Die eigentlichen weiteren Headerdaten und der ursprüngliche Text wird nach der Spam-Mail als einfacher Text angehängt. Dies kann der Angreifer aber auch noch durch weitere Tricks unterbinden, indem er die eigentliche Spam-Mail beispielsweise MIME-codiert.
Das Script newsletter.php enthält keine Routine um dies zu verhindern!?
Möglich wäre dies wenn man z.B. die Captcha-Methode verwenden würde, oder zumindest die maskierten Zeilenumbrüche vor dem Mailversand entsprechend filtert.
Es wäre ratsam sich diesem Problem zu stellen, anstatt es einfach zu ignorieren.
Greetz Daniel
Zuletzt geändert von danielb am 14.09.2005, 11:59, insgesamt 1-mal geändert.