INS-ecommerce

Security by Obscurity II - Math Comment Spam Protection Plugin

Anhand von StudiVZ hatte ich vor einigen Tagen ja mal den Punkt Security by Obscurity beleuchtet. Zusammengefasst: Für Web-Anwendungen ist so etwas eine schlechte Idee.

Nachdem Robert heute freudig seinen neuen Schutz gegen Kommentarspam vorgestellt hat, bin ich zufällig auf ein anderes Beispiel für Security by Obscurity gestossen. Das ist deswegen bemerkenswert, weil es jeder Anhand der Quelltexte selber nachvollziehen kann.

Robert benutzt (wie viele Andere auch) ein Wordpress-Plugin (Version 2.0 ist Basis dieser Beobachtungen) bei dem bei der Absendung eines Kommentars eine kleine Rechenaufgabe gelöst werden muss. Er möchte damit automatisch das Web durchsuchende Programme, die Spam in Kommentare schreiben, ausfiltern. Vorerst mit gutem Erfolg.

Wie funktioniert das Plugin?

Bei der Anzeige des Kommentarformulars wird das bereichts errechnete Ergebnis der Rechenaufgabe verschlüsselt in einem unsichtbarem Feld übergeben. Schickt der User nun das Eingabeformular ab, wird das vom User eingegebene Ergebnis verschlüsselt und mit dem verschlüsseltem Wert in dem unsichtbaren Feld verglichen.

Die Blog-Software bekommt also Formulardaten zurück, bei denen in einem Feld das unverschlüsselte Ergebnis (vom User eingegeben) und in einem anderem Feld (vorher berechnet) das verschlüsselte Ergebnis steht, und nur aufgrund dieser beiden Felder wird auf einen "erlaubten" Kommentar entschieden.

Traue keinem User-Input!

Da Eingabefelder von Formularen beliebig verändert und manipuliert werden können, ist es meist keine gute Idee kritische Entscheidungen oder Berechtigungen nur auf zurückgelieferte Eingabefelder zu stützen, wie in diesem Fall.

Dazu muss mindestens sichergestellt werden, dass das "verschlüsselte" Eingabefeld kryptografisch so abgesichert ist, dass es von einem Angreifer nicht gefälscht werden kann.

Das kryptografische Verfahren

Schauen wir uns also das Verfahren zum Erzeugen des "verschlüsselten" Wertes an. Also das "geheime Verfahren", welches bei einem Security-by-Obscurity Prinzip nie veröffentlich werden darf. Und (weil es ein PHP-Plugin ist) im Quelltext beim Autor heruntergeladen werden kann.

Das "verschlüsselte Ergebnis" besteht aus einem MD5-Hash, bei dem die Reihenfolge umgekehrt wurde (Reihenfolge umkehren erhöht die Sicherheit nicht!) und aus dem nur verschiedene feste Teilbereiche benutzt werden.


Der Haustürschlüssel liegt unter der Fussmatte

Woraus wird der MD5-Hash berechnet? Aus
  • dem Ergebnis der Rechenaufgabe
  • dem aktuellem Datum samt Uhrzeit des Servers
  • dem Blognamen/Titel des Blogs


Datum/Uhrzeit des Blogs lassen sich relativ leicht (zur Not durch probieren) herausfinden, und auch der Blogname findet sich je nach Wordpress-Template an verschiedenen automatisch abprüfbaren Stellen des Blogs.

Den Schutz aushebeln

Mit diesen Informationen kann sich also ein Angreifer zu einer beliebigen von ihm ausgedachten Ergebnis-Zahl das verschlüsselte Eingabefeld generieren und so die Rechenaufgaben-Überprüfung komplett aushebeln. Egal wie "unleserlich" die Rechenaufgabe im Kommentarformular ("1ins" statt "eins", "2wei" statt "zwei") gemacht wird.

Also zurecht ein Beispiel für "Security by Obscurity".

Fazit

