Spaß mit dem Kontaktformular

Oder: Wie Hacker Ihr Kontaktformular dazu verwenden können, Ihren Kundensupport in den Wahnsinn zu treiben

Jeder von uns hat vermutlich schon mal eine Nachricht über ein Kontaktformular auf einer Webseite verschickt. Immerhin sind solche Formulare auf sehr vielen Webseiten zu finden und stellen eine einfache und bequeme Art der Kontaktaufnahme dar.

Allerdings kann man auch als Hacker eine ganze Menge Spaß mit einem Kontaktformular haben, zumindest, wenn dieses nicht geschützt ist. Die möglichen Auswirkungen sind dabei recht vielfältig, von Denial of Service über den Versand von Spamnachrichten an unbeteiligte Dritte, bis hin zur mutwilligen Beschädigung der Domainreputation. Allen gemein ist aber, dass sie für den Angreifer vergleichsweise leicht umzusetzen sind, für das angegriffene Unternehmen aber durchaus ernste Folgen haben können.

In diesem Blog Beitrag unserer „Emails als Waffe“ Serie schauen wir uns deshalb an, was ein Angreifer mit einem Kontaktformular anstellen kann und welche Maßnahmen nötig sind, um dies zu verhindern.

Setup

Anmerkung: Selbstverständlich wurden alle in diesem Beitrag gezeigten Tests bei unseren eigenen Anwendungen vorgenommen. Wer die Funktionalität nachvollziehen will, kann das wie folgt machen:

Lokale WordPress Webseite (aktuelle Version 6.1.1) auf XAMPP
Contact Form 7 Plugin (aktuelle Version)
- Einstellung: skip_mail_on (verhindert, dass tatsächlich Mails gesendet werden)
Contact Form CFDB7 Plugin (zum Anzeigen der Formulare direkt in WordPress)
Python 3.11 (sollte aber mit beliebigen Versionen funktionieren)
Burp Suite (Community Edition ist ausreichend) mit der Copy as Python-Requests Erweiterung

Auf diese Weise lässt sich in kurzer Zeit eine eigene WordPress Instanz aufsetzen, auf der dann getestet werden kann, wie leicht sich ein Kontaktformular automatisieren lässt.

Kontaktformular automatisieren - wenn der Hacker 1000 Mal klingelt

Nachdem wir das Contact Form 7 Plugin installiert und unser erstes Kontaktformular erstellt haben, wird dieses wie folgt auf der Webseite angezeigt.

Soweit so gewöhnlich. Bevor wir nun auf Senden klicken, machen wir aber etwas Ungewöhnliches: Wir starten Burp Suite, aktivieren den Interception Proxy und fangen dann die Nachricht ab.

Wie im Ausschnitt des Screenshots zu sehen, ist unser Input in das Kontaktformular in Rot dargestellt (Zeilen 46, 50, 54 und 58).

Zusätzlich haben wir in Burp Suite die Erweiterung Copy as Python-Requests installiert, sodass wir den abgefangenen Request nun direkt als fertiges kleines Python Programm kopieren können.

Nun müssen wir nur noch ein neues Python File öffnen und das kopierte Programm einfügen.

Wenn wir das Programm dann ausführen, erscheint das Kontaktformular in unserer WordPress Seite.

Damit haben wir den ersten wichtigen Schritt zur Automatisierung geschafft: Wir können das Formular nun über unser Python Programm verschicken und müssen es nicht mehr im Browser manuell absenden.

Soweit also alles gut. Jetzt nehmen wir aber eine kleine Änderung mit großer Auswirkung vor: Der Code zum Verschicken des Formulars wird Teil einer Schleife und somit 1000 Mal ausgeführt.

Statt 1000 könnten wir natürlich auch eine beliebige andere Zahl nehmen, oder statt einer Zahl gleich direkt eine Endlosschleife mit while(True). Aber wir wollen unsere Testseite ja auch nicht überstrapazieren.

Wenn wir dieses Programm ausführen, sehen wir kurz darauf folgendes in der Datenbank.

Zu dem ersten manuell verschickten Formular haben sich 1000 weitere gesellt, die sich über 11 Seiten verteilen. Das ist, besonders wenn man die kurze Ausführungszeit bedenkt, durchaus geeignet denjenigen, der sich diese Formulare ansehen muss, in den Wahnsinn zu treiben.

Wer sich die rechte Spalte (Date) ansieht, wird feststellen, dass etwa 2 Formulare pro Sekunde verschickt wurden, pro Minute also 120. Das ist schon eine ganze Menge, vor allem wenn man bedenkt, dass unser Programm in keinster Weise auf Performance optimiert ist.

Würden wir unser Programm einen ganzen Tag lang ausführen, wäre es eine ziemlich undankbare Aufgabe, aus zigtausend Seiten die Formulare von echten Usern herauszufiltern. Da aber unser automatisiert versendetes Formular immer identisch ist (Name, Email, Betreff und Nachricht sind jeweils gleich) wäre es zumindest theoretisch möglich, wenn auch zeitaufwendig.

Im nächsten Schritt gehen wir als Angreifer daher noch einen Schritt weiter und schauen uns an, wie wir es unserem Zielobjekt nahezu unmöglich machen werden, echte von unechten Formularen zu unterscheiden.

Wie man den Support in den Wahnsinn treibt

Dazu benutzen wir die Python Library Faker, mit deren Hilfe wir zufällige Namen erzeugen können.

