In unserem ersten Beitrag zum Thema E-Mail-Sicherheit haben wir einen Einblick in die historische Entwicklung der E-Mail gegeben. Wir haben kurz erklärt wie der E-Mail-Austausch funktioniert und haben auf die Statistiken des E-Mail-Services an der RWTH Aachen University verwiesen.
Heute klären wir euch über das Übertragungsprotokoll „Simple Mail Transfer Protocol“ (SMTP) auf und welche Tücken es birgt.
Das SMTP Protokoll
Das SMTP Protokoll ist ein sehr altes Protokoll. Es verarbeitet über entsprechende Metainformationen den Absender bzw. den Empfänger einer E-Mail Nachricht. Zu den Meta-Informationen gehören also die Adressen der Absender und Empfänger oder auch das Datum und der Betreff der Nachricht.
Diese Metainformationen gehören zu einer Mail und sind im sogenannten Mail-Header enthalten. Im Rahmen des Versands einer E-Mail teilt der versendende Client dem Postausgangsserver ebenfalls den Absender und den/die Empfänger*in separat mit. Diese Angaben bilden den Mail-Envelope (Briefumschlag). Der Mail-Envelope wird fortan von allen auf dem Versandweg beteiligten Mailservern für die Zustellung der E-Mail verwendet. Bei der Zustellung der E-Mail ins Zielpostfach wird dieser Mail-Envelope wieder entfernt. Genau an dieser Stelle liegt aber eines der Probleme.
Analyse und Hauptprobleme des SMTP Protokolls aus Sicherheitssicht
Das SMTP Protokoll in seiner einfachsten Ausführung beinhaltet keinerlei Authentifizierung und Autorisierungsschicht. Das heißt, der Absender, der vom Client im Mail-Envelope angegeben wird, wird vom Server nicht überprüft. Somit ist es theoretisch möglich, dass jede Person mit jeder anderen Absende-Adresse E-Mails versenden darf. Wie man schnell feststellt öffnet dieser Mechanismus für Phishing und SPAM sämtliche Türen.
Ein zweites Problem besteht darin, dass es drei Absende-Adressen in jeder E-Mail gibt. Zum einen ist es die Envelope-Sender-Adresse. Wie weiter oben schon beschrieben, wird diese Information beim Empfangen einer E-Mail gelöscht. Sie ist aber hauptverantwortlich für die eigentliche Zustellung einer E-Mail.
Zwei weitere Metainformationen die den Absender beinhalten sind das „From-Path“ und das „Return-Path“ Attribut. Im Normalfall sind alle drei Attribute mit dem gleichen Wert belegt. Das „From-Path“ Attribut wird dem Empfänger einer E-Mail vom E-Mail-Programm als Absende-Adresse angezeigt. Das Return-Path Attribut wird dazu verwendet um dem Absender eine Bounce-Nachricht in dem Fall zuzuschicken, sollte die E-Mail nicht zugestellt werden können. Diese Informationen könnten in einem Mailheader wie folgt aussehen:
Zunächst einmal steht zu Beginn des Mail-Headers die Receive-Zeilen der Mail-Server, die diese konkrete Mail verarbeitet haben. Als Beispiel führen wir hier einen Mail-Header auf, der eine E-Mail von gmx.de an die RWTH Aachen beinhaltet. Der Mail-Header beinhaltet in diesem Fall die folgenden Informationen:
Neben dem absendenden und empfangenden Mail-System wird jeweils noch ein Zeitstempel mitgeführt, sodass im Idealfall die Laufzeit einer E-Mail ermittelt werden kann. Diese Informationen werden während des Versandwegs in den Mail-Header geschrieben.
Die Informationen des Mail-Headers kann man sich nun zu Nutze machen, wenn man überprüfen möchte ob eine E-Mail von einem Mail-Server versendet werden darf, oder ob es sich vermutlich um eine gefälschte E-Mail handelt. Dieses Verfahren wird als SPF (Sender Policy Framework) bezeichnet und wurde 2014 über den RFC 7208 [1] veröffentlicht. Hierbei wird im DNS Server [2] für jede E-Maildomäne ein Eintrag hinterlegt, der eine Liste der E-Mailserver enthält, die berechtigt sind E-Mails für Absender dieser E-Maildomäne zu versenden, sodass ein empfangender Mailserver mit Hilfe dieses Eintrags eine entsprechende Prüfung vornehmen kann. Die RWTH Aachen hat diese Protokollerweiterung vor einigen Jahren eingeführt. Über die Auswertung finden sich ebenfalls entsprechende Hinweise im Mail-Header:
In einem weiteren Blogbeitrag werden wir euch erklären was das IT Center derzeit noch implementiert hat um für Euch einen sicheren E-Mail Austausch bewerkstelligen zu können. Des Weiteren werden wir darauf eingehen was wir in Zukunft vorhaben um für kommende Entwicklungen gerüstet zu sein.
Verantwortlich für die Inhalte dieses Beitrags sind Morgane Overath und Thomas Pätzold.
[1] RFC: Die Requests for Comments sind eine Reihe technischer und organisatorischer Dokumente zum Internet. Es handelt sich um nummerierte Dokumente, in dem Protokolle, Konzepte, Methoden und Programme des Internets behandelt, beschrieben und definiert werden. Sie bilden beispielsweise die technische Grundlage von Internetanwendungen wie E-Mail.
[2] DNS Server: DNS steht für „Domain Name System“. Es handelt sich um ein hierarchisches Verzeichnissystem welches den Computernamen (Fully-Qualified Domain Name – FQDN) in die zugehörigen IP-Adressen übersetzt. Sie fungieren sozusagen als Telefonbuch des Internets.