Nachlese: Gehärteter Online-Banking-Browser S-Protect, neue Version, neue Erkenntnisse

Sicherheit (Pexels, allgemeine Nutzung)Der Deutsche Sparkassen- und Giroverband stellt mit dem S-Protect einen "gehärteten" Browser bereit, der Online-Banking-Kunden der Sparkassen vor den Risiken bei Bankgeschäften auf Windows PCs oder Macs besser schützen soll. Bei einem Test stellte sich heraus, dass diese Software in einer Komponente anfällig für DLL-Hijacking war. Inzwischen haben die Entwickler nachgebessert und gegenüber mir auch einige Details zum technischen Konzept des gehärteten Browsers S-Protect offen gelegt. In nachfolgendem Text gehe ich auf die Informationen und Erkenntnisse zur aktualisierten Fassung von S-Protect ein.


Anzeige

Ein kurzer Rückblick

Vom deutschen Sparkassen- und Giroverband wurde das Projekt eines gehärteten Browsers zum Online-Banking auf Desktop-Systemen (Mac, Windows) angestoßen. Und die Sparkasse Niederrhein stellt den Browser als S-Protect im Moment im Rahmen eines Pilot-Projekts auf ihrer Webseite als sichere Lösung zum Online-Banking auf dem PC an.

Bei heise gab es zum 2. Mai 2022 den Artikel Sichereres Online-Banking mit gehärtetem Browser der Sparkassen über dieses Konzept, und ich hatte mir zum Artikel die Notiz verfasst "da solltest Du bei Gelegenheit mal drüber bloggen – denn der Ansatz, einen "gehärteten" Browser für Online-Banking zu verwenden, klang für mich spannend.

Sicherheitsexperte Stefan Kanthak hatte sich die Lösung S-Protect der Sparkasse Niederrhein in Bezug auf Sicherheitsprobleme angesehen und stieß darauf, dass der Download s-protect.exe anfällig für DLL-Hijacking-Schwachstellen sei.

Stefan Kanthak hatte mich bei den Mails zwischen der IT der genannten Sparkasse und sich auf cc gesetzt, so dass ich über die sich abzeichnende Problematik im Bilde war. Im Mail-Austausch zeichnete sich für mich keine irgendwie geartete Lösung ab, so dass ich das Modul ebenfalls einem eigenen Test unterzog und die DLL-Hijacking-Schwachstelle im Download s-protect.exe verifizieren konnte. Am 9. Mai 2022 hatte ich die Ergebnisse im Artikel Gehärteter Online-Banking-Browser S-Protect, ein Totalausfall? dokumentiert.

Neue Entwicklungen und Erkenntnisse

Mit obigem Artikel war das Thema aus meiner Sicht abgeschlossen, die Entwickler konnten nachbessern oder auf den Sachverhalt reagieren. Durch Leserkommentare konnte ich aber Kontakt mit den Entwicklern aufnehmen. Zum 17. Mai 2022 gab es dann ein Telefonat, in dessen Nachgang mir diverse Informationen bereitgestellt wurden. Das ist der Anlass für diesen Nachfolgeartikel.

Anfälligkeit des Starters behoben, Browsersicherheit nicht getestet

Die Entwickler haben mir gegenüber bestätigt, dass das seinerzeit von mir getestete Modul s-protect.exe anfällig für DLL-SearchPathHijacking war. Das Konzept der Entwickler besteht aber aus zwei Komponenten:

  • Dem sogenannten Starter s-protect.exe, der vom Benutzer von der jeweiligen Sparkassenseite als portable Anwendung heruntergeladen wird.
  • Dem eigentlichen gehärteten Browser, der von s-protect.exe auf der Maschine eingerichtet wird.

Im Sinne der Transparenz: Diese Information wurde von keiner der Sparkassen, wo der Download erhältlich ist, auch nur angedeutet – das habe ich durch die Diskussion mit den Entwicklern erfahren.

Alle Ausführungen in meinem Artikel bezogen sich ausschließlich auf den sogenannten Starter s-protect.exe, der für DLL-SearchPathHijacking anfällig war. Ob dies ggf. auch für den eigentlichen gehärteten Browser zutrifft, wurde von mir nicht mehr getestet. Dafür gab es zwei Gründe:


Anzeige

  • Im Artikel stand die DLL-Hijacking-Schwachstelle des vom Nutzer herunterladbar und ausführbaren Moduls s-protect.exe in der Betrachtung des Sicherheitskonzepts im Vordergrund.
  • Weiterhin verweigerte der Starter in meiner Windows 7-Umgebung anschließend jegliche Funktion, so dass zusätzliche Komponenten des Browsers erst gar nicht heruntergeladen und eingerichtet wurden.

Es lässt sich also festhalten, dass der gehärtete Browser von mir nicht separat (und nach meinem aktuellen Kenntnisstand auch nicht von Stefan Kanthak) getestet wurde.

