SI CAPTCHA Anti-Spam Plugin von WordPress wirkungslos

SPAM SPAM SPAM, Egg, Sausage, Bacon and Spam! Immer wenn ich an SPAM denke, muss ich auch gleich an den Scetch “SPAM” von “Monty Python’s Flying Circus” denken. So lustig dieser Scetch auch ist und so sehr ich Monty Python auch mag, so sehr hasse ich es, wenn ich trotz Vorkehrungen immer noch SPAM Kommentare bekomme, deren Druchschlüpfen ich beim ersten Hinsehen fragwürdig finde, wenn ich ohnehin schon die Angabe von Name, Email und den Captcha (= Completely Automated Public Turing Test to Tell Computers and Humans Apart)  Code verpflichtend mache. Zugegeben sind die Spammer heute nicht mehr wehrlos gegen die verzerrten Zahlen-Buchstaben-Salate in den angezeigten Bilddateien, deren Inhalt der echte User in das nächste Eingabefeld abtippen soll, um seine Echtheit als Mensch zu bestätigen. Durch sogenannte “Optical Character Recognition” Verfahren, automatisieren Spammer das Lesen dieser “Codes” aus den Bilddaten um so den Schutz vor Spam-Attacken durch ihre Bots zu umgehen. Es gibt dazu bekannte Programme und Verfahren wie PWNtcha, Anti-Gimpy und aiCaptcha.

Zwei dieser Bots erreichte auch letztens meine Webseite. Zwei unterschiedliche Spammer, deren Mechanismen jedoch die gleichen sind, die mit folgenden Texten aus Lettland und Johannesburg mein Captcha durchbrachen und mich zum Review des Kommentars zwangen (Ich gebe Kommentare nicht sofort frei):

Der zweite Spamer in russischer Sprache, dessen Spam aus Johannesburg abgesetzt wurde (wahrscheinlich ein gehackter Blue Coat SG-S200 Gateway mit u.a. FTP, DOMAIN, HTTP, HTTPS Ports offen und einem Default-SSL-Hersteller-Zertifikat) macht sich nicht die Mühe seine Texte vorher zu übersetzen.

Aber Russland, Lettland, Johannesburg, Schwarzwald, Erzberg…. Was spielt das für eine Rolle wenn man gespamt wird.

Ein wenig stutzig mache es mich zu sehen, dass meine Applikationslogs keinerlei Einträge über diesen Zugriff wiedergegeben haben. Die Server-Logs natürlich schon. Aber demnach musste es sich um einen automatisierten Zugriff handeln, sonst wären die menschlichen Interaktionen im Blog von der Applikation mit protokolliert worden, sprich, ich hätte den Zugriff seitens des Kommentators in den Logs sehen müssen.

Da mir aber die Server-Logs auch nicht mehr sagen, welche IP das war und welche Seiten angefragt wurden sowie welcher Browser dabei zum Einsatz kam, habe ich mir den Quelltext meiner eigenen Seite im Bereich des Kommentarfelds zum Captcha Plugin einmal selbst angeschaut. Das Ergebnis ist verblüffend, dem Sachverhalt entsprechend selbsterklärend und ärgerlich!!! Welche Programmierer programmieren so einen Mist?

Bei einem Captcha Code geht es darum, dass der vorgegebene Wert (Code im Bild) zu dem eingegebenen Wert durch den Benutzer passen muss. Andernfalls sollte die Aktion nicht ausgeführt werden. Das ist der Sinn dahinter, um das automatisierte Zugemüllt werden durch SPAM-Bots zu vermeiden. In meinem Fall bringt aber dieser Schutz in der Form, wie diese Spam Attacke ausgeführt wurde, rein garnichts. Selbst durch einfache, einzelne manuelle Ausführung ist man in der Lage den Pseudo-Schutz dieses Plugins zu umgehen. Übrigens wird das “SI CAPTCHA Anti-Spam” Plugin seit WordPress 4.6.1 standardmässig installiert und ist aktuell ein Stamm-Plugin von WordPress, welches man natürlich einfach deaktiveren und durch bessere Verfahren ersetzen kann.

