Hacking Volkshochschule Stein – Nützlicher Use-Case für den Einsatz der Browser-Entwicklertools

Hollywood zeigt es immer, wie einfach "Hacken" doch ist. Ein Zeile unverständlichen Code irgendwo eingetippt und schon hat man Vollzugriff zur FBI-Zentrale. Nun ja… so einfach ist es in der Realität nun doch nicht.

In diesem Artikel zeige ich euch, wie man sich doch mit ein bisschen Fachkenntnis Türen aufmacht, die für die meisten anderen verschlossen sind.

Motivation

Dieser Artikel ist inspiriert durch meinen kürzlichen Versuch, bei der Volkshochschule Stein mich und eine weitere Person zusammen für einen Kurs anzumelden.

Auf der Webseite der Volkshochschule wählt man zuerst einen Kurs aus und legt ihn – wie in einem Online-Shop – in einen Warenkorb. Unterschied zum Online-Shop ist es, dass man nicht die Menge wählen kann, sondern nur den Kurs reinlegt. Vom Warenkorb aus geht es wie gewohnt zum Kassenbereich. Auf der Kassen-Unterseite hat man dann unten die Möglichkeit, weitere Teilnehmer hinzuzufügen. Nur funktioniert der Knopf nicht… !?

• 

• 

Es ist immer dasselbe Lied: Wenn eine Webseite mies programmiert ist, so hat nicht nur der Quellcode (von dem der Otto-Normal-Verbraucher nichts mitbekommt) seine Macken, sondern auch die allgemeine Nutzererfahrung leidet darunter.

In meinem Beispiel sehe ich nun einen Bereich "Teilnehmer (falls abweichend)", wo ich das tun kann, was ich eigentlich will. Eine gelbe Hinweis-Box erklärt mir sogar, wie es geht: Drück den grünen Knopf mit dem Männchen-Plus-Icon. Der Knopf ist da, aber es passiert nix, wenn man drauf klickt. Ein technisch unversierter Benutzer wäre jetzt am Ende. – Ich nicht! 😎

Analyse: Warum geht der Knopf nicht

Die hellgrüne Farbe des Buttons suggeriert schon, dass er wohl disabled – d. h. nicht klickbar – ist. Mit einem Druck auf F12 öffnet man die Entwicklertools des Browsers und kann dem Problem nun genauer auf den Grund gehen. Die Vermutung bestätigt sich. Man erkennt am <button>-Element ein disabled-Attribut. Ebenso erhalten wir weitere Informationen, warum das Attribut gesetzt ist: Ein data-bind-Attribut enthält Code, der etwas mit enable zu tun hat (Nebenbemerkung: Eine Google-Suche nach dem Attribut weist auf das Framework Knockout hin). Wir erkennen den Zusammenhang, dass der Button wohl nur klickbar ist, wenn der Kurs das erlaubt: !$root.disableAddWeiteren(kurs).

An dieser Stelle nochmal zurück zur Nutzererfahrung: Was wir eben durch Quellcode-Lesen rausgefunden haben, müsste eigentlich als freundliche "Du darfst zu dem ausgewählten Kurs keine weiteren Teilnehmer einladen"-Box für den technisch unversierten Nutzer angezeigt werden. Stattdessen haben wir eine Erklärung zu einer Funktion, die nicht benutzbar ist. Lieber Entwickler, einfach weglassen!

Wir wechseln nun in den "Sources"-Tab der Entwicklertools und sehen uns den JavaScript-Quellcode genauer an. Wir sollten disableAddWeiteren dort finden können. In der Datei anmeldung.js werden wir fündig. Die deutschen Quellcode-Kommentare sind leicht verständlich und wir erfahren, dass es wohl für Kurse gedacht ist, wo Paare angemeldet werden, z. B. Tanzkurse. Wir erfahren auch, dass noch nicht alles fertig ist ("werden noch nicht abgefangen").

Und meine Lieblingsbeobachtung bei Quellcode: Copy&Paste. In den Zeilen 217 bis 219 sehen wir auskommentierten Code, der – so der Kommentar – "speziell für Friedrichshafen" ist. Der Entwickler scheint den Code also kopiert zu haben, den er vorher der Volkshochschule Friedrichshafen verkauft hat. Ich werde am Ende meines Artikels hierzu noch etwas mehr schreiben.

(Auf weitere Code-Smells, die man im Quellcode sieht, geh ich hier bewusst nicht ein.)

• 

• 

Problemlösung: der eigentliche "Hack"

Wir haben nun genügend (fast schon wieder zuviel…) erfahren und widmen uns nun der Lösung des Problems. Im Grunde ist es uns völlig egal, warum der Button nicht klickbar ist. Unser Ziel ist es, einen weiteren Teilnehmer hinzuzufügen.

Mittels der Browser-Entwicklertools entfernen wir nun einfach das disabled-Attribut des Buttons. Ein Doppelklick erlaubt uns das Bearbeiten. Mit einem Druck auf die Entfernen-Taste wird das Attribut komplett entfernt. Man sieht sofort, dass der hellgrüne Button dadurch wieder sattgrün wird.

• 

• 