Stefan Kanthak wies in seiner Antwort auf den Punkt "der Browser wurde nicht getestet" darauf hin, dass es dazu auch keine Veranlassung gab: "Es genügt, eine Schwachstelle aufzuzeigen, um Konzept zu zerlegen. Wieso sollte ich weitere unbezahlte Arbeit machen."

Die nachfolgenden Informationen, die mir nun vorliegen, blieben daher unberücksichtigt. Nach einer telefonischen Diskussion schrieben mir die Entwickler am 17. Mai 2022 zum Sachverhalt folgendes:

  • Der Starter war anfällig für DLL-SearchPathHijacking. Herr Kanthak hat leider nur den Starter auf Sicherheit überprüft. [Dazu verweise ich auf die obige Stellungnahmen von Herrn Kanthak.] Seine Testergebnisse lassen daher keine Rückschlüsse auf die Sicherheit des Browsers zu.
  • Wir haben Teile der Sicherheitsfunktionen des Browsers auf den Starter ausgedehnt, so dass der Starter jetzt nur System-DLLs aus dem Windows-Verzeichnis nutzt.
  • Der Browser ist geschützt durch ein Zwiebelschalenmodell unterschiedlicher Sicherheitsfunktionen. Auch wenn man einen Mechanismus angreift, sind andere Mechanismen in der Lage gegenzuhalten.
  • Ein großer Teil der Sicherheit wird durch das Whitelist-Konzept erzeugt. Dies unterscheidet den Bank-Browser strukturell von allen anderen Browserkonzepten.

Zur Aussage, dass die Testergebnisse von Herrn Kanthak keine Rückschlüsse auf die Sicherheit des Browsers zulassen, antwortete dieser:

Jede vom Starter geladenen DLL kann bzw. konnte jede Komponente des anschließend gestarteten Browsers kompromittieren, beispielsweise die Signaturen immer als gültig ausweisen und den Browser mit ausgetauschten Dateien starten!

Ich habe diese Hinweise zum Anlass genommen, den sogenannten Starter (s-protect.exe) erneut von der Webseite der Sparkasse am Niederrhein herunterzuladen und in einem Sicherheitstestbett auf die DLL-Hijacking-Schwachstelle zu testen. Zudem ermöglichen mir die jetzt vorliegenden Informationen eine etwas erweiterte Betrachtung.

Kurzfassung des aktuellen Stands: Die Ausführung der Entwickler lässt sich bestätigen, in meiner Testumgebung konnte ich in diesem Modul keinerlei DLL-Hijacking-Anfälligkeiten mehr feststellen. Dieser Punkt ist inzwischen durch die Nachbesserung abgeräumt.

Hinweis auf nicht unterstützte Windows-Versionen

In meiner Testumgebung verwende ich bevorzugt Windows 7 SP1 mit Extended Security Update-Support (ESU). Das Betriebssystem wird ja von Microsoft noch bis Januar 2023 mit Sicherheitsupdates versorgt. In der Anfang Mai 2022 getesteten Form verweigerte S-Protect aber die Funktion und meldete sich mit diesem Dialogfeld.

S-Protect-Meldung alt

An dieser Stelle rätselte ich, was da an nicht erfüllten Systemvoraussetzungen gegeben sei. Der Hinweis, das Log-Protokoll in die Zwischenablage zu kopieren, brachte mich nicht weiter, da diese Informationen verschlüsselt waren. Bei meinem Telefonat mit den Entwicklern stellte sich heraus, dass S-Protect (auf Anforderung von Kunden) die Funktion auf Betriebssystemen sofort einstellt, wenn diese nicht mehr im Support für die Allgemeinheit sind. Beim Test der aktuellen Fassung von S-Protect erhalte ich nun diese wesentlich aufschlussreichere Meldung.

S-Protect-Meldung

Also auch hier wurde nachgebessert, mit der Anforderung kann der Benutzer etwas anfangen. Das Log-Protokoll ist zwar weiterhin verschlüsselt, aber normale Benutzer können damit eher nichts anfangen – das ist aus meiner Sicht für die Zielgruppe in Ordnung. An diesem Punkt kann ich also feststellen, dass die zwei Kritikpunkte aus meinem ursprünglichen Artikel im Rahmen der Nachbesserung durch die Entwickler von Coronic beseitigt wurden und somit gegenstandlos sind.

Erläuterungen der Entwickler zum S-Protect-Konzept

Inzwischen liegt mir eine schriftliche Stellungnahme der Entwickler zum Konzept von S-Protect und den von mir im ersten Artikel aufgeworfenen Sicherheitsfragen vor. Hier ein Abriss dessen, was mir jetzt an Informationen vorliegt.

Der Starter war anfällig für DLL-SearchPathHijacking, der Browser ist es nicht

