Posts mit dem Label Sicherheit werden angezeigt. Alle Posts anzeigen
Posts mit dem Label Sicherheit werden angezeigt. Alle Posts anzeigen

Hacker-Angriffe auf den SWIFT-Zahlungsverkehr

81 Millionen US-Dollar – diese Riesensumme haben Kriminelle von der Zentralbank Bangladesch gestohlen. Nicht bei einem filmreifen Überfall, sondern ganz still mit einem Hacker-Angriff. Die Diebe veranlassten mehr als 30 Überweisungen vom Konto der Bangladesh Bank bei der New Yorker Federal Reserve Bank (Fed) auf philippinische Konten. Dieser und weitere Fälle zeigen: Der Interbanken-Zahlungsverkehr ist ein lohnendes Angriffsziel. Und die Sicherheit des internationalen Finanznetzes SWIFT ist verletzlich. Der Aufwand, dort einzudringen, ist sicherlich groß, aber die zu erwartende Beute noch größer. Angesichts solch professioneller Attacken steht die Sicherheit des Zahlungsverkehrs erneut ganz oben auf der Agenda.


Die Bangladesh Bank wurde im Februar 2016 auf zwei Ebenen angegriffen. Offensichtlich waren die IT-Sicherheitseinrichtungen mangelhaft: Die Zentralbank verfügt angeblich über keine Firewall und nur über veraltete Netzwerktechnik. Durch diese Tür gelangten die Diebe in das Banknetz und dort an die Zugangsdaten für Überweisungen. Im SWIFT-Client Alliance Access konnten sie sich damit als Auftraggeber der Transaktionen autorisieren. Für die Fed traten die Urheber als Zentralbank von Bangladesch auf.

Die Sicherheitslücke erlaubte es den Angreifern laut BAE Systems auch, eine eigens programmierte Schadsoftware im SWIFT-Alliance-Server zu installieren. Diese Software manipulierte die Bestätigungsnachrichten des SWIFT-Netzes und schaltete den Zugriffsschutz für die Datenbank aus. Die ausgeführten Transaktionen wurden nicht korrekt protokolliert, um die Spuren zu verwischen.
Der Hacker-Angriff hebelte die Sicherheitsmechanismen von SWIFT komplett aus und eröffnete den Dieben nahezu unbegrenzte Möglichkeiten. Die Gesamtsumme der angeforderten Transaktionen belief sich gar auf 951 Millionen US-Dollar. Ein ungewöhnlicher Tippfehler in einer Nachricht ließ eine beteiligte Bank in Bangladesch nachfragen, ob die Überweisung so gewünscht sei. Nur dadurch fiel der gesamte Betrug überhaupt auf. Da waren die 81 Millionen aber bereits überwiesen und in philippinischen Kasinos und Privathänden verschwunden. In der Folge mussten Atjur Rahman, der Chef der Zentralbank Bangladesch, und seine Stellvertreter im März 2016 zurücktreten.

SWIFT selbst hat eingeräumt, dass in den letzten Monaten mehrfach betrügerische Nachrichten über das Netz gesendet worden sind. Im Mai 2016 war eine Geschäftsbank von einem ähnlichen Betrugsfall betroffen: Kriminelle sind in die IT-Systeme eingedrungen, haben Nutzerdaten abgegriffen und Nachrichten manipuliert. Nun sollen Updates die Sicherheitslücken in der SWIFT-Software schließen.

Auch wenn SWIFT betont, der Angriff stelle nicht die Sicherheit des Netzes infrage, sondern die des Zugangssystems, zeigt der Fall das Dilemma geschlossener internationaler Netze. Auch mit hohem technischem Aufwand lassen sie sich nicht absolut abschotten. Außer der Software des Netzbetreibers können auch die umgebenden Banksysteme eine Schwachstelle sein. Ganz zu schweigen von kriminellen Mitarbeitern, die beim Betrug mithelfen. Und sind die Angreifer erstmal drinnen, steht ihnen die ganze Welt offen. Das schafft Anreize. Ein Verfahren wie EBICS nutzt das offene Internet und verfolgt ein Sicherheitskonzept, das stark auf Schlüsseln für die Kryptografie und Authentifizierung basiert. Das kann eine Alternative zum geschlossenen Netz sein.

Angesichts der potenziell sehr großen Schäden muss der Interbanken- und Firmenkunden-Zahlungs­verkehr umfassend geschützt werden. Es ist zu erwarten, dass Cyber-Attacken wie die hier beschriebene zunehmen. Letztlich müssen die Sicherheitsmechanismen des Verfahrens, der Bank-IT und für das Personal lückenlos ineinander greifen.

