Support-Forum Mirko Böer Softwareentwicklungen

Verfasst: **09.12.2005, 19:24**

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.

Verfasst: **09.12.2005, 15:50**

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

Verfasst: **02.12.2005, 09:50**

Danke,

bin seit einigen Tagen auch massiv betroffen und habe mich sehr gefreut, sofort eine Lösung im Forum zu finden.

Schönen Tag noch
O.Petzold

preiswerte-fahrradteile.de

Verfasst: **30.09.2005, 11:41**

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.

Verfasst: **18.09.2005, 15:33**

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.

Verfasst: **18.09.2005, 14:51**

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.

Verfasst: **17.09.2005, 10:30**

Hallo,

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;
}

Verfasst: **17.09.2005, 09:20**

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

Verfasst: **15.09.2005, 12:12**

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:

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;  
}

nach dem schließenden } der Funktion eine neue reinkopieren, diese sieht so aus:

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") {

davor diesen Codenblock einsetzen:

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;
}
#####################################

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.

Verfasst: **14.09.2005, 16:06**

Hallo,

leite mir mal die falsche Anmeldungen weiter aber möglichst mit Header, ich brauche mehrere um das anschauen zu können.

Verfasst: **14.09.2005, 15:37**

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

Verfasst: **14.09.2005, 15:30**

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.

Verfasst: **14.09.2005, 15:11**

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

Verfasst: **11.09.2005, 15:15**

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

Verfasst: **11.09.2005, 15:07**

Naja, zum Spammen nicht zu gebrauchen, stimmt, aber zum senden von Mailbombs durchaus. Es ist nicht sehr angenehm für Nutzer des Supermailer von den Betroffenen als Mailbomber beschuldigt zu werden.

Wie müsste den das Script ergänzt werden, um das zu verhindern?

Greetz Daniel

Support-Forum Mirko Böer Softwareentwicklungen

Missbrauch von newsletter.php