Re: Kein Online-Banking im öffentlichen WLAN

[Danny Edel <mail@xxxxxxxxxxxxx>]

On 10/21/23 01:45, Werner Holtfreter wrote:
> Hallo Christian,
> 
> Am Freitag, 20. Oktober 2023, 19:32 schrieben Sie:
> 
>> Typischerweise wird auch der Nameserver im fremden Netz verwendet
>> und der kann natürlich sonstwas liefern. Der Benutzer findet sich
>> dann statt bei meine.bank.de bei meine.bank.ag, natürlich https
>> gesichert, sieht aus wie seine Bank
> 
> Nicht in der Adressleiste erkennbar?
> 
> Übel, wenn das nur am Nameserver hängt.
> 
>> Noch besser natürlich, wenn ein Zertifikat für meine.bank.de
>> von Honest Achmed's CA vorliegt.
> 
> Ich vermute, dass dagegen auch die 2-Faktor-Authentifizierung nicht hilft.

Hallo Werner,

im Zusammenhang mit HTTPS, Bank-Webseiten, wie schlimm und böse ein
unverschlüsseltes WLAN ist wird gerne viel unscharf formuliert und ist
daher gerne mal ein bisschen irreführend.

TLS (das "S" in HTTPS) wurde aber grundsätzlich entwickelt, um in einem
**unvertrauten** Netzwerk eine vertrauenswürdige Verbindung herstellen
zu können, die der Netzwerkbetreiber weder entziffern noch unbemerkt
manipulieren kann.  Man beachte, dass hier von vorn herein dem
Netzwerkbetreiber unterstellt wird, "böse" zu sein.

Daher empfehle ich, mal die gesamte Signalkette zu betrachten, um zu
verstehen, wann man angreifbar ist und wann nicht.  Bei dieser
Untersuchung wird unterstellt, dass das Endgerät des Benutzers **NICHT**
manipuliert wurde.  Sobald das Endgerät vom "Angreifer" manipuliert
worden ist, kann dieser prinzipbedingt mit Tastatur, Maus und
Bildschirminhalt machen, was er will.   In diesem Szenario ist bereits
alles verloren.  Daher gehe ich darauf mal nicht weiter ein...
Weiterhin nehmen wir an, dass die Systemzeit des Endgeräts zumindest
ungefähr (richtiges Datum) stimmt.


Schritt 1:   Anwender will auf sein Online-Banking gehen.

Option 1 (sicher): Er klickt auf sein Lesezeichen, wo z.B.
https://meine-bank.de/onlinebanking drinsteht.

Option 2 (unsicher): Er gibt (nur!) meine-bank.de in die Adresszeile
ein, der Browser erweitert das zu http://meine-bank.de und die Anfrage
geht unverschlüsselt raus.   Der böse Netzwerkadmin kann machen was er will.

Typischerweise wird er mit einem HTTP 302 Redirect nach
https://klingt-so-ähnlich-wie-meine-bank.de antworten, also einer
Webseite die er kontrolliert und für die er auch problemlos ein gültiges
TLS-Zertifikat bekommt.

=> Verloren!


Option 3 (mittelprächtig): Der Benutzer  gibt sowas wie "meine bank
onlinebanking" ein, der Browser macht daraus
https://suchmaschine.com/query=meine%20bank%20onlinebanking und der
Nutzer muss halt auf den echten Link klicken.    Solange $Suchmaschine
hier den richtigen Link ausgibt, haben wir noch nicht verloren.
Persönlich finde ich es aber schlecht, Nutzer darauf zu trainieren ihrer
Suchmaschine blind zu vertrauen und eben nicht die eigenen Lesezeichen
zu nutzen.





Schritt 2:  Browser will https://meine-bank.de/onlinebanking laden.
Nehmen wir also an, der Anwender hat in Schritt 1 seinem Browser
kommuniziert, dass er eine TLS-Verbindung zu "meine-bank.de" herstellen
will.  Was passiert jetzt?

Schritt 2.1: Der Browser braucht die IP-Adresse von meine-bank.de.  Der
Browser fragt daher den Nameserver (regelmäßig ist das der vom Netzwerk
per DHCP benannte, also der vom Angreifer kontrollierte), welche
IP-Adresse denn "meine-bank.de" hat, baut eine TCP-Verbindung zur
benannten IP auf und eine Nachricht in dieser TCP-Verbindung.  Da steht
im Prinzip drin "Ich hätte gerne eine sichere Verbindung zu
meine-bank.de, zeige mir bitte mal Dein Zertifikat".

Schritt 2.2: Zertifikatsvalidierung
Das vom (angeblichen) Server empfangene Zertifikat wird jetzt geprüft.
* Ist es ausgestellt für meine-bank.de?
=> Wenn der Angreifer nur den Nameserver manipuliert hat, aber den
Zielserver nicht gut konfiguriert hat, geht's schon hier schief.  Der
Zielserver sendet dann nämlich sein eigenes Zertifikat wie
"anfaengerhacker.com" oder "klingt-so-ähnlich-wie-meine-bank.de".
Der Browser betrachtet jede Abweichung als Angriff.