Nach dem Klick des Buttons erscheint ein Formular, womit die Daten eines weiteren Teilnehmers bearbeitet werden können. Die Funktion funktioniert also wie angedacht. Um mehrere weitere Teilnehmer hinzuzufügen, ist es notwendig, das disabled-Attribut am Button erneut zu entfernen. Im enable-Ausdruck findet sich auch ein Teilausdruck !$root.weitererTnWirdEditiert(), der dafür zuständig ist, den Button zu disablen, während ein weiterer Teilnehmer editiert wird (vielen Dank an den Deutsch-Englisch-Mischmasch, lieber Entwickler!).

Ich konnte am Ende das Formular erfolgreich abschicken und so die Kursanmeldung für zwei Teilnehmer abschließen. Im nachfolgenden Absatz erkläre ich, warum das Glück (oder Pech für den Entwickler) ist und keinesfalls selbstverständlich.

• 

Erklärung: Keine Prüfung auf Serverseite

Auch wenn dieser Hack nicht gerade schwierig war, so war es doch notwendig, dass eine Sicherheitslücke im Quellcode vorhanden ist, um das es klappt.

Normalerweise stellt ein Entwickler sicher, dass aus Clientseite (gemeint ist damit der Browser des Nutzers und seine Eingaben an die Webseite) keine "bösen" Daten kommen. Die Serverseite (gemeint ist der Webserver, d. h. das Stück Software, was die Webseite mit dem Formular ausliefert, die Nutzerdaten entgegennimmt und am Ende irgendwo abspeichert und verarbeitet) muss "böse" Daten ablehnen.

Konkret für meinen Fall: Ein Administrator hat den Kurs, für den ich mich angemeldet habe, irgendwann gepflegt. Dort wurde der Name, die Beschreibung und die Uhrzeit eingegeben. Auch gibt es dort das Flag, was besagt, ob Paar-Anmeldungen erlaubt sind oder nicht. Dieses Flag, auch wenn ich es nicht sehe, muss existieren, da es ja für die Verfügbarkeit des Buttons zuständig ist. Auch dieses Flag hat der Administrator gepflegt und in diesem Fall gesagt "Nein, Paar-Anmeldungen sind hier nicht erlaubt".

Jetzt kommt die Sicherheitslücke. Ich habe an den Server geschickt "Bitte 2 Teilnehmer für den Kurs, der keine Paar-Anmeldungen erlaubt, anmelden". Das sind böse Daten, weil diese eigentlich niemals hätten erfasst werden dürfen. Hätten sie normal auch nicht, aber wir haben ja mit dem Button getrickst. Der Server hätte beim Abschicken meiner Anmeldung jetzt merken müssen, dass meine Daten böse sind, eine Fehlermeldung zeigen und die Daten verwerfen. Stattdessen hat er meine Daten angenommen und verarbeitet.

Lieber Entwickler: Auch wenn heutzutage mit den vielen JavaScript-Frameworks (Angular & Co – oder in deinem Fall Knockout) vieles einfacher geworden ist, so heißt das nicht, dass du auf Serverseite nichts mehr tun musst. Im Gegenteil: Dadurch dass so viel Code auf Clientseite ist, weiß ein Angreifer viel einfacher, welche Möglichkeiten er hat, was er an Daten schicken kann. Um so viel mehr musst du auf Serverseite die Daten prüfen.

Blame: Auf der Spur des Entwicklers

Ich habe in diesem Artikel sehr viel über den Entwickler geschimpft (und ja, er hat's verdient!). Doch nun will ich über diesen auch noch etwas mehr herausfinden. Im Quellcode haben wir schon ein Indiz gefunden, dass er nicht nur die Webseite der Volkshochschule Stein programmiert hat, sondern auch für die Volkshochschule Friedrichshafen zuständig ist.

Wir werfen hierzu einen Blick in den Quellcode und sehen sofort in den ersten paar Zeilen den Firmennamen "Kubus Software GmbH". Ein Aufruf von Google bringt uns zu dessen Webseite, wo nur Stellenangebote und ein Impressum da sind. Der Link "Kontakt" führt auf eine andere Firma "Kufer Software" – hört sich ähnlich an, die Webseiten sehen von der Optik fast gleich aus. Beim Produktangebot findet man nun in den Referenzen zahlreiche Volkshochschulen, die alle gleich aussehen.

• 

• 

• 

Warum betone ich das so? Wir haben vorhin schon Indizien für Copy&Paste gefunden, d. h. es liegt nahe, dass alle diese Webseiten von derselben Sicherheitslücke betroffen sind.

Ein letztes Wort für alle, die diesen Artikel gelesen haben und nun sagen "Jetzt tu doch nicht so. Du hast hier doch keine große Sicherheitslücke ausgenutzt, nur weil du einen weiteren Teilnehmer zu einem Kurs angemeldet hast": Richtig, da hast du recht. Das war keine große Sache. Aber technisch macht es keinen Unterschied, ob die Lücke groß oder klein ist oder ob ich viel, wenig oder gar keinen Schaden anrichten kann.

Der Entwickler hat seine Daten nicht korrekt geprüft.
Der Punkt ist: Wenn er das beim Verarbeiten einer Kurs-Anmeldung nicht getan hat, tut er das an anderen Stellen vielleicht auch nicht…