Eine bequeme Art der Überweisung sind SEPA-Dateien. Eine SEPA-Datei enthält alle Überweisungs-Posten gesammelt.

Bequem, schnell und automatisch

Da die SEPA-Datei maschinenlesbar ist, können beispielsweise Buchhaltungsprogramme Gehaltsüberweisungen gebündelt ausspucken. Ein Mitarbeiter muss diese nur noch im Online-Banking hochladen und schon sind die Gehälter überweisen.

Dem Nutzer werden die Posten noch einmal aufgelistet, um sicherzugehen, dass die Daten korrekt sind.

Schließlich generiert man noch die TAN, um die Überweisungen abzunicken.

Ist das Verfahren nun sicher?

Auf den ersten Blick sieht alles super aus: Man lädt die Daten hoch, überprüft sie noch einmal und nickt sie dann ab. Doch der Teufel steckt im Detail.

Doch zuerst ein bisschen Vorgeschichte: Das ChipTAN-Verfahren wurde eingeführt, da Handy-TANs einige grundlegende Probleme haben: Die TANs werden zum einen über das unverschlüsselte GSM-Netz geschickt (Anmerkung: GSM ist zwar verschlüsselt, aber innerhalb von Sekunden knackbar), zum anderen reicht die Kenntnis einer TAN aus, eine beliebige Überweisung zu tätigen.

ChipTAN sollte das ändern. Mit einem privaten Schlüssel auf der Karte soll mittels eines Nicht-Kompromittierten Gerätes (ChipTAN-Lesegerät) die Eckdaten der Überweisung, Betrag und Kontonummer des Empfängers, eingeben. Durch die Verrechnung der Daten in der TAN soll sichergegangen werden, dass Änderungen zwischendrin erkannt werden und User somit darauf aufmerksam gemacht werden, wenn sie beispielsweise einen Virus im System haben.

Problematisch bei der Sammelüberweisung ist nun die Menge der eingegebenen Daten. Die Sparkasse fragt mich lediglich nach der Summe aller Überweisungen, sowie der Anzahl Posten. Für einen Betrüger ist es aber fast egal, wie viele Posten und welche Summe überwiesen wird. Es sieht sogar plausibler aus, wenn eine gefälschte Überweisung genau denselben Betrag überweist wie das Original. Der Betrüger will die Empfänger-IBANs gegen eigene Konten austauschen. Das Geld muss danach zwar noch gewaschen werden (wäre doof, wenn das Konto auf seinen Namen liefe), aber das ist momentan nicht unser Problem.

Wie sieht nun der Angriff aus?

Dem Angreifer muss es gelingen, die SEPA-Datei so auszutauschen, dass Betrag und Anzahl der Posten gleich bleiben, aber der Betrüger seine eigenen Empfänger-IBANs einträgt. Im oben gezeigten Bild „Schritt 1“ findet bereits der Upload statt. Ist die Datei einmal bei der Bank hochgeladen, ist es für den Betrüger zu spät. Er muss also die Datei vor dem Upload abgreifen und abändern.

Im „Schritt 2“ sieht der Nutzer noch einmal die Buchungen aufgelistet. Da der Betrüger schon die abgeänderten Dateien hat hochladen lassen, muss dem Anwender jetzt die Richtigkeit der Daten weiterhin vorgegaukelt werden. Das geschieht, indem der Betrüger die ausgetauschten Originaldaten jetzt per Plugin im Web-Interface einsetzt. Dem User wird also vorgegaukelt, er würde an die richtigen Personen überweisen.

Im Schritt 3 der Anleitung hat der Betrüger keine Mühe mehr, da Betrag und Anzahl Posten des Sammelauftrags ja gleich bleiben.

Zusammengefasst muss der Betrüger einen Virus entwickeln, der ein Browser-Plugin ins System einschleust, das den Upload abfängt und auswechselt, sowie die angezeigten Kontrolldaten noch einmal durch die alten Daten ersetzt. Den Virus in ein Firmennetzwerk einzubringen dürfte keine große Hürde sein und beispielsweise mit Social Engineering gemacht werden können. Der technisch unversierten BWL-Aushilfskraft wird eine E-Mail untergeschoben, in der beispielsweise eine Mahnung oder eine Rechnung steht. Da sie die Anweisung hat, Rechnungen zu verbuchen, ist es recht wahrscheinlich, dass sie den Anhang öffnen wird.

Wie müsste man das System der Sparkasse anpassen?

Der Knackpunkt bei Sammelüberweisungen ist die Integrität der SEPA-Datei. Anstatt den Betrag und die Anzahl der Posten bei der ChipTAN-Eingabe abzufragen, sollte stattdessen eine Prüfsumme eingegeben werden, die bestätigt, dass die SEPA-Datei nicht verändert wurde. Diese Prüfsumme muss der Nutzer selbst berechnen. Das klingt nicht gerade User-freundlich. Geht man aber davon aus, dass die Anwender von SEPA-Dateien eher Unternehmensberatungen und Steuerbüros sind und die SEPA-Dateien automatisch generiert werden, kann die Software, die die SEPA-Datei generiert, die Prüfsumme gleich mit ausspucken.

Als Empfehlung für ein Prüfsummenverfahren würde ich hier SHA-256 anbringen. Allein durch die Verwendung in Bitcoin und ähnlichen Blockchains sind tausende Goldgräber damit vertraut, zu versuchen, SHA-256 zu knacken. Dass es niemanden gibt, der massenhaft Bitcoin-Blöcke absahnt, beweist, dass SHA-256 extrem sicher ist.

Warum ist der Fail fatal?

