Es klingt gut, was der Deutsche Sparkassen- und Giroverband da angestoßen hat. Mit S-Protect legt man einen "gehärteten" Browser vor, der Online-Banking-Kunden vor den Risiken bei Bankgeschäften auf Windows PCs oder Macs besser schützen soll. Der Haken an der Geschichte: Zum Problem wird so etwas, wenn die Entwickler schlicht ihre Hausaufgaben nicht gemacht haben. Denn der "sichere" S-Protect-Browser ist unter Windows anfällig für DLL-Hijacking und somit ein potentielles Sicherheitsrisiko erster Güte. Zudem lässt das aktuelle Konzept den einfachen Austausch der Anwendung unter Windows zu, so dass auch dort ein Risiko besteht. Ich habe das Ganze mal etwas aufbereitet und zeige, wo es aus meiner Sicht krankt. Ergänzung: Die Entwickler haben nachgebessert, siehe am Artikelende.
Anzeige
"Gehärteter" Online-Banking-Browser S-Protect
Problem beim Online-Banking ist, dass unvorsichtige oder unerfahrene Nutzer durch allerlei Gefahren bedroht sind. Das fängt bei Phishing-Nachrichten an, die Online-Banking-Kunden auf gefälschte Anmeldeseiten umgeleitet werden, wo Betrüger die Zugangsdaten abfischen. Und das Ganze reicht bis hin zu Browsern, die durch infizierte Add-ons unsicher werden. Damit soll nun Schluss sein, denn der Deutsche Sparkassen- und Giroverband hat mit S-Protect einen gehärteten Online-Banking-Browser entwickeln lassen, der Kunden zur Verfügung steht.
Gehärteter Online-Banking-Browser S-Protect, Sparkasse am Niederrhein
Die Sparkasse am Niederrhein bewirbt den Browser S-Protect, der im Moment als Pilot-Projekt angeboten wird, auf ihrer Webseite als sichere Lösung zum Online-Banking auf dem PC mit folgenden Aussagen.
Unser S-Protect ist ein sogenannter gehärteter Banking-Browser. Sie können ihn sich am besten als einen zusätzlichen Schutzschirm fürs Online-Banking vorstellen. S-Protect verhindert, dass Trojaner und andere Schadprogramme, die sich möglicherweise auf Ihrem Computer versteckt haben, das Online-Banking ausspionieren oder manipulieren können. Die Einrichtung und Benutzung von S-Protect ist kinderleicht und verschafft Ihnen einen großen Sicherheitsvorteil bei allen Finanzgeschäften.
Der Browser steht dabei sowohl für Windows als auch für macOS kostenlos für Kunden der Sparkasse Niederrhein auf deren Webseite bereit. Die Sparkasse schreibt zu den Vorteilen von S-Protect:
Anzeige
- Schutz vor Datendiebstahl, Phishing-Attacken, gefälschten Websites
- Kinderleichte Handhabung, keine Installation oder Konfiguration
- Funktion zur automatischen Anmeldung (Auto-Login)
- Keine Beeinflussung anderer Sicherheitsverfahren
Liest sich wirklich gut und klingt nach dem Ende aller Sorgen für Online-Banking-Kunden. Man muss lediglich eine Änderung der Gewohnheiten einführen und Online-Banking immer durch Aufruf des gehärteten Banking-Browsers S-Protect vornehmen.
Der Browser lässt beispielsweise nur URLs von Banken zu, blockiert aber die URLs von Phishing-Seiten. Und ganz genial: Man braucht den S-Protect-Browser nicht mal zu installieren, der Aufruf der .exe-Programmdatei unter Windows reicht, um den Browser zu starten und sich anschließend in einer "sicheren" Umgebung zu bewegen. Dass dadurch keine anderen Sicherheitsverfahren beeinflusst werden und eine automatische Anmeldung möglich ist (Auto-Logoin), erscheint wie das Tüpfelschein auf dem i. Beim Überfliegen der obigen Angaben war ich "hin und weg", konnte das wirklich sein?
"Sicherer Browser" mit DLL-Hijacking-Schwachstelle
Ich hatte die Information zum S-Protect kürzlich bei heise gesehen und eigentlich geplant, das Ganze kurz in einem Beitrag vorzustellen, war aber noch nicht dazu gekommen, mir das Ganze genauer anzusehen. Bei heise klang bereits an, dass sich die Macher von S-Protect möglicherweise weit aus dem Fenster gelehnt hätten.
Vor einigen Tagen erreichte mich eine E-Mail von Stefan Kanthak. Der Sicherheitsexperte hatte die Sparkasse Niederrhein per Mail kontaktiert, um auf die Unzulänglichkeiten des Konzepts hinzuweisen, und mich auf CC gesetzt.
Das DLL-Hijacking-Problem
In seiner Mail wies Kanthak darauf hin, dass der "gehärtete" Browser S-Protect unter einer Anfälligkeit für DLL-Hijacking-Angriffe leidet. Dahinter verbirgt sich ein Problem, wie unter Windows DLL-Bibliotheken, die eine Anwendung anfordert, geladen werden. Ruft eine Anwendung eine DLL auf, versucht Windows diese DLL-Datei mit dem betreffenden Namen im Programmordner, aus dem die Anwendung gestartet wurde, zu laden. Scheitert dies, wird das Systemverzeichnis und im Anschluss das Windows-Verzeichnis nach der DLL-Datei des betreffenden Namens durchsucht. Das geht solange, bis die DLL gefunden wurde oder alle Verzeichnisse im Suchpfad abgearbeitet sind. Der erste Treffer für den jeweiligen Namen der Datei bewirkt, dass diese DLL in den Arbeitsspeicher geladen wird.
Das Problem bei diesem Ansatz: Ein Angreifer braucht lediglich eine manipulierte DLL-Datei mit einem bekannten Namen im Programmordner abzulegen und zu warten, bis die DLL-Hijacking-Falle zuschlägt. Typischerweise dürfte der "Programmordner" das Verzeichnis downloads des Benutzerkontos sein, da dort alle Downloads des Nutzers landen. Dort eine bcrypt.dll abgelegt, schon übernimmt diese die Kontrolle bei Verschlüsselungsvorgänge. Lässt sich mit jeder DLL durchziehen, die von einer Anwendung ohne voll qualifizierte Pfadangabe für den Ladevorgang angefordert wird.
Mein Test
Im aktuellen Fall habe ich mal einen Test mit s-protect.exe unter Windows 7 SP1 (mit ESU-Support) durchgeführt, wobei das Ganze in einem speziellen Test-Bett abläuft, mit dem sich DLL-Hijacking-Angriffe einfach aufdecken lassen. Der Test hätte auch unter Windows 8.1 oder Windows 10 erfolgen können, das Prinzip ist überall gleich.
Beim Testbett handelt es sich um einen Ordner, in dem Dummy-DLLs, die typischerweise unter Windows vorhanden sind und von Anwendungen geladen werden, platziert wurden. Ruft eine Anwendung eine solche DLL auf, zeigt die Dummy-DLL das an und reicht den Funktionsaufruf im Anschluss an die eigentliche Betriebssystembibliothek weiter. Sobald also eine Warnung erscheint, bedeutet dies: Ein Angreifer hätte das durch eine geeignete DLL missbrauchen können.
Das Testbett wird von Stefan Kanthak bereitgestellt. Man kann sich die Datei Forward.cab (ist für Windows 7, für Windows X gibt es ForwardX.cab) kostenlos von seiner Webseite herunterladen und in einen Ordner entpacken. Danach führt man die zu testende Programmdatei ebenfalls in diesem Ordner aus. Einige Hinweise zum Testbett von Stefan Kanthak zur Ermittlung von DLL-Hijacking-Schwachstellen habe ich z.B. im Blog-Beitrag Die Nirsoft-Tools und die DLL-Hijacking-Schwachstellen gegeben.
Obiger Screenshot zeigt eine der zahlreichen Sicherheitswarnungen, wo S-Protect statt der gewünschten Windows-Bibliothek eine möglicherweise schädliche DLL (hier aus meinem Testordner, beim typischen Anwender aus dem Download-Ordner) geladen hätte.
In obigem Screenshot wird beispielsweise die Datei bcrypt.dll gelistet, die aus dem S-Protect-Programmordner geladen wurde. In der Praxis dürfte dies bei der überwiegenden Anzahl an Windows-Nutzern das downloads-Verzeichnis des Benutzerkontos sein. Benötigt wird aber die Windows-Bibliothek gleichen Namens aus dem Windows-Unterordner System32. Die Bibliothek enthält API-Aufrufe zur Verschlüsselung von Daten. Lädt eine Anwendung die "falsche" DLL, könnten Angreifer beliebigen Schindluder in API-Aufrufen von exportierten Bibliotheksfunktionen treiben.
Grundsätze der sicheren Programmierung verletzt
Software-Entwickler können dieses DLL-Hijacking-Problem vermeiden, indem sie beim Aufruf solcher exportierten Funktionen sicherstellen, dass sie einen vollständigen Pfad auf die gewünschte Quelle der DLL-Datei im Programmcode vorgeben. Das ist alles keine Raketenwissenschaft sondern seit 25 Jahren als gute Praxis bekannt. Kanthak weist in der (bisher unbeantworteten) Mail an die Sparkasse Niederrhein auf diesen Sachverhalt hin und verlinkt auf folgende Fundstellen:
CWE-426: Untrusted Search Path
CWE-427: Uncontrolled Search Path Element
CAPEC-471: Search Order Hijacking
Auch Microsoft gibt seit Jahren Sicherheitsempfehlungen zur Vermeidung dieses Sicherheitsproblems (wobei deren Entwickler das inzwischen ebenfalls wohl nicht mehr kennen). Kanthak hat als Hilfestellung folgende Microsoft-Seiten verlinkt.
Load Library Safely
KB2533623: Microsoft Security Advisory: Insecure library loading could allow remote code execution
KB2389418: Secure loading of libraries to prevent DLL preloading attacks
Microsoft Security Advisory 2269637
Dynamic Link Library-Suchreihenfolge
Dynamic-Link Bibliothekssicherheit
Damit hat sich das Konzept des sicheren, gehärteten S-Protect-Browsers binnen Sekunden in seine Einzelteile zerlegt. Ein Programm, welches nicht sicherstellen kann, dass wenigstens die erwarteten DLL-Betriebssystem-Bibliotheken lädt, ist schlicht nicht vertrauenswürdig.
Noch eine Schwachstelle
Auf die Überlegung, dass böse Buben ja die Programmdatei s-protect.exe überschreiben und so das Sicherheitskonzept komplett aushebeln könnten, bin ich erst erst nach dem Verfassen des Artikels gekommen. Im Grunde hätte es meinem obigen Testlauf im Testbett nicht gebraucht.
Das Problem: Böse Buben könnten S-Protect clonen, patchen und dann bei einer Infektion des Zielsystems die Originaldatei überschreiben. Da braucht es in bei portablen Anwendungen nicht mal administrative Berechtigungen. Der Anwender bekommt nicht mit, was passiert und glaubt mit dem vermeintlich sicheren S-Protect zu arbeiten. Einen besseren Trojaner, der Banking-Zugangsdaten und mehr abfischt, kannst Du gar nicht bekommen. Bei einem "sicheren Browser" geht das in meinen Augen gar nicht.
Blindflug in S-Protect?
Fun-Fakt am Rande: Der S-Protect-Browser brauchte in meiner Windows 7-Umgebung, nachdem ich alle Warnungen des Testbetts bestätigt hatte, unendlich lange zum Laden. Ergänzung: In dieser Zeit versucht S-Protect einen Abgleich mit Update-Servern. Stellt der S-Protect Browser eine fehlende Internetverbindung fest, verweigert er die Arbeit und zeigt eine entsprechende Meldung. Bei bestehender Internetverbindung meldete sich das Programm auf meinem Testsystem anschließend mit einer Mitteilung, dass die Systemvoraussetzungen nicht erfüllt seien.
Das ist erst einmal gut. Windows 7 wird zwar als unterstützt angegeben, aber ich erhalte keinen Hinweis, was stört. Ich tippe darauf, dass S-Protect festgestellt hat, dass eines der letzten Updates noch fehlt (das ist mir bewusst), was aber so nicht angezeigt wird. Hier bleibt der Nutzer rätselnd zurück.
Meine Hoffnung, die betreffenden Informationen über die Schaltfläche Log-Protokoll in die Zwischenablag kopieren zu erhalten, und dann analysieren zu können, zerstoben aber sofort. Denn die Protokolldatei wird in verschlüsselter Form gespeichert – da wollte jemand auf "Nummer Sicher" gehen. Ich habe also – ohne genauere Analyse – keine Möglichkeit, festzustellen, woran es hakt. Das ist an dieser Stelle auch nicht mehr erforderlich, da das Grundkonzept, Sicherheit über einen "gehärteten Browser" zu gewährleisten, nicht greift.
Weitere Fragen
Ich habe an dieser Stelle den Test von S-Protect abgebrochen, da das Ganze alleine aus Sicherheitsgründen keinen weiteren Sinn mehr ergibt. Auf die Aspekte:
- Traue ich einer Anwendung aus einer "unbekannten Quelle" wie der Sparkasse Niederrhein, die einen Entwickler beauftragt hat, was zusammen zu klöppeln?
- Bin ich mir sicher, dass für S-Protect eine Aktualisierung in Bezug auf Bugs und Sicherheit auf längere Zeit gewährleistet wird?
bin ich erst gar nicht eingestiegen. Auch habe ich mich nicht mit der Frage befasst, ob S-Protect die Funktionalität bietet, die zum Online-Banking meiner Sparkasse benötigt wird.
Kleines Fazit
Das Konzept ist gemäß meinen obigen Ausführungen bereits im Ansatz gescheitert. Hier nochmals einige Gedanken zusammen gefasst.
Idee gut, Umsetzung gescheitert
Die grundsätzlichen Ideen sind ja nicht schlecht. Ein Browser, der nur Links verifizierter Banken als URL zulässt. Eine Überprüfung des Systems auf Sicherheitsupdates etc. macht schon Sinn. Aber am Ende des Tages zählt halt das Gesamtpaket. Es nützt nichts, wenn ich die Vordertüre mit allerlei Vorhängeschlössern sichere, der Hintereingang aber faktisch offen steht.
Unter diesem Aspekt ist der gesamte Ansatz in meinen Augen gescheitert und ich vermag nicht zu erkennen, wie das mit dem portablen Ansatz grundsätzlich sicherer gemacht werden kann (es kann ja nicht sein, dass einem Benutzer die Anwendung unbemerkt und ohne Administratorenberechtigungen überschrieben werden darf). Daher kann es für unbedarfte Benutzer, die Zielgruppe dieser Lösung sind, momentan nur heißen "Finger weg".
An dieser Stelle mein Dank an Stefan Kanthak für den Hinweis – ich hätte das Thema vermutlich noch einige Tage dümpeln lassen (auch wenn es seit Erscheinen des heise-Beitrags auf meiner Agenda stand). Und bin mir auch nicht sicher, ob ich S-Protect sofort über mein Sicherheits-Test-Bett gejagt hätte – nachdem ich bei Tools einfach zu oft auf diesen Sachverhalt gestoßen bin, traten diesbezüglich "Ermüdungseffekte auf" (Du kannst x Mal darauf hinweisen, die Masse interessiert das nicht und die Entwickler machen munter weiter – was auch für Microsoft gilt). Mal schauen, was in diesem Fall am Ende des Tages bei heraus kommt.
Der Entwickler
Ergänzung: Auf Grund der nachfolgenden Kommentare sieht es so aus, als ob die IT-Firma Coronic GmbH in Kiel als Entwickler fungiert. Nachfolgend ein Screenshot der Webseite dieses Entwicklers – liest sich auf den ersten Blick sehr gut.
Für S-Protect haben der Deutsche Sparkassen- und Giroverband (DSGV) und die Coronic GmbH in Kiel im April 2022 eine Kooperation unterzeichnet – siehe diesen Blog-Beitrag auf der Webseite des Anbieters. Der Anbieter wirbt auch mit dem Browser-Check Visor für Banken, wie man hier nachlesen kann. Ein weiteres Tätigkeitsfeld ist Software-Härtung und mobile Sicherheit, wie auf dieser Webseite erklärt wird.
An dieser Stelle ging mir schon der Gedanke "liegst Du mit deinen Bedenken einfach nur meilenweit daneben, oder hat da ein Anbieter (möglicherweise unbewusst) ein Potemkinsches Dorf gebaut" durch den Kopf. Aber die obigen Tests sind eindeutig – wer im Bereich Sicherheit unterwegs ist, sollte die grundsätzlichen Klippen kennen und berücksichtigen.
Ziemlich erschüttert
Das war dann der Punkt, wo ich ziemlich erschüttert war. Da gibt es eine Firma, die mit Sicherheitssoftware punkten möchte. Ich bin also davon ausgegangen, dass die viel mehr über Sicherheit wissen, als meine Wenigkeit. Und dann stelle ich aber fest (zumindest, wenn ich nicht gänzlich falsch liege), dass deren Entwickler in der Implementierung ziemliche Patzer hinlegen. Fehlt die Erfahrung oder wollte/konnte man das nicht besser?
Ergänzung: Nachdem Stefan Kanthak bei diversen Sparkassen wohl keine Antwort auf seine Mails erhielt, habe ich die Firma kontaktiert und erfahren, dass man den Artikel hier kennt und das Ganze momentan nachstellt. Details zum Sachstand kenne ich bisher nicht.
Der Vorfall erinnert mich an diverse Projekte im Gesundheitswesen, an das besondere elektronische Anwaltspostfach oder an die Luca-App, die von der Umsetzung und vom Sicherheitsansatz ein Alptraum waren. Ich hatte das Grundproblem kürzlich im Blog-Beitrag 60 Jahre Software-Entwicklung: Ein Alptraum, der mit grottiger Qualität und im Chaos endet angerissen. Wenn ich einen Architekt mit der Planung meines Hauses beauftrage und dieser einen Baustatiker hinzuzieht, muss ich mich darauf verlassen können, dass das Ergebnis stimmt. Wenn der Tüv ein Fahrzeug oder eine technische Einrichtung sicherheitstechnisch abnimmt, kann ich davon ausgehen, dass da essentielle Punkte abgeprüft wurden.
Nur im Bereich Software scheint jeder freifliegend werkeln zu dürfen. Das ist einer der Gründe, warum ich niemals in diesem Bereich aktiv geworden bin – denn mir fehlt – auch wenn ich gelegentlich hier über Sicherheitsthemen blogge – das Gen der sicherheitstechnischen Denke, die jeden Schritt und jede Entscheidung grundsätzlich und immer hinterfragt. Vielmehr glaube ich viel zu oft an das, was da versprochen wird – und nur ganz selten schaue ich genauer hin. Daher bin ich dann häufig erschüttert, wenn Sicherheitsversprechen mit einigen simplen Überlegungen pulverisiert werden.
Ergänzung: Entwickler haben nachgebessert
Da sich in der Berichterstattung weiterer Medien auf diesen Blog-Beitrag bezogen wird, möchte ich noch ein vorläufiges Status-Update geben. Ich stehe seit dem 17.5.2022 mit den Entwicklern von Coronic im Austausch und habe zusätzliche Informationen erhalten. Vorab eine Kurzfassung des aktuellen Stands:
- Der Starter S-Protect.exe des gehärteten Browsers war für DLL-Hijacking anfällig (siehe obige Ausführungen). Das Modul ist ein Starter und wohl auch ein Updater. Diese Schwachstelle wurde von den Entwicklern, laut eigener Aussage in einer neuen Version behoben (habe ich aus Zeitmangel noch nicht getestet).
- Nicht untersucht wurden (von Herrn Kanthak und mir) der separate Browser, der durch den Starter auf das System auf dem System eingerichtet wird. Die obigen Ausführungen lassen, so die Entwickler, in der vorliegenden Form keinen Schluss auf die Sicherheit des Browsers zu. Der Browser ist, laut Entwicklern, mit mehreren Sicherheitsmethoden geschützt. Eine geladene DLL im Starter stellt keinen erfolgreichen Angriff auf den Browser da.
Dem kann ich nach aktuellem Kenntnisstand nicht widersprechen oder zustimmen, denn zur endgültigen Beurteilung des gesamten Sachverhalts muss ich mir das aktualisierte Paket aber noch anschauen und testen (sofern dies möglich ist). Ein Folgeartikel mit weiteren Details und ggf. weiteren Testergebnissen befindet sich noch in der Planung, konnte aus Zeitmangel aber noch nicht abgestimmt und veröffentlicht werden.
Anzeige
Guter Bericht, der Programmier war bestimmt ein Neuland-Deutscher.
Was für ein selten dämlicher Kommentar bzgl des Programmierers.
Zum Bericht. So gut ist dieser gar nicht, da er sehr viele Mutmaßungen anstellt, ohne das Prinzip verstanden zu haben. Der Browser startet nicht. Ob das daran lag, dass ein Betriebssystem veraltet ist, oder dort Sicherheitsfunktionen gegriffen haben, ist überhaupt nicht klar. Der ganze Bericht klingt eher nach guckt mal wie schlau ich bin….
Zu deinen Mutmaßungen: Kann man so sehen – muss man aber nicht. Das ich nicht eruriere, was S-Protect da genau prüft, ist hier schlicht nicht mehr relevant. Belegt ist imho, dass die Anwendung unter einer DLL-Hijacking-Schwachstelle leidet – das sollte Standardwissen in diesem Bereich darstellen und hat nichts mit "schlau" zu tun. Und die Tatsache, dass eine Sicherheitsanwendung einfach so von einem Angreifer ausgetauscht werden kann, weil das vermutlich übersehen oder in Kauf genommen wurde, überzeugt auch nicht. Wenn das als "kuck mal wie schlau ich bin" zählt, kann ich damit leben ;-).
Sorry, aber es ist eine Mutmaßung, dass Du ein DLL Hijacking nachgewiesen hast. Um das abschließend nachweisen zu können, müsstest Du eine DLL ausgetauscht bekommen, der Browser anschließend laufen. Dann wäre der Minimumnachweis erbracht. So ist das ein typisches Show machen von Leuten, die zeigen wollen, wie viel Ahnung sie scheinbar von Sicherheit haben. Sehr schade, da ich es tatsächlich für wichtig erachte, das Sicherheitslücken wirklich aufgedeckt werden und sich Kunden nicht in einer trügerischen Sicherheit wiegen.
Bin mal gespannt, was der Hersteller zu dem sagt, ob er die mutmaßliche Lücke bestätigt, oder negiert.
Ok, ich habe es kapiert und wohl nix verstanden – kann ja mal vorkommen. Im Testbett war zwar eine DLL, die statt der Win-Variante aufgerufen wurde, aber egal. Jeden weiteren Kommentar erspare ich mir an dieser Stelle.
Warum muss der Browser mit einer "untergejubelten" DLL laufen? Es reicht doch wenn der PC infiziert wird.
"Show machen von Leuten, die zeigen wollen, wie viel Ahnung sie scheinbar von Sicherheit haben" macht hier vor allem ein gewisser Holger.
@Holger dieses so genannte Testbett tauscht alle dll's gegen eigene aus, nur das diese anstelle böses zu tun eben solche wie im Beitrag gezeigten MessageBoxen werfen.
Also da gibt's nichts mehr zu zeigen, wen die MessageBoxe aufpopt ist das kind schon in den Brunnen gefallen
Hat die Bank/Sparkasse den "gehärteten" Browser umgehend zurückgezogen?
Aktuell ist wohl alles in einer Pilot-Phase – die Sparkassen, die das anbieten, haben noch nicht reagiert. Aber das Thema liegt jetzt beim Entwickler – die können sich meine Überlegungen ansehen und dann entscheiden, wie sie vorgehen.
Ergänzung: Bekomme automatisch Mails zwischen Kanthak und diversen Sparkassen als cc. Es heißt, die Entwickler wollen nachbessern – bin mir aber nicht sicher, ob das Problem schon wirklich angekommen und verstanden wurde. Es bleibt abzuwarten, was am Ende des Tages bereitgestellt wird und dann nochmals genauer hinzuschauen.
Vermutlich hat die Rechtsabteilung den Bau eines solchen Browers empfohlen.
So haften die Kunden die ihn nicht benutzen voll.
Vielleicht bauen sie ja auch noch einen Sichern TAN-Generator wie bei Smartphones dazu? 2-Faktor ist ja so immer aber unbequem…so mit einem 2. Gerät 'rum fummeln.
Andersherum:
Wer ihn benutzt (und eine böse DLL eingefangen hat,) haftet natürlich nicht mehr selbst…oder?
Oder war die SparKa so naiv zu glaubern, dass es so etwas wie "absolute Sicherheit" gibt und haben die AGBs nicht entsprechend geändert, weil durch den S-Browser kann ja nichts mehr schief gehen.
Warum erinnert mich da an das "besondere Anwaltspostfach" oder "Atlas(Zoll)" oder de-Mail oder eGK oder Maut-System?
Achso, ja: Alles Qualität aus dem Land der Dichter und Denker.
DLL-Hijacking ist ja wahrlich nicht neues. Insofern mehr als peinlich.
Hi…
Paul sagt: "Alles Qualität aus dem Land der Dichter und Denker."
DAS ist das Problem – in diesem Land gibt's an den entscheidenden Positionen leider absolut keine qualifizierten Fachleute (in diesem Fall Programmierer).
Alles andere ist Einbildung!
So ein Projekt nennt man "Rohrkrepierer" – aber vom Feinsten. Da hatte jemand eine Idee und keine Ahnung – Erinnerungen an die "08/15 Bank" durchwandern meine Gedanken … lol
Das doofe daran ist, das es genug unbedarfte Anwender gibt, die das für gut halten und wie Günter schreibt "aus dem Download" – Ordner, und weil man ja auf Nummer sicher geht, laden die dann auch noch jedes mal die aktuellste Version vorher von der Webseite – wer braucht schon einen Überblick über seinen download-sau-stall.
Hauptsache man hat eine "gutes Feeling"
Man soll einfach Leute, die absolut kein Händchen für Computer haben, nicht mit Filialschließungen und Personalabbau dazu nötigen, ihre Bankgeschäfte online zu erledigen!
Das ist so ein typisches Angebot für den DAU, der keinerlei Durchblick hat, was wo auf seiner Rechenmaschine abläuft. So wie die Heerscharen von Smartphone-Nutzern, die sich dazu dressieren lassen, dankbar für alles und jedes eine eigene „Äpp" zu installieren, natürlich gratis und mit EULAs, die sich mit einem Wisch absegnen lassen.
Eigentlich dürfte man davon ausgehen, dass die Entwickler der professionellen Browser deutlich mehr Erfahrungen mit Sicherheitsfragen haben als ein Allerweltsprogrammierer, der mal eben für einen Kunden eine Web-Oberfläche zusammenschneidern soll. …wenn halt mal die Entwickler bei Google & Mozilla sich auf einen „gehärteten" Browser für das gesamte WWW konzentrieren würden, statt ihre Produkte mit immer neuen Blink-blink-Funktionen zu spicken, deren potentielle Sicherheitslücken hundertmal größer sind als der tatsächliche Nutzwert.
da hat die Sparkasse ja wieder mal eine Leistung verbracht, die schon gang und gebe ist. Das Geld Ihrer Kunden verbrennen. Gut, es ist nicht weg. Es haben nur andere und auch Vorstand und Consorten.
Einen "gehärteten" Browser? Das klingt eher nach Porno-Film.
Ist dieser Browser auf was aufgesetzt wie Chrome oder Mozilla oder eigens zusammengebastelt? Alles sollte man nicht machen.
So nun die entscheidende Frage – Haftet dafür die Sparkasse?
Ich gehe so vor das ich die Signierung der Library prüfe bevor ich sie lade.
Dann interessieren mich auch irgendwelche Pfade nicht mehr, bei dem Ansatz sehe ich auch Schwachpunkte.
Erstaunlich, dass das Teil noch angeboten wird.
Der eigentliche Anbieter scheint dieser zu sein ( als ich vor einem Jahr nach so etwas gesucht hatte, bin ich zunächst bei der "Sparkasse Förde" gelandet )
http://www.coronic.de/s-protect/
" 6. Juli 2020
Seit genau 10 Jahren gibt es den sicheren Protect Browser der CORONIC GmbH aus Kiel"
Und S-Protect dann nur ein Anpassung für die Sparkassen.
https://www.sparkasse-am-niederrhein.de/protect
"Windows-Nutzer benötigen Windows 8.1 oder Windows 10, eine aktive Internetverbindung und 300 MB freien Speicherplatz. "
coronic.de
coronic.de/mobilsecurity
coronic.de/frank-bock
Nichts dazu zu sagen. Erklärt sich selbst.
coronic.de/support/
coronic.de/jobs
Tipp: Echte Begeisterung kann fehlende Erfahrung wettmachen
Hatte die Links gesehen – aber als erstes die TeamViewer-Support-Seite aufgemacht – und das Ganze als vermeintlichen SEO-Spam erst mal in diesen Ordner einsortiert – ist auch eine Folge des zu häufigen Troll-Alarms ins letzter Zeit.
Erst bei der Nachrecherche bin ich darauf gekommen, was Du mit den Links kommunizieren wolltest (siehe auch mein Nachtrag im Artikel).
Wäre gut, künftig einen Satz voranzustellen, was eine Link-Sammlung eigentlich bedeutet – denn so was ist für mich Neuland ;-).
Online Banking mit externem Chipkartenleser und HBCI… da beißen sich die "phösen" noch immer die Zähne aus! Einzige mir bisher bekannte Sicherheitslücke: Einbruch und Manipulation des Chipkartenlesers ( oder geizistgeil Primaten welche den schon manipuliert aus China ordern)… also eher unwahrscheinlich.
/edit/
wobei der DAU selbst da noch schafft zu verkacken!
Kenne da wen der hat doch tatsächlich die HBCI Karte zur Kontrolle eingeschickt als er per Mail darauf hingewiesen wurde.
Tja manche Leute kann man eben nicht helfen.
Meine Kreissparkasse hat HBCI letztes Jahr leider eingestellt. 15 Jahre ohne Probleme genutzt, ich denke die Infrastruktur wurde denen zu teuer :-/
HBCI fand ich auch immer sehr gut, es ist aber eine rein deutsche und aufwändige Insellösung gewesen, die natürlich die Kosten in die Höhe treibt. Für Privatkunden zu Anfang noch attraktiv, weil es noch mit Diskette funktionierte, aber schon der Kartenleser war nicht billig. Mit Chip-Tan optisch oder QR kann man aber auch bequem leben und insbesondere das QR Verfahren funktioniert sehr gut und bequem.
HBCI wurde nicht eingestellt, sondern idR lediglich die HBCI-Karte. Dies resultiert aus den Vorgaben zur PSD2
Das ganze wird trotzdem per HBCI/FinTS übertragen.
Guter Kommentar!
Ich ergänze aus WP: "HBCI mit Chipkarte und Kartenleser nach Secoder-Standard gelten derzeit als das Nonplusultra an Sicherheit, wobei die jeweilige Bank sowie die Homebanking-Software die Secoder-Erweiterung für HBCI unterstützen müssen."
Leider guckt einen das imkompetente Gekreuch an den Serviceschaltern der Bankfilialen frech mitleidig an, wenn man auf Kartenleser (gleich welcher Ausprägung) besteht. In deren Gesichtskreis gibt es nur noch 'App, App, App', alles andere gilt als hinterwäldlerisch. Ich erlebe das öfter, weil ich ehrenamtlich Senioren und soziale schwache Haushalte betreue.
Ich frage mich wirklich, wann uns in der bunten Republik die "systemrelevante" IT um die Ohren fliegt.
vermutlich wird die DLL Hijack Problematik bei S-Protekt demnächst behoben,
doch um es mit einem der "beliebten" KFZ-Vergleiche zu sagen:
Wenn ein KFZ-Marke "SPARKAroSSErie" ein neues Modell "S-Protect 500 Turbo"
mit angeblich besonders starkem Insassenschutz, aber ohne Sicherheitsgurte auf den Markt bringt.
(deren fehlen der Branche seit sehr langer Zeit als Sicherheitsproblem bekannt sind!)
Und der Hersteller dann, bei bekannt werden dieses Mangels sagt,
"Upps, kann man ja mal passieren, kommen sie in die Werkstatt, die werden sofort nachgerüstet"
Wie weit traut man dann, auch nach der Nachrüstung, dem Rest des Fahrzeugs!?
Das alte und ewige Herumreiten auf DLL Hijacking und dann noch die Behauptung über 25 Jahre best practice, Ich lach mich tot, DLLs die sich in Systemverzeichnissen befinden sind per se nicht vertrauenswürdiger als in irgendeinem anderen Verzeichnis. Auch dort können sie beliebig manipuliert werden, ggf braucht der Angreifer dann halt die Mitwirkung des DAU oder einen höherwertigen Angriff mit priviledge ecalation. Das eigentliche Problem ist, dass der Nutzer nicht bestimmen kann, aus welchem Verzeichnis die shared objects geladen werden. Und dann sind wir bei der immanenten Unsicherheit von Wiondows angekommen. Nicht DLL hijacking ist das Problem, sondern das Betriebssystem selbst. Ganz egal ob shared objects von irgendwoher geladen werden oder ob im Browser Javascript aus obsureken und nicht transparenten Quellen geladen wird die Sicherheit kommt zu kurz. Daher ist das dynamische Linken bei sicherheitskritischen Programmen immer ein kritisches Problem. Sicherheit beginnt eben beim Design, auch des Betriebssystems.
Den letzte Satz unterschreibe ich. Den Rest: Leider gilt hier die Macht des faktischen – im konkreten Fall nutzt niemand zum Online-Banking sichere Umgebungen, sondern Windows, Android-Geräte etc. sind die Qual der Wahl.
Wenn dann eine Anwendung Sicherheit verspricht, sollte man schon hinterfragen, wie es um das Sicherheitsverständnis bestellt ist, wenn DLL-Hijacking nicht berücksichtigt wird – dass das gesamte Konzept mit dem portablen Ansatz gestorben ist, ist nochmals ein anderer Aspekt.
Als Nutzer muss man nehmen, was vom Entwickler vorgegeben wird. Wenn da aber Sicherheit versprochen wird, das aber nicht halten kann, wird es schwierig. Von daher lässt mich dein Kommentar jetzt etwas ratlos zurück. Weil ich grundsätzlich DLLs nicht trauen und als Nutzer nichts ändern kann, muss ich mir keine Gedanken machen und das Herumreiten auf DLL-Hijacking stört nur – also einfach weiter wie bisher? Ist das die Botschaft?
Eine Bank, die es ermöglicht Ihre PushTAN-App auf ein neues Smartphone zu transferieren OHNE Aktivierungsbrief NUR mit den abgephischten Zugangsdaten und als Sicherheitsabfrage das Geburtsdatum und die EC-Karten Nummer, den 2. Faktor also Ad Absurdum führt … was soll man da erwarten?
Bin auch Sparkassen Kunde.
PushTan würde ich allerdings nicht nutzen solange ChipTan zur Verfügung steht.
Einer TAN Anwendung auf dem Kryptochip der Sparkassenkarte welche genau wie EMV unter SECCOS läuft, vertraue ich da wesentlich mehr. Schließlich ist die TAN Anwendung an Hardware gebunden und kann wohl nicht kopiert werden.
Ich bin mit ChipTan USB und ChipTan QR sehr zufrieden.
Solange der Nutzer nicht auf die Idee kommt, eine TAN am Telefon oder wo auch immer auf Zuruf weiterzugeben, halte ich ChipTan für nahezu 100% sicher.
Habe das Thema noch auf der Agenda – ich habe kürzlich einen Hinweis von der Bank erhalten, dass mit dem Austausch der Debitkard das chipTAN-Verfahren nicht mehr nutzbar ist. Die TAN-Generatoren müssen dann ausgetauscht werden. Das pushTAN-Verfahren halte ich für bedenklich, bin aber noch nicht gänzlich durch die Thematik durch.
Das von Ihnen angesprochene Problem bezieht sich nur auf das veraltete ChipTan mit Flickercode.
Die Flickercode Generatoren können mit den Sparkassen Cards der neuesten Generation nicht mehr benutzt werden. Die anderen Übertragungswege von ChipTan (QR Code, USB(Mit Software FinTs) und Blue Tooth sind auch in Zukunft weiter nutzbar.
https://www.sparkasse-nuernberg.de/de/home/service/online-mobile-banking/chiptan.html?n=true&stref=productbox
Bei der Postbank wurde in der Tat das Ende des ChipTan Verfahrens eingeläutet.
Die haben die Umstellung von Flicker auf das viel bessere ChipTan QR nicht nachvollzogen, sehr zum Unmut vieler Postbank Kunden wenn man den Foren Glauben schenken darf.
Die Postbank bietet nur noch das "BestSign" Verfahren der Firma "Seal One" an. Das geht über eine App oder einen dedizierten Generator.
Ich halte den Weg den die Sparkassen/Finanzinformatik gehen für wesentlich besser und bin froh Sparkassen Kunde zu sein.
Da gibt es beim Thema Onlinebanking wirklich nichts zu meckern. Alles läuft stabil und mit höchster Verfügbarkeit.