36C3 - Email authentication for penetration testers

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 Kopfzeile haben sollte, aber die Kopfzeile selbst

könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail

erhalten, die von verschiedenen Personen stammen würde, aber das ist erlaubt. Aber das

Wichtigste, was Sie hier noch einmal verstehen müssen, ist dies bereits erwähnte

Rückwärtskompatibilität. Obwohl die Standards erklären, wie Sie die Haupt-Kopfzeile

verwenden sollten, und dass Sie in der Praxis nicht mehr als eine dieser Kopfzeilen haben

sollten, können Sie bei einer Zustimmung zu fehlerhaften E-Mails diese mit mehreren

Kopfzeilen in der selben Kopfzeile senden. Sie könnten Kopfzeilen senden, die laut RFC kein

"Von" enthält, aber einen "Absender". Das ist nicht korrekt. In der Praxis wird es.

funktionieren. Die meisten Organisationen, die meisten E-Mail-Dienste werden Ihr Bestes tun,

ihre völlig fehlerhafte E-Mail nach besten Kräften zu analysieren, weil sie wirklich daran

interessiert sind, die Supportkosten zu senken. Wenn etwas also nicht funktioniert, wird man

zu Ihnen kommen. Es ist also besser, dafür zu sorgen, dass meistens alles funktioniert.

Für Penetrationstester bedeutet das natürlich, dass Sie damit herumspielen können, weil es

verschiedene Implementierungen gibt und es genau darauf ankommt, welche Gefahr besteht.

Wenn beispielsweise 2 Kopfzeilen angezeigt werden oder für einen Algorithmus verwendet,

hängt dies von der jeweiligen Implementierung ab. Da es so viele Implementierungen gibt, sind

diese auf unterschiedliche Weise miteinander verbunden. Sie können und sollten als

Penetrationstester verschiedene Dinge ausprobieren, zum Beispiel die gleiche

Kopfzeile mehrmals hinzufügen. OK. Nachdem wir nun diese Grundlagen behandelt haben,

wollen wir uns ansehen, Wie Sie versuchen würden, zum Beispiel eine E-Mail zu fälschen.

Ja, genau. Und hier sind wir wieder, wir kommen zurück zu diesem Diagramm, das wir

schon einmal gesehen haben. Und beispielsweise in dem 1. Beispiel, wo Alice eine

E-Mail an Bob gesendet hat. Sagen wir mal, wir sind Chuck. Wir sind also eine dritte Partei. Wir

sind lizenzierte Penetrationstester, wir haben eine Vereinbarung, die uns erlaubt, dies zu tun

und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In diesem Beispiel versuchen

wir, die Nachricht von Alice zu fälschen. Unsere Absicht ist es, dass Bob will, dass Bob eine

E-Mail erhält. Es sollte für Bob so aussehen, dass die E-Mail von Alice gesendet

wurde. Also ein Risiko. Okay. Ich möchte das Risiko nicht übernehmen. Ich denke, Sie können

das verstehen. Ich kann mir vorstellen, dass gefälschte Nachrichten eines der Probleme

sind, die wir in Lettland gesehen haben. Sie wurden gegen Regieurngsbehörden eingesetzt.

Und als jemand gefälschte Nachrichten per E-Mail an andere Leute, Organisationen etc.

sendete und versucht hat, sich als jemand anderes auszugeben. Und natürlich können Sie

sich vorstellen, dass das keine gute Sache ist. Aber das Interessante hier ist, dass Chuck zwar

angreift, es aber von Ihrer Perspektive abhängt. Es könnte wie ein Angriff auf Alice oder Bob

aussehen. In diesem Fall werden E-Mails nicht durch Alices Systeme geleitet. Wie Sie sehen

können, sendet Chuck E-Mails an Bobs Posteingangsserver. Nun gibt es eine 2. Art von

Angriffsart, die wir uns ansehen werden. Wenn wir eine E-Mail in die andere Richtung senden,

von Bob an Alice. Und unser Kunde ist Alice. Und in diesem Fall versuchen wir wieder, Chuck

zu sein. Wir senden E-Mails. in diesem Fall wird die E-Mail durch das System

von Alice geleitet. Die interessante Frage ist daher, was einfacher zu schützen ist.

Es könnte den Anschein haben, dass seit dem 2. Beispiel, die E-Mail tatsächlich durch die

Systeme von Alice läuft. Das bedeutet, dass Alice mehr Befugnisse hat, etwas zu tun, um

einige zusätzliche Kontrollen und Abgleiche usw. durchzuführen. Aber wie wir in Zukunft

sehen werden, ist es tatsächlich einfacher, das 1. Beispiel zu schützen. Auch wenn unser Kunde

Alice ist, versuchen wir Alice zu schützen. Aber in der Praxis ist es einfacher, dieses Beispiel zu

schützen und in die Praxis umzusetzen, in dem jemand E-Mail verkauft und versucht, sich als

Alice auszugeben. Okay. Oh, ja. Es gibt noch das 3. Beispiel: Wenn Alice mit ihren Kollegen

innerhalb derselben Organisation kommuniziert, sind wir Chuck.

In diesem Fall werden wir die E-Mail nur an den Posteingangsserver von Alice senden, nicht an

Postausgangsserver. Richtig. Das ist wichtig zu beachten. Im Prinzip ist dieses 3. Beispiel am

