Re: [Hbci4java-help] InfoPoint-Server-Abfrage

[HBCI4Java (S. Palme) <hbc...@ka...>]

Hallo Michael,

danke für Dein umfrangreiches Feedback. Ich picke mal ein paar
Punkte heraus, auf die ich spontan antworten möchte... ;-)


> Sicherheit:
> -----------
> Der Bankserver verschlüsste mit SSL und verwendet dabei entweder ein c)
> vertrauenswürdiges Zertifikat oder d) ein Zertifikat, dessen Fingerprint
> dem Nutzer bekannt ist.
> 
> Die Daten, welche der InfoPoint Server ausliefert, können durch diesen
> nicht überprüft werden, da entweder der Fingerprint oder der Hostname
> der Bank nicht vertrauenswürdig bekannt ist.

Soweit ACK. Eine URL https://www.hora-obscura.de/pintan/PinTanServlet
für die BLZ 80007777 würde vom InfoPoint-Server als völlig valide und OK
angesehen werden, weil das dafür verwendete SSL-Zertifikat tatsächlich
validiert werden kann - der InfoPoint-Server weiß nur nicht, dass
"hora-obscura" keine "richtige" Bank ist.


> Da der InfoPoint die Bankdaten schlecht verifizieren kann, liefert er
> potentiell manipulierte Daten aus.

Theoretisch möglich. Du sprichst da schon dem Fall der "völligen Auto-
matisierung" auf InfoPoint-Server-Seite. Ich hatte mir gedacht,
dass der InfoPoint-Server aber frühestens dann neue Daten für eine
bestimmte BLZ meldet, wenn 

a) diese von mehreren verschiedenen Clients als "funktionierend"
   an den InfoPoint-Server gemeldet wurden, und

b) im selben Zeitraum auch keine Infos mehr mit den alten Daten
   reinkommen.

Punkt a) könnte man als Angreifer natürlich leicht faken - einfach
massenweise gefakte InfoPoint-Server-Infos an den Server senden, und
zwar von vielen Rechnern aus.
Aber um auch Punkt b) zu fälschen, müsste sich ein Angreifer schon
ganz schön anstrengen ;-)  [das funktioniert natürlich nur, wenn es
keine oder nur eine kurze Übergangsphase gibt, bei der BEIDE Urls
funktionieren...]