Die Gründe für meinen zahnlosen Tiger

Formulare werden in HTML innerhalb eines FORM-Tags eingebettet und alle Eingabefelder darin werden mit derim Form-Tag angegeben Aktion (URL) mit der POST Methode an den Webserver binär kodiert übergeben. Das macht insofern sinn, dass man mit der GET Methode alle eingegebenen Daten im Adressfeld des Browsers sichtbar machen würde, dieses Feld nicht ewig lang ist und insbesondere bei Datei-Uploads absolut keinen Sinn macht. Zudem wären sensitive Informationen wie eingegebene Passwörter plötzlich als Key/Value Parameter sichtbar. Auch der vom Benutzer eingegebene (zuvor vom Captcha Bild abgelesene) Code wird mithilfe des Formulars an den Webserver übertragen. Hier besteht auch das Problem: Die “Hidden” Felder. Hidden Felder sind Parameter, die für die Verarbeitung von Formulardaten u.U. wichtig sind, aber nicht zwingend angezeigt werden müssen, oder sollten. In unserem Fall ist es das Fatale, dass die Programmierer dieses Captcha Plugins keine Referenzierung des angezeigten Captcha Codes zu einem eindeutigen Index vorgenommen haben, sondern den Captcha-Code selbst, beim ersten Aufruf der Seite als kodierten Schlüssel in einem “Hidden”Feld dem Formular mitgegeben haben. Der kodierte Schlüssel erzeugt praktisch den Code im Captcha-Bild. Das ist nicht gerade zu Ende gedacht würde ich sagen. Das ist wie das Abschliessen einer Haustür mit anschliessendem Steckenlassen des Schlüssels im Schloss.

(Der Einfachheit halber, lasse ich einpaar unwichtige HTML Abschnitte aus dem <Form> Tag weg)

<form action="https://www.networm.ch/wp-comments-post.php" method="post" id="commentform" class="comment-form" novalidate>
 ......................
 <img id="si_image_com" class="si-captcha" src="https://www.networm.ch/wp-content/plugins/si-captcha-for-wordpress/captcha/securimage_show.php?si_form_id=com&amp;prefix=faFS9OJpltVeCAz7" width="175" height="60" alt="CAPTCHA" title="CAPTCHA" />
 <input id="si_code_com" name="si_code_com" type="hidden"  value="faFS9OJpltVeCAz7" />
 .....................
 <p><input id="captcha_code" name="captcha_code" type="text" size="6"  />
 .............
 </form>

Dieser Prefix ist solange wie die Session gültig und erzeugt solange auch den gleichen Code. Kennt also ein Angreifer die Codierung des Prefix, kennt er den Code selbst. Da der Plugin praktisch open source ist, ist es auch nicht schwer das angewendete Verfahren zu verstehen und daraus ein Script zu bauen, welches solange ein SPAM Formular an den Server übergibt, bis der richtige Code zu einem kodierten Schlüssel gefunden wurde. Da die kodierte Schlüssellänge nicht allzu lang ist, kann man zu den möglichen Kombinationen von Captcha-Codes (4 Stellen, Zahlen und Buchstaben) die entsprechenden Prefix Schlüssel übergeben und somit immer ein “TRUE” erzeugen, also den richtigen Wert übergeben uns somit ein Kommentar absetzen, welcher nicht durch den Captcha Code abgewehrt werden kann. Einige Blogs erlauben es ihren Benutzern mithilfe von Captcha-Codes Kommentare direkt zu posten. Dieser werden vorher nicht durch die Redaktion gesichtet. Gerade solche Seiten werden vermutlich von Spam überhäuft werden.

Fazit:

Ich werde demnächst auf ein aufgabenbasiertes Captcha-Code umsteigen, worin ein Benutzer eine Frage beantworten oder eine einfache Rechenaufgabe lösen muss um den richtigen Wert zu ermitteln. Dieses Verfahren in Verbindung mit Bilddateien erschwert die Arbeit von SPAM-Bots zumindest etwas mehr.

Getestete SI CAPTCHA Anti-Spam Version: 3.0.0.4

(red)