Die Postbank, nach eigener Aussage größter Anbieter von Onlinebanking in Deutschland, bietet ihren Kunden eine rein HTML-basierte Onlinebanking Lösung. Leider läßt die Lösung Mißbrauch zu - und zwar mit 128 Bit!
Das Verfolgen von Kontobewegung ist unter Umständen nämlich ohne PIN über lange Zeiträume hinweg möglich.
Um es vorweg zu nehmen: wir wollen die Sache nicht überbewerten und sprechen uns hiermit ausdrücklich für die Nutzung von Onlinebanking- und ECommerce-Systemen aus. Es ist wie mit dem Auto: für den unbestreitbaren Nutzen nimmt man ein gewisses Risiko in Kauf.
Tatsache bleibt aber, es gibt ein konkretes, vermeidbares Problem das in seiner Art signifikant für viele Sicherheitslösungen ist und auch Fragen nach dem Sinn von Sicherheitszertifizierungen aufwirft.
Die Postbank hat getan, was man von ihr verlangen kann. Ihr durch eine unabhängige Firma mit Akkreditierung beim BSI zertifiziertes und von der Stiftung Warentest mit dem Urteil "Gut" bewertetes Onlinebanking System, ist eines der bislang wenigen in Deutschland, das auf den Einsatz von Java verzichtet und eine rein HTML-basierte Lösung auf der Basis von neuerdings exportfähigen, mit 128Bit Verschlüsselung arbeitenden, WWW-Servern anbietet.
Dies hat, wie wir vermuten, vor allem finanzielle Gründe, sind doch die Java-basierten Lösungen teurer. Der Ansatz verdienst also Respekt.
Allerdings hat es die Postbank in der 128-Bit Verschlüsselungseuphorie fertig gebracht zu übersehen, daß man sich innerhalb von 15 Minuten nach der letzten Banking-Sitzung einfach anhand des "Verlauf"-Buttons im MSIE oder der History-Funktion im Netscape Communicator den Kontostand des Vorgängers per Mausklick herzaubern kann - ohne PIN, dafür aber mit vollen 128-Bit verschlüsselt.
Wir haben das Problem weiter untersucht und u.a. festgestellt, daß:
Die Festellungen waren insgesamt wenig überraschend, da sie aus technischer Sicht zu erwarten waren.
Wir haben die Banking-Vorgänge automatisiert und auch einen PIN-Guesser zum Erraten
von PINs geschrieben (die Postbank schreibt zwar, sie würde nach drei Versuchen
abbrechen, aber man weiß ja nie ...). Obwohl tatsächlich nach drei falschen PINs eine
Deaktivierung des Kontos erfolgte, gibt es ein weiteres Problem: zur Reaktivierung des
Kontos wird einen gültige TAN verlangt. Gibt man nun einfach eine falsche TAN ein, ist
das Konto dauerhaft für Onlinebanking gesperrt und man muß richtig Aufwand betreiben um
es wieder freischalten zu lassen -> "Denial of Service" leicht gemacht.
Wohlgemerkt:
Man kann Konstostände und Kontobewegungen verfolgen und evtl. Accounts lahmlegen. Man
kann keine Überweisungen o.ä. durchführen und keine TANs knacken/vorbestimmen.
Transaktionen sind nicht betroffen.
Aber:
Denoch handelt es sich um einen Fehler, der unserer Meinung nach nicht hätte
passieren dürfen und es ist uns unklar wie so viele Instanzen (Stiftung Warentest Urteil:
"Gut", unabhängige Sicherheitszertifizierung, etc ...) das Problem übersehen
konnten.
Was wiederum die Frage nach dem Sinn von formalen Sicherheitsprüfungen
und -zertifizierungen aufwirft.
Der Fehler (respektive das Problem. "It's a feature, not a bug") ist eines der ältesten im WWW-Bereich überhaupt und so grundsätzlich Protokolldesignbedingt, daß man es eigentlich hätte bedenken müssen. Von daher fällt es schwer, eine Entschuldigung zu finden.
Das HTTP-Protokoll ist ein "zustandsloses" Protokoll. Dieser Umstand, oder genauer, der Mangel eines bekannten Zustands, ist grundlegendes Design; nur der Browser auf Ihrem PC hat eine Vorstellung eines "Zustandes", bzw. der Information, wo Sie gewesen sind und wie Sie dorthin zurückkommen. Jeder Seitenabruf, ja sogar jeder Abruf einer Seitenkomponente wie z.B. einer Grafik, ist eine abgeschlossene Transaktion über das Netz, die unabhängig von allen anderen ausgelöst und abgewickelt wird. Um Informationen zwischen unterschiedlichen Seiten auszutauschen (z.B. der Eingabe der Kontonummer und der PIN und später dann dem Abruf des Konstostands) muß man deswegen Hilfsmittel heranziehen: man speichert die verbindende Information (die sogenannten "Session-ID") in Cookies, übergibt sie durch Forms oder als Parameter über den URL. Zumindest letzteres ist schlecht, da die Information im "Verlauf" der Browser gespeichert wird.
Da der Server auch nicht weiß , wie lange Sie eine HTML-Seite betrachten, bzw. ob Sie überhaupt noch online sind (hat er die Daten für eine Seite einmal verschickt, ist der Fall für ihn erledigt), ist man gezwungen der Session-ID ein Verfallsdatum mit zu geben. Ist dieses zu kurz, kann man nicht richtig arbeiten, da man sich andauernd nei einologgen müßte. Ist es zu lang, kann jeder, der in den Besitz der Session-ID gelangt, eine Sitzung innerhalb der Gültigkeitsdauer der Session-ID weiterführen. Die Server werten jeweils das Laden neuer Seiten als Zeichen dafür, daß Sie noch Online sind und verlängern die Gültigkeitsdauer der Session-ID jedesmal ein Stück. Dies kann man sich aber, wie gezeigt, auch mißbräuchlich zu nutze machen, in dem man die Seite mit der Session-ID immer kurz vor Verfall des Keys, neu lädt und damit die Sitzung über lange Zeiträume aufrecht erhält.
Es handelt sich um die klassische Situation: geistige Fokussierung auf einen Schwerpunkt (Verschlüsselung) gepaart mit einer Art Betriebsblindheit und dem Glauben an formale Sicherheitschecks schaffen es, daß man zwar den Burggraben mit Wasser und Krokodilen füllt, aber keiner merkt, daß das Tor heruntergeklappt ist.
Der einzige Ausweg für den Kunden ist es, die Session-ID zu entwerten. Das kann aber nur der Anwender selbst, womit das Problem bei ihm hängen bleibt.
Die Postbank hat mittlerweile einen Hinweis auf den Ende-Button, der die
Session-ID
entwertet, auf ihrer Banking-Seite angebracht. Diesen sollte man tunlichst auch immer
drücken - mehr kann man nicht tun, das ist aber auch ausreichend.
Die Anbieter der Systeme sollten zumindest eine maximale Lebensdauer für Session-IDs einführen. Es ist kaum anzunehmen, daß jemand länger als 24 Stunde aktiv Onlinebanking betreibt. Es dürfte deswegen kein Problem darstellen, wenn eine Session-ID nach 12 oder 24 Stunden einfach zwangsweise verfällt. Damit wäre wenigstens die dauerhafte Kontostandsverfolgung unmöglich gemacht.
Bedauerlich ist, daß die Sicherheit nicht mehr nur vom System abhängt, sondern ein Stück weit von der Sorgfalt des Nutzers.
Das Problem ist in der Form systemimmanent bei vielen (vielleich den meisten?) HTTP/HTML basierten Shopping- und Banking-Systemen. So kann man auch bei Quelle oder Beate-Uhse anhand des Verlauf-Knopfs den Warenkorb des Vorgängers anschauen, teils sogar noch nach Stunden.
Häretiker würden sagen: HTML/HTTP ist nur beschränkt tauglich für sichere ECommerce
Lösungen. Wir auch.
Holger Heimann
(Stand 2/99)