Außerdem sollte diese Entscheidung, neue Daten für eine BLZ zu melden,
auch nicht sofort geschehen, sondern erst, wenn dieser Zustand über
einen gewissen Zeitraum anhält (also wenn z.B. wenigstens zwei Tage
lang nur noch Infos mit einer neuen URL "URL2" reinkommen, aber keine
Infos mit der alten URL "URL1" mehr...

Beim Ausbalancieren dieses Zeitfensters muss man natürlich Effizient
(kurzes Fenster) und Sicherheit (langes Fenster) gegeneinander 
abwägen...


> Die Hürde, den Zettel heraus zu suchen ist viel höher, als die IP und
> die Protokollversion einzugeben.

Selbst wenn der Anwender die IP manuell eingibt, und das Zertifikat dem
Fall (d) entsprechen soll (also nicht automatisch, sondern nur manuell
über den Fingerprint verifizierbar), muss der Anwender diese
Verifizierung tun - denn wer garantiert denn, dass ein Angreifer nicht
den kompletten Traffic für die richtige IP an einen badboy-Server um-
leitet...

> Während ohne InfoPoint die
> Bankmitteilung dem Nutzer eh vorlag, die Fingerprintüberprüfung also
> eine niedrige Hürde darstellte, wird nun die Mitteilung nur zur
> Fingerprintüberprüfung benötigt und hat daher eine wesentlich höhere
> Hürde. Gleichzeitig kann dem Nutzer gezielt eine geänderte Server-IP
> untergejubelt werden, sodass in Verbindung mit PIN Authentifizierung
> der Angreifer nun die PIN mitlesen könnte und den Traffik an die Bank
> weiterleiten.

Verstehe ich Dich richtig - Du willst hier eher auf ein "psychisches"
Problem hinaus? Wenn der Nutzer den Bankbrief rauskramen muss, um
die richtige URL einzugeben, macht er halt die Fingerprint-Überprüfung
gleich mit, weil der Zettel ja eh einmal draußen ist.

Wenn die Einrichtung jedoch vollautomatisch geht, und er den Zettel
NUR rauskramen muss, um diese nervige Fingerprint-Überprüfung zu
machen, dann lässt er das schon eher mal sein und vertraut einfach
darauf, dass das schon i.O. ist...

Meinst Du das so? 

Solche "Faulheit" wäre aber durch keine Software der Welt zu
unterbinden. Denn auch WENN der Nutzer den Zettel einmal auf dem
Tisch hat, könnte er ja sagen "20 öde Zahlen-/Buchstaben-
Kombinationen zu vergleichen ist mir jetzt zu anstrengend - wird
schon passen"...


> Bei einer Aktualisierung der Bankverbindung (b) bzgl. der Server-IP wird
> sich der Fingerprint ebenfalls ändern, da das Zertifikat auch den
> Hostnamen beinhaltet. Ein Angriff ist dort analog denkbar.

Nein. Ein SSL-Zertifikat ist auf einen Hostnamen und nicht auf eine IP-
Adresse ausgestellt. Wenn eine Bank Ihren Server auf eine andere IP-
Adresse umzieht, den Hostnamen aber beibehält (also praktisch nur eine
Änderung um DNS machen muss), dann ändert sich aus Sicht von HTTPS und
SSL-Zertifikaten überhaupt nichts.


Wenn sich auch der Hostname ändert, braucht es natürlich auch ein
neues SSL-Zertifikat, welches validiert werden muss. Die Validierung
mit Fingerprint wäre dabei sicherer, weil der Nutzer gezwungen wird,
mal händisch draufzugucken ob alles i.O. ist (dazu muss der Nutzer
aber natürlich auch eine entsprechende Info von seiner Bank bekommen,
wie der neue Fingerprint denn lauten muss). 

Die automatischeValidierung via "vertrauenswürdiges Zertifikat" ist da
wirklich kritischer, weil ein Angreifer tatsächlich eine beliebige
eigene Domain mit einem gültigen SSL-Zertifikat versehen kann und eine
URL innerhalb dieser Domains als "PIN/TAN-URL" ausgeben könnte.

In dieser Hinsicht stimme ich Dir voll und ganz zu. Das ganze kann
aber relativ einfach gelöst werden ("gelöst" immer in dem Sinne, dass
es automatisierte, 100%ige Sicherheit nicht geben kann - die Anwendung
und der Anwender müssen schon ein bisschen mitspielen):

Zum einen sollte der InfoPoint-Server nur dann neue Daten für eine BLZ
zurückgeben, wenn er selbst daran "glaubt", dass die echt sind (siehe
oben).

Desweiteren könnte eine Anwendung ja im Falle der Erst-Initialisierung
eines Zugangs den Nutzer auffordern, die URL sowie das Zertifikat einmal
manuell zu prüfen und zu bestätigen (ich glaube, bei Hibiscus wird das
im Moment sogar so gemacht - selbst wenn das SSL-Zertifikat vertrauens-
würdig ist).

Und im Falle der Änderung von Daten könnte die Anwendung dem Anwender
ja mitteilen, dass scheinbar neue Daten für seine Bank verfügbar sind,
und er doch bitte überprüfen möchte, ob die "Sinn machen", ob das
neue Zertifikat stimmt usw... 


> In einer persönlich gepflegten und überprüften Datenbank tritt dieses
> nicht so stark auf, da die Anwendung die Identität des InfoPoint Servers
> überprüfen kann und somit auch den dort hinterlegten Daten vertrauen
> kann. Es ist dem Angreifer nicht mehr so leicht möglich, den
> vertrauenswürdigen Ersteller der Datenbank zu manipulieren.

Prinzipiell ACK - aber das Ziel des InfoPoint-Servers ist es ja,
genau dieses manuellen Aufwand zu reduzieren. Wenn der InfoPoint-
Server nur Sinn macht, wenn man die hinterlegte Datenbank pflegt,
dann brauche ich ihn eigentlich gar nicht mehr - denn eine manuelle
gepflegte "Datenbank" befindet sich bereits in der Datei blz.properties,
die Teil von HBCI4Java ist (natürlich mit wenig weniger Daten als im
InfoPoint-Server mal gespeichert werden sollen, es ging mir jetzt nur
ums Prinzip) ;-)


