Nicht WLAN aus, sondern SSL an!

[mark13]

Wer seine Sicherheit darauf aufbaut, dass auf der Leitung nicht mit gelauscht wird, hat schon ein ganz anderes Problem: Sich selbst.

[antares]

mark13 schrieb:
--------------------------------------------------------------------------------
> Wer seine Sicherheit darauf aufbaut, dass auf der Leitung nicht mit
> gelauscht wird, hat schon ein ganz anderes Problem: Sich selbst.


sslproxy owned you.
SSL ist nicht sicher, auch wenn andere stellen das suggerieren wollen. Fakt ist, dass ettercap schon seit ewigkeiten live in SSL reinhören kann, und ein Openwrt-basierter Router kann SSL-Daten nicht nur live entschlüsseln und weiterleiten, er kann sie auch noch modifizieren.

Um dich zu zitieren:
> Wer seine Sicherheit darauf aufbaut, dass auf der Leitung nicht mit
> gelauscht wird, hat schon ein ganz anderes Problem: Sich selbst.

Warum UNIX/Linux schaedlich ist:
'kill' macht Menschen zu brutalen, blutruenstigen Bestien,
'killall' zuechtet regelrecht Massenmoerder,
'whoami' loest bei psychisch labilen Personen Existenzkrisen aus!
'touch /dev/breasts' macht root zum Sex-Offender
******
macht aus nutzern raubmordhörer ohne klickibuntigui!

[Atrocity]

Man kann aber nur mithören wenn man das Zertifikat der Gegenstelle hat...

[antares]

Atrocity schrieb:
--------------------------------------------------------------------------------
> Man kann aber nur mithören wenn man das Zertifikat der Gegenstelle hat...


Falsch! SSLProxy ist eine klassische MITM Attacke. Das Zertifikat der gegenseite wird von sslp aus zufallsdaten generiert.

Warum UNIX/Linux schaedlich ist:
'kill' macht Menschen zu brutalen, blutruenstigen Bestien,
'killall' zuechtet regelrecht Massenmoerder,
'whoami' loest bei psychisch labilen Personen Existenzkrisen aus!
'touch /dev/breasts' macht root zum Sex-Offender
******
macht aus nutzern raubmordhörer ohne klickibuntigui!

[Atrocity]

Hmm, müsste der Angreifer dazu nicht mein komplettes Netzwerk verbiegen? Also über transparenten proxy leiten, meinen Nameserver ändern via dhcp?

Wobei er mir natürlich immer noch das komplette Internet vorspielen kann inkl. Fake antworten von den IPs die ich anfrage...

Damn, ich bin doch eh schon paranoid o_0

[ID51248]

Wenn der Mann in der Mitte nicht den private Key hat, kann er zwar einen Tunnel aufbauen, aber sich nicht authentifizieren: der Browser beklagt ein falsches Zertifikat. Erst wenn der Benutzer das abnickt (kommt leider zu oft vor, weil es viele self-signed-certificates gibt), dann geht er dem Mann auf den Leim.

Grüße
Sascha

[drep]

Atrocity schrieb:
--------------------------------------------------------------------------------
> Hmm, müsste der Angreifer dazu nicht mein komplettes Netzwerk verbiegen?
> Also über transparenten proxy leiten, meinen Nameserver ändern via dhcp?

CMIIW, Es reicht doch auch das der DNS Server im gefakten WLAN für z.b. www.meinebank.de eine falsche IP-Adresse liefert. Dann fängt er die Zertifikats-Abfrage ab jubelt ihm das falsche Zertifikat unter und fertig.

[Atrocity]

Nunja, wenn ich etwas google und en Maillisten Archiv sein self signed cert bestätigt haben will, ok, kein Ding, das mach ich.

Aber wenn so etwas bei meiner Bank auftauchen würde, würde ich viel machen, aber sicher nicht das Zertifikat abnicken!

[antares]

Das Problem dabei ist, dass nicht alle Browser die Zertifikate auch wirklich prüfen. Nach dem Motto: Wenn der ausweis einigermassen echt aussieht, wird ers wohl auch sein. Abgesehen davon wirkt das SSL-Zertifikat eben echt. Der Browser wird keinen Unterschied zur Originalseite feststellen.

> Hmm, müsste der Angreifer dazu nicht mein komplettes Netzwerk verbiegen? Also über
> transparenten proxy leiten, meinen Nameserver ändern via dhcp?
>
> Wobei er mir natürlich immer noch das komplette Internet vorspielen kann inkl. Fake
> antworten von den IPs die ich anfrage...
> Damn, ich bin doch eh schon paranoid o_0