* Ist es derzeit gültig?
=> Es hat einen Sinn, dass Zertifikate nach einer Weile ablaufen.  Wenn
der Angreifer beispielsweise alte Festplatten auf ebay kauft, findet er
vielleicht ein altes, aber ansonsten gültiges Zertifikat eines
Webservers.   Sofern das Ablaufdatum bereits erreicht war, als die
Festplatte entsorgt wurde, war der Fund wertlos.  (Bitte nicht
unterschätzen, wie oft Festplatten mit lesbaren Daten gebraucht verkauft
werden...)
Der Browser betrachtet abgelaufene (oder "noch nicht gültige")
Zertifikate als Angriff.  An dieser Stelle muss die Systemzeit des
Endgerätes zumindest ungefähr stimmen.

* Ist es von einer vertrauten CA ausgestellt?
=> Hier ist die Crux.   Ein un-manipulierter Browser "glaubt" in der
Regel nur den Firmen auf der Mozilla-CA-Liste, die alle von sich
beteuern, sorgfältig zu prüfen, dass sie nur dem legitimen Betreiber von
meine-bank.de ein Zertifikat für meine-bank.de ausliefern und eben nicht
dem Angreifer.  Wenn wir annehmen, dass Mozilla diese CA-Firmen
hinreichend strikt kontrolliert, dann dürfen wir davon ausgehen, dass
wir jetzt wirklich mit dem "echten" Server für meine-bank.de reden.

=> In einem Firmennetzwerk, bei dem SSL-MitM gemacht wird, wird der
Firmennetzwerkadmin seine eigene CA, mit der der Proxy MitM macht, vor
Ausgabe des Geräts an den Mitarbeiter in diese Liste eintragen.  Wir
haben es also bei Firmengeräten regelmäßig NICHT mit unmanipulierten
Geräten zu tun.   Wenn wir darüber reden wollen, ist das eine andere
Geschichte.


Wenn diese Validierung erfolgreich verlaufen ist, dann stellt der
Browser die Verbindung her.   Andernfalls kommen deutliche
Zertifikatswarnungen.

Um diese Zertifikatswarnungen mal zu sehen, empfehle ich die Webseite
https://badssl.com, auf der Links zu absichtlich fehlkonfigurierten
Servern angeboten werden.   Hiermit kann man seine Anwender schulen:
"Wenn Ihr Browser dieses Bild zeigt, dann ABSOLUT NIE auf den
Ignorieren-Knopf drücken!"

Für die aktuelle Geschichte relevant wären
* Expired (altes Zertifikat auf ebay gefunden)
* Wrong Host (Angreifer hat *nur* den Nameserver manipuliert)
* Untrusted Root (un-manipulierter Laptop im Firmen-WLAN)


Das HTTPS-Verfahren an und für sich ist ziemlich sicher, und es wurde
von vorn herein entwickelt, um in unvertrauten Netzen sichere
Verbindungen herzustellen.  Und das haben die Ingenieure eigentlich gut
gelöst.


Erfolgreiche (!) Angriffe haben daher fast immer folgende Ursachen:

(1) Der Benutzer hat NICHT https://meine-bank.de aufgerufen sondern
https://klingt-so-ähnlich-wie-meine-bank.de

Erfolgreichste Taktik.   Der Angreifer bringt das Opfer dazu, auf seinen
Link zu klicken, und somit absichtlich(!) zu seinem Server zu gehen,
anstatt zum Server der Bank.   Hier stellt TLS natürlich sicher, dass
wir *wirklich* mit dem Server des Angreifers reden : )

Die Standardmethode ist, dass Emails verschickt werden, die so klingen
als wären sie von der Bank, irgendein $Problem ist dringend und bitte
klicken Sie hier um das Problem zu beheben, weil sonst $Drohung.


Daher bitte die Anwender schulen:   NIEMALS auf Links in Emails klicken,
um aufs Onlinebanking zu kommen!   IMMER Lesezeichen verwenden!



(2) Der Browser hat ein Problem erkannt, aber der Benutzer hat die
Browserwarnung ignoriert und trotzdem geladen

Gerade in Firmen-Netzwerken ist es üblich, dass MitM gemacht wird.  Wenn
dies NICHT sachgemäß gemacht wird, insbesondere wenn vergessen wird, die
MitM-CA auf den Clients zu installieren, werden die Benutzer
entsprechend geschult, Browserwarnungen immer zu ignorieren.  (Ja,
wirklich!)

Daher bitte, WENN Sie schon MitM in der Firma machen:  Machen Sie es
richtig und manipulieren Sie die Endgeräte entsprechend, sodass keine
Zertifikatswarnungen kommen!   Benutzer zu trainieren, Warnungen
wegzuklicken ist eine Steilvorlage für jede Art erfolgreichen Angriff!



tl,dr:    Mit einem Un-Manipulierten Browser ist es völlig egal, ob das
WLAN offen ist, wenn man seine Lesezeichen aufruft.   Der Browser wird
einen eventuellen Angriffsversuch melden.   Falls das tatsächlich
passiert, macht man hier und heute eben kein Onlinebanking sondern macht
das dann nachher oder geht in ein anderes Gasthaus.



Gruß
- Danny

-- 
Unix User Group Rhein-Neckar e.V.: https://www.uugrn.org
Archiv und An-/Abmeldung:          https://mail2.uugrn.org
Social Media:                      https://social.uugrn.org