Michael Lembcke 

EBICS und TLS 1.2 – etwas sicherer, aber nicht ohne Tücken

Curd Reinert, Projektleiter EBICS-Kernel, PPI AG


Wer einen Blick in die aktuelle EBICS-Spezifikation wirft, stellt womöglich überrascht fest, dass dort für die Transport Layer Security (TLS) noch die Version 1.0 vorgeschrieben ist. Das war mal eine sehr kluge Wahl: Bei Veröffentlichung der EBICS-Spezifikation war TLS 1.0 der Stand der Technik. Man hat sich also vor allem gegen SSL entschieden. Und damit waren die Hersteller und Betreiber z. B. bei POODLE fein raus: EBICS schließt SSL aus, die EBICS-Anwendungen waren vor POODLE sicher. Ohnehin hätte POODLE bei einem EBICS-Client kaum eine Chance: Der Angreifer bringt den Client dazu, tausende Anfragen an den HTTPS-Server zu schicken, um z. B. an das Session-Cookie zu kommen. Bei EBICS wird aber weder ein Session-Cookie genutzt, noch sind die Clients Web-Anwendungen, die man per JavaScript dazu bringen kann, tausende Anfragen zu schicken. Aber erklären Sie das mal der Revision!


Und das war ja auch nur einer der bösen Angriffe mit den lustigen Namen: HEARTBLEED nutzte einen Fehler in der TLS-Implementierung von OpenSSL aus. Und dann ist da noch BEAST. Wie schon bei POODLE eignet sich EBICS auch nicht für den BEAST-Angriff. Aber der Ruf von TLS 1.0 ist nachhaltig beschädigt, und alle Seiten raten zum sicheren Nachfolger TLS 1.2.

Das hat man auch bei EBICS erkannt und entsprechende Change Requests für die nächste Version vorgesehen, um TLS 1.2 zu unterstützen. Leider verzögert sich diese nächste Version, und in der Zwischenzeit fragen die Revisoren: Wieso macht ihr mit EBICS noch TLS 1.0? „Weil es so in der Spezifikation steht“, reicht als Argument kaum noch aus, wenn das BSI offiziell vor dieser Version warnt. Auf der offiziellen EBICS-Seite stehen darum jetzt Sicherheitsempfehlungen, die zu TLS 1.2 raten – ohne zu erklären, wie sich das mit der Spezifikation vereinbaren lässt.

Wir haben 82 EBICS-Server in Deutschland und Frankreich getestet: Gerade einmal 52 Server konnten mit uns TLS 1.2 sprechen. Wenn Sie sich also als Kundenprodukthersteller heute dazu entschließen, TLS 1.0 gar nicht mehr zu unterstützen, dann können Sie sich mit ca. einem Drittel der EBICS-Server nicht mehr verbinden. Server-Betreibern dürfte es mit den Kundenprodukten in den unterschiedlichsten Versionen noch schlechter ergehen.



Was kann man dann tun? Man kann TLS 1.2 anbieten, ohne TLS 1.0 zu verbieten. Das geht sowohl als Client als auch als Server, und im TLS-Handshake einigen sich beide Seiten auf die sicherste gemeinsame Variante – so die Theorie. Bei immerhin 28 der getesteten Server hat das auch funktioniert. Leider haben wir aber auch zwei Server gefunden, die die Kommunikation rigoros abbrechen, wenn der Client TLS 1.2 vorschlägt. Das ist für die Hersteller von Kundenprodukten sehr unangenehm, weil die Clients dann nicht einfach „auf Verdacht“ TLS 1.2 vorschlagen können – oder sie nehmen in Kauf, dass die Kommunikation mit einigen wenigen Servern scheitert.

Wir haben die Betreiber der beiden EBICS-Server benachrichtigt. Da unser Test aber nicht alle EBICS-Server umfasst, sollte jeder Betreiber das Verhalten seines EBICS-Servers selbst prüfen.
Eine Frage drängt sich noch auf: Wie gefährlich wäre eine Entschlüsselung des TLS-Layers in EBICS überhaupt; welche Daten wären sichtbar? Die Auftragsdaten selber werden ein zweites Mal verschlüsselt und bleiben für den Angreifer unsichtbar. Es bleibt der XML-Rahmen um die Auftragsdaten, oder wie man es in der Post-Snowden-Ära nennt: Metadaten. Das sind vor allem die Auftragsart bzw. das Fileformat, die Kunden- und die Teilnehmer-ID. Mit anderen Worten: nicht besonders viel. Ob man damit die Gemüter beruhigen kann, steht auf einem ganz anderen Blatt.

Curd Reinert