Getestet wurde von mir ursprünglich der Starterprozess s-protect.exe, nicht jedoch den Browser selbst. Der Starter s-protect.exe ein gesondertes Programm, das den Browser auf Aktualität prüft, bevor der eigentliche Browser startet. Der Starter (als reiner Update-Prüfer) stand, so die Entwickler in der Stellungnahme, daher sicherheitstechnisch nicht so stark im Fokus wie der Browserprozess. Dafür gibt es zwei Gründe:

  • Es wurde lediglich gezeigt, dass man den Starter dazu bringen kann eine DLL zu laden und dann eine Falschmeldung anzuzeigen. Das kann man aber auch, indem man die Starter-Exe löscht und eine beliebige Datei gleichen Namens auf den Desktop legt. Das ist für alle Computer gleich: lösche die Anwendung, ersetze sie durch die Falschmeldung, das funktioniert immer. Ein gegen DLL-SearchPathHijacking abgesicherter Starter kann weiter durch Austauschen der Exe manipuliert werden.
  • Der Browser ist mit mehreren Sicherheitsmethoden (dazu unten etwas mehr) geschützt. Eine geladene DLL im Starter stellt keinen erfolgreichen Angriff auf den Browser da.

Anmerkungen: Das Problem, dass die Dateien wie s-protect.exe, die beim Download durch den Nutzer mit dessen Berechtigungen abgelegt werden, durch jeden Prozess, der über diese Benutzerrechte verfügt, ersetzt wird, hatte ich im ursprüngliche Artikel ja bereits angedeutet. Das ist das prinzipielle Problem bei portablen Apps.

Der Browser liegt im Benutzerprofil

Ich habe dann nachgesehen, beim Starten von s-protect.exe wird von diesem der eigentliche Browser protect.exe samt den benötigten Dateien im Benutzerprofil:

C:\Users\<username>\AppData\Local\CORONIC\

abgelegt. Beim Aufruf lässt sich über ein Dialogfeld eine Desktop-Verknüpfung auf den Starter anlegen. Der Profilordner mit den Dateien des gehärteten Browsers ist mit den jeweiligen Benutzerrechten beschreibbar – die Dateien im Benutzerprofil ließen sich also durchaus austauschen. Umgehen ließe sich dies lediglich durch eine installierbare (msi-Installer-) Version des s-protect-Pakets, die dann administrative Berechtigungen erfordert.

Die Dateien in diesem Profilordner sind allerdings digital durch Coronic signiert und können beim Start des Moduls starter.exe per Internet aktualisiert werden. Auf meinem Windows 10-Testsystem benötigt der Browser dann auch einige Zeit, bis er arbeitsfähig ist. Wenn ich es richtig gesehen habe, wird die QT5 Web-Engine zur Implementierung des Browsers verwendet.

Wie es letztendlich um die Sicherheit dieses Pakets bestellt ist, vermag ich nicht abschließend zu beurteilen – und sehe dies auch nicht als meine Aufgabe (bin ja kein bezahlter Pentester). Ein Anfälligkeit gegen DLL-SearchPathHijacking konnte ich bei einem schnellen Test nicht feststellen. Die notwendigen DLLs im Profilverzeichnis trugen ein aktuelles Datum. Hier kommt es in meinen Augen darauf an, wie zuverlässig und zeitnah der Entwickler ggf. in den Helper-Bibliotheken aufgedeckte Sicherheitslücken durch aktualisierte Module schließen kann. Jedenfalls wird der gehärtete Browser beim Start auf Aktualisierungen geprüft. Und zur Frage: Müssen Schwachstellen sofort gefixt werden, da sehr kritisch, gibt es im folgenden Text auch noch eine Abschätzung.

Modifikationen am Starter

Auf Grund meines Artikels haben die Entwickler reagiert und schreiben, dass sie Teile der Sicherheitsfunktionen des Browsers auf den Starter ausgedehnt haben. Hier die Kernpunkte der schriftlichen Aussagen:

Trotz unserer Anmerkungen im vorangegangenen Abschnitt, haben wir uns entschieden den Starter mit Sicherheitsmechanismen des Browsers weiter abzusichern.

Die Entwickler möchten damit der Diskussion vorgreifen, wann genau welche Sicherheitsmechanismen am besten ergriffen werden sollten. Sie merken auch an, dass es nicht schade, den Starter stärker abzusichern. Aber das ist nicht wirklich hilfreich, das der betreffend abgesicherte Starter weiterhin durch einfachen Austausch der exe-Datei manipuliert werden könnte.

Das gilt aber auch für die Dateien des eigentlichen Browsers und der Bibliotheken, die von einem Angreifer mit lokalen Benutzerrechten ausgetauscht werden könnten. Damit könnte das nachfolgend skizzierte Sicherheitskonzept des Browsers durch Ersetzen der prüfenden Module außer Kraft gesetzt werden. Aus praktischen Erwägungen stellt sich aber die Frage, ob Angreifer diesen Aufwand treiben.

