Re: E-Mail Sicherheit

York Maier <YM@xxxxxxxxxxxxxxx>:
Viele Provider bieten keine Verschlüsselung beim Zugriff
auf den E-Mail-Zugang an (offenbar werden sonst die
Supportprobleme zu groß). Das heißt insbesondere, dass
Kennwort und Passwort unverschlüsselt über das Inter-
net geschickt werden.

Nicht Zwangslaeufig. Du musst zwischen Transportverschluesselung
(SSL/TLS) und Verschluesselung innerhalb der Applikation (IMAP/POP3
Mailclient) differenzieren.

Das ist natürlich unschön. Doch was bedeutet es tatsäch-
lich in der Praxis:

Sowohl IMAP als auch POP3 unterstuetzen zwar den verschluesselten
Passwortaustausch, wo kein Klartextpasswort uebertragen wird auch wenn
keine Transportverschluesselung verwendet wird - und praktisch
alle E-Mail Clients unterstuetzen das, leider gibt es jedoch einen
Fallback auf unsichere PAsswortuebergabemethoden, die ebenso jeder
Client beherscht - teilweise transparent (d.h. fuer den Anwender
unsichtbar).

Welche Risiken bestehen, dass ein "Zufalls-Hacker" an die
Daten herankommt (also ein Hacker, der ohne konkretes
Ziel versucht, wo er etwas erreichen kann).

Bei mobilen Clients (Notebook, Smartphone, Heim-PC mit WLAN):
Sehr hoch.

Bei stationaeren Clients (Heim-PC mit Kabel): gering. Insbesondere
wenn der Mailprovider und Internet-Provider identisch sind, ist
dieses Risiko nahezu Null. Nicht ganz, denn ein erfolgreicher Angriff
z.B. auf deine DNS-Resolver kann dich trotzdem an den falschen
Mailserver umleiten - dies waere jedoch ein gezielter Angriff - die
bei Ottornormalverbrauchern eher selten sind.

Wie kann ein Hacker, der gezielt an die Zugangsdaten
herankommen will, vorgehen?

Es genuegt z.B. wenn ein Angreifer kompromittierte oder fake
Hotspots betreibt mit SSID-Namen bekannter Hotspotbetreiber in die
sich Mobile Endgereaet mit Mailclient automatisch einbuchen, dort
per Impersonation-Angriff sich als E-Mailserver ausgibt, der jedoch
nur die Unsicheren Klartext-Passwortmechanismen unterstuetzt, dein
E-Mailclient (der sich automatisch verbindet) den FAllback macht und
schon kennt der Angreifer deinen Mailprovider, deine Anmeldekennung
und dein PAsswort. Und das vollautomatisch bei Mobilgeraeten im
Vorbeigehen. Und damit du diesen Angriff nicht bemerkst (und bei
naechster Gelegenheit das Passwort aenderst), leitet er dich
automatisch weiter an den echten Mailserver und dein Mailclient
signalisiert erfolgreiche Verbindung zum richtigen Mailserver.

Sowas findet man durchaus in Flughafennaehe, Bahnhoefen und Hotels
mit entsprechender Zielgruppe. BTST.
(Dieser Angriff ist so einfach, praktikabel und bequem fuer den
Angreifer, dass es sich nicht um einen hypothetischen Angriff handelt,
sondern durchaus praktiziert wird. Und das nicht nur in irgendwelchem
Ausland)

(Die Mails selbst kann man im Prinzip verschlüsseln. Doch
kaum ein gewerblicher Anwender ist dazu - außer in Aus-
nahmefällen - bereit.)

Das hilft dir nichts mehr, wenn der Angreifer die Kontrolle ueber
dein Mailkonto erlangt hat.

Und weil die Mehrheit aller Anwender keine unterschiedlichen Kenndaten
fuer verschiedene Dienste verwenden, kennt der Angreifer mit deinem
Mailpasswort auch das Passwort fuer alle anderen Anmeldungen
(Social-Media, Firmenzugang etc.)