Die Titel können (und werden) wir weglassen, indem wir nur die Parameter Firstname und Lastname ausgeben und nicht den kompletten Namen.

Faker bietet uns auch die Möglichkeit, Emailadressen zu erzeugen (fake.emails()), allerdings lediglich mit der @example Domain. Da wir aber möglichst echt wirkende Adressen haben wollen, schreiben wir uns eine eigene kleine Funktion, die aus einem Namen eine Emailadresse erzeugt.

Diese Funktion konvertiert den Namen zunächst in Kleinbuchstaben (aus Max Müller wird max müller), ersetzt dann Umlaute und das scharfe S (aus max müller wird max mueller). Anschließend wird eine Zufallszahl erzeugt, wenn diese 1 ist, werden die Leerzeichen im Namen entfernt (aus max mueller wird maxmueller), ist die Zahl dagegen 2, werden die Leerzeichen durch Bindestriche ersetzt (aus max mueller wird max-mueller).

Anschließend wird eine weitere Zufallszahl zwischen 1 und 10 erzeugt. Wenn diese größer als 7 ist (also 8, 9 und 10 d.h. in ca. einem Drittel der Fälle) wird dem Namen eine Zahl zwischen 10 und 99 angehängt.

Zum Schluss wird noch aus einer Liste von 5 Emailprovidern einer ausgewählt und anschließend können wir die Emailadresse zurückgeben.

Auf diese Weise können aus den Namen sehr unterschiedliche Emailadressen erzeugt werden, sodass sich nur schwer sagen lassen dürfte, ob diese echt sind oder nicht.

Nachdem wir nun Namen und Emailadressen haben, brauchen wir noch den Betreff und die Nachricht. Für diese beiden Parameter definieren wir verschiedene Möglichkeiten in Textfiles.

Zu Testzwecken haben wir uns für recht negative Inhalte entschieden, genauso könnten wir aber auch Fragen zu Produkten stellen, Informationen anfordern o.ä.

Je mehr Detailkenntnisse ein Angreifer zudem hat (Produktnummern, Brancheninfos etc.) und je mehr Zeit er investiert (erstellen möglichst vieler Varianten der Nachrichten und Betreffzeilen), umso einzigartiger (und somit auch schwerer zu entdecken) wird jede einzelne Nachricht.

Produktnummern können z.B. aus dem Shop ausgelesen werden, Bestellnummern sind oftmals fortlaufend, wenn man also eine Bestellung tätigt und die Nummer 1234 drauf steht, kann man mit einer gewissen Sicherheit davon ausgehen, dass 0001 bis 1233 zu bereits getätigten Bestellungen gehören.

Für jede Iteration wird jetzt ein Name generiert, eine passende Emailadresse erstellt und ein Betreff sowie eine Nachricht zufällig ausgewählt.

Damit können wir dann recht zufällige Nachrichten erzeugen.

Zwar passen in Einzelfällen Betreff und Nachricht nicht zusammen (z.B. Betreff „Wo bleibt meine Lieferung“ und Nachricht „Zwei Tage benutzt, schon kaputt“), das ist allerdings nicht weiter dramatisch, um dieses Problem zu lösen, müssten wir nur die Betreffzeilen möglichst generisch formulieren, sodass sie für möglichst viele Nachrichten zutreffen.

Wir könnten auch einen Schritt weiter gehen und beispielsweise verschiedene Input Files für verschiedene Arten von Nachrichten (z.B. Beschwerden, Reklamationen, Fragen etc.) definieren, und dann wieder nach dem Zufallsprinzip auswählen.

Hier stellt für uns als Angreifer also lediglich unsere eigene Fantasie und die Zeit, die wir zu investieren bereit sind, eine mögliche Grenze dar. Wer sich hier hinsetzt und mehrere Stunden lang passende Nachrichten erstellt, der wird mit ziemlicher Sicherheit den Kundensupport in den Wahnsinn treiben können.

Im nächsten Schritt kombinieren wir nun unsere beiden Programmversionen: Die zufällig erzeugten Nachrichten werden nun nicht mehr auf der Konsole ausgegeben, sondern mit dem Kontaktformular verschickt. Dazu müssen lediglich die bisher hartcodierten Werte im Kontaktformular…

…durch unsere Variablen ersetzt werden.

Anschließend wird das Formular in einer Schleife 1000 Mal verschickt, zudem bauen wir dieses Mal eine kleine Zeitmessung ein. Damit wird die Zeit zu Beginn und Ende der Programmausführung gestoppt und dann die Differenz ermittelt.

453 Sekunden entsprechen grob 8 Minuten. In dieser Zeit sollten also unsere tausend Formulare verschickt worden sein.

Wie zu sehen, funktioniert das Ganze relativ gut, lediglich in Einzelfällen scheint zwar ein Betreff vorhanden zu sein, aber keine entsprechende Nachricht. Aufgrund der recht kleinen Menge an möglichen Nachrichten kommt es zudem häufiger zu Wiederholungen bzw. dazu, dass dieselben Nachrichten direkt aufeinander folgen (das ließe sich aber durch eine größere Menge an Nachrichten leicht beheben).

Nichtsdestotrotz: Da die Nachrichten mit einer Geschwindigkeit von 2 Formularen pro Sekunde verschickt werden und ein Mensch vermutlich mindestens 1 bis 2 Sekunden braucht, um ein Formular als falsch zu identifizieren (tendenziell eher deutlich länger), ist das ein Kampf, den die menschliche Seite nicht gewinnen kann.