Wie wird der Browser geschützt?

Kern- und Angelpunkt des ganzen Ansatzes ist die Frage, ob es Angreifern gelingt, die Komponenten des gehärteten Browsers zu kompromittieren – oder ob Schwachstellen, die vielleicht durch fehlende Updates der Komponenten entstehen, ausgenutzt werden könnten. Hier hatte ich eine kurze Diskussion mit den Entwicklern und diese haben mir auch schriftlich einige zusätzliche Informationen zukommen lassen. Der verfolgte Ansatz: Der Browser ist geschützt durch ein Zwiebelschalenmodell unterschiedlicher Sicherheitsfunktionen – und Geschäftsprozesse im Internet sind nur so sicher wie der Browser mit dem sie durchlaufen werden. Dazu schreiben die Entwickler:

  • Die Aufgabe eines Browsers ist es, jede Internetseite anzuzeigen und jedes Video abzuspielen. Damit ist der Browser das genaue Gegenteil einer sicheren Software, denn er erlaubt erst einmal alles. So zielen auch die Angriffsmethoden von Banking-Trojanern stets auf die Manipulation von Browserfunktionen. Sie verändern die Seitendarstellung der Bank im Browser und täuschen die Nutzer mit gefälschten Einblendungen.
  • Um dem zu begegnen, wurden die technischen Schutzverfahren von Banken in den vergangenen Jahren immer komplexer. Auch Zweikreisverfahren nützen wenig, solange der Nutzer sich, basierend auf den gefälschten Meldungen im Browser, nicht korrekt verhält und sich gewissermaßen selber ausraubt. Gerade bei diesen fehlgeleiteten und technisch nicht aufgeklärten Kunden muss man heute attestieren, dass jeder Online-Geschäftsprozess nur so sicher ist, wie der Browser mit dem er durchlaufen wird.
  • Könnte man den Zugriff der Trojaner auf den Internetbrowser des Bankkunden verhindern, so wäre der im Browser ablaufende Geschäftsprozess sofort wieder sicher – weil gegen Fehlbedienung gefeit.
  • Gleichzeitig muss der Browser so einfach zu benutzen sein, dass ihn auch nicht technisch-affine Kunden (denn die werden üblicherweise beklaut) problemlos und fehlerfrei benutzen können. Wegen dieser einfachen Nutzbarkeit ist der Browser als portable Anwendung designed, man kann ihn herunterladen, ihn ohne Adminrechte nutzen, alles ist auf Endkunden ohne technische Vorbildung ausgelegt.

Hier verwenden die Entwickler den Ansatz: Der Browser kontrolliert sich selbst und die genutzten Bibliotheken anhand von Zertifikaten.

  • Im Update-Prozess des Starters werden sämtliche für den Browser benötigten Dateien heruntergeladen. Diese werden anhand ihrer Zertifikate und Prüfsummen kontrolliert. Auch der Update-Server selbst wird überprüft und auch der Update-Server überprüft den Client anhand seiner Zertifikate.
  • Alle im Programmverzeichnis des Browsers befindlichen DLLs sind signiert.
  • Der Browser selbst ist mit einem Code-Zertifikat signiert, sodass der Nutzer jederzeit überprüfen kann, dass es sich tatsächlich um die Browser-Datei der Firma CORONIC handelt.
  • Beim Programmstart des Browsers wird erneut die Identität der Softwaresignaturen überprüft. Die Prüfung wird für alle Artefakte der Software durchgeführt.
  • Der gesamte Prozessspeicher wird zur Laufzeit stetig auf Manipulation überwacht.

Hinweis der Entwickler: Auch das bisher mögliche Nachladen einer DLL im Starterprozess (wie von Herrn Kanthak gezeigt) hätte keine Auswirkung auf den Browserprozess. Selbst wenn er weitere manipulierende DLLs nachgeladen hätte, könnten diese im Browser-Prozessraum nicht agieren und die Sicherheit des Browsers nicht beeinträchtigen.

Anmerkung: Diese Annahme der Entwickler im letzten Absatz kann ich nicht abschließend werten und bestätigen oder widerlegen, da mir da die zeitlichen Ressourcen und auch die Kenntnisse fehlen, dies bis zum letzten Winkel zu durchdenken und zu überprüfen. Ich gestehe aber, dass mir genau an dieser Stelle die meisten Bauchschmerzen kommen. Denn gelingt es, nur ins unreine gedacht, einem Angreifer den Starter und dann die initale Updater-Komponente samt den Prüfroutinen des gehärteten Browsers auszutauschen, wäre eine Manipulation in meinen Augen denkbar.

