ForceSSL
Natürlich würden Sie nie ihre Haustür offen stehen lassen und natürlich schließen Sie ihr Auto immer ab und vielleicht gibt es sogar noch eine Alarmanlage. Und warum greifen Sie auf ihre persönlichen Mails noch ohne Verschlüsselung zu? Spätestens der Artikel auf http://www.heise.de/ct/artikel/Aufstand-der-Router-1960334.html sollte sie aufscheuchen, dass nicht nur staatliche Organisationen wie NSA, BKA etc. ihre Kommunikation ablauschen können, sondern auch kriminelle Personen durchaus etwas mit ihren Zugangsdaten anfangen können.
Was passiert ?
Es gibt mittlerweile Schadcode, der sich gar nicht mehr auf ihrem PC sondern auf dem kleinen unscheinbaren Internetrouter einnistet, der die von ihnen gesendeten Daten zum Internet überträgt. Sie schaut in jedes Paket, ob dort Zugangsdaten enthalten sind und sammelt diese gezielt ein um sie dann an den Betreiber weiter zu geben. Dagegen hilft kein Virenscanner auf dem PC o.ä. sondern nur zuverlässige Verschlüsselung aller übertragenen Daten. Beim "Homebanking" ist es ja schon normal, dass nur ein verschlüsselter Zugriff möglich ist und wenn Sie auf andere Webseiten per Browser gehen, dann werden fast immer ebenfalls die Zugangsdaten per SSL abgefragt aber leider noch nicht überall.
Vergessen wird dabei aber immer, dass viele Anwender auch ihre Mails per POP3 oder IMAP4 abrufen und hier nur ganz selten "verschlüsselt" wird.
Betrifft mich das ?
Vielleicht sagen Sie nun, dass ihre Mails ja nicht so geheim sind und dass sich dafür doch eh niemand interessiert. Aber was passiert, wenn Sie z.B.: die Zugangsdaten zu ihrem PayPal, Twitter, Amazon oder anderen Konten "vergessen" haben und sie auf der per HTTPS verschlüsselten Webseite des Anbieter ein Kennwort-Reset/Recover anfordern? Sie erhalten eine Mail an ihre Postfach mit einem personalisierten Link. Und in dem Moment ist ihr Postfach bzw. der Zugriff darauf schon wieder der Schlüssel zu ihrem Geldbeutel.
Wenn ich ihre Zugangsdaten direkt mitgelesen oder über die Rücksetzfunktion erhalten habe, kann ich mich "als sie" ausgeben und beträchtlichen Schaden anrichten. Sei es monetär, weil ich über ihr Konto bei einem Versender Waren bestelle oder weil ich in ihrem Namen Links, Nachrichten, Tweet o.ä. poste oder an ihre Freunde in ihrem Namen weiteren Schadcode senden. Der Angreifer hat damit schon einen Vertrauensvorschuss und seine Erfolgsrate ist signifikant höher.
Das große Risiko ist dabei auch, dass ein Anwender das gleiche Kennwort bei unterschiedlichen Diensten verwendet und wenn nur einer der Zugriffe unverschlüsselt ist, öffnen sich alle Türen.
Betroffene Dienste
Der Schlüssel zu ihrer Identität ist in den meisten Fällen daher ihr Postfach, denn die meisten Anbieter von Webdiensten nutzen mittlerweile schon SSL, so dass ein Mitschneiden der direkten Anmeldung nicht einfach ist, zumindest wenn die SSL-Schlüssel lang genug, die Zufallsgeneratoren genug zufällig und der Angreifer nicht mit sehr viel Rechenleistung gesegnet sind.
- Ihr Postfach
Wenn Sie heute ihr Postfach per POP3/IMAP4 ohne Verschlüsselung abrufen, dann sollten Sie dies schleunigst umstellen. Sollte ihre Provider dies nicht anbieten, dann rate ich zu einem Providerwechsel. - FTP uploads von Webseiten
Pflegen Sie eine Webseite wie ich meine MSXFAQ und laden Sie neue HTML-Datei per FTP zum Provider hoch? Dann sollten Sie umgehend auch hier von FTP auf SFTP oder FTPS umstellen. Ansonsten kann ein Schnüffler sehr einfach den von ihnen gemieteten Webserver um eigene Dateien bereichern. Sie helfen damit kriminellen Personen, die über ihren Webserver dann weitere Straftaten begehen, sei es als PHP-Skript um andere Seiten anzugreifen oder die Rückmeldung von anderen Trojanern zu verschleiern oder Inhalte bereit zu stellen. - Zugänge zu Wordpress-Blogs,
Joomla CMS etc
Sie müssen ihre Webseite gar nicht lokal bearbeiten und per FTP hochladen, wenn Sie ein Content Management System oder eine Blogsoftware auf dem Webserver installiert haben. Die wenigsten Betreiber nutzen hierbei SSL was bei einem "Shared Hosting" mit vielen Blogs hinter einer IP-Adresse sowieso nur über Umwege möglich wäre. Aber das Kennwort ist natürlich sehr einfach auszulesen
Und es gibt noch viele weitere Dienste und Anwendungen die sie vielleicht tagtäglich verwenden und nicht darauf achten, dass die Verbindung "verschlüsselt" ist.
Hallo Provider !
Bei dieser Betrachtungsweise ist es eigentlich extrem leichtsinnig bzw. aus meiner Sicht sogar unverantwortlich, dem Anwender einen Zugang zum Postfach ohne Verschlüsselung zu erlauben. In der Anfangszeit des Internet waren SSL, TLS und Zertifikate oft noch "nice to have" aber heute darf man es Lauschern nicht mehr so einfach machen. Ich würde mir wünschen, dass die Anbieter von Diensten den Zugang ohne verschlüsselten Übertragungsweg gar nicht mehr zulassen. Aber einfach Abschalten kann man den Zugang natürlich auch nicht.
- Phase1: unverschlüsselte
Nutzer erkennen, zulassen und
informieren
Es ist für einen Provider sehr einfach zu erkennen, welcher Anwender über Port POP3 (110) oder IMAP4 (143) statt 995/993 ankommt. Es wäre langsam an der Zeit solche Zugriffe zu erkennen und dem Anwender immer wieder eine Information zukommen zu lassen, dass er sich über einen "unsicheren Weg" anmeldet und wie er dies umstellen kann - Phase 2: unverschlüsselte
Verbindungen auf ein Dummy-Postfach
mit Infos erlauben
Wenn es ein Provider wirklich ernst meist, dann würde ich hinter dem Port 110/143 einfach nur einen POP3/IMAP4-Dummy-Server betreiben, der Verbindungen von jedem Client mit beliebigem Benutzernamen und Kennwort zulässt aber immer nur genau eine Mail ausliefert, die ihm beschreibt, wie er den "richtigen Server" mit Verschlüsselung erreicht
Über kurz oder lang sollten die Clients auch zum Schutz des Anwender gesperrt sein, die kein SSL unterstützen. Man könnte das vielleicht noch abschwächen und POP3/IMAP4 ohne SSL zulassen, wenn dann wenigstens das Anmeldeverfahren, d.h. die Übermittlung der Anmeldedaten gesichert erfolgt. Exchange Administratoren können einstellen, dass ein Server eine Anmeldung mit "Plain Text" nur per SSL erlaubt und unverschlüsselt dann NTLM, Kerberos, Digest o.ä., zum Einsatz kommen muss
Analyse erforderlich
Als Betreiber eines Mailservers sollten Sie auf jeden Fall Anstrengungen unternehmen um solche "unsicheren" Anwender zu erkennen und zu informieren, wenn Sie denn wirklich POP3 und IMAP4 ohne SSL mit "Plain Authentication" zulassen wollen. Bei Exchange ist das definitiv nicht per Default der Fall und können Sie gerne auch nachschauen. So sollte es NICHT aussehen
[PS] C:\>Get-ClientAccessServer | Get-ImapSettings | ft server,logintype,*bind* -AutoSize Server LoginType unencryptedOrTLSBindings SSLBindings ------ --------- ------------------------ ----------- EX1 PlainTextAuthentication {[::]:143, 0.0.0.0:143} {[::]:993, 0.0.0.0:993} EX2 SecureLogin {[::]:143, 0.0.0.0:143} {[::]:993, 0.0.0.0:993}
Hier ist gut zu sehen, dass der Server EX1 eine Klartextanmeldung zulässt und Port 143 gebunden sind. Das gleiche auch für POP3
[PS] C:\>Get-ClientAccessServer | Get-POPSettings | ft server,logintype,*bind* -AutoSize Server LoginType unencryptedOrTLSBindings SSLBindings ------ --------- ------------------------ ----------- EX1 PlainTextAuthentication {[::]:110, 0.0.0.0:110} {[::]:995, 0.0.0.0:995} EX2 SecureLogin {[::]:110, 0.0.0.0:110} {[::]:995, 0.0.0.0:995}
Standardeinstellung ist bei Exchange die Einstellung von EX2, bei der ein "SecureLogin" erforderlich ist.
Wer auf ihrem Exchange Server per POP/IMAP ohne SSL zugreift, können Sie einfach erkennen, Wenn Sie die Protokollierung einschalten. Sie ist per Default ausgeschaltet:
[PS] C:\>Get-ClientAccessServer | Set-ImapSettings -ProtocolLogEnabled $true [PS] C:\>Get-ClientAccessServer | Set-popSettings -ProtocolLogEnabled $true
Hinweis: Diese Änderungen erfordern einen Neustart des IMAP bzw. POP3 Diensts, was in einer administrativen PowerShell schnell erledigt ist. Bei Exchange 2013 sind es auf einem kombinierten Server gleich zwei Dienste
[PS] C:\>Get-Service *pop* | Restart-Service [PS] C:\>Get-Service *imap* | Restart-Service
Die Protokolle haben per Default folgende Einstellung
[PS] C:\>Get-ImapSettings | fl *log* LoginType : SecureLogin ProtocolLogEnabled : False LogFileLocation : C:\Program Files\Microsoft\Exchange Server\V15\Logging\Imap4 LogFileRollOverSettings : Daily LogPerFileSizeQuota : 0 B (0 bytes) [PS] C:\>Get-popSettings | fl *log* LoginType : SecureLogin ProtocolLogEnabled : False LogFileLocation : C:\Program Files\Microsoft\Exchange Server\V15\Logging\Pop3 LogFileRollOverSettings : Daily LogPerFileSizeQuota : 0 B (0 bytes)
Bei Exchange 2010 müssen Sie V15 durch V14 ersetzen. Auf einem Exchange 2013 Server, der sowohl Mailbox als auch CAS ist, landen dann zwei Logfile pro Tag im Verzeichnis:
- IMAP4BE20130921-1.Log
Protokolldatei des Backend Servers. Hier ein exemplarischer gekürzter Auszug. Man sieht u.a. das Anmeldeverfahren aber nur den Port des Backend Servers. Ob die Verbindung per SSL gesichert war, ist hier nicht zu sehen.
dateTime,sessionId,seqNumber,sIp,cIp,User,duration,rqsize,rpsize,command,parameters,context #Software: Microsoft Exchange Server #Version: 15.0.0.0 #Log-type: IMAP4 Log #Date: 2013-09-21T12:04:15.362Z #Fields: dateTime,sessionId,seqNumber,sIp,cIp,User,duration,rqsize,rpsize,command,parameters,context 2013-09-21T12:04:15.362Z,01,0,[ipv6]:9933,[ipv6]:65110,,191,0,53,OpenSession,, 2013-09-21T12:04:20.425Z,01,1,[ipv6]:9933,[ipv6]:65110,fcarius,4407,31,33,authenticate,PLAIN,"R=ok;Msg="....."" 2013-09-21T12:04:20.456Z,01,2,[ipv6]:9933,[ipv6]:65110,fcarius,0,0,0,CloseSession,,"Budget=..."
- IMAP420130921-1.Log
Protokoll des Frontend Proxy mit der echten Client-IP.
#Software: Microsoft Exchange Server #Version: 15.0.0.0 #Log-type: IMAP4 Log #Date: 2013-09-21T12:04:13.144Z #Fields: dateTime,sessionId,seqNumber,sIp,cIp,User,duration,rqsize,rpsize,command,parameters,context 2013-09-21T12:04:13.144Z,01,0,192.168.100.32:143,192.168.100.20:22228,,103,0,53,OpenSession,, 2013-09-21T12:04:13.284Z,01,1,192.168.100.32:143,192.168.100.20:22228,,64,15,125,capability,,R=ok 2013-09-21T12:04:13.362Z,01,2,192.168.100.32:143,192.168.100.20:22228,,79,13,36,starttls,, 2013-09-21T12:04:13.378Z,01,3,192.168.100.32:143,192.168.100.20:22228,,5,15,113,capability,,R=ok 2013-09-21T12:04:20.425Z,01,4,192.168.100.32:143,192.168.100.20:22228,fcarius,7042,44,26,login,frank.carius@netatwork.de *****,"R=ok;Msg="...."" 2013-09-21T12:04:20.441Z,01,5,192.168.100.32:143,192.168.100.20:22228,fcarius,0,0,0,CloseSession,,"Budget=""Owner:Sid~MSXFAQ\fcarius~Imap~false,Conn:1,MaxConn:unlimited,MaxBurst:60000,Balance:60000,Cutoff:unlimited,RechargeRate:240000,Policy:GlobalThrottlingPolicy_815f51d8-e00b-466c-97a0-d2e568f6fab4,IsServiceAccount:False,LiveTime:00:00:06.2656665"""
Hier kann man ebenfalls sehen, dass die Anmeldung erfolgt ist. Das Kennwort ist unkenntlich gemacht und da der Port 143 verwendet wird, ist die Verbindung nicht per SSL auf Port 995 erfolgt. Aber Sie sehen auch das "STARTTLS", was ebenfalls eine Verschlüsselung des Datenstroms anfordert. Um Exchange Logs auszuwerten, müssen also mehrere Zeilen ausgewertet werden.
Weitere Links
- Aufstand der Router - Hinter
den Kulissen eines Router-Botnets
http://www.heise.de/ct/artikel/Aufstand-der-Router-1960334.html - Netzwerkcheck
http://www.heise.de/security/dienste/portscan/test/go.shtml?scanart=1