Der Angreifer braucht dein Netzwerk nicht zu verbiegen. DU verbindest dich ja zu SEINEM Hotspot. Dabei wird in der Regel DHCP benutzt, weil du als Client die IP-Einstellungen ja nicht wissen kannst. Der Hotspot ist dabei gleichzeitig auch dein Standardgateway.
Mein Oben angeführtes Beispiel mit OpenWRT würde damit den Job bereits erledigen. Es reicht eine einzige IPTables Firewallregel, um allen Traffic auf Port 443(SSL) auf localhost umzuleiten, wo ein transparenter SSL-Proxy lauert, der schaut, welche seite du haben willst.
Beispiel: Du willst auf www.paypal.com gehen
Dein Browser öffnet eine SSL-Verbindung auf www.paypal.com:443
Das Gateway(der angreifende Hotspot) leitet diese Verbindung via iptables auf sich selbst um. Der transparente SSL-Proxy auf dem Gateway schaut nach, welche seite du haben willst. Diese ist im HTTP-Header, den dein Browser sendet vermerkt(GET /URI HTTP/1.1\r\nHost: www.paypal.com\r\n...). Daraufhin baut der SSL-Proxy selbst eine Verbindung zu paypal auf, fragt das Zertifikat ab, kopiert die wesentlichen Infos und erstellt daraus selbst ein Zertifikat. Aussteller des Cert ist dabei der Proxy selbst, ausgestellt wird es auf paypal.com. Damit ist das Cert schon mal nicht self-signed. Eventuell prüft der Browser an dieser stelle, ob das Cert stimmt und gültig ist(der SSL Proxy wird in der Regel eine dem Browser bekannte Root-CA als aussteller angeben). Dieser Traffic kann vom Gateway abgefangen werden, und wenn der Browser auf seine CA Anfrage keine Antwort bekommt, akzeptiert er das CA idr stillschweigend. DU hingegen surfst auf irgendeiner Site die sich paypal.com nennt, und auch das schöne grüne Icon in der Addressleiste hat. Alles SSL-Verschlüsselt.

Und nun viel Spass beim einloggen^^

Ach ja, ganz vergessen: Arbeitsaufwand um derartiges einzurichten(inkl Hardwaremodding[WLAN aufbohren, man will ja möglichst viel coverage/OpenWRT drauf/Konfigurieren/UMTS-Verbindung einrichten/Akku einsetzen/Gerät aufstellen]) beträgt je nach übung und vorkenntnissen in der Materie ca 6-12 Stunden. Für 3 Kreditkarteninformationen und den restlichen Value Added Traffic nimmt man die doch gerne in Kauf?

Warum UNIX/Linux schaedlich ist:
'kill' macht Menschen zu brutalen, blutruenstigen Bestien,
'killall' zuechtet regelrecht Massenmoerder,
'whoami' loest bei psychisch labilen Personen Existenzkrisen aus!
'touch /dev/breasts' macht root zum Sex-Offender
******
macht aus nutzern raubmordhörer ohne klickibuntigui!

[Oswald]

antares schrieb:
--------------------------------------------------------------------------------
> Der transparente SSL-Proxy auf dem Gateway schaut nach,
> welche seite du haben willst. Diese ist im HTTP-Header, den dein Browser
> sendet vermerkt ...

Aber der HTTP-Header ist doch per SSL verschlüsselt. Wie soll dann der SSL-Proxy da ran kommen?

> Aussteller des Cert ist dabei der Proxy selbst,
> ausgestellt wird es auf paypal.com. Damit ist das Cert schon mal nicht
> self-signed.

Wenn das Zertifikat nicht self-signed ist, dann schaut der Browser in seiner Liste vertrauenswürdiger Certification Authorities nach, ob er dort den Aussteller des Zertifikates findet. Da dein Proxy dort nicht auftaucht, gibt der Browser eine Warnung aus.

Aber es kann ja sein, dass dein Proxy sich für eine Certification Authority ausgibt, die der Browser als vertrauenswürdig einstuft. Dann prüft der Browser anhand des öffentlichen Schlüssels der Certification Authority (den kennt der Browser, brauch ihn also nicht über's Netz besorgen) ob die Signatur deines (gefälschten) Certifikates echt ist. Das ist nicht der Fall, da du ja zum Signieren deinen eigenen Privaten Schlüssel verwendet hast, und nicht den der echten Certification Authority. Spätestens jetzt meckert der Browser.

> Eventuell prüft der Browser an dieser stelle, ob das Cert
> stimmt und gültig ist(der SSL Proxy wird in der Regel eine dem Browser
> bekannte Root-CA als aussteller angeben). Dieser Traffic kann vom Gateway
> abgefangen werden, ...

Das Zertifikat der Root-CA ist bereits im Browser eingebaut. Da entsteht überhaupt kein Traffic. Traffic entsteht nur dann, wenn der Browser seine Certificate Revocation List aktualisiert.

> und wenn der Browser auf seine CA Anfrage keine Antwort
> bekommt, akzeptiert er das CA idr stillschweigend.

Das stimmt nicht. Erst wenn der Browser sicher ist, dass das Zertifikat formal gültig ist (also nicht abgelaufen und von der CA tatsächlich ausgestellt) und dann die Certificate Revocation List der CA nicht erreichbar ist, dann akzeptiert der Browser das Zertifikat stillschweigend. Genau diese Schwachstelle wurde aber seit Bekanntwerden der Komprimitierung von Comodo in vielen Browsern beseitigt.

Dein Angriff kann also nur dann funktionieren, wenn der Benutzer die Warnungen des Browsers ignoriert und das gefälschte Zertifikat akzeptiert.



2 mal bearbeitet, zuletzt am 28.04.11 04:13 durch Oswald.