Stefan Kanthak antwortete zu meinem im vorherigen Absatz aufgeworfenen Punkt: Ich wage sehr zu bezweifeln, dass a) alle Dateien digital signiert sind, und b) die Signaturen bei jedem Laden geprüft werden (das Zeitfenster zwischen der Prüfung durch den Starter und dem Laden im Browser ist sicher gross genug, um die signierten Dateien auszutauschen), und c) dass alle der vielen verwendeten Drittanbieter-Komponenten wie Qt5 keine Schwachstellen haben (Qt5 beispielsweise hat bis vor kurzem Dateien aus einem gaenzlich anderen Pfad C:\… geladen), und d) keine der DLLs/EXE-Dateien des Browsers anfaellig fuer DLL-Hijacking ist.

Das Whitelist-Konzept des Browsers

Bei der Diskussion mit den Entwicklern kam natürlich auch ein Punkt auf, der nicht von der Hand zu weisen ist: 90 % aller mit Schadsoftware hinterlegten Internetseiten werden von den gängigen Standardbrowsern nicht (schnell genug) erkannt. Der Nutzer infiziert sich beim Besuchen der manipulierten Internetseite oder seine Zugangsdaten (PIN) werden abgefischt. Dies passiert mit dem S-Protect Bank-Browser nicht, so die Entwickler, da dieser nur die freigegebenen Seiten der jeweiligen Bank aufrufen kann.

Um das sicherzustellen überprüft der S-Protect-Browser nicht nur die Gültigkeit der Bank-Zertifikate, sondern kontrolliert die Zertifikate anhand ihres Hashwertes auf Echtheit. Das Whitelist-Konzept hat nach Ansicht der Entwickler drei positive Folgen für den Nutzer:

  • Wenn der Nutzer immer daran denkt, seine Bankgeschäfte nur mit dem Bank-Browser zu machen, kommt er auf keine Phishing-Seiten.
  • Die Anforderungen an eine dauerhafte Aktualität der Rendering-Engine entfällt, denn der Nutzer bewegt sich nur auf den "guten Seiten" seiner Bank.
  • Da die meisten Social-Engineering-Angriffe per Telefon darauf basieren im Vorfeld Kontonummer und die PIN zu entwenden, scheitern auch viele betrügerische Telefonanrufe, denn aus dem Bank-Browser lassen sich die Anmeldedaten nicht herauskopieren.

Am Kern dieser Argumentation ist natürlich etwas dran. Verwendet der Bankkunde immer den von seinem Institut bereitgestellten, gehärteten S-Protect-Browser, kommt er auf keine fremde Seiten. Selbst wenn eine Schwachstelle im Browser existiert, wäre dies weniger kritisch, da die Webseiten der Banken für Online-Banking i.d.R. keine Schadsoftware beherbergen – Angriffe aus dieser Ecke durch eine kompromittierte Online-Banking-Seite sind eher nicht zu erwarten.

Mein abschließendes Fazit

Das Konzept des gehärteten Browsers, der sich selbst und die Online-Bankseite zur Sicherheit überprüft, ist nachvollziehbar. Der einzige Punkt, der mich am gesamten Konzept fragend zurücklässt: Gibt es ein Szenario, bei dem ein Angreifer die auf dem Rechner liegenden Komponenten des gehärteten Browsers so austauschen und manipulieren kann, dass der S-Protect-Browser zwar startet, die vermeintlichen Prüfungen nicht mehr ausführen kann und dann Daten vom Nutzer, die dieser ggf. eingibt, abgreift.

Ist der gestartete Browser integer, verhindert er zumindest das Anfertigen von Screenshots oder das Markieren und Kopieren von Inhalten in die Windows-Zwischenablage (das ist mir aufgefallen, als ich die Lizenzbedingungen für diesen Beitrag herauskopieren wollte). Zudem stellt er sicher, dass der Benutzer auf der Online-Banking-Seite seines Instituts unterwegs ist.

Aber an dieser Stelle kommen wir mit der Annahme "der gestartete Browser ist integer" etwas zum Kernproblem des gesamten Ansatzes, welches Stefan Kanthak in folgender Aussage aufgreift:

Sobald der Austausch einer Datei zwischen Prüfung und Laden möglich ist oder im Browser eine Datei aus einem anderen Pfad geladen wird, ist die Aussage "der Browser ist ohne Installation sicher verwendbar" nicht mehr haltbar.

Da der Installationspfad überall gleich %LOCALAPPDATA%\CORONIC\ ist, kann ein Angreifer dies für Manipulationen nutzen.

