Original-URL des Artikels: https://www.golem.de/news/it-sicherheit-sicherheitsluecke-in-banking-software-elba-business-1811-137758.html    Veröffentlicht: 16.11.2018 16:45    Kurz-URL: https://glm.io/137758

IT-Sicherheit

Sicherheitslücke in Banking-Software ELBA-business

Die Netzwerkinstallation der österreichischen Banking-Software ELBA-business ließ sich übernehmen - mitsamt darunterliegendem System. Der Angriff war aufwendig, aber automatisierbar.

Der Pentester Florian Bogner startete den Online-Banking-Client einer österreichischen Firma und wurde stutzig: Die Anwendung ELBA-business suchte automatisch nach Updates und installierte sie. Erst dann fragte das Programm den Nutzer nach Nutzernamen und Passwort. Von diesem ersten Verdachtsmoment aus forschte Bogner weiter und konnte schließlich die komplette Datenbank und das darunterliegende System übernehmen. Damit wäre es einem Angreifer nicht nur möglich gewesen, Banktransaktionen zu manipulieren, sondern auch, beliebige Programme auf dem Zielsystem auszuführen, berichtet er in einem Blogbeitrag.

ELBA5 ist in Österreich weit verbreitet, die Business-Variante unterstützt 24 österreichische Banken. Von der Sicherheitslücke waren ausschließlich Anwender der Netzwerkinstallation betroffen, keine Einzelplatzinstallationen. Mit der Netzwerkinstallation können Firmen von mehreren Arbeitsplätzen aus verschiedene Konten bei unterschiedlichen Banken mit einem einzelnen System verwalten. Entwickelt wird die Anwendung von der Raiffeisen Software GmbH. Durch die Zusammenarbeit von Bogner mit dem Unternehmen ist das Problem mittlerweile behoben und eine aktualisierte Software-Version steht zur Verfügung. Ein Schaden sei nicht entstanden, sagte die Raiffeisen Software auf Nachfrage von Golem.de, denn die Schwachstelle sei nicht von Angreifern ausgenutzt worden.

Ein verdächtiger Update-Mechanismus gibt den Hinweis

Hinter dem verdächtigen Updatemechanismus vermutete Bogner von der Firma Bee IT Security hardgecodete Login-Daten, die eine Verbindung zum Backend möglich machten, um die Aktualisierung auszulösen. Also suchte er während des Anmeldeprozesses im Speicher nach Inhalten, die wie Nutzernamen und Passwörter aussahen. Er fand gleich zwei solcher Paare: eines für den User "connector" und eines für "elba". Während "elba" über Administratorprivilegien verfügte, hatte "connector" nur sehr begrenzte Zugriffsrechte - für eine einzelne Spalte in einer einzigen Datenbanktabelle.

In dieser Spalte lag das mit AES verschlüsselte Administrator-Passwort. In einer Bibliothek, in die die Datenbanklogik ausgelagert war, ergaben sich weitere Hinweise, und so fand Bogner im Speicher den statischen Key, um das Passwort des Administrator-Users "elba" zu entschlüsseln.

Der Angreifer könnte eigene Transaktionen eingeben

"Kombiniert man, was ich bis dahin herausgefunden habe, stellt man fest: Es war verlässlich möglich, Datenbank-Administratorrechte für jede ELBA5-Netzwerkinstallation zu bekommen", schreibt Bogner in seinem Blogbeitrag. Damit könnte ein Nutzer beispielsweise neue Transaktionen anlegen und sich selbst Geld überweisen. "Der Exploit hebelt das TAN-Verfahren aber nicht aus", sagte er im Gespräch mit Golem.de. Jemand muss die Transaktion also noch autorisieren: "Es ist recht unwahrscheinlich, dass eine komplett neue Transaktion da nicht auffallen würde."



Automatisierbarer Angriff

Für wahrscheinlicher hält Bogner es, dass ein Angreifer die Kontonummer einer bereits eingegebenen, aber noch nicht ausgeführten Transaktion ändern würde. Das falle vermutlich nicht sofort ins Auge. Aus Sicht eines Pentesters sei es jedoch viel interessanter, das gesamte System zu übernehmen, schreibt Bogner in seinem Blogbeitrag. Auch das gelang. Mithilfe von xp_cmdshell ließen sich Anwendungen auf dem darunterliegenden System ausführen und sogar neue Administratoren im Windows-System anlegen.

"Der Angriff war aufwendig, aber er ist automatisierbar", so Bogner weiter. Mittlerweile hat er ein Python-Exploit-Skript veröffentlicht, mit dem sich der Angriff nachvollziehen lässt. Um die frühere Schwachstelle ausnutzen zu können, hätte das System im lokalen Netzwerk erreichbar sein müssen. "Ich vermute, der Angriff wäre vor allem bei größeren Firmen interessant gewesen", sagt Bogner. "Durch Phishing hätte jemand Malware im Firmennetzwerk platzieren und so auf den von der Anwendung genutzten Port zugreifen können."

Im Gespräch mit Golem.de betont Bogner wiederholt, dass die Zusammenarbeit mit der Raiffeisen Software außerordentlich gut und professionell gewesen sei und schnell reagiert worden sei. Auf Anfrage von Golem.de berichtet die Raiffeisen Software, nach der Meldung von Bogner habe das Unternehmen gemeinsam mit ihm, der eigenen Security-Stabsstelle und einem staatlich geprüften Sachverständigen ein zweistufiges Konzept erarbeitet.

Im ersten Schritt sei eine Version bereitgestellt worden, bei der der Login-Prozess unter anderem mehrstufig gestaltet worden sei. "In einem zweiten Schritt wurde mit Hilfe architektonischer Anpassungen - Login mit Benutzereingaben, One-time Credentials, keine parallelen Verbindungen auf die Datenbank - das Angriffsszenario zur Gänze unterbunden", so das Unternehmen. Über das notwendige Update seien alle Kunden informiert worden. Auf der Konferenz IT-SECX werden Florian Bogner und Raphael Zoidl, Application Security Manager bei Raiffeisen Software, den Exploit gemeinsam vorstellen.  (abi)


Verwandte Artikel:
Sparkasse und DKB: Neue iPhones haben Probleme mit Push-TAN-Apps   
(24.09.2018, https://glm.io/136728 )
BSI-Richtlinie: CCC und OpenWRT kritisieren Router-TR als "Farce"   
(19.11.2018, https://glm.io/137796 )
Hacker: Was ist eigentlich ein Exploit?   
(15.06.2018, https://glm.io/134909 )
BSI-Richtlinie: Routerhersteller müssen Support-Ende nicht auf Gerät drucken   
(16.11.2018, https://glm.io/137119 )
Deutsche Darknet-Größe: Wie "Lucky" demaskiert wurde   
(14.11.2018, https://glm.io/137709 )

© 1997–2020 Golem.de, https://www.golem.de/