Mehrere Schwachstellen in UC eBanking Prime

NSIDE hat mehrere, zum Teil kritische Schwachstellen in UC eBanking Prime (Versionen 6.1.0 und 6.2.0) gefunden. Die Schwachstellen ermöglichen Angreifern unter bestimmten Umständen unautorisierten Zugriff zur UC eBanking-Prime-Webanwendung und damit zu sensiblen Daten wie Kontoständen und der Transaktionshistorie. Diese Schwachstellen werden nun im Rahmen eines Responsible-Disclosure-Prozesses offengelegt. Mit diesem Blogartikel möchten wir die zeitgleich veröffentlichten Advisorys NSIDE-SA-2025-001 und NSIDE-SA-2025-002 mit weiteren technischen Details ergänzen.

Einleitung

UC eBanking Prime ist eine On-Premise-Electronic-Banking-Lösung für Geschäftskunden der Hypovereinsbank (HVB)/UniCredit. Die Lösung besteht aus einer Webanwendung, die im Intranet des Kunden installiert wird, sowie einer Desktopanwendung namens OTC Client, die für die Anmeldung an der Webanwendung benötigt wird.

Im regulären Betrieb meldet sich der Benutzer zunächst mit einer sogenannten „Keybag“-Datei und dem dazugehörigen Passwort an der Desktopanwendung OTC Client an:

Der OTC Client kommuniziert mit dem Server, um die angegebenen Daten zu validieren (mehr dazu später) und gibt anschließend einen achtstelligen „One-Time-Code“ (im Folgenden „OTC-Code“) zurück:

Mit diesem Code kann sich der Benutzer innerhalb einer Minute an der Webanwendung anmelden:

Welche Informationen in der Webanwendung eingesehen werden können und welche Aktionen dort durchgeführt werden können, hängt anschließend von den Berechtigungen des Benutzerkontos ab.

Ablauf der Anmeldung

Wir sind während eines Red-Teaming-Projekts zum ersten Mal auf UC eBanking Prime gestoßen und da „Online Banking“ eins der vordefinierten Ziele („Critical Functions“) war, haben wir uns die Anwendung genauer angeschaut, insbesondere das Anmeldeverfahren. In den folgenden Abschnitten erklären wir zunächst objektiv die Analyseergebnisse, also den Ablauf der Anmeldung, und gehen dann auf die dabei entdeckten Schwachstellen genauer ein.

Der Anmeldeprozess besteht aus mehreren Aktionen, die offenbar unabhängig voneinander durchgeführt werden:

1. Zuerst gibt der Benutzer die zu ladende Keybag-Datei sowie das Passwort an. Bei der Keybag-Datei handelt es sich um eine PKCS#12-ähnliche Struktur, die mehrere private Schlüssel enthält, die bei der allerersten Anmeldung lokal generiert werden, sowie einige Metainformationen, wie die aus zwölf Zeichen bestehende Benutzer-ID (User-ID).
2. Aus der Keybag-Datei extrahiert der OTC Client die User-ID und schickt sie zum Webserver, um zu prüfen, ob das Benutzerkonto sich zu diesem Zeitpunkt überhaupt anmelden darf. Falls das Benutzerkonto gesperrt ist, entweder weil es explizit deaktiviert wurde, oder aufgrund zu vieler fehlgeschlagener Anmeldeversuche, teilt der Server dies dem Client mit. Andernfalls bestätigt er die Anfrage.
3. Danach versucht der OTC Client, einen Teil der Keybag-Datei mit dem vom Benutzer eingegebenen Passwort zu entschlüsseln. Schlägt diese Entschlüsselung fehl, so teilt die Anwendung dies dem Server in einer weiteren Anfrage mit, sodass der Server den Zähler fehlgeschlagener Anmeldeversuche für dieses Benutzerkonto erhöhen kann. Danach wird der Benutzer über den fehlgeschlagenen Anmeldeversuch informiert.
4. Falls das Konto jedoch aktiv ist und das angegebene Passwort validiert werden konnte, sendet die Desktopanwendung die eigentliche OTC-Anfrage. Diese Anfrage enthält außer der Benutzer-ID keine benutzerspezifischen Informationen, insbesondere nicht das Passwort. Der UC-eBanking-Prime-Server antwortet mit dem OTC-Code in verschlüsselter Form. Die Entschlüsselung ist nur mit einem privaten Schlüssel aus der Keybag-Datei möglich.

Der ganze Ablauf ist im folgenden, etwas ausführlicheren Diagramm auch noch einmal grafisch dargestellt, inklusive einiger zusätzlicher Interaktionen:

Schwachstellen

Im beschriebenen Anmeldeprozess konnten wir mehrere Schwachstellen feststellen, denen teilweise konzeptuelle Schwächen, teilweise auch nur Fehler in der Implementierung zugrunde liegen. Die Schwachstellen sind nicht durch den offiziellen Prime-OTC-Client ausnutzbar, allerdings haben wir die Kernfunktionalität des OTC Clients in einem Python-Exploit-Skript nachimplementiert und damit entsprechende Anfragen simuliert.

Zunächst treten einige Schwachstellen auf, weil die zuvor beschriebenen Schritte offenbar größtenteils unabhängig voneinander sind:

1. Schwachstelle 1: Anmeldung trotz Kontosperrung: Die Anfrage eines OTC-Codes ist auch möglich, wenn das entsprechende Benutzerkonto gesperrt ist. Hierfür kann die Statusabfrage (Schritt 2) einfach übersprungen werden. Dabei spielt es keine Rolle, ob das Benutzerkonto von einem Administrator explizit deaktiviert wurde oder aufgrund mehrfacher fehlgeschlagener Anmeldeversuche gesperrt ist.
2. Schwachstelle 2: Offline Brute-Force-Angriff: Technisch gesehen wird das Passwort lokal validiert und der Server nur über fehlgeschlagene Anmeldeversuche informiert. Durch Unterdrücken dieser können deutlich mehr Anmeldeversuche getätigt werden. Mit ein wenig Optimierung sind hier vollständige Offline-Brute-Force-Angriffe gegen die Keybag-Datei möglich.
3. Schwachstelle 3: Absichtliches Sperren eines Benutzerkontos: Die HTTP-Anfrage, die den Server darüber informiert, dass ein Anmeldeversuch fehlgeschlagen ist, ist nicht authentifiziert. Das heißt, dass Angreifer mit Zugriff auf eine User-ID das entsprechende Benutzerkonto absichtlich sperren können. Ein solcher Angriff ist bei Anmeldungen natürlich häufig möglich, könnte hier allerdings vermieden werden, indem die Anfrage zusätzlich authentifiziert wird, beispielsweise indem der Client beweist, Zugriff auf die Keybag-Datei zu haben.

Zusätzlich konnten allerdings noch zwei Schwachstellen gefunden werden, die auf Schwächen in der Implementierung zurückzuführen sind:

4. Schwachstelle 4: Anmeldung ohne Kennwort (Advisory NSIDE-SA-2025-001): Zwar wird während der Validierung ein Teil der Keybag-Datei mit dem eingegebenen Passwort entschlüsselt, der für die OTC-Entschlüsselung verwendete private Schlüssel gehört allerdings nicht Dieser ist nämlich nur mit einem statischen, im OTC Client hartkodierten Passwort verschlüsselt.
   In der Praxis bedeutet dies, dass Angreifer, die Zugriff auf eine Keybag-Datei haben und über das Netzwerk mit dem Prime Server interagieren können (per HTTP(S)), sich ein gültiges OTC-Code generieren können und damit anmelden können, falls für das entsprechende Benutzerkonto nicht die optionale, zusätzliche Zweifaktorauthentifizierung per TOTP aktiviert ist. Dies ist auch möglich, falls das Benutzerkonto gesperrt ist (siehe Schwachstelle 1).
   Diese Schwachstelle war für uns als Red-Team mittlerweile in mehreren Projekten äußerst hilfreich. Es ist unklar, ob sie mittlerweile behoben ist (siehe Abschnitt „Reponsible Disclosure“).
5. Schwachstelle 5: Preisgabe von Sitzungs-IDs über WebSockets (Advisory NSIDE-SA-2025-002): Sobald der Benutzer den OTC-Code in der Webapplikation eingibt, zeigt der OTC Client dies an. Um diese und andere Benachrichtigungen darstellen zu können, baut der OTC Client eine WebSocket-Verbindung zum Prime Server auf, in der Nachrichten im Spring STOMP-Format übertragen werden. Diese WebSocket-Verbindung ist ausschließlich mit der User-ID „authentifiziert“. Nach der Anmeldung wird eine „Anmeldung erfolgreich“-Meldung übertragen. In den Kopfzeilen dieser Benachrichtigung überträgt der Server zusätzlich die JSESSIONID der Webanwendung.
   In der Praxis bedeutet diese Schwachstelle, dass Angreifer, die die User-ID eines Benutzers kennen, ebenfalls einen solchen WebSocket-Kanal aufbauen können. Sobald sich der Benutzer anmeldet, wird ihnen die JSESSIONID zugespielt und sie können die Sitzung übernehmen. Die Benutzer-IDs bestehen zwar im Allgemeinen aus einer zwölfstelligen Buchstaben- und Zahlenkombination, allerdings wird diese nicht als sensibel eingestuft. Außerdem hat das vorinstallierte Administratorkonto stets die User-ID „111-111-111-111“.
   Diese Schwachstelle wurde durch die Hypovereinsbank/UniCredit bereits mit Version 6.2.0.3 behoben, indem die JSESSIONID durch den SHA-256-Hash der JSESSIONID ersetzt wurde.

Proof-of-Concept-Video

Da der Behebungsstatus aktuell noch ungeklärt ist, veröffentlichen wir unseren Python-Exploit-Code aktuell noch nicht. Stattdessen haben wir zwei Videos aufgezeichnet, die die Ausnutzung der Schwachstellen demonstrieren.

Im ersten Video demonstrieren wir zunächst den regulären Anmeldeprozess und dann Schwachstelle 4:

Der zweite Clip demonstriert Schwachstelle 5:

Beide Videos wurden mit UC eBanking Prime Version 6.2.0 aufgezeichnet.

Responsible Disclosure

Wir haben die Schwachstellen in einem Kundenprojekt Ende März 2025 entdeckt und sie mit Zustimmung unseres Kunden am 7. April 2025 an die Hypovereinsbank gemeldet. Da die Hypovereinsbank jedoch nach eigener Aussage keine Schwachstellenmeldungen von externen Unternehmen akzeptiert, mussten wir die Schwachstellenmeldung unter Einbezug unseres Kunden durchführen. Daraufhin erkannte die Hypovereinsbank die Schwachstellen am 8. Mai an. Die Schwachstelle 5 (Preisgabe der Sitzungs-IDs über WebSockets) wurde anschließend in Version 6.2.0.3 (Juni 2025) behoben. Die übrigen Schwachstellen sollten ursprünglich als Teil eines Feature-Updates „Ende Oktober 2025“ behoben werden, dieses Update wurde im November 2025 bereitgestellt, enthielt aber nicht die Behebungen. Diese wurden erst in einem weiteren Patch im Dezember 2025 nachgeliefert. NSIDE hatte (noch) keine Möglichkeit, die Effektivität der Behebung zu überprüfen.