Hier kommt es in meinen Augen auf die Betrachtungsweise an. Stelle ich die Frage, ist es aus Sicherheitsgründen besser, beim Online-Banking den S-Protect-Browser anstelle eines Standard-Browsers zu verwenden, lautet die Antwort Ja. Denn der Browser kann sich nur mit der Bankingseite der jeweiligen Sparkasse verbinden. Der Preis besteht darin, dass der Nutzer penibel darauf achten muss, den S-Protect-Browser für sein Online-Banking zu verwenden. Auf meiner langsamen Testmaschine dauert es schon mal eine Minute, bis der S-Protect-Browser arbeitsbereit ist. Das läuft dann doch auf eine Geduldsprobe hin. Steht der Bankkunde dies durch, oder greift er doch zu seinem Standard-Browser?

Gehärteter Online-Banking-Browser S-Protect
Gehärteter Online-Banking-Browser S-Protect, Sparkasse am Niederrhein

Ich möchte hier eine Analogie anführen: Ein Sicherheitsgurt beim Auto schützt vor den Folgen eines (leichteren) Unfalls oder milder diese, kann aber keinen Unfall als solches verhindern.

Als problematisch empfinde ich in diesem Kontext, wie der S-Protect-Browser für die Zielgruppe beworben wird. Die Sparkasse am Niederrhein preist diesen ja mit "Rundumschutz für Ihr Banking" an. Das verleitet Nutzer u.U. zum Gefühl der totalen Sicherheit (mir kann jetzt nichts mehr passieren), die aus den oben skizzierten Gründe so nicht gegeben ist. Wird das System kompromittiert, hilft der S-Protect-Browser u.U. auch nicht mehr. Hier sehe ich die größte Gefahr: Es wird eine Sicherheit vorgespiegelt (der Sicherheitsgurt verhindert den Unfall), die so nicht gewährleistet werden kann.

Was bleibt noch anzumerken? Die Entwickler haben nach meinem ersten Artikel schnell reagiert und den Browser bzw. dessen Startmodul überarbeitet. Die initialen Kritikpunkte aus meinem ersten Artikel sind damit ausgeräumt – die aktualisierte Fassung des Browser liegt bereits auf der Seite der betreffenden Bank. Das ist top. Auch zeigten sich die Entwickler im Austausch offen und haben mir die obigen Informationen bereitgestellt – ein positiver Zug, den ich so nicht (immer) von anderen Firmen in ähnlichen Situationen kenne.

Was im Rückblick nicht ganz optimal gelaufen ist: Ich hätte ggf. versuchen können, die Entwickler vorab zu recherchieren und zu kontaktieren. Da ich aber über den Mail-Austausch zwischen Stefan Kanthak und der betreffenden Sparkasse im Bilde war, deutete sich für mein Gefühl ein "kein Weiterkommen" an. Ich habe daher gehandelt, den Artikel verfasst und Stefan Kanthak vorab drüber schauen lassen.

Andererseits wurde im Beitrag ja keine Sicherheitslücke im eigentlichen Sinne offen gelegt, die sofort einen unberechtigten Abfluss von Daten ermöglicht hätte. Vielmehr drehte sich alles um die Frage: Wie sicher müssen/sollen bestimmte Module sein und was ist an Design-Kriterien zu beachten. Daher waren die Kriterien für ein resposible disclosure auch nicht gegeben. Mit dem hier vorliegenden Nachtragsartikel, den sowohl die Entwickler als auch Stefan Kanthak vorab lesen konnten, steht jetzt eine weitergehende Betrachtung zur Verfügung, so dass sich Jeder über die Pros und Cons informieren und dann seine Einschätzung treffen kann.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit, Software abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