einfachsten zu erkennen weil Alices Organisation vermutlich weiß, dass ihre E-Mails

immer von einem, von diesem bestimmten Postausgangsserver kommen sollen. Richtig.

Wenn wir beispielsweise eine E-Mail von Alices Kollegen senden, sollte der Posteingangsserver im

Prinzip auch ohne Standards oder ähnliches, die volle Leistung haben.

Aber in der Praxis gibt es tatsächlich ziemlich oft eine spezielle Whitelist für Alices eigene Organisation.

Es finden keine Überprüfungen statt, falls der Posteingangsserver von Alice E-Mails empfängt,

die wiederum von Alice stammen.

Übrigens gibt es dieses Beispiel, das wir in den letzten Jahren gesehen haben.

Ich denke, das ist nicht spezifisch für Lettland. Deshalb ist hier als Beispiel eine kanadische Adresse und auch

andere, wie Sie sehen können. Es handelt sich hierbei um gefälschte E-Mails, wie Ransomware-Sachen.

Im Grunde sagen sie Ihnen, dass Sie in diesem Fall Ihren Computer oder Ihre E-Mails gehackt haben. Und

alle möglichen Aktivitäten arrangiert haben oder Sie erpresst.

Und senden Sie uns bitte das Geld. Ihr Geld. Ich meine Ihr Geld in Bitcoins an deren Adresse.

Soweit diese E-Mails. Der interessante Teil dieser E-Mails besteht darin, dass sie normalerweise

dazu dienen; Ihnen zu beweisen, dass Sie Zugang zu Ihrem E-Mail-Konto haben.

Sie senden E-Mails von Ihrer Adresse an Ihre Adresse.

Bei vielen Menschen funktioniert das, Sie sehen also, dass jemand Ihr Konto gehackt hat, weil Sie eine

E-Mail von sich selbst erhalten haben.

Wie Sie also später sehen werden, ist es sehr einfach, solche E-Mails zu fälschen, falls keine

Schutzvorkehrungen vorgenommen wurden. Das Wichtigste ist also, dass ich hoffe, dass niemand in

diesem Publikum auf einen solchen Betrug hereinfällt.

Aber vielleicht haben Sie Freunde oder Kollegen, die Sie kontaktiert haben und Ihnen von solchen E-Mails

erzählt haben. Aber eines der Dinge, die neben der Überprüfung der Passwörter zum Einsatz kommen

sollte, ist eine effektivere Authentifizierung zu nutzen. Vielleicht könnten Sie Ihnen sagen, dass sie Ihre E-Mail

Administratoren oder ihr IT-Team kontaktieren und nach dem Anti-Spoofing-Schutz fragen sollten.

Denn wenn sie solche E-Mails empfangen können und diese nicht gefiltert werden,

stimmt etwas nicht. Okay.

Und nun sehen wir uns eine gefälschte SMTP-Konversation an, also ein ähnliches Beispiel wie eben.

Aber in diesem Beispiel jetzt sind wir tatsächlich Chuck, also wird dies von Chuck an Bob gesendet.

Aber wir tun so, als wären wir Alice. Die Frage ist, können Sie den Unterschied zu der vorherigen

erkennen? Und es ist schwer, den Unterschied zu erkennen, da es keinen Unterschied gibt, da es

sich um das gleiche Gespräch handelt.

Der Punkt hier ist also, dass das SMTP-Protokoll an sich eigentlich keinen Schutz bietet.

Oh ja, Sie könnten es einfach zum Beispiel tun, wenn Sie dieser Typ sind, der die gefälschten Lösegeldbrief verschickt.

verschickt. Sie können diesen Text einfach aufschreiben und ihn einfach an Telnet senden.

Das funktioniert bei vielen Organisationen. Aber nicht bei allen. Und natürlich kennen die E-Mail-

Administratoren sich damit aus. Sie wissen, dass SMTP in diesem Fall nicht sehr zuverlässig ist.

Das ist leicht zu fälschen und so weiter. Und es gäbe viele Versuche, einen gewissen Schutz hinzuzufügen,

einfach auf Ad-hoc-Art. Also ohne Standards. Fügen Sie einfachen paar zusätzliche Filter und ähnliches in

Ihre eigene Mail ein. Und einige dieser Schutzmaßnahmen verstoßen tatsächlich gegen RFC,

Aber wen interessiert das schon? RFC ist ja kein heiliger Text, den ich zum Beispiel absolut

befürworte. Also machen Sie weiter. Aber das Problem ist, dass es nicht genügend Informationen gibt.

Wenn Sie also zurückdenken, sind wir Bob und versuchen, unsere Systeme zu schützen.

Wir sind also Bob, irgendein Systemadministrator, oder Bob ist der Systemadministrator und wir

versuchen, einige zusätzliche Regeln und so etwas hinzuzufügen.

Was können wir dann eigentlich tun? Ein Beispiel, das ich hier aufgelistet habe, ist die Durchführung dieses

SMTP-Rückrufs. Das bedeutet, dass wir E-Mails von Alice erhalten. Wir prüfen tatsächlich, ob

diese E-Mail überhaupt vorhanden ist. Denn viele Spammer senden einfach E-Mail von nicht

existierenden E-Mails. Und es wird funktionieren