Jetzt mag man nicht ganz zu Unrecht argumentieren, die Erkennung von Kommentarspam ist nicht besonders sicherheitsrelevant, und die Spammer würden sich nicht die Mühe machen, solch ein Verfahren zu implementieren. Das ist jedoch zu kurz gedacht. Die (Un-)Sicherheit von Web-Anwendungen fängt meist mit solchen vermeintlichen "Kleinigkeiten" an.

Kleiner Tipp für die Verbesserung des Plugins: Statt "get_bloginfo(name)" einen nach Aussen nicht sichtbaren für das Blog generierten Zufallswert verwenden, dann kann ein Angreifer von Aussen nicht so einfach den Hash-Wert selber erzeugen.



Geschrieben von af in am: Mittwoch, 13. Dezember 2006
Permalink

Tags: , , , , ,

Diesen Beitrag bei folgenden Diensten bookmarken:
del.icio.us - Digg it - Mister Wong - Technorati - Ruhr.com Suchmaschine

Kommentare
  • Roland Donnerstag, 14. Dezember 2006, 11:15 Uhr
    Ich meine, WP_SECRET wird bei WordPress-Installationen von Hause aus mitgeliefert? Oder irre ich mich da jetzt? Auf jedem (!) Fall sollte dies schnell nachgeholt werden.

    Mein Plug-in generiert auf ähnlicher Weise einen MD5- oder wahlweise SHA1-Hash. Es wird der besagte WP_SECRET-String eingebunden und zudem eine ganze Menge Daten mehr, Stichwort "Entropy". Beispielsweise binde ich den Uni*-Timestamp der letzten Änderung von wp-config.php und dem Plug-in-Script selber ein.

    Das alles ist zwar schön und gut und man kann auch noch zusätzlich etwas "Salz" reinstreuen in den String (siehe phpsec.org !), aber was nützt dies, wenn der Spambot vor jeder POST-Anfrage das Kommentarformular ausliest und den generierten Hash extrahiert? Der Spammer braucht dann nur einmal den "richtigen" Hash + Ergebnis finden und schon ist der Schutz wiedermal geknackt.

    Ich denke, das mit dem WP_SECRET ist vom Ansatz her gut, aber vielleicht sollte auch der Titel des Beitrages und - wenn entsprechendes Plug-in installiert ist, auch die Anzahl Views vom Beitrag mit in den Hash eingebunden werden.

    Dennoch: Insgesamt finde ich Deinen/Ihren (?) Beitrag zum Thema Security By Obsurity sehr gut und ich kann nur hoffen, dass dies bei vielen Bloggern nicht verhallt, mal ihre Plug-ins zu patchen. :)

  • sven Freitag, 15. Dezember 2006, 08:27 Uhr
    Nun ja, also dein Spamschutz hier (deine Rechenaufgabe) ist überhaupt nicht verschlüsselt sondern findet sich im Quelltext der Seite...


  • Andreas Freitag, 15. Dezember 2006, 09:42 Uhr
    @Sven: Richtig, wer die Seite parst, und die Rechenaufgabe "erkennt" kann die Rechenaufgabe lösen und die Antwort geben.

    Der Punkt ist aber, dass dazu die Seite geparst werden muss (was man Schritt für Schritt abhängig vom Spam-Aufkommen immer weiter über komplexere Captchas erschweren kann, das ist die Schutzfunktion), es aber in dem oben beschriebenem Verfahren eine einfache "Hintertür" gibt, um die eigentliche Schutzfunktion zu umgehen.
  • Quix0r Freitag, 15. Dezember 2006, 11:58 Uhr
    Selbst das Codieren der Zahlen in &#xx; bringt bereits bei vielen Bots nicht. Nur der "dumme" Bot kann dies nicht. Die Rechenaufgabe in ein Bildchen tun, ist genau so mit OCR-Software auslesbar (oder für Sehbeinträchtigte nicht entzifferbar), also im Grunde genommen sind wir dann wieder bei Captchas angekommen...

Nächster Artikel: Web 2.0 Social Networks: Miete Deine Freunde

Vorheriger Artikel: Dummdreister Domaingrabber