dahamwirdensalat

SMTP, das steht für Simple Mail Transport Protocol, und ist im Wesentlichen auch das: Ein einfaches Protokoll zum Transport von eMails. Meiner Meinung nach sollte es aber eigentlich MTSMTP heissen – Much Too Simple Mail Transport Protocol. In der Zeit, als es entwickelt wurde, war es vielleicht ausreichend, aber jetzt – nachdem das Protokoll schon etwas Staub angesetzt hat – zeigen sich grundlegende Probleme des gesamten Systems des Mailtransports, die bei der Entwicklung von SMTP noch nicht absehbar waren.

SMTP wurde als Request For Comments 821 im August 1982 von Jonathan Postel veröffentlicht (http://www.ietf.org/rfc/rfc0821.txt). Dieses Protokoll wurde in einigen Bereichen erweitert und verändert, aber weniger im Funktionsumfang, als vielmehr, um es in andere technologische Entwicklungen der letzten 20 Jahre zu integrieren. Die derzeit aktuelle Spezifikation ist RFC 2821 (http://www.ietf.org/rfc/rfc2821.txt), veröffentlicht 2001.

Das bedeutet nichts anderes, als dass die Fundamente der Nachrichtenübertragung per eMail mittlerweile 22 Jahre alt sind. Sie stammen aus einer Zeit, in der noch gar nicht abzusehen war, dass es so etwas wie das kommerzielle Internet jemals geben wird. Auch vom WWW war damals noch keine Spur. Erst 12 Jahre nach der Einführung von SMTP wurde das Netz für nicht-wissenschaftliche Zwecke geöffnet!

Es ist also kein Wunder, dass dieses Protokoll einige massive Schwierigkeiten hat, mit den Gegebenheiten des modernen Internet klar zu kommen. Schauen wir uns mal ein paar solcher Probleme an.

RFC 2821 definiert eine klare Abfolge, wie die Kommunikation zwischen dem Versender eines eMails (z.B. eines eMail Clients wie Outlook oder Mail.app) und dem Mailserver, der für den Weitertransport der eMail zuständig ist, vonstatten gehen muss. Es ist durchaus hilfreich, sich diesen Prozess einmal genau anzusehen.

Auf Computer A läuft ein Mailserver-Programm. Dieses Programm horcht auf Netzwerkverbindungen auf dem Port 25, dem sogenannten “well known port” für SMTP. Auf Computer B schreibt gerade jemand eine eMail. Wenn diese Person fertig ist, schickt sie die Mail ab, d.h. der Computer B verbindet sich zu A auf Port 25.

A reagiert auf diese Verbindung mit einer Status-Meldung. Danach kann B den Befehl EHLO (oder HALO bei älteren SMTP-Implementierungen) senden. Dieses EHLO kann gefolgt werden von einem Namen für den Computer B.

Damit ist die Verbindung zwischen den beiden Rechnern initialisiert, und B kann nun versuchen, an A eine eMail abzusenden. Der zweite Befehls-Block lautet wie folgt:

Dieser Dreischritt macht einige Probleme, wie man später noch sehen wird. Für den Anfang begnügen wir uns mit zwei Feststellungen: Erstens gibt es keinen standardisierten Mechanismus, wie der Mailserver die Richtigkeit der in Schritt 1 angegebenen eMail Adresse überprüfen könnte. Ob somewhere.org existiert, weiss ich nicht. Ich weiss aber, dass bill@microsoft.com als Absende-Adresse von jedem Mailserver der Welt akzeptiert werden würde. Auf der anderen Seite wird die Gültigkeit des Rezipienten sehr wohl bereits am Beginn der Transaktion festgestellt. Dabei handelt es sich aber primär um eine Arbeitserleichterung für den Mailserver.

Zweitens: Dieses Verfahren trennt die eMail (im RFC als “mail object” bezeichnet) und das zu ihrer Zustellung benötigte Verfahren ab. Es gibt grundsätzlich keine definierte Verbindung zwischen der Information in 1 und 2, und der eMail, die ab Schritt 3 übertragen wird. Das wird noch wichtig.

Versandte eMails bestehen also aus zwei Teilen: Dem Teil, der vor dem Schlüsselwort DATA geschickt wird, und dem Teil, der danach an den Server übermittelt wird. Der erste Teil wird – in Form einer Analogie zu Briefen – als Envelope (Umschlag) bezeichnet. Adressinformationen, die für die Zustellung benötigt werden, stehen auf diesem Envelope. Evntl. finden sich solche Adressinformationen von Absender und Empfänger ebenso im Brief selbst wieder. Klar ist aber, dass diese Informationen nicht der Zustellbarkeit der Briefsendung dienen, sondern der besseren Archivierbarkeit. Zusatzinformationen wie eine Betreffzeile oder das Datum sind ebenso nur für den Empfänger des Briefs interessant, nicht aber für denjenigen, der für die Zustellung des Briefs zuständig ist.

Genauso verhält es sich auch mit eMails: Informationen der Zustellung finden sich generell im Envelope, Informationen, die für den Empfänger des eMails notwendig sind, befinden sich im eigentlichen Mail Object.

eMail und Envelope – Wie Brief und Umschlag

Um weiter bei der sehr ergiebigen Analogie des “normalen” Briefverkehrs zu bleiben, muss man sich den eigenen Mailserver nun nicht wie einen Postkasten vorstellen; Briefsendungen werden von der Post so wie sie sind in den Postkasten gelegt – mit unberührtem Envelope. Ein Mailserver hingegen agiert wie die Posteingangsstelle einer grossen Organisation: Eingehende Briefsendungen werden geöffnet, der Inhalt an die Postfächer der jeweiligen Adressaten verteilt, der Umschlag wird vernichtet. Eventuell wird noch zusätzliche Information auf dem Dokument vermerkt (z.B. das Datum des Eingangs), um Auskunft über Teile des Briefverkehrs geben zu können. Genauso verhält es sich auch mit dem Mailserver: Manche Informationen, die ermöglichen sollen, die Mail-Transaktion nachzuvollziehen, werden vom Envelope in das Mail hineinkopiert, der Envelope selbst aber wird verworfen.

Die “gelbe Post”, also die schöne Tradition, Scheiben toter Bäume in der Gegend herumzuschicken, erlaubt es, anonyme Nachrichten zu versenden. Ich bin mir da sehr sicher, weil ich heute in meinem Postkasten einen Brief fand, der zwar an mich adressiert war, aber keine Absender-Adresse hatte (Es war die Benachrichtung über den Gewinn eines Gewinnspiels, an dem ich nicht teilgenommen habe).

Auch hier funktioniert die Analogie zwischen gelber und elektronischer Post einwandfrei, denn genau das ist auch mit eMails möglich. Und ebenso, wie die anonyme Briefzustellung nur Spuren der Identität des Absenders beinhaltet (z.B. den Ort der Aufgabe auf dem Poststempel), hat auch die anonyme eMail nur Spuren dieser Identität (kurioserweise auch wieder den “Ort” der Aufgabe). Auch dazu später mehr.

Die Möglichkeit, (mehr oder minder) anonyme Briefe zu verschicken, ergibt sich daraus, dass das System, das für den korrekten Transport der Briefsendungen verantwortlich ist, die korrekte Angabe eines Absenders nicht überprüft. Daraus lässt sich natürlich sofort ableiten, dass es auch ohne Probleme möglich sein sollte, im Namen Anderer Briefe zu versenden. Für die gelbe Post kann ich das nur vermuten, aber bei der elektronischen Post geht auch das ohne Probleme.

Jeder Mail-Benutzer kann jederzeit eMails im Namen von Bill Gates verschicken. Alles, was dazu getan werden muss, ist im Mail Client als Absender-Adresse “bill@microsoft.com” einzutragen. Probiert es aus, wenn ihr wollt, oder glaubt mir einfach.

Um die eine oder andere Sache, die hier vorgestellt wird, auszuprobieren, braucht man telnet, ein kleines Programm, mit dessen Hilfe man Daten an Server schicken Kann. Um telnet zu starten, auf “Start” – “Ausführen” gehen, und dann telnet MAILSERVER 25 eingeben (statt MAILSERVER natürlich den Namen des eigenen Mailservers eingeben). Benutzer eines richtigen Betriebssystems nehmen bitte ein Terminal zur Hand und tippen telnet MAILSERVER 25.

Fangen wir mal mit einem Exoten an: Dem Mail ohne Kopf. Dieses mail ist sehr einfach herzustellen, wie folgender telnet-Dialog mit dem Mailserver beweist:

kitty:~ peterriegersperger$ telnet mail.subnet.at 25
Trying 193.170.141.20...
Connected to grey.subnet.at.
Escape character is '^]'.
220 grey.subnet.at DSMTP ESMTP Mail Server
HELO
251 OK, then. I'll call you 193.170.141.124
MAIL FROM: <>
250 Command MAIL OK
RCPT TO: 
250 Command RCPT User found OK
DATA
354 Command DATA Start mail input; end with .

Das ist das Mail ohne Kopf. Gruselig, oder?
.
250 Command DATA Processed mail data Ok
QUIT
221 Command QUIT grey.subnet.at Service closing transmission channel to 193.170.141.124
Connection closed by foreign host.

Von mir eingegebene Textpassagen sind hervorgehoben. Nun muss man nur noch ein bisschen warten, und dann trudelt ein äusserst eigenartiges eMail ein.

Das Mail ohne Kopf in meiner Inbox.

Hmmm. Ein Mail von niemandem, an niemanden, ohne Subject. Und es ist in meiner Inbox. Wie unheimlich. Zum Glück können so ziemlich alle (wenn nicht wirklich alle) eMail Clients die Header Informationen eines eMails anzeigen. Das sollten wir mal ausprobieren:

Das Mail ohne Kopf, diesmal mit Header-Informationen.

OK. Da haben wir ja schon was gelernt. Netterweise hat unser Mailserver Die IP-Adresse des Senders und die eMail Adresse des Empfängers aus dem Envelope in den Header kopiert. Schauen wir uns das mal näher an:

From (null) Wed Mar 17 09:45:02 2004
Received: from 193.170.141.124 ([193.170.141.124]) by subnet.at ; Wed, 17 Mar 2004 10:00:28 +0100

Hmmm. Der Computer, der das Mail verschickt hat, hat keinen Namen. Zumindest hat er keinen angegeben. Aber er hat eine IP-Nummer. Mit einem host 193.170.141.124 (Windows-User verwenden bitte nslookup 193.170.141.124) erhalte ich:

kitty:~ peterriegersperger$ host 193.170.141.124
124.141.170.193.in-addr.arpa domain name pointer kitty.subnet.at.

Uff. Schwein gehabt. Bin doch nur ich.

Also kein Grund zur Panik oder Dämonenaustreibungen.

Dramaturgisch ist die Demonstration des Mails ohne Kopf natürlich schlecht – es verrät im Grunde schon alle Tricks, derer man sich bedienen kann, um den Kopf von Mail-Empfängern ordentlich zu verwirren. Nichts destro trotz ist es ein Exot, denn es erfüllt keinen Zweck, oder zumindest keinen eindeutig nachvollziehbaren, der über die Verwirrung hinausgeht. Schauen wir also noch ein bisschen weiter, was man sonst noch so alles treiben kann.

Nehmen wir mal für einen Moment an, ich hätte die Absicht, eMails im Namen anderer zu verschicken. Geht denn das? Natürlich. wir sind ja schon zu Genüge darauf eingegangen. Machen wir trotzdem den Versuch, und und sehen uns dann das Ergebnis an. Also wieder wie vorhin:

kitty:~ peterriegersperger$ telnet mail.subnet.at 25
Trying 193.170.141.20...
Connected to grey.subnet.at.
Escape character is '^]'.
220 grey.subnet.at DSMTP ESMTP Mail Server
EHLO mailserver.apple.com
250-grey.subnet.at. Hello mailserver.apple.com (193.170.141.124)
MAIL FROM: 
250 Command MAIL OK
RCPT TO: 
250 Command RCPT User found OK
DATA
354 Command DATA Start mail input; end with .
From: Steve Jobs 
To: Peter Riegersperger 
Subject: Hey!
Dear Peter,
I think your work is terrific. I decided to donate 1 million us dollars to your cause.

Yours,

Steve

.
250 Command DATA Processed mail data Ok
QUIT
221 Command QUIT grey.subnet.at Service closing transmission channel to mailserver.apple.com
Connection closed by foreign host.

Und plötzlich bekomme ich Post vom CEO von Apple.

Ein Mail von Steve Jobs? An mich?

Und das Mail schaut gut aus, oder?

Ja. Eindeutig. Steve Jobs.

Natürlich fliegt der Schwindel wieder auf, wenn man sich die Daten ansieht, die der Mailserver vom Envelope in den Mail Body kopiert hat. Denn im Header findet sich die Zeile

Received: from mailserver.apple.com ([193.170.141.124]) by subnet.at ; Thu, 25 Mar 2004 15:08:44 +0100

Und anhand dieser Zeile wird deutlich, dass der Computer, von dem das Mail geschickt worden ist, zwar vorgibt, mailserver.apple.com zu sein, aber die IP 193.170.141.124 hat. Diese IP kann man überprüfen, und man würde zu dem Ergebnis gelangen, dass es sich dabei um eine IP von subnet handelt.

Nun kann man natürlich schon ahnen, wie die Sache weitergeht. Da sowohl der Absender, als auch der Empfänger ja im Envelope angegeben werden, und die Information im Header nur der Information dient, kann man nicht nur den Absender fälschen, sondern auch den Empfänger.

Beim Empfänger der eMail ensteht dann der Eindruck, die Post hätte sich geirrt, und man habe versehentlich ein mail bekommen, das gar nicht für einen bestimmt war. Aber dieser Eindruck täuscht – Beispiel gefällig?

Hier wieder eine Konversation zwischen mir und unserem Mailserver:

kitty:~ peterriegersperger$ telnet mail.subnet.at 25
Trying 193.170.141.20...
Connected to grey.subnet.at.
Escape character is '^]'.
220 grey.subnet.at DSMTP ESMTP Mail Server

Jetzt kommt wieder erste Trick: Eigentlich heisst mein Computer ja kitty.subnet.at, aber das muss ich dem Mailserver ja nicht auf die Nase binden. Stattdessen melde ich mich mit:

helo mailserver.microsoft.com

was grey.subnet.at so quittiert:

250 grey.subnet.at. Hello mailserver.microsoft.com (193.170.141.124)

Wer genau schaut, merkt, dass hier was nicht stimmt: grey.subnet.at hat zwar mailserver.microsoft.com als namen aktzepiert, aber er schreibt auch die IP-Nummer meines Rechners mit – das wiederum bedeutet, dass der Schwindel leicht auffliegen kann, weil ein einfaches

nslookup 193.170.141.124

mich sofort verrät:

124.141.170.193.in-addr.arpa    name = kitty.subnet.at.

Wenn ich aber soweit mit den Niederungen des Internet vertraut bin, bin ich ohnehin nicht mehr Zielgruppe. Oder hätten Sie’s gewusst?

Weiter im Text. Jetzt werde ich mal so tun, als wäre ich Bill Gates:

mail from:

Der mailserver kann das ja nur schwer überprüfen … Daher meint er folgerichtig:

250 Command MAIL OK

Der Mailserver hat meinen Absender also geschluckt. OK, nun gehts weiter im Text. Zunächst mal möchte ich mir das Mail ja selbst schicken, also:

rcpt to: 

Hierbei handelt es sich um die einzige Hürde in diesem ganzen Vorgang: Dieser Recipient muss am Server existieren. Da es mich auf diesem Server gibt, sieht der Mailserver auch überhaupt kein Problem:

250 Command RCPT User found OK

Nun bin ich wieder dran, jetzt möchte ich das Mail schreiben. Nach einem einfachen “data” fange ich damit an und tippe folgendes:

From: "bill gates" 
To: "steve jobs" 
Subject: You won!

OK. OS X is better than WindowsXP. You win, I quit.

Yours,

Bill Gates
.

Danach noch ein quit, und schwupps, ist das mail auf dem Weg.

Bevor wir uns das Ergebnis anschauen, fassen wir kurz zusammen:

Schauen wir uns nun an, wie das mail aussieht, das ich erhalten habe:

Hoppla. Welcher Mailserver hat sich denn da vertan?

Sieht man sich aber den Header des mails auch einmal genauer an, dann fliegt der Schwindel natürlich sofort auf:

Die Header-Informationen zeigen, dass das mail sehr wohl an mich adressiert war.

Erstens ist klar erkennbar, von welcher IP-Adresse aus das mail verschickt wurde – daher ist auch sein Weg durchs Netz überprüfbar. Und zweitens war der Mailserver auch so nett, den Recipient aus dem Envelope in den Header hineinzukopieren – das X-Rcpt-To Feld ist gesetzt. Das hindert meinen Mail Client aber nicht daran, im “To” Feld etwas ganz anderes anzuzeigen, nämlich Steve Jobs, der sich sicher ärgern wird, dass er dieses mail nicht bekommen hat.

Nun könnte man meinen: Na, dann ist ja eh alles bestens. Aber – Hand auf’s Herz – wer schaut sich schon immer die Header seiner mails an?

Klar geworden ist – denke ich – dass das vollständige Fälschen einer eMail nicht ganz so einfach ist, wie es auf den ersten Blick scheint. Im Header stehen oftmals äusserst hilfreiche Informationen, die bereits einen gewissen Plausibilitätstest zulassen. Trotzdem gibt es Fälle, in denen diese Plausibilitätstests wenig erfolgversprechend sind, z.B. dann, wenn der Angreifer/Fälscher denselben Provider wie der angebliche Absender des eMails benutzt.^[2]

Anonyme Remailer, die wichtige Herkunftsinformationen aus dem Header entfernen, bringen zwar einen grossen Vorteil was die Privacy des Absenders betrifft (und können damit tatsächliche Anonymität gewähren, im Vergleich zur Pseudo-Anonymität des “normalen” Mailservice), haben aber auf der anderen Seite auch den Nachteil, dass sie die Herkunft des entsprechenden Mails effektiv verschleiern – eine Plausibilitätsprüfung ist daher kaum möglich.

Spam, Unsolicited eMail, Junk Mail, wie auch immer man die unerwünschten und meist zweifelhaften Werbe-Mails nennen will, die täglich in Hundertschaften die Mailboxen von Millionen von Internet-Nutzern füllen, wird nicht so ohne weiteres weggehen. Spam ist lästig, und oft ärgerlich, manchmal aber auch sehr erheiternd. Wesentlich schwieriger wird es, wenn Personen (aus ganz unterschiedlichen Motiven) versuchen, mit eMails tatsächlich Schaden anzurichten.

Bisher haben wir uns nur ein paar Spass-Fälle angesehen, was man denn so alles machen könnte mit eMails. Nachrichten als Bill Gates zu verschicken – naja, darauf wird ja wohl hoffentlich niemand reinfallen. Angebliche Mails vom Microsoft-Support scheiden schon beim Plausibilitäts-Test des Inhalts aus, da muss man sich noch gar nicht mal den Header ansehen.

Wie aber sieht es mit gezielten Attacken aus? Was würde denn passieren, wenn ich die Mails, die ich beispielhaft oben verfasst habe, nicht im Namen von Bill Gates verschickt hätte, sondern z.B. in Deinem Namen? Was könnte da alles passieren? Sicher keine angenehme Situation.

Wir wir gesehen haben, gibt es keinen zuverlässigen Mechanismus, die Echtheit einer eMail-Nachricht eindeutig zu überprüfen. Man muss daher auf Überlegungen der Plausibilität zurückgreifen, um die Echtheit abschätzen zu können. Folgende Fragen können helfen: Wie plausibel ist, dass ich ein eMail vom angeblichen Absender erhalte? Wie plausibel ist der Inhalt? Als Beispiele können hier dienen, dass erstens Steve Jobs sicher nicht weiss, dass ich überhaupt existiere, und zweitens sogar, wenn er es wüsste, kaum eine Million Dollar für mich übrig hätte. Da gibt’s schon andere, die das Geld besser gebrauchen könnten (wobei ich hier anonyme Spender nicht – ich wiederhole – nicht verschrecken will).

Ist das Mail zwar grundsätzlich plausibel, kommt einem aber trotzdem irgendwie komisch vor, lohnt ein Blick in den Header. Es ist zwar an sich nicht selbstverständlich, dass man von Nutzern verlangt, eMail Header lesen zu können, aber auf der anderen Seite ist das ein bisschen wie mit Autos: Wer keinen Reifen wechseln kann, muss damit rechnen mitten in der Nacht auf einer Nebenstrasse in einem Wald mit einem Platten zu stranden. Es zahlt sich also durchaus aus, sich mit den Grundlagen der verwendeten Technologie auseinanderzusetzen – auch bei eMail.

Der Blick in den Header gibt meist Auskunft über die IP-Adresse des Absenders; und diese IP-Adresse kann mittels dem Befehl whois (auch als Webinterface der RIPE auf http://ripe.net/db/whois/whois.html) den jeweiligen für das entsprechende Netzwerk verantwortlichen Personen oder Institutionen zugeordnet werden. Im Zweifelsfall lohnt es sich, Rücksprache mit dem angeblichen Absender zu halten.

Diese Art der technischen Forensik ist mühsam, aufwendig und liefert nicht immer aufschlussreiche Ergebnisse. Kann man denn gar nichts machen, um eMails sicherer zu machen? Zuerst muss man sich darüber klar werden, dass eine Sicherung von SMTP auf Ebene der Infrastruktur mittelfristig nicht in Sicht ist. SMTP ist bereits vom Design her so problematisch, dass eine Integration sichernder Mechanismen schwierig bis unmöglich sein dürfte. Die einfachste – und wahrscheinlich auch die beste – Variante ist, etwas für die Sicherheit von eMail auf Applikationsebene (bei den MUAs, den Mail User Agents) zu unternehmen. Hier kann mittels Verschlüsselung und digitaler Signaturen auf relativ einfache Art einen grossen Sprung in Sachen Sicherheit machen. Das ist dann aber ein Thema für einen zweiten Teil.