So, habt Ihr Euch jemals gefragt, wie man perfekt eine Email testen kann? Dann seid Ihr hier im
richtigen Podcast. Wir haben hier unseren nächsten Sprecher. Andrew arbeitet gerade für das
Nationale CERT in Lettland. Er ist ein Sicherheitsforscher.
Und er wird gleich über E-Mail Fälschungen sprechen und Strategien für modernes Anti-Spoofing..
Die Bühne gehört Dir.
Applaus
Also Grüße. Ich bin Andrew und ich habe für das Lettische National CERT gearbeitet. Eures unserer aktuellen Ziele ist
idie Verbesserung des Zustands der E-Meil-Sicherheit in unserem Land und
das erreichen wir hauptsächlich durch die Erhöhung der Sensibilisierung für dieses Problem und die Vermittlung bewährter
Praktiken. Und natürlich sind wir nicht die einzige Organisation, die dies tut.
Es gibt viel mehr Gruppen in anderen Ländern und es gibt verschiedene
Nichtregierungsorganisationen, die das Gleiche tun. Und konventionelle Einrichtungen.
Doch bisher sind, offen gesagt, unsere kollektiven Fortschritte ziemlich
enttäuschend. Daher ist hier zum Beispiel eine Statistik, die die Nutzung einer bestimmten
Technologie in Dänemark zeigt, was , wie Sie in diesem Vortrag erfahren werden, ziemlich
wichtig ist und ich hoffe, dass jeder diese Technologie verwendet. Auf der linken Seite
werden 20.000 Domains weltweit angezeigt, die wichtige Domains sind für
wichtige Organisationen, die es eigentlich besser wissen sollten. Und auf der rechten Seite
sehen wir die Top 50 der TOP 500 EU-Einzelhändler und in beiden Gruppen haben 2/3
Dänemark bisher nicht einmal konfiguriert. Und von denen, die die Mehrheit konfiguriert haben,
haben nicht keine strengen Richtlinien aktiviert. Wenn es also nur eine wichtige Erkenntnis aus
diesem Vortrag gibt, hoffe ich, dass jeder damit beginnen sollte, Dänemark zu verwenden. Es ist
wichtig, es auch für Domains zu verwenden, die keine E-Mails senden sollen. Eine Erklärung
für diese niedrige Akzeptanzrate ist meiner Meinung nach, dass es anscheinend zu viele
konkurrierende Technologien gibt. Das ist der Inhalt meines Vortrags. Und ich habe wirklich
mein Bestes gegeben, um ihn einzuschränken. Aber wie Sie sehen, gibt es 3 Abkürzungen, also
und SMTP und außerdem SPF, DKIM und DMARC und aktuelle 2, an deren Namen ich mich
nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass
es zufiele Schlagworte gibt, zu viele Technologien, und es ist nicht klar
welche wir davon verwenden sollten, das ist nicht spezifisch für E-Mails. Und wir haben das
in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir
inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar
Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt wurde
und die Ergebnisse veröffentlicht wurden, können wir mit dem Gespräch beginnen. Wir
können das Gespräch darüber führen, ob Ihre Organisation Technologie A oder B bevorzugt,
wir können stattdessen die Fragen beantworten, die wirklich wichtig sind, wie:
Ist es möglich, dass jemand für eine 3. Person die E-Mails ihrer Organisation fälscht und
solche E-Mail zum Beispiel an Ihre Kunden oder Ihre Partner oder an Medienorganisationen so
zu versenden, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation
stammen? Deshalb sind Penetrationstester die wichtigste Zielgruppe für diesen Vortrag.
Ich hoffe jedoch, dass alle Blue-Teamer im Publikum diesen
Vortrag interessant finden. Ich bin sicher, dass Sie bereits alle Grundlagen über die
E-Mail und über diese Technologien kennen, aber wenn man das Problem aus den
verschiedenen Perspektiven des Angreifers betrachtet, kann man die Dinge ins rechte Licht
rücken. Es kann Ihnen helfen zu verstehen, worauf Sie sich beim Schutz Ihrer Umwelt
konzentrieren sollten. Und schließlich das SMTP Protokoll. Die Technologie, die in unseren
E-Mail-Konversationen steckt, ist eigentlich relativ leicht zu verstehen.
Und auch die Lehren, die man daraus gezogen hat. Diese Entwicklung von SMTP, wie es wurde
und wie es möglich ist, es zu fälschen, und all die Technologien, die versuchen,
Spoofing zu verhindern. Ich denke, es ist eine interessante Fallstudie und es sollte auch für
solche Leute interessant sein sie zu verfolgen, die neu im E-Mail-Bereich sind. Nun final zur
Bedrohungslandschaft. E-Mail Sicherheit ist ein ziemlich umfangreicher Themenbereich. Heute
werde ich mich auf einen kleinen Teil fokussieren. Dieser ist das erfolgreiche
Spoofing von E-Mails, also Manipulationsattacken. Ich weiß, dass viele Pentrationstester bereits teilweise
Phishing oder Spear-Phishing-Emulation in ihre Arbeiten einbeziehen. So viel ich weiß, tun sie
dies meist aus der Social-Engineering-Perspektive, indem sie beispielsweise Tools wie
das Social-Engineering-Toolkit verwenden und ich möchte nicht behaupten, dass es wichtig ist,
dies zu tun und dem Kunden zu zeigen, welche Risiken in dieser Hinsicht bestehen. Ich denke
jedoch, dass Sie mit Social Engineering dem Kunden einen Dienst erweisen, wenn dies das
Einzige ist, was Sie aus der E-Mail-Perspektive testen, denn aus der Perspektive der Kunden,
beispielsweise von Managern, die Ihre Berichte lesen, erwähnen Sie dann nur Social-
Engineering-Angriffe. Die logische Schlussfolgerung ist, dass der beste Weg, diese
Bedrohungen einzudämmen. darin besteht, Ihr Personal zu schulen, insbesondere diejenigen,
die am wenigsten technisch versiert sind, wie dies in diesem Vortrag zu sehen ist.
Es gibt ziemlich viele Angriffe und viele Organisationen sind anfällig für diese Angriffe.
Und hier hilft auch keine noch so große Benutzerschulung, denn wir können von den
Benutzer nicht erwarten, dass sie beispielsweise die Kopfzeilen manuell
überprüfen. Deshalb müssen wir unsere E-Mail-Infrastruktur tatsächlich verbessern. Daran
führt kein Weg vorbei. Bevor wir uns schließlich den eigentlich technischen Dingen zuwenden,
gibt es noch ein kleines Geheimnis. Ich denke, es könnte Leute helfen zu verstehen , die nicht
in der E-Mail-Branche arbeiten, warum wir solche Probleme haben, und für E-Mail-
Administratoren, die in der Vergangenheit die Verfügbarkeit ihres Systems und die
Zuverlässigkeit viel mehr schätzten, als die Sicherheit. Und das liegt daran, dass das keine
ideologische Entscheidung ist. Es ist eine sehr pragmatische. Wenn Sie also beispielsweise
ein E-Mail-Administrator in einer Organisation sind und einige ihrer Kunden keine Rechnungen
mehr erhalten, wird Ihr Management Sie finden, sie darüber informieren und Sie freundlich
bitten, das Problem so schnell wie möglich zu beheben, auch wenn es nicht Ihre Schuld ist.
Es könnte sein, dass das Problem möglicherweise auf einer anderen Seite liegt,
nicht auf Ihrem Server. Ein anderes Beispiel ist, dass Sie, dass einige Ihrer Mitarbeiter bald
keine E-Mails mehr empfangen können, oder E-Mails nicht früh genug erhalten, um das
Passwort wiederherzustellen oder um die E-Mail zu verifizieren oder ein
Mehrfaktor-Authentifizierungs-Token zu verwenden und sie können sich bei einigen
wichtigen Systeme nicht mehr einloggen. Dann müssen Sie das lösen. Aber wenn Ihr System
Sicherheitslücken hat, wenn es für Spoofing-Angriffe und so weiter anfällig ist, dann wird es
normalerweise weder den Anwendern, noch dem Management auffallen. Aber Sie haben
diese Schwachstelle. Deshalb sind Penetrationstester natürlich wichtig. Okay.
Jetzt können wir endlich anfangen, über die Technik zu sprechen. Wir starten mit der
kurzen Einführung in das SMTP-Protokoll. SMTP ist das Protokoll, das der gesamten E-Mail-
Kommunikation zugrunde liegt und es ist ziemlich einfach zu befolgen. Hier ist also
ein Datenfluss, der zeigt, was passiert, wenn eine Person E-Mails an eine andere Person
sendet. Zum Bespielt sendet Alice an Bob und sie arbeiten für unterschiedliche Unternehmen.
Sie verwenden unterschiedliche Domains. Was also passiert ist, dass beide sagen würden
benutze E-Mail-Clients wie Outlook oder Thunderbird. Alice sendet E-Mails. Sie geht
über dieses Protokoll SMTP an Alices Mail-Server. Wichtig ist aber zu beachten dass dies
ein Server für ausgehende E-Mails ist. Üblicherweise verfügen Organisationen über
2 Arten von Diensten, einen für eingehende und Transaktionen und einen für ausgehenden.
Und auch für kleine Organisationen kann es einer sein, aber auch hier ist es für
Penetrationstester wichtig, sich dies als unterschiedliche Systeme vorzustellen. Denn
selbst wenn es physisch ein einziger Computer ist, wird er eine unterschiedliche Konfiguration
für ausgehende und eingehende E-Mails haben. Als Penetrationstester müssen Sie also
überprüfen, ob beide in Ordnung sind. Wenn Alices Server nun versucht, E-Mails an Bobs
Server zu senden, gibt es eine Art von Problem, das darin besteht, dass der Server irgendwie
automatisch den richtigen Server zum Versenden von E-Mails finden muss. Dies
geschieht über diese Bluebox und eine Mischung aus DNS-spezfifischen DNS-
Eintragstypen und -mischungen. Das ist also etwas, das von Bobs Organisation gepflegt wird,
Bobs Organisation wird also, wenn sie E-Mails erhalten möchten, diesen DNS-Eintrag erstellen.
Und ich sage: Okay, wenn Sieuns eine E-Mail senden möchten, benutzen Sie bitte diesen
speziellen Server. Es sollte also auf Bobs verwiesen werden. Und jetzt kann Alices
Ausgangsserver, der die eingehende Serveradresse von Bob kennt, mit diesem
kommunizieren und Bob wird später seine E-Mail erhalten. Wir als Penetrationstester
versuchen eigentlich, zwischen dem Server von Alice und dem von Bob zu vermitteln. Dann
müssen wir über das 2. Beispiel nachdenken, das umgekehrt ist. Sie denken vielleicht, dass
es sich um ein sinnloses Beispiel handelt, weil wir im Grunde nur die Richtung des
Datenverkehrs ändern. Aber das Wichtigste hier ist, dass wir als Penetrationstester verstehen,
dass unser Kunde nur einen Teil der Transaktion kontrolliert. Falls unser Kunde,
sagen wir mal, für den Rest dieser Präsentation Alice oder Alices Organisation ist,
dann werden im 2. Beispiel, wenn wir eine E-Mail von Bob an Alice senden, nur E-Mails
gesendet. Grundsätzlich läuft ein Teil dieser Transaktion im 1. Beispiel über Alices Server.
Wenn wir E-Mails von Alice an Bob senden, wäre dies nicht der Fall. Wenn es also etwas
verwirrend ist, ist das in Ordnung. Wir werden etwas später darauf zurückkommen. Und
schließlich gibt es noch ein 3. Beispiel, das ähnlich, aber nicht ganz so aussieht. Und zwar
nur, wenn Alice kommuniziert. Alice ist unser Kunde. Und wenn sie mit ihren Kollegen
kommuniziert, die in der gleichen Organisation sind, denselben E-Mail-Server und die gleiche
Domain haben, wird es in diesem Beispiel logischerweise 2 E-Mail-Server geben, ein
Ausgagnsserver und ein Eingangsserver.
Aber beide gehören unserem Kunden. Also können Sie im Moment, wenn Sie sich mit
E-Mail nicht auskennen, versuchen darüber nachzudenken, welche dieser 3 Szenarien
leichter zu schützen sind. Später werden wir sehen, sie es tatsächlich abläuft. Okay.
Dann müssen wir uns ansehen, was tatsächlich gesendet wird, wenn eine E-Mail versandt wird.
Also noch einmal, es wird das SMTP-Protokoll verwendet und es ist ein wirklich gutes
Protokoll. Wie Sie sehen können, handelt es sich nur um Text. Es handelt sich also um ein
reines Testprotokoll und es ist sehr einfach zu bedienen, weil man einfach eine Telnet-
Verbindung zum richtigen Server öffnet und man versuchen kann, die Befehle einfach mit
den Händen aufzuschreiben. Um zu versuchen, etwas zu zerstückeln oder zu modifizieren, oder
zu versuchen, verschiedene Typen auszuprobieren und in Echtzeit zu sehen, wie
es weitergeht. Auf der linken Seiten sehen wir hier also 2 Teile, die durch SMTP definiert sind.
Als erstes kommt der SMTP-Umschlag, den Sie im Grund mit dem Server verbinden. Sagen Sie
"Hallo". Dann sagen Sie, was der Absender der E-Mail und der Empfänger der E-Mail
angegeben haben. "Mail von" ist der Absender. Empfänger ist zum Beispiel Bob. Und dann
beginnt der 2. Teil mit Daten und endet mit "Beenden". Und das ist der Teil, der sich
Inhalt/Nachricht nennt. Wenn Sie also ein bisschen damit herumspielen wollen, wird dies
durch einen anderen Standard definiert, der für Penetrationstester nicht so wichtig ist. Aber
wenn Sie sich die Details ansehen möchten, dann könnte es wichtig sein. Und diese interne
Nachricht, die entweder Inhalt oder SMTP genannt wird, enthält wiederum 2. Teile. Der
eine Teil ist die Kopfzeile und der andere der Hauptteile. Und ich denke, dass einige Leute
vielleicht nicht mit der E-Mail vertraut sind, aber wahrscheinlich ist jeder Zuhörer mit HTTP
vertraut und das sieht ganz ähnlich aus. Also leicht zu verstehen. Aber der interessante Teil
ist, dass sie vielleicht bemerkt haben, dass wir
Alices und Bobs Adressen zweimal haben. Das stimmt. Zum Beispiel ist Alices Adresse in der
zweiten Zeile "Mail von". Und dann haben wir die gleiche Adresse. Alice @ ihre Organisation in
der Kopfzeile "Von". Die roten Bereiche sind die Kopfzeilen. Und das gleiche gilt für Bob. Und
warum ist das so? Nun, es kommt darauf an, wie wir E-Mails sehen. Ich als eine normale
Person, die E-Mails in den letzten Jahren benutzt hat, sehe sie normalerweise so, wie
auf der linken Seite beschrieben, wie eine Art Postkarte. Auf der Postkarte steht also jemand,
der sie abgeschickt hat. Der Absender. Da ist dann noch der Empfänger. Das bin ich
normalerweise. Ich empfange. Und dann ist da noch eine Nachricht. Zumindest habe ich das so
wahrgenommen, bevor ich etwas mehr darüber gelernt habe. Aber E-Mail Administratoren und
die Standardgremien sehen diese Situation, wie sie rechts dargestellt ist. Da ist ein Umschlag
und darin befindet sich diese Nachricht oder vielleicht eine Postkarte. Sie haben also 2
Adressen in diesem Szenario. Sie haben die Adresse von und an wen sie sich den Umschlag
senden. Dies ist beispielsweise der Teil, den die Post einsehen wird. Aber das Postbüro wird im
Allgemeinen nicht in Ihrem Umschlag nachsehen und sehen, dass sich dort eine
weitere Nachricht, die interne Nachricht befindet, die eigentliche für den Empfänger
bestimmt ist. Man könnte also eigentlich sogar noch mehr machen und man könnte sogar den
ganzen Umschlag mit der Nachricht der Postkarte in einen anderen Umschlag stecken.
Und das klingt für mich als normalen Menschen verrückt, aber tatsächlich ist das bei E-Mail.
möglich. Und in dem RFC, dem Standarddokument, gibt es einige Beispiele,
warum das notwendig ist. Warum solche Dinge erlaubt sind. Aber sie sind doch verwirrend.
Und so als Ergebnis sehen wir in diesem ersten Beispiel , dass wir im Allgemeine die gleiche
Adresse zweimal angeben. Aber als Penetrationstester sollten wir uns die Frage
stellen: Ist das aktuell erforderlich? Ist das immer wahr, oder handelt es sich nur um
Wunschdenken? Und es ist tatsächlich ein Wunschdenken. Standards schreiben nicht
ausdrücklich vor, dass Sie die gleiche Adresse für den Empfänger oder für das "Von" des
Absenders auf dem Umschlag und innerhalb einer Nachricht angeben. Es gibt also
tatsächlich viel mehr Kopfzeilen als die, die ich gezeigt habe. Die, die ich gezeigt habe, sind
meiner Meinung nach nur die, mit denen wir alle Erfahrung haben, denn wenn man nur
E-Mail benutzt, sind das normalerweise die Dinge, die man sieht oder man sieht das
Datum, den Betreff, den Inhalt, wer Dir etwas gesendet hat und an wen es gesendet wurde.
Üblicherweise Du selbst. Und dort könnten es natürlich auch mehrere Empfänger geben.
Oh ja. Und die Frage ist dann noch eine andere:
Was ist eigentlich, wenn wir aus irgendeinem Grund etwas versehentlich angegeben haben
oder vor allem, wenn wir unterschiedliche Adressen in diesem Umschlag angegeben
haben, welche der Benutzer sehen wird. Der Empfänger, das ist eigentlich die Kopfzeile. Ok.
Wie ich schon sagte, gibt es tatsächlich Standards, die mehr Kopfzeilen erlauben. Und
es gibt aktuell 3 Kopfzeilen "Von", "Absender", "Antwort an", die semantisch wirklich nahe
beieinander liegen und im Standard ist eigentlich erklärt, wann man welche Überschrift
verwenden sollte. Und das Lustige für mich ist, dass zum Beispiel die "Von" Überschrift ist,
diejenige ist, in der wir sehen, was sie beinhaltet. Wenn Sie den RFC lesen, werden Sie
sehen, dass man nicht mehr als eine solche Überschrift haben sollte, aber die Überschrift
selbst könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail
erhalten, die von verschiedenen Personen stammt, aber das ist erlaubt.