Was mich an der Sache stört ist, dass die Sparkasse bei Einzelüberweisungen so sehr acht gibt und Betrag und Kontonummer prüft, selbst bei den kleinsten Beträgen. Wenn es hingegen um Millionenbeträge geht bei Gehaltsüberweisungen, ist die Sicherheit auf einmal nicht mehr gegeben.

Zudem gibt es in vielen Firmen eine katastrophale Sicherheitslage, die Betrüger nur so einlädt, das Netzwerk zu kompromittieren. Überall, wo mehrere Personen als Einfallstor dienen, wird dadurch die Sicherheit geschwächt.

Inwieweit die Sparkasse darauf reagieren wird, weiß ich nicht. Die Sache zuerst der Sparkasse zu melden war für mich von Anfang an keine Option. Am Schalter hätte man mich komisch angeschaut und ein direkter Kontakt in die Sicherheits- und IT-Abteilung war mir zu viel Rechercheaufwand. Zudem gab es in der Vergangenheit zu viele Sicherheitsforscher, die nach ihrer diskreten Meldung entweder ignoriert wurden, mit 25 €-Gutscheinen abgespeist wurden oder gar rechtliche Probleme bekommen haben, weil ihnen die Forderung nach einer Belohnung fürs Finden der Lücke als Erpressung ausgelegt wurde.

Zudem gehe ich davon aus, dass bei der Sparkassen-IT keine Idioten arbeiten. Ich denke eher, dass diese Sicherheitslücken für mehr User-Komfort in Kauf genommen wurden. Die Entscheidung kommt schließlich von Oben und nicht von den Fachexperten. Die Frage ist nur, ab welcher Verlustsumme es sich für die Sparkasse lohnt, in mehr Sicherheit zu investieren. Jedoch könnte man die verfälschten SEPA-Dateien auch den Firmen zuschreiben, womit die Verluste eher bei den Kunden der Sparkasse lägen – also null Handlungsbedarf.

Das Problem sitzt noch tiefer

Angenommen, der Rechner wäre kompromittiert und ich generiere meine SEPA-Datei aus einem Programm, das auf dem kompromittierten Rechner läuft – dann ist doch die komplette Sicherheit der Bank unnütz.

Hier gibt es mehrere Arten, wie die SEPA-Datei entstehen kann. Zum einen kann eine externe Partei, wie z.B. der Steuerberater die SEPA-Datei erstellen und mir die SHA256-Summe auf sicherem Wege zukommen lassen. Es müssten schon beide Parteien infiziert sein und der Virus zusätzlich auf die Software des Steuerberaters spezialisiert sein, um den Angriff durchführen zu können.

Doch selbst, wenn die SHA-256-Summe auf meinem kompromittierten Rechner erstellt wurde, kann man speziell die Wirtschaftlichkeit einer Viren-Entwicklung betrachten: Es gibt 3-4 verbreitete Browser, aber hunderte Buchhaltungsprogramme, sowie tausende Individuallösungen, die SEPA-Dateien erstellen. Wenn die Banken also ihre Pflicht tun würden, wäre schon einmal ein Risikofaktor ausgeschalten.

Weitere Design-Schwächen des ChipTAN-Verfahrens

Es gibt zwar noch einige andere Dinge, die mich am ChipTAN-Verfahren stören, aber ich gehe mal davon aus, dass die Bedrohungslage recht überschaubar ist und dass die Sparkasse für ihre fehlende Sicherheit schön selbst haften wird (um keinen Skandal zu provozieren – rechtlich müsste sie nicht, da sich in vielen Fällen von verseuchten Computern gar nicht nachweisen lässt, ob nun der Nutzer oder der Virus die Aktion getätigt hat).

Einzelüberweisung sind so ein Stein des Anstoßes: Es wird der Betrag und die Kontonummer abgefragt, nicht aber die Bankleitzahl (bzw. der Anfang der IBAN). Überrede ich nun eine Bank, ein Konto zu eröffnen, das dieselbe Kontonummer hat wie ein Zahlungsempfänger meines Opfers, kann ich leicht per Browser-Plugin die Bankleitzahl der Überweisung austauschen und erhalte das Geld selbst. Das Opfer wird zuerst nichts merken, da Kontonummer ja stimmt und der Betrag auch – nur der Empfänger wird sein Geld nicht sehen.

Eine weitere Design-Lücke, die wesentlich tiefer liegt, ist die Schlüsselerzeugung. Ich bekomme meine EC-Karte von der Bank zugeschickt. Der private Schlüssel auf dem Chip wird nicht von mir generiert. Demzufolge wäre bei einer bestätigten Überweisung nachweisbar entweder ich oder meine Bank der Urheber. Eine TAN ist also nicht der eindeutige Beweis, dass eine Überweisung von mir autorisiert wird, da sie die Bank als signierenden Part nicht ausschließen kann. Das wäre erst möglich, wenn ich den Schlüssel selbst generieren dürfte und in den Chip einbrennen darf. Dass das aus Usability-Gründen nicht geht und die Chip-Schreibgeräte ebenfalls kompromittiert sein könnten, lassen wir mal außen vor.

Dieser Artikel soll keine Rüge gegen die Sparkasse allein sein. Ich kann mir vorstellen, dass andere Banken dieselben Fehler machen oder dass die Banken gar nur Standards umsetzen (die sie natürlich selbst mit beeinflusst haben).

Fazit

Ich hoffe, dass ich nie einen Virus haben werde, der sich auf die Verfälschung von SEPA-Dateien spezialisiert. Ansonsten wären die finanziellen Folgen heftig. Ich hoffe, dass, bis die Sparkasse den Fehler behoben hat, Linux noch nicht so verbreitet ist, dass es Drive-By-Viren gibt, die auf meinem System Unheil anrichten können. Sollte es doch dazu kommen, muss ich wohl Sammelüberweisungen sein lassen und alle Posten einzeln einhacken.