> Also Kontra-Argument ist mir bewusst, dass hier versucht wird, ein
> soziales Problem technisch zu lösen.

Nicht nur ein soziales, sondern auch ein technisches Henne-Ei-Problem.
Ein Anwender, der völlig auf der grünen Wiese anfängt, weiß z.B.
nicht, welche HBCI-Versionen er verwenden kann, welche "Filter" (laut
HBCI-Standard gibt es da mehrere Möglichkeiten, die in er Praxis bloss
nicht benutzt werden) usw.

Diese Daten erfährt er zwar, indem er die BPD von der Bank abholt.
Aber genau dafür bräuchte er die Daten ja schon... 


> Gleichzeitig denke ich aber, dass
> bei einer erfolgreichen Lösung des sozialen Problems der Vorteil der
> technischen Lösung gering ist: bei PIN/TAN muss weiterhin der
> Fingerprint überprüft werden und bei der Verwendung einer Chipkarte
> können die Serverdaten auch auf der Chipkarte gespeichert werden.

ACK.

> Problemlos verwendbar ist der InfoPoint Server aus meiner Sicht zur
> Abfrage von Port, HBCI Version, Protokoll und unterstützten
> Geschäftsvorfällen, da dadurch das Vertrauen in die Serveridentität
> nicht verändert wird. 

ACK.

> Vermeidbar wäre der o.g. Angriff, indem die Bankserverzertifikate
> explizit eine Bankleitzahl angeben würden, welche vom Aussteller
> überprüft wurde. Der Hostname oder die IP des Servers ist dagegen -
> anders als bei normalen Surf-Anwendungen - weniger relevant.

Stimmt, aber da begeben wir uns leider in die wünsch-dir-was-Welt
- dieses Feature ist leider nicht in irgendeiner Weise standardisiert
vorgesehen :)


> Der InfoPoint-Server hat notwendiger Weise die Möglichkeit, zu erfassen,
> welche IP wann welche BPD abruft oder abliefert. Er kann daher dazu
> benutzt werden, Rückschlüsse darauf ziehen, wer Kunde bei welcher Bank
> ist. Allerdings ist dieses Datum selten geheim und kann nicht
> automatisiert Personen zugeordnet werden. Im Einzelfall kann die
> Funktion außerdem ungenutzt bleiben.

Im Prinzip könnte man damit "IP-basierte Profile" erstellen, soweit
richtig. Einen Rückschluss auf einen konkreten Kunden kann man damit
jedoch nicht ziehen, denn es werden nur die sowieso öffentlich
verfügbaren Daten an den InfoPoint-Server übermittelt.


> Eine Anwendung sollte nicht zu oft den InfoPoint abfragen, da dieser
> sonst potentiell überlastet wird.
> ...

Die Performance-Geschichte habe ich absichtlich erst mal noch
gar nicht betrachtet, um die Komplexität des Konzepts und der
Implementierung nicht gleich zu hoch zu treiben.

Momentan ist der InfoPoint-Server ja eigentlich auch noch in einer
Proof-Of-Concept-Phase, wo es nur darum geht, zu sehen, ob sowas
prinzipiell machbar ist und sinnvoll genutzt werden könnte...


Letztendlich sehe ich den InfoPoint-Server also so eine Art "DNS für
HBCI-Server" - also mit ähnlichen Problemen wie das DNS-System
(Fälschung von DNS-Einträgen zum Zwecke der "Umleitung" von Traffic)
und ähnlichen Anforderungen an die Anwender (auch wenn ich 
https://www.meine-bank.de manuell im Browser eingebe, sollte ich mal
aufs Zertifikat gucken, um sicher zu sein, dass ich wirklich da bin
wo ich hin wollte) usw...

Danke jedenfalls für den Input!

Grüße
-stefan-