Spamattacke über Kontaktformular, Versand von illegalen Massenmails Einstellungen

[Biene]

Guten Tag

Auf einer Kundenwebseite wurde das Kontaktformular (Version 1.7.3) für den Versand von illegalen Massenmails missbraucht. Der Provider hat den Versand via Formular gesperrt und mir folgende Nachricht zukommen lassen:

Grund für die Sicherheitslücke ist, da Ihr Kontaktformular keine "Injections" abfängt. So ist es möglich Headerinformationen über die Formularfelder Ihres Kontaktformulares mitzusenden. Schreibt man beispielsweise "\nBcc:adresse123@test.tst", so wird die Nachricht zusätzlich an eine weitere Adresse versendet. Auf diese Weise lassen sich durch 1 absenden des Kontaktformulares tausende Spammails versenden.

Die Angreifer verwendeten dabei meist Bcc-Einträge in den Formularfeldern.

Als Ihr Webspaceprovider sind wir dazu verpflichtet Ihren Webaccount so lange zu sperren bis das Problem behoben wurde. Da wir aber nicht Ihre gesamte Website lahm legen möchten haben wir nur das Sendescript des Kontaktformulares gesperrt.

Was muss ich tun, um diese Sicherheitslücke zu beheben?

Herzlichen Dank für Eure Antwort.

[alexander]

Schreibt man beispielsweise "\nBcc:adresse123@test.tst", so wird die Nachricht zusätzlich an eine weitere Adresse versendet

in welchem feld deines kontaktformulars soll das funktionieren?

Grund für die Sicherheitslücke ist, da Ihr Kontaktformular keine "Injections" abfängt. So ist es möglich Headerinformationen über die Formularfelder Ihres Kontaktformulares mitzusenden.

soviel ich weiss verwendet björn im kontaktformular eine klasse die sehr wohl die headerdaten prüft.

Da wir aber nicht Ihre gesamte Website lahm legen möchten haben wir nur das Sendescript des Kontaktformulares gesperrt.

wäre interessant wie sie das gemacht haben. denn der code der die mails versendet steht ja in der datenbank und wird per eval ausgeführt. hätten sie da was gesperrt, dann würde das ganze cms wohl nicht mehr funktionieren.

unabhängig davon aktualisiere mal auf version 2.0 des kontaktformulars und aktivere die captcha funktion und das logging.

[amk]

hab Björn bereits schon auf misstände im kontaktformular hingewiesen ... auch 2.0 ist imho wenig sicher. zumindest bei 1.7.4 konnte man e-mails auch über die url-allein (per GET) versenden. und injection-schutz gibts bei 2.0 glaube auch nicht ... kann mich da aber irren.

[alexander]

auch 2.0 ist imho wenig sicher

wieso?

und injection-schutz gibts bei 2.0 glaube auch nicht ... kann mich da aber irren.

da die mails ja jetzt über die pear mail klasse versendet werden durchlaufen diese die funktion _sanitizeHeaders(&$headers) welche genau das macht.

[amk]

wieso?

weil du bspw. kein formular brauchst zum e-mail-versand ... es wird nicht zw. get & post unterschieden - alles läuft über $_REQUEST - insofern kannst du per url&formularfeld=sowieso&formularabsendeflag=true mails verschicken ... darauf hat mich ein provider hingewiesen und wie ich das im 2.0-code so sehe hat sich diesbezüglich nichts geändert, oder?

bzgl. 2.0 & pear - ok wusst ich nicht ... nutzte hier noch meine präparierte 1.7.4+

[alexander]

weil du bspw. kein formular brauchst zum e-mail-versand ... es wird nicht zw. get & post unterschieden - alles läuft über $_REQUEST - insofern kannst du per url&formularfeld=sowieso&formularabsendeflag=true mails verschicken ... darauf hat mich ein provider hingewiesen und wie ich das im 2.0-code so sehe hat sich diesbezüglich nichts geändert, oder?

mit tools wie curl kannst du auch fast jedes form per post automatisiert absenden. was soll also die methode post an der sicherheit verbessern? ok die url für einen get request zu erzeugen ist vielleicht einfacher aber deswegen nicht sicher oder unsicherer als post. da helfen dann nur dinge wie cpatchas, prüfung des referers oder die methode die der formbuilder verwendet.

[amk]

ok die url für einen get request zu erzeugen ist vielleicht einfacher aber deswegen nicht sicher oder unsicherer als post.

hab nicht gesagt das get oder post sicherer/unsicherer ist. es ist die methode wie das formular funktioniert ... je leichter die manipulationsmöglichkeiten, desto unsicherer ist das formular. und formularfeldinhalte inkl. versand-flag über die url übergeben zu können ist eine art der manipulation. dazu braucht man dann eben auch keine spezielle software, oder viel wissen. das muss nicht sein - ist ganz einfach ein schwachpunkt.

[alexander]

das muss nicht sein - ist ganz einfach ein schwachpunkt.

nein das ist nicht der schwachpunkt. der knackpunkt ist wie die übergebenen daten und der aufruf des form geprüft werden/wird und nicht die methode (post/get) wie die daten übergeben werden. jemand der spam versenden will wird sich nicht davon aufhalten lassen ob das get oder post ist. wenn ich mir meine logs von apache modsecurity ansehe dann laufen fast 90% aller spamversuche per post ab.

[amk]

bei mir & meinem kunden waren es mehrere tage lang 100% über get ... mir hat das gereicht und es wäre eventuell nicht dazu gekommen, wenn es so nicht möglich gewesen wäre. ist doch komplett latte wieviel prozent von dem oder dem ... und wenn es 0.1 % ist, kann dieser kleine prozentsatz mit leichtigkeit vermieden werden - wozu also die diskussion alexander? kannst es ja für unbedeutend halten ... kein problem.