Eine wirksame Gegenmassnahme besteht aus drei Punkten:
1.) auf IMAP mit TLS verschluesselten Zugang bestehen.
2.) alle Mailclients so konfigurieren, dass sie ausschliesslich TLS
gesicherte Verbindung eingehen, unverschluesselten Fallback ablehnen
(nicht alle beherrschen das! -> Produktauswahl).
3.) den Mailclients die Verifikation der TLS-Zertifikate beibringen,
und dafuer sorgen dass bei falschem/unerwartetem Serverzertifikat
keine Verbindung gemacht wird - sonst hilft dir das nicht beim
Angriff.

Insbesondere die letzten beiden Punkte schraenken die Auswahl bei
Mailclients sehr stark ein. Die wenigsten Produkte erlauben es dem
Anwender zu gunsten der Sicherheit auf Bequemlichkeit zu verzichten -
und machen trotz gegenlautender Einstellmoeglichkeiten munter Fallback
auf Unverschluesselt wenn der Server sich per TLS unpaesslich zeigt,
oder blasen dein Passwort ueber jede Unverifizierte TLS-Verbindung,
oder es kuemmert den Mailclient einen Scheissdreck, dass der
Mailserver - der bisher immer ein gueltiges Zertifikat von z.B. der
Root-CA der deutschen Post o.Ae. signiert, ploetzlich ein gueltiges
Zertifikat von Comodo, zwei Microsoft Root-CAs oder StarCom praesentiert.
Fast allen Mailclients ist das scheiss egal, er sagt nur "Toll
Sicher! und garantiert der Echte Mailserver!!1elf".

Diese genannten CAs wurden in Vergangenheit kompromittiert,
zwei davon haben sich aber herausgeredet und werden nach wie vor
von der ueblichen Software per Default vollvertraut!

Mickeysoft hat immerhin die Root-CA Stammzertifikate geblacklistet
(Revozierung funktionert da mangels CRL im Zertifikat schlicht nicht)
womit ein Mailclient unter Wintendo der die GSS-API nutzt sowas als
ungueltig erkennt. Immerhin. Allerdings hat niemand sich bisher
getraut die anderen zusammen mit Diginotar kompromittierten CAs zu
blockieren - weil anders als bei Diginotar diesen niemand nachweisen
konnte, dass sich ihre GEschaeftgrundlage selbst zerstoert hat.
Und selbst die ploetzliche und unerwartete Flut revozierter
Zertifikate (ohne kommentar/begruendung) ist halt doch nur ein Indiz.
vgl: https://www.eff.org/deeplinks/2011/10/how-secure-https-today

Es gibt uebrigens derzeit keinen einzigen Mailclient auf dem Markt
(weder fuer $$$ noch kostenfrei/Opensource) der gezielt die
TLS-Zertifikatsverifikatoin auf ein Stammzertifikat oder wenigstens
ein einzelnes vom Anwender festgelegtes Server-Zertifikat einschraenken kann.

Selbst der Mailclient M/2 im Opera Webbrowser kann das nur ueber den
Umweg der kompletten Blockade aller andern Root-CAs auch fuer webseiten.
Der Zerfikatsstore von Mac OS X, den Mail.app verwendet, erlaubt zwar
immerhin die differnzierte Auswahl, welche Root-CA Zertifikate fuer
E-Mail als vertrauenswuerdig eingestuft werden sollen - das betrifft
aber leider nur die S/MIME Pruefung, und nicht die TLS-Operationen des
Mailclients selbst - hier wird die generische Einstellung verwendet
die auch fuer HTTPS-Webseiten im Browser gelten.

Falls jemand einen Mailclient kennt, bei dem man gezielt und dediziert
fuer die TLS-Verbindung zum Mailserver die Root-CA Zertifikate oder
wenigstens das Serverzertifikat einschraenken kann - ohne diese gleich
fuer alle anderen Anwendungen zu machen (das geht bei IE/Windows,
Safari/OS X oder Opera Browsesr auch ueber den jeweiligen eigenen
Zertifikatsstore), bitte hier aufzaehlen.

Nur so liesse sich dem TLS-Impersonation/MitM Angriff wirksam begegnen.

Alles ander ist halt Bequem.

Juergen
--
Juergen P. Meier - "This World is about to be Destroyed!"
end
If you think technology can solve your problems you don't understand
technology and you don't understand your problems. (Bruce Schneier)
.