Zu Erinnerung: 1000 Formulare in 8 Minuten sind ca. 170.000 am Tag (und das wie gesagt ohne Performance Optimierung. Würden wir das Programm zusätzlich auf Performance trimmen, könnte diese Zahl in etwa verzehnfacht werden).

Das stellt das Unternehmen, dessen Datenbank mit diesen Formularen geflutet wird, vor verschiedene Probleme:

Wenn jedes erhaltene Formular manuell geprüft werden soll, ist der bestehende Kundensupport damit massiv überfordert, es müssten also neue Leute eingestellt und eingearbeitet werden
Wenn die Formulare einfach seitenweise gelöscht werden, gehen dabei auch echte Formulare verloren, die von tatsächlichen Kunden verschickt wurden. Das wiederum führt zu einer negativen Auswirkung auf die Kundenbeziehungen, bzw. sogar einem Rückgang von Umsätzen
Früher oder später ergeben sich auch ganz praktische Probleme wie eine volle Datenbank (gerade kleinere Unternehmen nutzen oft Hostingpakete, in denen die Größe der Datenbank beschränkt ist). In diesem Fall könnten keine neuen Formulare mehr angenommen werden, sodass der Zugang für reguläre User eingeschränkt wird (Denial of Service)

Wie man über Ihr Kontaktformular Potenzpillen verkaufen kann

In den beiden obigen Beispielen wird das Kontaktformular dazu benutzt, das Unternehmen anzugreifen, dass die Webseite mit dem Kontaktformular betreibt. Eine bestimmte Konfiguration des Kontaktformulars macht es aber auch möglich, diese Angriffe gegen unbeteiligte Dritte zu richten.

Dies ist dann möglich, wenn direkt nach dem Versand des Formulars eine automatische Nachricht an die angegebene Emailadresse versandt wird. Diese informiert in der Regel entweder über den Eingang der Nachricht oder enthält zusätzlich noch die eingegebene Nachricht selbst (sozusagen als Kopie für die Unterlagen des Users).

Prinzipiell keine schlechte Sache, vor allem wenn sich die Bearbeitung der Anfrage ein paar Tage hinzieht, kann man auf diese Weise nachvollziehen, wann man was geschrieben hat. Unter Umständen ist dies hilfreich wenn es um Fristen (z.B. Umtauschfristen) geht.

Was allerdings auffällt: In dieser Nachricht ist die Original Nachricht und der Original Betreff enthalten. Diese sind durch den Absender kontrollierbar. In solchen Fällen kann ein Hacker also statt einer legitimen Serviceanfrage auch eine Spam Nachricht eintragen.

Und nun wird statt der eigenen Emailadresse eben die Emailadresse von jemand anderem eingetragen. Und dann wird der Vorgang wiederholt. Und wiederholt. Wie das funktioniert, haben wir oben bereits gesehen. Der einzige Unterschied wäre, dass wir jetzt nicht die Nachricht variieren (diese bleibt immer fix) und die Emailadressen nicht künstlich erzeugen, sondern aus einer Liste von echten Emailadressen (kann man sich online leicht kaufen oder über einen Email Harvester selbst erstellen) auslesen.

Jede dieser Emailadressen bekommt dann die Kopie der Nachricht zugestellt, die unsere Spam Botschaft enthält. Das bedeutet, wir können das Kontaktformular (und die dahinterstehende Infrastruktur wie Mailserver etc.) als Relais nutzen um eine Vielzahl von Leuten zu erreichen.

Dieses Vorgehen hat für den Spammer eine Reihe von Vorteilen:

Die Mail kommt von einer legitimen Domain und nicht direkt von einer Spamseite, sie landet also mit sehr viel höherer Wahrscheinlichkeit im Postfach des Users als eine Mail die von der Domain billigepotenzpillen.tv verschickt wird
Der Spammer benötigt keine eigene Infrastruktur, sondern kann die Infrastruktur der Firma nutzen, die das Kontaktformular auf ihrer Webseite anbietet. Dadurch spart sich der Spammer Kosten und bleibt deutlich anonymer als beim Betrieb eigener Infrastruktur
- Gerade bei großen Firmen kann zudem davon ausgegangen werden, dass die vorhandene Infrastruktur zum Versand von Emails recht leistungsfähig ist, möglicherweise deutlich leistungsfähiger als das, was der Spammer „privat“ nutzen könnte

Die Vorteile die der Spammer hat, führen allerdings auch direkt zu negativen Konsequenzen für die Firma deren Kontaktformular auf diese Weise missbraucht wird:

Da viele User die erhaltenen Mails als Spam einstufen werden (zurecht!) leidet die Domainreputation schon nach kurzer Zeit. Das bedeutet, selbst legitime Mails die von dieser Domain dann verschickt werden, werden mit hoher Wahrscheinlichkeit im Spam Ordner landen. Unter Umständen kann eine Domain dadurch sogar soweit verbrannt werden, dass sie überhaupt nicht mehr sinnvoll nutzbar ist. Die Fähigkeit einer Firma mit ihren Kunden zu kommunizieren kann dadurch massiv gestört werden
Dass der Spammer die Infrastruktur kostenlos nutzt, bedeutet nicht, dass dafür keine Kosten entstehen. Gerade Cloud Services werden in der Regel nach Verbrauch abgerechnet, der zusätzliche Versand von 2 Millionen Mails pro Tag schlägt sich also sehr schnell auf der Rechnung nieder

