SMTP: Das naivste Protokoll des Internets
Hood Informatik
https://www.youtube.com/watch?v=218UQxdT_EI

Transkript (automatisch erstellt)

0:00 Früher konnte jeder eine E-Mail verschicken, die aussah, als käme sie direkt von jemand anderem. Warum ging das damals und warum geht das heute
0:07 nicht mehr? Willkommen zurück bei Hot Informatic. E-Mail ist alt, richtig alt. Das zugrunde liegende Protokoll SMTP, kurz für Simple Mail Transfer Protocol
0:17 wurde 1982 entworfen in einer Zeit, in der das Internet ein akademisches Netzwerk war, in dem sich alle kannten. Niemand kam auf die Idee,
0:26 Absendeadressen zu fälschen, weil es schlicht keinen Grund gab. Entsprechend naiv war das Design. Wenn du einem Mailserver sagst, die E-Mail kommt von
0:33 chef@apple.com, dann glaubt er dir einfach: Kein Passwort, keine Prüfung, kein gar nichts. Und genau das haben Angreifer
0:41 jahrzehntelang ausgenutzt für Fishing, für CEO Fraud und für Betrug in Milliardenhöhe. Es gab einen Zeitraum, in dem du buchstäblich mit drei Terminal
0:49 Befehlen eine E-Mail im Namen des Bundeskanzlers verschicken konntest und viele Mailserver sie anstandslos zugestellt hätten. Heute funktioniert
0:57 das nicht mehr, zumindest nicht gegen gut konfigurierte Domains. Und um zu verstehen, warum, müssen wir uns anschauen, wie E-Mail unter der Haube
1:04 wirklich funktioniert. Wenn dein Mailprogramm eine E-Mail verschickt, passieren zwei Dinge, die die meisten Menschen nicht auseinanderhalten und die
1:12 früher die Wurzel des ganzen Problems war. Es gibt erstens den sogenannten Envelope Sender, also den technischen Absender auf Protokollebene. Das ist die
1:21 Adresse, die SMTP intern verwendet, vergleichbar mit der Rücksendeadresse auf dem Umschlag, die der Postbote liest, wenn ein Brief nicht zustellbar
1:30 ist. Und dann gibt es den Fromheader, also das, was du als Empfänger in deinem Mailprogramm wirklich siehst. Prominent oben in der Nachricht, das entscheidende
1:39 Detail. Und ihr merkt es wahrscheinlich schon, diese beiden Felder sind vollständig voneinander unabhängig. Du kannst eine Mail mit dem Envelopesender
1:47 test@hoodinformatic.de verschicken, aber im fromheader ceo@apple.com eintragen. Der Empfänger sieht ceo@apple.com.
1:57 Der Mailserver hat früher einfach nichts dagegen gesagt und die Mail einfach durchgewingt. Die Antwort der Industrie auf dieses Problem kam nicht in einem
2:05 großen Schritt, sondern in drei aufeinander aufbauenden Mechanismen. Zusammen bilden Sie heute das Rückrad der E-Mail Authentifizierung. Der erste
2:12 Mechanismus heißt SPF und es steht für Sender Policy Framework. Die Grundidee ist elegant einfach. Eine Domain kann im DNS hinterlegen, welche Mailserver
2:23 überhaupt berechtigt sind, E-Mails in ihrem Namen zu verschicken. Falls du nicht weißt, was ein DNS ist, verlinke ich oben rechts und in den Kommentaren
2:31 den Link dazu. Apple kann also im DNS von apple.com eintragen. E-Mails von uns kommen nur von diesen fünf Servern. Wenn eine Mail jetzt behauptet von apple.com
2:40 zu kommen, aber von einem Server irgendwo anders abgeschickt wird, der nicht auf dieser Liste steht, dann schlägt die SPF Prüfung fehl. Aber SPF
2:48 hat eine frühe Schwäche, die man kennen muss. Es prüft nur den Envelope Sender, also den technischen Absender auf Protokollebene, nicht den Fromheader,
2:58 den der Empfänger sieht. SPF alleine war also kein vollständiger Schutz. Der zweite Mechanismus ist DKIM. Das steht für Domain Keys identified mail. Und
3:07 hier wird es kryptografisch. Der versendende Mailserver signiert die E-Mail mit einem privaten Schlüssel, also einem geheimen kryptografischen
3:15 Wert, den nur dieser Server kennt. Den zugehörigen öffentlichen Schlüssel veröffentlicht die Domain im DNS, sodass jeder ihn einsehen kann. Wenn der
3:24 empfangende Server eine Mail bekommt, schaut er in den DNS der behaupteten Absenderdomain, holt sich den öffentlichen Schlüssel, der ja für jeden
3:33 erreichbar ist und prüft damit die Signatur. Stimmt sie? weiß er, diese Mail wurde tatsächlich von einem Server verschickt, der den privaten Schlüssel
3:41 dieser Domain besitzt. Und zusätzlich, die Mail wurde auf dem Weg nicht verändert, weil jede nachträgliche Änderung die Signatur ungültig machen
3:50 würde. SPF und DKIM zusammen sind also schon deutlich besser, aber sie lösen das Problem immer noch nicht vollständig. Sie sagen dem empfangenen
3:59 Server zwar, ob etwas stimmt oder nicht, aber sie sagen ihm nicht, was er im Fehlerfall tun soll und sie schließen immer noch nicht die Lücke zwischen dem
4:06 technischen Absender und dem sichtbaren Fromheader. Genau hier kommt DMK ins Spiel. Der Name steht für Domain based authentication Reporting and
4:16 Conformance. Sperrig, aber jeder Teil des Namens ist wichtig. Dmark tut nämlich drei Dinge. Erstens legt es als Richtlinie fest, was mit einer Mail
4:27 passiert, die SPF oder DKIM nicht besteht. Die Domain kann sagen, schickt diese E-Mail dann in Quarantäne, also in den Spamordner oder lehnen sie komplett
4:36 ab. Das gibt Domains echte Kontrolle darüber, was mit gefälschten Mails in ihrem Namen passiert. Zweitens, erzwingt DMK eine sogenannte Ausrichtungsprüfung.
4:46 Das bedeutet, der sichtbare Fromheader muss zur Domain passen, die entweder SPF oder DKIM verifiziert haben. Damit wird die alte Lücke geschlossen, über die wir
4:57 ganz am Anfang gesprochen haben. Du kannst also nicht mehr einen validen Envelopeender nutzen, aber einen gefälschten Fromheader einsetzen, der
5:04 dem Empfänger etwas anderes vorspielt. Und drittens, und das wird oft unterschätzt, ermöglicht DMK Berichte. Domainhaber bekommen regelmäßig Berichte
5:13 darüber, wer versucht hat in ihrem Namen Mails zu verschicken. Das gibt Unternehmen Sichtbarkeit darüber, ob ihre Domains aktiv missbraucht wird.
5:22 Aber schauen wir uns das Ganze mal in der Praxis an. Ihr könnt hier mit so einem Dockerbefehl einfach mal Mailhack starten. Ihr seht das bei mir jetzt hier
5:28 schon im Hintergrund und zwar sieht das Ganze so aus. Ihr könnt darüber so eine Art SMTP Synculieren. Das heißt, dieses Ding kann jetzt für uns E-Mails
5:36 empfangen und wir können uns die mal anschauen. Hierzu habe ich hier einen kleinen Python Code und zwar connecten wir uns hier mit Local Host mit diesem
5:43 Port. Wir sagen einfach mal unsere E-Mail ist hood@local.test. Ihr könnt hier aber reinschreiben, was ihr wollt und der E-Mailtext ist
5:50 einfach: "Hi, ich bin's." So, dann senden wir drei verschiedene E-Mails und zwar mit ganz verschiedenen Signaturen und so weiter. Ich führe das Ganze jetzt
5:58 einfach erstmal aus. Wir machen einfach mal Python und dann z.Ppi. So. Und sobald ich das ausführe, seht ihr hier schon die drei E-Mails. Wir können uns
6:06 jetzt einfach mal die erste nehmen und die mal anklicken. Dann sehen wir hier, ich habe da einfach in Betreff schon legitim mit reingeschrieben. Und zwar
6:13 können wir uns jetzt hier die Headers dieser E-Mail mal anschauen. Wir sehen hier oben den sogenannten Fromsender, ne? Also, das ist die From Adresse, die
6:22 wäre in dem Fall info@apple.com. Bei Mailhawk ist das hier der Envelope Sender, über den ich vorhin gesprochen habe. Es gibt also zwei Arten von
6:31 Sendern. Einmal den Fromheader und einmal den Envelope Sender. Der ist aber auch info@apple.com. Beide matchen. Wir haben hier also gar kein Problem. Gehen
6:40 wir jetzt mal einen zurück und schauen uns den nächsten an. Hier sehen wir und das seht ihr, hier haben wir einmal den Envelope Sender. Das bin ich,
6:49 angreifer@evil.com. Aber den Header, also das was das Opfer sehen soll, ist auf info@apple.com. Schauen wir uns das Ganze an. Machen wir
6:57 die Header mal zu. Wenn ich die E-Mail ganz normal bekommen würde und es keine Sicherheitsfeatures gäbe, dann würde ich einfach nur sehen, oh, die E-Mail kommt
7:04 tatsächlich von Apple und die ist an mich gerichtet und das ist der Text. Wenn wir jetzt aber in die Header schauen, dann sehen wir, das ist zwar
7:11 der From sender, aber im Envelope Sender steht angreifer@evil.com. Was würde SPF jetzt aber tun? SPF würde im DNS nachschauen, ob von meiner
7:22 Adresse aus überhaupt E-Mails über apple.com verschickt werden dürfen. Und wie das aussieht, das können wir uns mal anschauen. Wir schauen uns erstmal den
7:29 DNS-intrag von apple.com an. So und hier sehen wir, dass die SPF Informationen in sogenannten Subrecords stehen. Die müssen wir also auch
7:38 abfragen. Wir können also einfach mal machen d txt und dann kopiere ich das mal kurz rüber. Wir nehmen den Part, fügen den hier ein und drücken noch mal
7:46 auf Enter. und dann bekommen wir IP-Adressen, von denen tatsächlich eine E-Mail geschickt werden kann im Namen von
7:54 apple.com. Das heißt, SPF würde in dem Fall erkennen, hm, die Adresse kommt nicht von einer dieser IPs, das heißt SPF schlägt hier Fail. Machen wir weiter
8:04 mit der nächsten E-Mail. Es ist ein bisschen tricky, das Ganze hier in Mailhawk zu zeigen, weil ich das Ganze ja nur simuliere. Mailhawk selbst hat
8:10 keine Authentifizierung und all den Kram. Es fängt jede einzelne E-Mail ab. Im Normalfall würde diese E-Mail hier, weil SPF ja fehls schlägt, schon gar
8:19 nicht durchgehen, aber Mailhawk fängt quasi alles ab. Deswegen das ist jetzt nur zu Testzwecken, ne, um euch das einmal zu demonstrieren. Und hier seht
8:25 ihr das Beispiel für die DKIM Signature. Das folgt jetzt demselben Prinzip. Auch hier würde genau geguckt werden im DNS, wie sieht der Public Key dafür aus? Und
8:34 dann würde man diesen public Key benutzen, um diese Signatur zu verifizieren. Diese ganze Thematik zeigt etwas Grundsätzliches. Sicherheit im
8:41 Internet funktioniert nicht immer durch einen einzigen genialen Einfall, sondern oft durch Schichten. SPF und DKIM allein waren nicht genug. Erst DMK als
8:50 verbindendes Regelwerk hat die einzelnen Teile zu einem funktionierenden System gemacht. Und damit sind wir auch schon beim Ende des Videos angekommen. Falls
8:58 euch solche Videos genauso Spaß machen wie mir, lasst gerne ein Abo da. Das hilft mir nämlich enorm. Und damit stay safe und bis zum nächsten