Wohl kaum eine Technologie wird im beruflichen Umfeld so stark eingesetzt wie E-Mail. In Deutschland ist es fast vierzig Jahre her, dass die erste E-Mail verschickt wurde, und an so manchen Stellen merkt man dem Protokoll das Alter auch an.
Die Probleme dürften jedem bekannt sein: Nervigkeiten, wie Spammails, aber auch Sicherheitskritisches, wie Mails mit Schadsoftware oder Phishingmails. Neu sind diese Probleme aber nicht. Warum bestehen sie dann immer noch?
Bei einem so alten Protokoll, das eine derart hohe Verbreitung hat, ist die Absicherung besonders schwierig. Änderungen müssen bei jedem Teilnehmer vollzogen werden, sie müssen zwingend abwärtskompatibel sein und müssen in unterschiedlichsten Softwarestacks implementiert werden.
In diesem Blogbeitrag wollen wir uns anschauen, welche Methoden und Verfahren es gibt, damit E-Mails sicher werden, und welche Probleme darin lauern. Zunächst schauen wir uns die notwendigen Grundlagen an, gekürzt auf das, was absolut notwendig ist.
Grundlagen
Die zwei wichtigsten Protokolle für den E-Mailverkehr sind das Simple Mail Transfer Protocol (SMTP) und das Internet Message Access Protocol (IMAP). Wie der Name bereits vermuten lässt, wird IMAP zum Abrufen von Mails verwendet, während SMTP für den Verkehr zwischen Mailservern zum Einsatz kommt. Für uns ist deswegen nur SMTP interessant.
Server Struktur
Beim Versenden einer E-Mail sind in der Regel mehrere Server beteiligt. In kleineren Installationen kann ein einziger Server alle Aufgaben übernehmen, häufig werden die verschiedenen Aufgaben aber an mehrere Server übertragen. Ein übliches Layout kann man in der folgenden Skizze sehen:
Will ein User eine E-Mail verschicken, so sendet er diese mittels seines Mail User Agents (MUA) zu einem Submission Server. Dieser Server nimmt nur E-Mails an und übergibt diese dann an einen Outgoing Server. Der Outgoing Server findet den richtigen Incoming Server für den Empfänger der Mail und schickt diesem die E-Mail. Der Incoming Server entscheidet, ob er diese Mail annimmt und sendet diese an einen Storage Server, der die Mail abspeichert und bei dem der Empfänger diese E-Mail abholen kann.
Simple Mail Transfer Protocol
Den meisten dürfte bekannt sein, dass E-Mails sogenannte Header haben. In diesen Headern stehen beispielsweise der Absender, der Empfänger, die Uhrzeit usw. Im SMTP Protokoll werden allerdings diese Header nicht angeschaut. Für ein Beispiel eines SMTP Transfers sei auf die deutschsprachige Wikipedia verwiesen [1]. Bei SMTP wird die gesamte Mail in einen Umschlag gesteckt und ein Absender und Empfänger auf bzw. über diesen Umschlag (engl. Envelope) geschrieben. Eine SMTP Verbindung läuft nun in den Schritten: HELO, MAIL FROM, RCPT TO und DATA ab. Im MAIL FROM wird der Absender der Nachricht angegeben, im RCPT TO der Empfänger der Nachricht. Im Data Schritt wird die Mail, Header wie Body, übertragen. Das heißt, der Header-From und der Envelope-From stimmen nicht zwangsläufig überein. Dasselbe gilt für die Empfänger (TO, CC, BCC). Diese Eigenschaft ist den meisten Nutzern allerdings nicht bewusst, und wird häufig für diverse Attacken verwendet.
Unerbetene Gäste: Spam, Phishing, Scams und Viren
Nicht jede Mail ist beim Empfänger auch erwünscht. Neben altbekanntem Spam, zum Beispiel, man sei der letzte lebende Verwandte eines sehr reichen kürzlich verstorbenen Adligen, Werbung für Produkte aller Art, gibt es moderne Adaptionen, wie das Versprechen, durch Bitcoin schnell reich zu werden. In den letzten Jahren gibt es auch häufiger Mails, die sich erst nach einem weiteren Mailverkehr als Betrugsversuch darstellen. Im unserer Umgebung werden Benutzer von “angeblichen” Professoren angeschrieben, mit der Bitte sich rasch zurückzumelden. Nach der Rückmeldung wird gesagt, man sei gerade sehr beschäftigt und darum gebeten, Google Play Karten zu kaufen und die Nummer zuzusenden. Auch immer wieder erfolgreich, eine Mail von der IT Abteilung zu senden, dass das Passwort abgelaufen, die Mailbox voll, oder man sich aus anderen Gründen mittels eines Links schnell einloggen müsste. Im universitären Umfeld treiben sich auch predatory Publisher/Journals rum: Mit Angeboten einfach publizieren zu können, schaden diese der Wissenschaft und den Wissenschaftler:innen.
Nicht zuletzt gibt es auch immernoch Personen, die Mails mit schadhaften Dateien verschicken. Durch Routinen und Muskeltraining der Empfänger wird häufig auch ein erforderlicher Klick auf »Bearbeitung aktivieren«, wie er für schädliche Office Macros erforderlich ist, erreicht.
Gegenmaßnahmen
Was kann man nun tun, um weniger Spam zu erhalten und seinen Nutzern weniger Viren oder Betrugsversuche zuzustellen? Vielleicht wird der geübte Leser schon über Sicherheitsziele gestolpert sein. Der BSI Grundschutz verlangt immer: Integrität, Verfügbarkeit und Vertraulichkeit. Übergeordnet ist aber noch das Ziel Authentizität. Wie kann ich das erreichen?
Gefälschte Absender: SPF, DKIM, DMARC
Im HELO Schritt nennt der sendende Mailserver seinen Namen. Der empfangende Server kann über DNS den genannten Namen auflösen und mit der sendenden IP-Adresse abgleichen. Außerdem überprüfen viele Server über einen reverse DNS Lookup, ob die IP-Adresse auch auf den Namen zurückverfolgbar ist.
Den MAIL FROM zu überprüfen ist schon problematischer. Ein Mailserver liefert in der Regel Mails für mehrere Domains aus, deswegen kann hier nicht auf Gleichheit der Domain mit dem HELO Namen überprüft werden. Mit SPF wurde ein Verfahren entwickelt, mit dem durch DNS abgefragt werden kann, welche Server berechtigt sind für bestimmte Domains Mails zu verschicken. Gibt der Server als MAIL FROM die Adresse »foo@bar.example.com« an, werden die TXT Einträge der Domain »bar.example.com« abgefragt. Für »kit.edu« gibt es beispielsweise folgenden SPF Eintrag:
v=spf1 ip4:129.13.231.64/26 ip4:141.3.10.8 ip4:141.3.10.80 ip4:141.3.10.81 ip6:2a00:1398:9:f712::/64 ip6:2a00:1398:2::10:8 ip6:2a00:1398:2::10:80 ip6:2a00:1398:2::10:81 ~all"
Hier werden also die IP Adressen genannt, die als MAIL FROM die Domäne »kit.edu« angeben dürfen.
Der MAIL FROM gibt die Adresse an, an die im Fehlerfall ein Zustellungsfehler gesendet werden soll. Gibts es beispielsweise eine Mailadresse nicht, soll an die MAIL FROM Adresse eine Mail mit der Fehlerbeschreibung geschickt werden. Daher sollte diese Adresse von den Beteiligten Mailservern nicht abgeändert werden. Nun kann es durch eine zu strikte Anwendung von SPF allerdings zu unerwünschten Verhalten kommen. Nehmen wir an, eine Professorin nimmt einen Ruf an einer neuen Universität (uni-b) an. Ihre alte Uni (uni-a) lässt eine Weiterleitung auf die neue Uni zu, damit die alte Mailadresse, die auf zahlreichen Papern steht, noch Gültigkeit besitzt. Schickt nun eine Person (Mail person@p.example.com) eine E-Mail an die Professorin (prof@uni-a.example.com), so ensteht folgende Konstellation: Person → Uni A → Uni B → Professorin. Für den Mailserver der Uni B sieht es nun so aus, also würde der Mailserver der Uni A eine Mail von »person@p.example.com« schicken. Wenn der SPF Eintrag dies nun verbietet, funktioniert die Weiterleitung nicht mehr.
Wie oben schon erwähnt ist es ein Problem, dass MAIL FROM und Header FROM nicht zwingend identisch sind. In manchen Fällen hat Benutzer gar keine Möglichkeit, sich den MAIL FROM anzuschauen, weil der Eingangsserver diesen nicht in die Header schreibt, generell machen es aber die Mailprogramme (Mail User Agents, MUA), schwer, sich weitere Infos der E-Mail Header anzuzeigen. Wer schon versucht hat, sich E-Mail-Header in Microsoft Outlook anzeigen zu lassen, kann das vermutlich nachvollziehen.
Nun kann heutzutage schon der Wald- und Wiesen Spammer- und Virenverschicker eine Domain einrichten und darüber seine E-Mails loslassen. Er kann dafür auch eine beliebige Mailadresse in den Header FROM eintragen, mittels SPF ist diese Adresse nicht geschützt. Der Empfänger sieht die Mail, denkt sich “Person X kenne ich” und klickt auf den Link, um sein Passwort zu zurückzusetzen. Um den möglichen Senderkreis einer E-Mail mit einem bestimmten Header FROM einzuschränken, schauen wir uns nun DKIM und DMARC an. Wir haben anfangs schon gelernt, dass SMTP Header und Body einer E-Mail nur als Datenteil auffasst. Im Header FROM einer Mail könnten eigentlich mehrere Absender stehen. Faktisch kommt das aber nicht vor und wird sowohl von vielen Spamfiltern direkt aussortiert und durch Mailprogramme wie Outlook auch nicht angeboten. DKIM und DMARC setzen nun auf diesen Industriestandard.
DKIM ist ein Verfahren um Header und Body einer Mail kryptographisch zu signieren, und so Änderungen an der
E-Mail zu verhindern. In der E-Mail wird ein Key angegeben, der im DNS unter <Schlüsselname>._domainkey.<DOMAIN> hinterlegt ist.
Mit diesem Key sind Teile des Headers und der gesamte Body signiert.
Schickt nun »person@p.example.com« eine Mail, die DKIM signiert durch den Schlüssel »test« ist,
kann der empfangende Mailserver den Schlüssel unter test._domainkey.p.example.com herunterladen.
Dadurch kann er nun die erhaltene Mail auf Integrität prüfen.
Das ist leider nur die halbe Miete. Wenn der Spammer keine DKIM Signatur verwendet, kann der Empfänger
daraus nichts ableiten.
Hier kommt nun DMARC ins Spiel. DMARC ist wieder ein Eintrag im DNS, der unter _dmarc.<DOMAIN> abgerufen werden kann, in unserem Beispiel also _dmarc.p.example.com.
In diesem Eintrag kann der Domänenbesitzer eintragen, wie Mails behandelt werden sollen, bei denen weder SPF, diesmal bezogen auf
den Header FROM noch DKIM den Ursprung der Mail verifizieren können.
Schauen wir uns nochmal das Beispiel der Professorin an. Signiert der Mailserver von »p.example.com« seine Mails mittels DKIM, so wird diese DKIM-Signatur durch die Weiterleitung erhalten bleiben. An Uni-B wird zwar der SPF Record ungültig sein, die Authentizität wird durch DKIM dennoch bestätigt.
Ist nun alles gut? Nein, leider nicht. Durch DMARC können Mailinglisten leider nicht mehr wie bisher betrieben werden. Normalerweise blieb bei Mailinglisten der Header From erhalten, der MAIL FROM wurde auf eine Adresse der Mailinglistensoftware gesetzt. Nun wurde für jeden Empfänger eine neue Mail generiert, mit Mailinglisteninformationen im Body, wodurch die DKIM Signatur unbrauchbar wurde. Überprüft der Empfänger nun die DMARC Einstellungen, so können weder SPF noch DKIM verifiziert werden. Infolgedessen breitete sich die Methode aus, dass der Header FROM geändert wurde in »Nutzer via Mailingliste mailingliste@example.com« oder ähnliches.
Es gibt also Gründe, warum SPF, DKIM und DMARC noch nicht überall eingesetzt werden. Unerwünschte Mails, die durch eine DMARC Prüfung kommen, sind meistens anders, als die Standard Mails, die angeblich von einem nigerianischen Prinzen verschickt werden. Wie man solche Spammails erkennt, wird im nächsten Absatz erklärt.
Spamfilter
Die meisten Mailserver dürften mittlerweile mit einem Spamfilter betrieben werden. Die bekanntesten Vertreter für Spamfilter sind »SpamAssassin« und »rspamd«. Bei Beiden lassen sich Eigenschaften definieren, für welche dann ein Symbol und ein Score hinzugefügt wird. Diese Eigenschaften umfassen beispielsweise den Absender, Wörter im Betreff oder im Mailbody, oder der Standort des versendenden Servers. Der Mailserver führt dann ab einem festgelegten Score verschiedene Aktionen aus, zum Beispiel das Ablehnen der Mail oder das Taggen als Spam. Spamfilter können mit guten (HAM) und schlechten (SPAM) Mails trainiert werden. Dadurch wird die Präzision erhöht und neue Mails werden seltener falsch einsortiert. Für dieses Training können auch E-Mails automatisch eingelernt werden, sobald diese einen Score über- bzw. unterschreiten.
Außerdem gibt es Anbieter von Blocklisten, auf denen Server und Absender von Spammails gesammelt werden. Diese Blocklisten können entweder vom Mailserver oder vom Spamfilter benutzt werden, um neue Mails abzulehnen.
Für virenbehaftete Anhänge können diese Mails mit einem Virenscanner überprüft werden. Auch lehnen viele Mailserver bestimmte Anhänge (.exe-Anhänge, Office Dateien mit Macros)[3] ab.
Ein guter Spamfilter muss leider immer erneuert werden, damit er Spam herausfiltern kann. Schauen wir uns zwei Möglichkeiten an:
Spamtrap
Um an schlechte E-Mails zu kommen, lässt sich eine sogenannte »Spamtrap« einrichten. Diese Spamtrap sind Mailadressen, hinter denen keine legitimen Empfänger stehen. Entweder werden diese Mails in einem Postfach gespeichert, oder diese Mails werden nur verwendet um den Spamfilter zu trainieren. Mailadressen der Spamtrap (zum Beispiel »dein.name@kit.edu«) können auf der Webseite veröffentlicht werden und werden da von Spammern gesammelt.
Spammeldeverfahren
Am KIT gibt es einen gemeinsamen Ordner, in dem die Teilnehmer Spam hinterlegen können, der nicht durch den Spamfilter erkannt wurde. Nach einer manuellen Prüfung werden diese E-Mails benutzt um den Spamfilter zu trainieren. Bei einer Auswertung können auch neue Regeln erstellt werden, beispielsweise das Bestrafen von bestimmten Betreffen. Die Rate, wieviele Mails pro Tag gemeldet werden, ist einer der wichtigsten Key Performance Indicator (KPI) für den Spamfilter. Je erfolgreicher Spammails erkannt werden, desto weniger Mails werden gemeldet.
Weitere Maßnahmen
Die größeren Puzzleteile haben wir jetzt schon zusammen. Aber das Bild wird erst komplett, wenn wir auch kleinere Maßnahmen miteinbeziehen. Zum einen sind das Einstellungen an den Mailclients der User, zum anderen Möglichkeiten, die der Betreiber von Mailservern haben sollte, damit sie schnell umgesetzt werden können, bevor sich die Notwendigkeit ergibt.
Einstellungen am Mail User Agent
In Exchange werden E-Mails bekannter Absender aus »Junk-Ordner« wieder in den Posteingang gefiltert. Dieser Mechanismus benutzt die Mailadresse aus dem »From« Header. Wie oben bereits erwähnt, lässt sich dieser sehr leicht fälschen. Dementsprechend ist von dieser Option abzuraten, wenn kein DMARC benutzt wird.
Outlook ist auch so einzustellen, dass es die Mailadresse des »From« Headers anzeigt. Die frei wählbaren Namen werden bei Phishing Mails häufig auf Abteilungsleiter:innen und Professor:innen gesetzt. Wenn die Angreifer aber Antworten erwarten, können sie die Mailaddresse nicht ändern, die den Betrug schnell auffliegen lässt.
Sperren von Empfängern (ausgehend)
Bei dem oben erwähnten Betrug über Google-Play Karten ist es auch sinnvoll die Absender der Mails am ausgehenden Mailserver zu sperren. Dadurch wird die weitere Kommunikation zum einen verhindert, zum anderen erhalten alle eine Fehlermeldung, die danach versuchen dem Empfänger eine E-Mail zu schreiben.
Sperren von Absendern
Genauso sollte auch die Möglichkeit bestehen, bestimmte Absender oder Absenderdomains zu sperren. Dadurch lassen sich auch zielgerichtete Angriffe unterbinden.
Wenn das Kind schon in den Brunnen gefallen ist: Reaktive Maßnahmen
Auch die besten Maßnahmen werden nicht verhindern, dass Personen auf Betrugsversuche hereinfallen. Am wichtigsten ist hier erstmal Verständnis. Auch wenn es leider einige Vertreter in der IT-Community gibt, die das behaupten, liegt es nicht an fehlender Intelligenz, dass ein Betrugsversuch erfolgreich war. Betrüger nutzen aus, dass das rationale Denken aussetzt, wenn Zeitdruck vorliegt [2]. Die meisten Betroffenen bemerken direkt nach dem Betrug, dass sie hier Opfer geworden sind. Wenn diese Angst haben, für ihr Verhalten abgestraft zu werden, melden sie ihre abgeflossenen Daten nicht und erzeugen dadurch noch ein größeres Sicherheitsproblem.
Freeze Verfahren
Durch Phishing kompromittierte Accounts werden häufig auffällig, da sie selbst beginnen, Spam zu versenden. Scannt man nun auch Mails am ausgehenden Mailserver, so kann man hier auffällige Mails erkennen. Am KIT verwenden wir hier ein ausgefeilteres Verfahren, bei dem auch weitere Faktoren, wie zum Beispiel unzustellbare Mails oder der Standort des versendenden Accounts einbezogen werden.
Fazit
E-Mails sind zwar ein sehr altes Medium, aber immernoch unverzichtbar in der Arbeitswelt. Sie abzusichern ist deshalb ein wichtiges Unterfangen und erfordert viele Prozesse, die ineinander verzahnt werden müssen. Dabei dürfen aber auch technisch unversierte Personen nicht verloren gehen, die Sicherheit eines Unternehmens entscheidet sich leider häufig im schwächsten Glied der Kette.
Dies waren bisher nur Verfahren, die zwischen den Servern ablaufen können. Weitere Verfahren wie Signaturen und End-To-End Verschlüsselung durch PGP oder SMIME, Gefahren durch HTML E-Mails liefern noch genug Stoff für weitere Blogbeiträge.
Verweise
[1] https://de.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol
[2] Daniel Kahneman: Thinking, Fast and Slow
[3] https://support.google.com/a/answer/6590?hl=en#zippy=%2Cmessages-that-dont-have-attachments%2Cmessages-that-have-attachments
Konstantin Zangerle, KIT-CERT, Karlsruher Institut für Technologie