Aus diesem Grund ist die Funktion, eine Kopie der Kontaktformular Nachricht zu versenden, durchaus mit Vorsicht zu genießen. Falls man sie für nötig erachtet, sollte man zumindest soweit wie möglich auf Inhalte verzichten, die durch den User manipulierbar sind. Dies wäre etwa in folgender Nachricht der Fall:

Diese Nachricht informiert lediglich mit einem Standardbetreff und einem Standardtext darüber, dass die Nachricht angekommen ist und bald mit einer Rückmeldung zu rechnen ist. Eine solche Mail kann daher nicht zu Spam Zwecken missbraucht werden.

Email Bombing

Die oben aufgeführte Nachricht kann zwar nicht mehr genutzt werden, um Spam Nachrichten zu verschicken, dennoch lässt sie sich durch einen Angreifer missbräuchlich verwenden.

In diesem Fall können wir einfach unser DoS Programm aus dem ersten Abschnitt erneut verwenden, nur haben wir dieses Mal im abgefangenen Request die Emailadresse unseres Ziels eingetragen (im Screenshot nicht zu sehen weil die Zeile zu lang ist).

Wird das Programm ausgeführt, dann tauchen nicht nur tausend neue Formulare in der Datenbank der Webseite auf, sondern es werden auch tausend automatische Emails an „unsere“ Mailadresse versandt (zumindest wenn kein interner Filter vorhanden ist, siehe dazu die Gegenmaßnahmen).

Damit können über eine Firmenwebseite die Emailkonten von unbeteiligten Dritten mit Mails geflutet werden. Insbesondere bei Freemail Accounts ist der Speicherplatz in der Regel auf 500MB bis 1GB begrenzt, sodass nach einiger Zeit keine neuen Mails mehr von diesem Account empfangen werden können, da das Postfach voll ist.

Auch wenn kommerzielle Emailaccounts mit einem flexibel erweiterbaren Speicher genutzt werden, kann dieser Angriff recht frustrierend für das Opfer sein (wobei sich die Wut dann übrigens gegen die Firma richtet, die das Kontaktformular anbietet, da der Empfänger ja nicht wissen kann, dass der Versand böswillig getriggert wurde).

Wie man die Reputation einer Domain zerstört

Eine kleine Variation des DoS Programms führt zu einem völlig neuen Angriffsvektor: Die Zerstörung der Domainreputation. Dazu werden die Mails jetzt nicht mehr an eine einzige Emailadresse versandt, sondern an jeweils unterschiedliche Adressen, die nicht existieren, aber scheinbar einem realen Provider gehören. Dazu müssen zunächst zufällige Mails mit einer realen Providerendung erzeugt werden.

Die entstandenen Mails bestehen aus 4 bis 20 zufälligen Zeichen vor dem @ Symbol und einer zufällig gewählten Providerendung.

Für jede Iteration der Schleife kann nun eine zufällige Mail erzeugt und in das Kontaktformular eingetragen werden.

Was dann passiert ist (vereinfacht) folgendes:

Ihr Mailserver sieht, dass im Kontaktformular die Emailadresse fsjdpqklsfds@gmail.com eingetragen ist
Er schickt deshalb die Email mit der Kopie des Kontaktformulars an den Gmail Mailserver, damit dieser sie zustellen kann
Der Gmail Mailserver nimmt die Nachricht zunächst auch an, immerhin ist sie ja für ein Gmail Konto bestimmt
Der Gmail Server sucht dann das Konto fsjdpqklsfds, findet es aber nicht
Der Gmail Server lehnt die Mail dann nachträglich ab und teil ihrem Mailserver mit, dass die Email nicht zustellbar ist
Die Email ist damit gebounct (weil die Meldung zurück an Ihren Server kommt)

Passiert das ab und zu, ist das nicht weiter schlimm. Passiert es aber tausende Male am Tag, dann erhöht sich damit die Bounce Rate Ihrer Domain. Das hat zwei entscheidende Folgen:

Erstens werden Emails von Domains mit einer hohen Bounce Rate mit einer sehr viel höheren Wahrscheinlichkeit als Spam eingestuft.

Zweitens stellen Drittanbieter unter Umständen den Emailversand komplett ein, wenn die Bounce Rate ein bestimmtes Level erreicht hat.

Amazon behält sich beispielsweise vor, den Versand von Emails zu pausieren, wenn die Bounce Rate bei über 10% liegt. In einem solchen Fall können Sie also, zumindest temporär, gar keine Emails mehr verschicken.

Je nachdem wie wichtig die Kommunikation per Mail für Ihr Geschäftsmodell ist, kann das drastische Auswirkungen haben.

Was kann man damit machen?

An dieser Stelle haben wir gesehen, wie wir das Kontaktformular auf verschiedene Weisen automatisieren können. Nun schauen wir uns als nächstes an, welche Auswirkungen sich daraus für eine Firma ergeben können.

Frustration

Stellen Sie sich vor, Sie sitzen acht Stunden vor Ihrem Laptop und müssen die immer gleiche Aufgabe durchführen:

Nachrichten markieren
Nachrichten löschen
Nachrichten markieren
Nachrichten löschen
…

Und am Ende des Tages sind dennoch mehr Nachrichten vorhanden als zu Beginn. Wie schnell wären Sie frustriert? Vermutlich ziemlich schnell. Das wirkt sich früher oder später vermutlich auch auf ihre Kollegen und die Kunden aus.