20 Antworten zu Nachlese: Gehärteter Online-Banking-Browser S-Protect, neue Version, neue Erkenntnisse

  1. Stephan sagt:

    Danke für deine Arbeit, Günter! Ein gehärteter Browser ist erstmal keine schlechte Idee, aber man muß es auch können.

    Und in der Praxis stellen sich bei dem Konzept ganz andere Fragen:
    1. Den Browser im Benutzerverzeichnis zu installieren ist eine grundsätzlich völlig unsichere Idee, wie du bereits beschrieben hast. Portable Apps können leicht von Malware verändert werden.
    2. Programme im Benutzerverzeichnis bringen auch noch andere Probleme mit sich. Insbesondere so ein Starter, der weitere ausführbare Dateien nachlädt, wird die Virenscanner auf die Palme bringen. Der langsame Start könnte auch damit zusammenhängen. Teams hat ein ähnliches Problem und Microsoft empfiehlt sogar, Teams im Virenscanner zu whitelisten, was eine totale Katastrophe ist.
    https://docs.microsoft.com/en-us/microsoftteams/troubleshoot/teams-administration/include-exclude-teams-from-antivirus-dlp
    3. Es ist auch völliger Mist für gehärtete und verwaltete Geräte. Auf einem gut gehärteten Gerät will mit mit AppLocker und Co. Ausführung aus dem Benutzerverzeichnis komplett unterbinden.
    4. Für den technisch nicht versierten Benutzer ist es doch noch schwieriger, zu verifizieren, ob das Programm echt und aktuell ist, als die URL im Chrome, Edge oder Firefox zu prüfen. Das Konzept, daß er das manuell herunterlädt, ist auch schon realitätsfern. Selbst in stark kontrollierten Stores wie beim iPhone tauchen ständig gefälschte Apps auf. Zum Beispiel gab es mal von einer Schweizer Kantonalbank eine gefälschte PhotoTAN-App fürs iPhone. Das fiel lange nicht auf, weil die Bank gar kein PhotoTAN anbietet. Aber woher soll der normale Kunde das wissen? Er glaubt, die App wäre von der Bank, und gibt seine Daten ein.

  2. Stephan sagt:

    Man beachte auch die inkonsistenten Domains der Sparkassen, zum Beispiel:
    http://www.sparkasse-niederrhein.de
    http://www.berliner-sparkasse.de
    http://www.haspa.de

    Ein Angreifer könnte einfach ha-spa.de oder spaha.de registrieren. Wie soll ein normaler Bankkunde wissen, welche Domain echt ist?

    Besser wäre:
    niederrhein.sparkasse.de
    berlin.sparkasse.de
    hamburg.sparkasse.de

    Die Volksbanken hatten auch mal sicher-online-einkaufen.de benutzt, da haben Sicherheitsforscher dann online-sicher-einkaufen.de usw. registriert, um sie zu ärgern …

    • Bernd B. sagt:

      Sicherer? Ja!
      Besser? Weiss nicht, ich wollte als selbständiges Unternehmen nicht meine gesamte online-Unternehmenskommunikation von Dritten abhängig machen (Domaininhaber von sparkasse.de ist ja eine dritte Partei, evt. der Sparkassenverband).

  3. T Sommer sagt:

    Wenn man mir Sonntags morgens beim Frühstück so einen Artikel auf mein Tablet legt, bekomme ich irgendwie Lust das einmal näher in Augenschein zu nehmen.

    Ich habe in einer VM mit Windows 10 das ganze heruntergeladen und mir den Ordner näher angesehen. Was auffällt ist, das das Programm einen Seriennummer hat und diese sich im Ordner der App wiederfindet.

    Ich habe mir einige Dateien angesehen und diese waren ausnahmslos mit einer Digitalen Signatur von CORONIC signiert – auf die von QT5 und Microsoft.
    Dann habe ich einen Test mit meiner eigenen Sparkasse gestartet, die das Programm (noch) nicht anbietet, gemacht und konnte mich dort anmelden! Das Angebot, die eingegeben Daten zu Speichern passt m.E. nicht zum Konzept!

    Dann habe ich mir die msruntime140.dll in dem S-Protect Ordner zu Brust genommen und diese durch ein im system32 befindliche Original Microsoft Version ersetzt. Das Programm gestartet – läuft. Die Datei im S-Protect Ordner wurde wieder durch eine von Coronic ersetzt! Das ist doch mal etwas!

    Dann habe ich die Kiste erstmal neu gestartet und die msruntime140.dll erneut durch die original MS-Datei ersetzt. Allerdings habe ich dieses Mal die Datei "schreibgeschützt". Die App gestartet und man konnte sehen, das das Programm versucht die Anwendung zu aktualisieren – da das nicht geklappt hat, hat der Browser anschließen eine Fehlermeldung (!) auf dem Bildschirm angezeigt:
    ——
    Unzulässige Speichermanipulation
    Ein Programm versucht den Programmspeicher von S-Protect zu manipulieren.

    Eine solche Manipulation kann verschiedene Ursachen haben.

    Sie nutzen ein sehr intrusives Programm, das versucht, sich in andere Programme "einzuklinken". Dies kann auch durch bestimmte Laufzeit-Schutzprogramme verursacht werden.
    Ein Schadprogramm agiert im Arbeitsspeicher des Computers.
    Da die Ursache für die Manipulation nicht bekannt ist, muss S-Protect aus Sicherheitsgründen beendet werden.

    Falls der Fehler weiterhin auftritt, wenden Sie sich bitte an den Support
    —-
    Das das Log nicht lesbar ist, ist zum einen Schade (für den Admin) und gut damit der Hacker nichts davon hat.

    "Sie nutzen ein sehr intrusives Programm," – Boah ich fühle mich geehrt – was bin ich doch böse ;-)

    Webseiten die nicht zur Sparkasse gehörten wurden blockiert (borncity), ebenso anderen Banken.

    Also kann man davon ausgehen, das hier der Schutz des Programmes gewährleistet wird. Übrigens konnte ich die Fehlermeldung mit Copy & Paste aus der VM in den Host-PC in den Editor übertragen. Ein Screenshot mit Boardmitteln innerhalb des Windows in der VM ging nicht.

    • Stefan Kanthak sagt:

      "Also kann man davon ausgehen, das hier der Schutz des Programmes gewährleistet wird. "

      AUTSCH: NEIN, DAS KANN "MAN" NICHT!
      Kopiere NICHT die Original-DLLs, sondern meine "Minen" nach "%LOCALAPPDATA%\CORONIC", schütze sie gegen Überschreiben und beobachte.
      1. Wird die Integrität NACH dem Laden der DLLs geprüft, dann hat Windows die DllMain()-Funktion bereits ausgeführt — die kann die Funktion zur Integritätsprüfung einfachst kurzschliessen;
      2. Wird die Integrität VOR dem Laden der DLLs geprüft, dann können diese (beispielsweise dank "opportunistic locks") zwischen Prüfung und Laden ausgetauscht werden.

      Abgesehen davon: der "Starter" ist nach wie vor anfällig für DLL-Hijacking, womit 1. auch dort gilt!

  4. Paul sagt:

    Wieso kann der Kunde in seinem Konto nicht einstellen das er nur noch mit dem Sicherheits-Browser arbeiten will?
    Er muss ja auch sagen welchen 2. Faktor er benuten will. (Oder ist der nicht mehr nötig?)

    Welche Bank ist es, die für Telefon-Banking dieselbe Pin benutzt? Gibt es das wirklich?

    • Stephan sagt:

      Es gibt keine Möglichkeit, den Client zu erkennen. Der User Agent kann leicht gefälscht werden.

      • Paul sagt:

        Es soll kein bösiwilligrr Angriff verhindert werden sondern die Tapsigkeit der Users.
        Für den Anbieter entsteht so ein Dritter Faktor der neben Sicherheit und Komfort für den Kunden immer an erster Stelle steht: Der Support.

        Natürlich hat man verloren wenn man einen aktiven Virus auf seinem Computer hat. Da hilft auch ein Sicherheits-Browser nichts.

        Ob mein es Browser ist scheint durchaus möglich zu sein.
        Z. B. Sollte man auch bei Amazon 2FA aktivieren.
        Dort kann man sagen, das man auf diesem Rechner kein 2FA mehr möchte, weil ed doch sehr nervig ist.
        Natürlich ist das umgehbar und gefährlicher als jedes mal den 2. Faktor auszuhandeln.

    • Günter Born sagt:

      Konto meint Bankkonto – müsste man mit der Bank klären. Halte ich aber für problematisch, da man blockiert ist, wenn S-Protect streikt.

      • Paul sagt:

        Ja, das ist das Problem. Aber wenn die Batterie in meinem Kobold-Karten -Leser sich wieder leergelegen hat habe ich auch so ein Problem.
        Oder wie gesagt: Ich kann wählen mit welchem Gerät der 2 Faktor erzeugt wird. Ist das Gerät kaputt…
        Nach Basel 2 muss jedes anmelden mit 2 FÄ erfolgen.
        Manche Banken interpretieren das zwar anders, aber.

  5. JohnRipper sagt:

    Der Browser liegt im Benutzerprofi

    –> wird bei mir nicht laufen…wer macht denn sowas?

  6. A. Nonym sagt:

    Was ist, wenn der PC kompromitiert ist? Also ein key-logger oder Mimikatz läuft?

    Gibt es eine Empfehlung einen weiteren User nur für Banking rinzurichten? Oder gleich einen Pc nur fürs Banking.

  7. Ulf sagt:

    Ich finde das Konzept sehr interessant und es scheint doch nicht so schlimm zu sein wie behauptet. Ich werde den Browser in Zukunft nutzen. Was wäre die Alternative? Mein normaler Browser?

  8. Cestmoi sagt:

    CORONIC soll das Ding erstmal von irgendeiner einschlägigen Bude zertifizieren lassen, vor dem Hintergrund von /1/ (Bsp.) aber bitte keine TÜV!

    Vorher installier' ich definitiv nichts.

    /1/
    https://www.heise.de/security/meldung/Die-Illusion-von-Safer-Shopping-848125.html

    • Karl sagt:

      > CORONIC soll das Ding erstmal von irgendeiner einschlägigen Bude zertifizieren lassen, vor dem Hintergrund von /1/ (Bsp.) aber bitte keine TÜV!

      Eine nachvollziehbare Zertifizierung einer Instanz, die noch nicht zu negativ aufgefallen wäre.
      Derart relevante Software sollte aber zusätzlich öffentlich reviewed werden. Die Sparkassen sind öffentlich-rechtliche Unternehmen und sollten selbst darauf drängen, dass der Source-Code offen gelegt wird. Schützt ggf. auch vor schlechten Erfahrungen (neXenio/Luca), öffentlichen Klagen und einer dauerhaften Rufschädigung.
      Ist der Browser, der da benutzt wird eigentlich eine Eigenentwicklung von CORONIC?

Schreibe einen Kommentar zu A. Nonym Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.