[alexander]

wozu also die diskussion alexander? kannst es ja für unbedeutend halten ... kein problem.

weil einfach nicht die methode get/post das problem ist, sondern man da woanders ansetzen muss um es sicher zu machen als es jetzt schon (in version 2.0) ist. wenn der nächtse spamversuch auf deine kunden dann per post kommt was machst du dann? wie stellst du eigentlich fest, das deine spamversuche nur per get gekommen sind?

[amk]

weil einfach nicht die methode get/post das problem ist, sondern man da woanders ansetzen muss um es sicher zu machen als es jetzt schon (in version 2.0) ist. wenn der nächtse spamversuch auf deine kunden dann per post kommt was machst du dann?

dann fange ich wohl möglich wieder an mit dir zu diskutieren

wie stellst du eigentlich fest, das deine spamversuche nur per get gekommen sind?

ich hab diese geschichte letztlich über die server-log-files bemerkt. NATÜRLICH könnnen nebenher auch noch andere spamversuche vorgekommen sein ... *ts*

[alexander]

server-logs

welche logs genaue? welche tools verwendest du um die postdaten auszuwerten?

[severin Koke]

Hallo zusammen,

sollte nicht die PHP-Konfiguration oder der Apache Strings aus Formularen mit einem Backslash in der Form wie \nbcc:email@email.com,... mit einem weiteren Backslash escapen? Nur so eine Idee, um serverseitig ein weiteres Sicherheitsfeature einzuschalten.

Ist mir bei verschiedenen Providern schon vorgekommen, dass hier einige escapen andere nicht. Keine Ahnung ob dies wirklich Spamattacken verhindern kann.

Just my 2cents.

Viele Grüße,
Severin

[bjoern]

Das ganze Ungemach kommt aus dem PEAR Mailpackage. Die Version, die in der beta2 drinne ist, unterstützt das Prüfen des Headers noch nicht. Es kann einfach gelöst werden, indem das aktuelle PEAR Mailpackage verwendet wird. Ich habe es als Anhang dran gepackt. Bitte in den Ordner "backend\external\pear.php.net\" kopieren. Vorhandene Dateien und Ordner überschreiben.

EDIT: DOWNLOAD ENTFERNT, DA FEHLER NICHT ZUTREFFEND. SIEHE AUCH http://forum.sefrengo.org/index.php?s=&...post&p=6896 WEITER UNTEN

[amk]

welche logs genaue? welche tools verwendest du um die postdaten auszuwerten?

ich habe lediglich auf den hinweis vom providers des kunden reagiert und war über äußerst lange urls im access-log doch sehr überrascht ... ich sage mit keinem wort, dass es letztlich nicht am wichtigsten ist die verarbeitung/validität von daten zu prüfen, anstelle der art der übertragung - alexander!

*bump*

[alexander]

Die Version, die in der beta2 drinne ist, unterstützt das Prüfen des Headers noch nicht.

hm, aber in der Mail.php existiert doch die function _sanitizeHeaders(&$headers) wird die nicht ausgeführt? die dateien haben sogar das gleiche erstellungsdatum und die erstellungszeit. wo ist der unterschied?

und war über äußerst lange urls im access-log doch sehr überrascht ...

tja im apache access log siehts du aber per default keine post daten das ist also nur die halbe miete

Bearbeitungsgrund: small edit

[amk]

tja im apache access log siehts du aber per default keine post daten

sag bloss, is ja 'n ding ... versteh mich doch mal ... oder magst du prinzipiell nicht?

wenn man irgendwie hacken will fängt man doch nicht mit der etwas komplizierteren methode an, oder etwa doch? mir ist doch sowas von klar das es so oder so möglich ist ... 'n einbrecher haut auch kein loch ins dach um ins haus zu kommen, wenn er viel praktischer die tür eintreten / das fenster einschlagen kann ... wenn ich aber die möglichkeit hab tür und fenster unzerstörbar zu machen, dann tue ich es doch auch und der einbrecher muss bspw. übers dach und dies ist mit mehr aufwand verbunden und hält den einen oder anderen ab überhaupt einzudringen. ... so what?! *lol*

[bjoern]

OK, dann liegt es nicht an dem PEAR Package, sondern am Kontaktformular 1.7.4. Hab das im Changelog wohl falsch dokumentiert. Ich hab inzwischen das Kontaktformular in der Version 1.7.4 ausgegraben und musste feststellen, das in dieser version noch gar kein Versand über PEAR genutzt wird.

Daher: Ein Update auf das Kontaktformular 2.0 behebt das Problem, da dort die PEAR Klassen zum Mailversand genutzt werden. Die Sefrengo Version muss mindestens die beta2 sein, weil erst dort ein PEAR Fehler behoben wurde, der in die gleiche Richtung geht (siehe http://pear.php.net/package/Mail/download/1.1.13).

[alexander]

dies ist mit mehr aufwand verbunden und hält den einen oder anderen ab überhaupt einzudringen. ... so what?! *lol*

für einen spammer ist das kein mehraufwand. der ändert einfach den aufruf seines curl befehls von get auf post fertig ... und schon wäre das modul wieder anfällig.

[amk]

right'y'right - nun dann hoffen wir niemand der curl nich kannte, kennt es jetzt und wird ein neuer junger des frühstücksfleischterrorismus ...

... kann jetzt aber erstmal nicht mehr diskutieren ... muss käse und kippen kaufen ... sonst geht die welt noch vor dem 21.12.2012 unter. ich bitte um nachsicht