Verlust von Aufträgen / Beeinträchtigung der Kundenzufriedenheit

Wenn jeden Tag 200.000 neue Formulare in der Datenbank auftauchen, ist es extrem schwierig, die 20 Stück herauszufiltern, die zu echten Kunden gehören.

Das führt zwangsweise dazu, dass Kundenanfragen übersehen werden. Dies wiederum resultiert in nicht erteilten Aufträgen (wer möchte schon mit jemandem zusammenarbeiten, dem offensichtlich nichts an einer Zusammenarbeit gelegen ist?), schlechten Bewertungen (wer nach Tagen noch keine Antwort auf seine Anfrage erhalten hat, wird kaum den top Kundenservice loben) und kaputten Geschäftsbeziehungen (zu den meisten Anbietern gibt es Alternativen, warum also bei jemandem kaufen, bei dem man nicht zufrieden ist?).

Anfangs mag es dabei vielleicht nur um kleinere Beträge gehen. Mit der Zeit potenziert sich das Problem aufgrund schlechter Bewertungen, Mund zu Mund Propaganda etc. aber immer weiter, sodass es irgendwann zu empfindlichen Einschnitten kommt.

Und eine einmal zerstörte Reputation wieder neu aufzubauen, ist dann ein sehr aufwendiger und langwieriger Prozess, für dessen Gelingen es am Ende doch keine Garantie gibt.

DoS: Füllen von Datenbanken und Postfächern

Jedes einzelne Kontaktformular nimmt zwar nur vergleichsweise wenig Speicherplatz ein, wenn diese aber derart massenhaft verschickt werden, dann ergibt sich daraus letzten Endes doch eine beträchtliche Wirkung, nämlich eine überfüllte Datenbank.

Ist die Datenbank voll, dann können reguläre User das Kontaktformular nicht mehr nutzen, was möglicherweise zu Verstimmungen führt. Zudem sind auch andere Teile der Anwendung, die Speicherplatz benötigen, möglicherweise von der Funktionseinschränkung betroffen. Im Extremfall kann der Angreifer auf diese Weise also die Verfügbarkeit der gesamten Webseite beeinträchtigen (Denial of Service).

Anmerkung: Wenn es um das Auffüllen von Speicherplatz geht, dann macht es als Angreifer natürlich Sinn, möglichst umfangreiche Formulare zu verschicken, da diese mehr Speicherplatz wegnehmen. Für diesen Fall muss nicht zwangsläufig ein sinnvoller Inhalt im Formular stehen, es reicht, wenn möglichst viel Text vorhanden ist.

Auch dafür können wir die Faker Library nutzen, die eine Funktion zur Erzeugung von Text bietet.

Diese rufen wir 100 Mal auf und fügen die so erzeugen Sätzen zusammen, was Output in der folgenden Art erzeugt:

Macht keinen Sinn, nimmt aber mehr Platz weg als unser normales Formular. Wenn man jetzt noch bedenkt, dass bei vielen kleineren Hostingpaketen die Größe von Datenbanken beschränkt ist, dann wird es durchaus möglich, diese mit solchen Nonsens Formularen aufzufüllen, sodass rechtmäßige User die Funktion nicht mehr nutzen können.

Noch einfacher wird das Ganze übrigens, wenn das Kontaktformular auch eine Möglichkeit zum Dateiupload bietet. Ist dies der Fall, dann können mit jedem Formular Dateien hochgeladen werden, die mehrere Megabyte groß sind, sodass sich die Datenbank bei einem längeren Betrieb des Programms recht schnell auffüllen lässt.

Domain Reputation

Eine Zerstörung Ihrer Domain Reputation ist tendenziell vor allem für Konkurrenzunternehmen interessant, da Ihnen auf diese Weise auf längere Sicht geschäftliche Einbußen drohen.

Zudem ist ein Neuaufbau der Reputation recht aufwendig, zumal es auch keine Garantie dafür gibt, dass die Emailprovider darauf reagieren werden.

So könnten Sie zwar gegenüber Provider ABC versichern, dass die Millionen an nicht zustellbaren Mails von Ihrer Domain auf einen Angreifer zurückzuführen sind und Sie das Problem mittlerweile behoben haben, ob der Provider Ihre Domain dann allerdings wieder von seiner schwarzen Liste entfernt, liegt allein an ihm und kann von Ihnen kaum kontrolliert werden.

Unter Umständen haben Sie also auch noch Monate oder Jahre später Probleme damit, Kunden zu erreichen die ein Emailkonto bei einem bestimmten Provider haben. Zwar könnten Sie darauf bei der Registrierung hinweisen, doch die Anzahl von Kunden die Ihretwegen den Emailprovider wechselt, dürfte doch eher gering sein.

Kostentreiber

Während Unternehmen früher ihre IT-Infrastruktur häufig selbst betrieben haben, wird heute immer mehr zu Cloud Anbietern ausgelagert. Das hat durchaus Vorteile, etwa dass keine hohen Anschaffungskosten entstehen, oder dass nur die tatsächlich genutzte Leistung abgerechnet werden muss, oder dass die Infrastruktur bei kurzzeitigen Nachfragespitzen flexibel skaliert werden kann.

Allerdings ergeben sich dadurch unter Umständen auch Möglichkeiten für Angreifer (z.B. ein Konkurrenzunternehmen) diese Kosten zu beeinflussen.

Bei AWS fallen pro 1000 Mails 10 Cent an Kosten an:

Wir erinnern uns, dass unser Skript in der Basisvariante ca. 170.000 Formulare pro Tag verschicken kann. Also immerhin 17 Euro pro Tag an zusätzlichen Kosten verursacht (bzw. 510 Euro im Monat oder 6120 Euro im Jahr). Für ein kleineres Unternehmen kann dies schon eine nicht unerhebliche Belastung darstellen.

Und wie gesagt, das bezieht sich nur auf die Basisvariante des Skripts, die ohne Performance Optimierung auf einem einzigen Rechner ausgeführt wird. Würde das Skript auf eine schnelle Ausführungszeit hin optimiert und dann noch gleichzeitig auf verschiedenen Rechnern ausgeführt, so würden schnell sechsstellige Beträge im Jahr an zusätzlichen Kosten auflaufen.

Wer würde so etwas machen?

Nachdem wir nun gesehen haben, WAS man alles machen kann, kann man sich natürlich auch die Frage stellen, WER so etwas denn machen würde. Die Antworten darauf sind recht vielfältig:

Leute die neugierig sind: Manchmal steckt nicht mal unbedingt eine böse Absicht dahinter, sondern eher die Lust, etwas Neues ausprobieren, mit etwas zu spielen, so lange zu testen bis es funktioniert. Dass es dann eben zufällig Ihr Kontaktformular trifft, ist einfach blöd gelaufen (auch wenn das natürlich keine Entschuldigung ist!).
Verärgerte Kunden: Wer mit Ihrem Service, Ihrem Produkt an sich oder dem Verhalten eines konkreten Mitarbeiters unzufrieden ist, für den stellt eine Automatisierung des Kontaktformulars eine recht einfach Art der Revanche dar
Unzufriedene Mitarbeiter: Wer bei einer Beförderung übergangen wurde, mit seinen Kollegen nicht klar kommt und vielleicht innerlich schon gekündigt hat, für den mag es durchaus eine Option sein, dem Arbeitgeber auf diese Weise noch eine reinzuwürgen
Kriminelle: Wenn Nachrichten echter Kunden in einer Flut falscher Formulare untergehen, sinkt bald die Kundenzufriedenheit. Man könnte in diesem Fall natürlich eine Vielzahl neuer Supportmitarbeiter einstellen (was teuer ist) oder man bezahlt eine Art Schutzgeld an den Kriminellen, damit er die Angriffe einstellt. Da es wohl wenig Möglichkeiten gibt, einfacher Geld zu verdienen, sind auch kriminelle Hacker mit monetären Motiven an solchen Automatisierungen sehr interessiert
Die Konkurrenz: Wenn Ihre Geschäfte schlechter laufen, profitiert davon vermutlich die Konkurrenz. Das kann durchaus eine Verlockung darstellen, dem Ganzen ein wenig nachzuhelfen

Glücklicherweise ist man den Launen dieser Personen aber nicht vollkommen schutzlos ausgeliefert, denn es gibt auch verschiedene Gegenmaßnahmen, mit denen man sein Kontaktformular besser absichern kann.

Gegenmaßnahmen

Captchas - und ihre Schwächen

An dieser Stelle wird hoffentlich jeder zustimmen, dass es keine gute Idee ist, wenn ein Kontaktformular mit einem simplen Programm automatisiert werden kann. Diese Automatisierung zu verhindern, sollte also die erste und wichtigste Gegenmaßnahme sein. Glücklicherweise gibt es dafür auch eine sehr schöne Lösung, nämlich Captchas. Die Frage ist nur, welche Art von Captcha?

Rechenaufgaben

Eine der einfachsten Captcha Arten sind kleine Rechenaufgaben, die vor dem Versand des Formulars gelöst werden müssen (z.B. 2 + 4 oder 15 – 3).

Das funktioniert insofern, dass unser ursprüngliches Programm jetzt erst einmal nicht mehr funktionsfähig wäre. Allerdings ist das Lösen von Rechenaufgaben etwas, das Computer deutlich besser beherrschen als Menschen, sodass die Mauer, die hier zum Schutz errichtet wird, nicht sonderlich hoch ist.

Diese Art von Captcha kann wie folgt umgangen werden:

In jeder Iteration der Schleife muss die Seite mit dem Kontaktformular aufgerufen werden
Aus dem HTML Code der Response wird die Rechenaufgabe ausgelesen, sowie der Wert, der diese Session identifiziert (entweder als Hidden Value im HTML oder in Form eines Cookies)
Die Rechenaufgabe wird durch das Programm gelöst (dafür müssen die in Textform vorliegenden Zahlen in einen Zahlendatentyp wie Int oder Float konvertiert werden)
Zusätzlich zur Nachricht des Kontaktformulars muss die Lösung der Rechenaufgabe und der Session Identifier an den Post Request angefügt werden

Somit sind zwar einige Schritte mehr nötig und auch die Performance wird in diesem Fall schlechter ausfallen, grundsätzlich kann diese Art von Captcha aber recht leicht umgangen werden und bietet deshalb keinen ausreichenden Schutz vor Automatisierungsversuchen.

Buchstaben/Wörter erkennen

Ebenfalls recht gebräuchlich sind Captchas, bei denen Buchstaben und Zahlen aus einem Bild korrekt erkannt werden müssen. Teilweise handelt es sich dabei um echte Wörter, teilweise auch um zufällige Kombinationen wie im folgenden Screenshot zu sehen:

Das ist grundsätzlich schon einmal sehr viel schwerer zu automatisieren als simple Rechenaufgaben (allerdings nicht komplett unmöglich, das Zauberwort hierfür heißt OCR (Optical Character Recognition)).

Das Problem hierbei ist eher die Usability. So sind Captchas dieser Art auch durchaus dazu geeignet, echte Menschen verrückt zu machen. Beispielsweise dann, wann Zeichen sehr schwer lesbar sind oder unklar ist, ob Groß- und Kleinschreibung beachtet werden soll oder nicht.

Im obigen Screenshots sind die ersten beiden Zeichen zwar recht eindeutig als „Z“ zu erkennen, allerdings sind sie auch unterschiedlich dargestellt (mit und ohne Serifen). Unklar ist nun, ob es sich dabei einfach um unterschiedliche Darstellungen handelt, oder ob eine davon als klein- die andere als großgeschriebene Version erkannt werden soll.

Dies kann leicht dazu führen, dass mehrere Versuche nötig sind, bis das Captcha erkannt wird, was wiederum, je nach User, zu einer deutlich gesteigerten Frustration führt. Möglicherweise auch zum Abbrechen des Vorgangs.

Hier steht man als Webseitenbetreiber also vor einer Gratwanderung: Sind die Zeichen zu leicht zu erkennen, öffnet man unter Umständen auch wieder der Automatisierung Tür und Tor. Sind sie dagegen zu kryptisch, läuft man Gefahr, auch reguläre User zu verprellen.

Diese Art von Captcha ist also sicherer als reine Rechenaufgaben, aufgrund potenzieller Usability Probleme aber nicht ideal.

Bilder zuordnen

Ebenfalls recht gebräuchlich und auch immer weiter verbreitet, ist die Google Recaptcha Lösung bei der entweder in einem Bild bestimmte Elemente gefunden werden müssen (z.B. die Ampel in einer Straßenansicht) oder aus einer Bilder Auswahl diejenigen ausgewählt werden sollen, die einen bestimmten Inhalt haben (z.B. neun Bilder zur Auswahl, alle die einen Bus zeigen, müssen ausgewählt werden).

Das ist eine Aufgabe, die einen Menschen in der Regel nicht vor Probleme stellt (und entsprechend keine negativen Auswirkungen auf die Usability hat), für einen Computer aber nicht so leicht zu erledigen ist (und daher geeignet ist, die Automatisierung zu verhindern).

Dennoch kann auch dieses Captcha umgangen werden und zwar, man glaub es kaum, indem man die Captchas einfach von Menschen lösen lässt.

Etwa durch einen Service wie 2captcha.com oder anti-captcha.com:

Dies sind nur zwei Anbieter, mittels Google lassen sich noch diverse weitere finden. Diese sind mal mehr, mal weniger günstig, funktionieren im Grunde aber immer gleich: Das Captcha wird hochgeladen, durch einen menschlichen Arbeiter gelöst und anschließend dem Kunden mitgeteilt.

Nachteil dabei ist als User natürlich, dass Kosten entstehen. Wer als Angreifer also nur mal eben seinen Kumpel im Kundenservice ärgern will, dem ist das vielleicht ein paar Euro wert, die beim Lösen von ein paar tausend Captchas entstehen. Wer aber als Spammer zwei Millionen Mails verschicken will, der wird sicher anfangen zu rechnen und dann vermutlich zu dem Schluss kommen, dass es ab einem bestimmten Punkt wirtschaftlicher ist, einen eigenen Mail Server zu betreiben als für das Lösen von Captchas zu bezahlen.

Auch die Bilder Captchas sind also nicht fehlerfrei. Da sie aber recht userfreundlich sind und für einen Angreifer zumindest eine gewisse finanzielle Hürde darstellen, sind sie momentan aber die geeignetste Captcha Variante. Zumal ein Captcha im Idealfall ja auch nicht nur die einzige Sicherheitsmaßnahme ist, sondern nur ein Baustein von vielen.

Filter

Um zu verhindern, dass eine einzelne Emailadresse mit Nachrichten überschwemmt wird, sollte intern festgelegt werden, dass z.B. nur höchstens eine Nachricht pro Tag an eine Kundenemailadresse versandt werden darf. Zusätzliche Nachrichten müssen dann ausgefiltert werden.

Dadurch wird dann verhindert, dass ein Angreifer die Funktion der automatischen Kopie missbraucht und immer dieselbe Emailadresse in das Formular einträgt, sodass diese mit Nachrichten geflutet wird.

Aufgrund des Filters wird nur die erste Nachricht zugestellt (für den Fall, dass es sich um eine legitime Anfrage handelt), alle anderen aber nicht mehr.

Limits festlegen

Um aus dem Ruder laufende Kosten für Cloud Dienste zu verhindern, macht es Sinn, Limits festzulegen. Entweder in Form der jeweiligen Aktion (z.B. nur X Mails sollen pro Tag verschickt werden) oder in Form eines Budgets (z.B. nur X Euro sollen pro Tag oder Monat höchstens verbraucht werden).

Diese Limits müssen so festgelegt werden, dass sie im Normalbetrieb nicht erreicht werden und auch kurzfristige Nachfragespitzen abfangen können (z.B. wenn unerwartet ein Prominenter etwas positives über die Firma postet und sich dann am folgenden Tag mehrere tausend neue Newsletter Anmeldungen ergeben).

Zudem sollte man sich benachrichtigen lassen, wenn ein bestimmter Prozentsatz des Limits erreicht ist (z.B. wenn 80% der Kapazität verbraucht wurde). In diesem Fall kann dann geprüft werden, ob der Verbrauch auf organische Art und Weise zustande gekommen ist, oder ob es sich möglicherweise um einen laufenden Angriff handelt.

Ist letzteres der Fall, können Maßnahmen ergriffen werden, beispielsweise die temporäre Deaktivierung des Kontaktformulars oder die Beschränkung des Emailversands auf verifizierte Bestandskunden.

Bounce Rate im Auge behalten

Angriffe auf die Domain Reputation (z.B. durch eine Steigerung der Bounce Rate) sind nicht immer leicht zu bemerken, wirken unter Umständen aber noch über Monate oder sogar Jahre hinaus nach, was sie sehr tückisch macht.

Die Bounce Rate ergibt sich aus der Anzahl der gebouncten Emails geteilt durch die Anzahl insgesamt verschickter Emails (wer das Ergebnis als Prozentzahl will, multipliziert anschließend noch mit 100). Solange die Bounce Rate bei ca. 1% bleibt, sollte alles in Ordnung sein. Eine Bounce Rate von 0% ist praktisch nicht möglich, da selbst ohne böse Absichten immer mal wieder falsche Emailadressen eingegeben werden (z.B. Tippfehler) oder Emailadressen zwischenzeitlich gelöscht werden.

Steigt die Bounce Rate auf einen mittleren einstelligen Wert an, sollte man anfangen sich Sorgen zu machen und dieses Verhalten definitiv näher untersuchen. Überschreitet die Bounce Rate einen Wert von 10%, muss man damit rechnen, dass es zu schwerwiegenderen Problemen kommt. AWS behält sich in diesem Fall beispielsweise das Aussetzen des Emailversands vor, was zu erheblichen Einschränkungen führen kann, insbesondere für Unternehmen, die sich stark auf Email Kommunikation verlassen oder in Phasen, in denen diese Art der Kommunikation besonders wichtig ist (z.B. um Kunden auf Angebote im Rahmen von Sonderaktionen hinzuweisen).

Insbesondere dann, wenn ihr Emailserver viele Fehlermeldungen erhält (was je nach Konfiguration gegebenenfalls in den Logfiles geprüft werden muss), sollten Sie sich die aktuelle Bounce Rate anschauen und prüfen, ob momentan ein entsprechender Angriff gegen Ihre Domain Reputation läuft.

Keine Kopie

Wie wir oben gesehen haben, kommen mit der Kopie Funktion (das verschickte Formular wird dem User direkt als Email zugeschickt) noch einige zusätzliche Risiken hinzu. Auch wenn eine solche Funktion also praktisch sein mag, aus Sicht der IT-Sicherheit sollte man doch lieber darauf verzichten.

Sollte ein Verzicht nicht möglich sein, dann sollten die automatisierten Nachrichten zumindest keine Bestandteile enthalten, die durch den User kontrolliert werden können. Das bedeutet: Statt die verschickte Nachricht als Kopie beizufügen, sollte lediglich in einem Standardtext darüber informiert werden, dass die Nachricht erfolgreich gesendet wurde und sich nun in Bearbeitung befindet.

Kein Kontaktformular

Auch wenn es im ersten Moment radikal wirken kann, sollte man hinterfragen, ob man überhaupt ein Kontaktformular benötigt.

Zwar stellt ein solches eine einfache Möglichkeit zur Kontaktaufnahme für Kunden (oder potenzielle Kunden) dar, doch birgt es, wie in diesem Beitrag gezeigt, auch nicht unerhebliche Risiken.

Alternativen zu einem Kontaktformular könnten beispielsweise sein:

Die Angabe einer Support- oder Kontakt Emailadresse an die man sich bei Fragen wenden kann. Auch das ist zwar nicht ganz ideal, allerdings weniger unsicher als ein Kontaktformular
Ein FAQ, in dem die häufigsten Kundenfragen bereits beantwortet werden, kann das Bedürfnis nach einer Kontaktaufnahme reduzieren
Ein Chatbot kann, insbesondere wenn man die aktuellen Entwicklungen wie ChatGPT mit einbezieht, dazu genutzt werden, zumindest einfachere Kundenfragen zu beantworten bzw. Probleme zu lösen

Klar ist aber auch, dass vermutlich nicht jedes Unternehmen sein Kontaktformular einfach abschaffen kann oder will. Wenn ein Kontaktformular genutzt werden soll, muss aber zumindest darauf geachtet werden, dass es bestmöglich abgesichert ist, z.B. durch Captchas und interne Limits.

Fazit

Kontaktformulare sind aus dem Internet nur schwer wegzudenken. Ihre Benutzung ist sowohl für User als auch Webseitenbetreiber einfach und bequem. Allerdings kann ein nicht abgesichertes Kontaktformular auch einem Angreifer diverse Möglichkeiten bieten, sich daran auszutoben.

Manche der oben beschriebenen und gezeigten Angriffe sind hauptsächlich nervig (z.B. der Versand von tausenden exakt gleichen Formularen) andere können dagegen den geschäftlichen Erfolg eines Unternehmens auf Jahre hinaus negativ beeinflussen (z.B. die Beeinträchtigung der Domain Reputation).

Wer ein Kontaktformular auf seiner Webseite zur Verfügung stellt, sollte sich also in jedem Fall auch Gedanken darüber machen, wie dieses abgesichert werden kann.