[Vorspann]
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. Eines unserer aktuellen Ziele ist
die Verbesserung des Zustands der E-Mail-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
DMARC 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, DMARC 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, an deren Namen ich mich
nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass
es zu viele 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 dies
in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir
inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar mit Hilfe von
Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt werden
und die Ergebnisse veröffentlicht werden, 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,
oder 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
versendet, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation
stammt? 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 blaue Box MX und DNS-spezfischen MX typen.
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 Sie uns 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
Ausgangsserver 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 Textprotokoll 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, wenn Sie nur einen einfachen
SMTP-Server haben. SMTP-Callback bedeutet also, dass Sie, eine E-Mail erhalten,
Wenn Sie beispielsweise E-Mails von Alice erhalten, versuchen Sie, einen separaten
Prozess zu starten. Dieser wird eine Verbindung zu Alices Server herzustellen, etc.
Und er wird versuchen, ihr eine E-Mail zu senden. Wenn ein Server sagt, "Ja, das ist OK",
eine solche E-Mail existiert und so weiter, dann ist es nicht so, als hätten Sie die Konversation
tatsächlich beendet. Aber dann kann Ihr System automatisch feststellen, dass diese E-Mail auch
wirklich existiert. Eine andere Möglichkeit, dies zu tun, ist durch Überprüfung dieses "Hello".
Und das ist die erste Zeile und in der ersten Zeile sollte normalerweise der Hostname des
Servers stehen, der die E-Mail sendet.
Interessanter Teil. Laut RFC sollten Sie also nicht überprüfen, ob man es verifizieren kann.
Und wenn es sich um eine zufällige Zeichenfolge handelt, sollten Sie es akzeptieren.
Aber viele Server werden zunächst versuchen, diesen Hostname zu überprüfen, von dem Sie
sagen, dass Sie dieser Hostname sind. Zunächst ob es tatsächlich auf dieselbe IP-Adresse
verweist und dann machen Sie das Gegenteil. Sie nehmen die IP-Adresse und versuchen,
eine umgekehrte DNS-PTR-Abfrage auszuführen. Und Sie werden versuchen
herauszufinden, ob diese IP-Adresse wirklich auf diesen Hostname antwortet. Also nochmal.
Als Penetrationstester sollten wir uns über diese Schutzmaßnahmen, Ad-Hoc-
Schutzmaßnahmen im Klaren sein. Denn wenn Sie sie nicht kennen, werden Sie versuchen
etwas auszuführen und es wird bei Ihnen nicht funktionieren. Aber Sie einfach, wenn Sie
kennen und erkannt haben, dass diese Organisation sie verwendet. Sie sind leicht zu
umgehen, so dass sie keinen guten Schutz bieten. Sie sollen vor massenhaftem
Missbrauch durch Spam schützen. Ok. Also bietet SMTP, wie wir gesehen haben, keinen
Schutz. Welche Ergänzungen zum Protokoll können also nachträglich tatsächlich verwendet
werden, um uns zu schützen? Eines dieser Protokolle ist SPF. SPF versucht wie ein Spiegel
MX-System sein. Das MX-System ist ein gemischtes System, das Alice grundsätzlich
benutzen kann, damit Alices Server automatisch den Server finden kann, der Bob und seinem
Posteingangsserver gehört. SPF ist also das Gegenteil davon. Da ist also eine Idee, das
System automatisch auf dem Posteingangsserver von Bob auszuführen.
Wenn Bob nun die E-Mail erhalt, können sie wieder eine DNS-Abfrage ausführen und
herausfinden, welche IP-Adressen eigentlich zu Alices Postausgangsserver gehören. Das
stimmt. Ich denke, es ist einfach zu verstehen, dass dies tatsächlich ein sinnvoller Weg ist. Es
ist eine Ergänzung. Und das eine Feld, das in diesem Beispiel überprüft wird, ist der
Absender des Umschlags. OK. Und hier ist ein Beispiel für minimale SPF-Syntax. Wie wir
sehen können, ist es meiner Meinung nach leicht zu verstehen, auch wenn man die Syntax
nicht kennt. Die Syntax besteht darin, dass sie IP-Adresse aufgelistet wird, die die IP-Adresse
des Postausgangsservers ist. Und dann steht da noch dieses "alle", was wiederum leicht zu
verstehen ist. In diesem Fall bedeutet es, das dies das einzige Mal ist. Wenn Sie also eine
Nachricht erhalten, kommt diese von dieser IP-Adresse, Das ist cool. Ich akzeptiere es. Wenn es
etwas anderes ist, dann lösche ich es einfach. Und es gibt mehrere Möglichkeiten, die IP-
Adresse anzugeben. Sie könnten einfach die IP-Adresse angeben. Sie könnten ein IP-Subnetz
angeben, Sie könnten einen DNS-Hostname angeben. Es ist also nur für den Administrator.
Für einen Penetrationstest ist es grundsätzlich nicht viel anders, für Administratoren ist es
einfacher, diese Systeme zu warten. Und dann gibt es diese Qualifikanten. Das ist etwas, das
man den Methoden voranstellt. Hier in diesem Beispiel hat IPv4 keinen Qualifikanten. Es gibt
kein Plus oder Minus oder so etwas. Das liegt daran, dass das Plus standardmäßig
angenommen wird. Dadurch wird standardmäßig alles, was im SPF-Eintrag
aufgeführt ist, mit einem legitimen SMTP-Ausgangsserver übereinstimmen sollte. Es
gibt jedoch andere Optionen, die Sie verwenden können. Minus verwenden, das heißt "Fehler".
Und das bedeutet, wenn etwas mit diesem Datensatz übereinstimmt, das ist
normalerweise die letzte Möglichkeiten, dann senden Sie bitte die Mail ab. Es ist nicht echt. Es
ist eine gefälschte Mail. Un dann ist da noch die 3. Option, bei der es sich um eine Software
handelt, die für die Testphase gedacht ist. Wenn Sie also gerade mit der Implementierung von
SPF beginnen, könnte es welche geben. Problematisch könnte sein, dass Sie vergessen,
einige SMTP-Server hinzuzufügen. Weil Sie das noch nicht getan haben, denken Sie vielleicht,
Sie haben nur einen SMTP-Postausgangsserver. Aber in Wirklichkeit haben Sie tatsächlich
mehrere Möglichkeiten, E-Mail zu senden. Wenn Sie in diesem Fall beginnen würden, den
oben genannten SPF-Eintrag mit der "Fail"-Strong-Richtlinie festzulegen, könnten Ihre
Benutzer die Nachricht nicht mehr senden. Deshalb ist das Testen gut. Hier sind einige
andere Beispiele, die etwas komplizierter sind. Eines davon wurde aufgenommen. Anstatt also
die Richtlinie selbst zu definieren, weil Sie in diesem Beispiel einen Drittanbieter verwenden,
zum Beispiel Google, dann schließen Sie einfach das ein, was Google veröffentlicht hat. Und das
Interessante daran ist de Verwendung von SPF. Wenn wir uns nur die Anzahl der Domains
ansehen, die eine Art Richtlinie definiert haben, dann sieht die Zahl ziemlich gut aus. Ich denke,
das gilt zum Beispiel für die beliebtesten Domains, ungefähr 70 %. Aber das Problem
ist, dass die meisten von ihnen entweder schlecht konfiguriert sind, oder nur die Softfail-
Option benutzen. Und was die Softfail praktisch tut, ist nichts. Auch wenn es eine Richtlinie für
Softfail gibt, können Sie in den meisten Fällen Ihre E-Mail fälschen und sie wird trotzdem
ankommen, weil der Empfänger denkt, dass sie sich nur im Testmodus befindet. Sie sollten E-
Mails nicht automatische löschen. Ja. Eigentlich ist der Prozentsatz nicht so groß. Aber das
Wichtigste für uns als Penetrationstester ist es, dies zu verstehen. Was sollen wir also tun, wenn
wir diese SPF sehen? Bedeutet das, dass wir jetzt keine E-Mail mehr fälschen können? Nein,
das bedeutet es nicht. Damit ist das Spiel für uns vorbei. Wir können einige Sachen tun.
Also zunächst einmal ist diese Softtail, die ich erwähnt habe. Und dass bedeutet im Grunde,
dass Sie einige Regeln, Regeln, Regeln haben und am Ende setzen Sie typischerweise nur
diese Softfail ein. Falls wir als Penetrationstester also versuchen, von einer unbekannten IP-
Adresse aus zu fälschen, die nicht in den vorherigen Regeln aufgeführt ist, dann tun sie
nichts. Machen Sie nichts. Ich meine, lassen Sie keine E-Mail fallen. Das ist doch gut für uns,
oder? Das bedeutet, dass wir tatsächlich auf die gleiche Art und Weise fälschen können und es
wird meistens funktionieren. Eine Anmerkung hier ist, dass einige Systeme nicht nur diese
binäre Klassifikation benutzen, egal ob etwas gut oder schlecht ist, sondern sie versuchen
eine Bewertung vorzunehmen. Und dann kann es sein, dass Sie, Ihre E-Mail nicht automatisch
löschen, obwohl Sie diese Softfail haben. Aber vielleicht fügen Sie ihr eine verdächtige Ebene
hinzu. Aber wichtig ist, das es nicht automatisch zu Ende ist.
Eine andere Sache ist dieses Include. Also Include ist sehr praktisch, wenn man mit
Drittparteien arbeitet. Aber das Problem ist, dass es für einige Leute nicht das ist, was es
scheint. Zumindest wird im Standard erwähnt, dass es ein schlecht gewählter Name war. Und
der Grund dafür ist, dass es sich nicht um ein Macro handelt. Um also zu verstehen, was
passiert, wenn dies eingeschlossen ist, sollten Sie nicht einfach alles von innen kopieren und
auf der obersten Ebene einfügen. Das ist nicht die Funktionsweise. Es wird versuchen, alle
darin enthaltenen Prüfungen durchzuführen. Aber wenn dies fehlschlägt, wird die Nachricht
nicht automatisch gelöscht. Es wird auf die oberste Ebene gehen und versuchen, die
anderen Regeln auszuführen. Das Problem dabei ist, dass es in 2 der häufigsten Fälle,
entweder vergessen hat, dieses Minus zu ergänzen, oder Ihr Administrator hat es
vergessen. In diesem Fall, selbst wenn Sie dieses Minus eingeschlossen haben, wird es
nicht funktionieren. Ich denke, dass es funktionieren würde, weil, wenn der Empfänger
es mit "Minus" überprüft hat, "all inside include" nicht dasselbe bedeutet wie auf der obersten
Ebene. Und das Zweite wäre, wenn Sie alles außer der Software hinzugefügt hätten. Und
einige Admins könnten das denken. Aber das ist okay, weil ich Gmail mit einbeziehe, und GMail
diesen schwerwiegenden Fehler hat. Auf diesem Weg funktioniert es nicht. Und dann
ist, glaube ich vielleicht der häufigste Fall, dass man oft diese Art von SPF-Einträgen sieht. Aber
da ist viel Zeug in den IP-Adressen. Es gibt diese A-Rekorde, es gibt einen MX. Es gibt einen
Zeiger. Im Grund genommen alles, was den Administratoren einfällt und der Grund dafür
ist, dass sie einfach nicht sicher sind, wie es funktioniert. Sie wissen nicht, was sie eingeben
sollen. Eine Sache, die darauf hinweist, ist zum Beispiel,
ob es einen MX-Eintrag im SPF gibt. Die meisten Organisationen, sofern sie nicht sehr klein sind
und nur einen Server haben, haben verschiedene Server, verschiedene IP-Adressen
für ausgehende Mails und für eingehende Mails. Das heißt, dass es für Organisationen
keinen praktischen Grund gibt, MX in SPF aufzunehmen, denn keine E-Mail sollte durch
ihren Posteingangsserver werden. Und ein anderer Fall könnte sein, dass die
Administratoren verstehen, wie es funktioniert. Ihre Architektur ist aber wirklich
chaotisch und sie senden E-Mails von vielen, vielen unterschiedlichen Stellen senden, was
für Penetrationstester gut ist.
Das bedeutet, dass sie nicht gut organisiert sind. OK. Und dann gibt es noch einen
Schwachpunkt, der darin besteht, dass die Granularität nicht sehr gut geeignet ist. Das
einzige, was Sie tun können, sind mehrere dieser Datensatztypen. Aber alles was sie tun,
ist die Auflösung der IP-Adresse. Aber wie Sie sich vorstellen können. ist die IP in vielen Fällen
nicht nur mit dem Mailserver verknüpft. Auf einer IP kann möglicherweise ein Mailserver
und eine Webserver oder eine Datenbank oder etwas anderes vorhanden sein. Das bedeutet,
dass Sie als Penetrationstester dieses ausnutzen können. Nicht den Mailserver selbst,
denn der Mailserver ist üblicherweise ziemlich unauffällig. Es gibt nicht viele Schwachstellen.
Sie können sie einfach ausbessern, und das wars. Aber diese anderen Systeme, zum
Beispiel das Web, lassen sich in den meisten Fällen leicht ausnutzen. In gewisser Weise kann
man die Privilegien erhöhen, indem man sich Zugriff verschafft auf einem anderen Server mit
dieser IP-Adresse oder IP-Bereich. Sie können mit dem Versenden von E-Mails beginnen. Sie
werden alle SPF-Filter passieren. OK. Ein Beispiel ist "Shared Hosting", was sehr häufig
der Fall ist. Das Problem besteht darin, dass Sie in diesem Fall eine IP des SMTP-Servers haben.
Vielleicht ist das ein Server, der nur zum Versenden von E-Mails verwendet wird. Aber
der Server selbst arbeitet nicht nur für Sie. Er arbeitet für viele Domains, vielleicht Hunderte
bis Tausende. Das heißt, als Angreifer könne Sie mindestens einen von ihnen ausnutzen, oder
für Shared Hosting kaufen. Sie können Kunde dieses Shared Hosting werden. Sie müssen
nicht einmal etwas nutzen. Und dann können Sie möglicherweise eine E-Mail starten, die in
Bezug auf SPF genauso gut aussieht, wie die eigene. Und das andere ist die falsche
Überprüfung. Und das ist wahrscheinlich das schlimmste Problem mit SPF. Es gibt, wie ich
bereits erwähnt habe, mindestens 2 Identifikatoren. Der Umschlagabsender, der
externe also, der den Absender angibt. Und dann gibt es eine interne, die normalerweise
die "Von" Kopfzeile ist. Aber von diesen beiden überprüft SPF nur, ob SPF die einzige
Technologie ist, die Sie verwenden. SPF überprüft nur den ersten: den Umschlag-
Absender. Und wie ich bereits erwähnt habe, sehen tatsächliche Benutzer, die die E-Mail
erhalten, in den meisten Fällen keinen Umschlag-Absender. Sie werden
beispielsweise dies sehen und eine "Von" oder eine der anderen Kopfzeilen. Dieses Verhalten
wird tatsächlich durch DMARC behoben, was die Technologie ist, die ich erwähnt habe. Aber
die Mehrheit der SPF-Installationen, Domains, die SPF nutzen, haben kein DMARC. Also sind
dadurch nicht geschützt. Selbst wenn deren SPF großartig für Angreifer ist, bedeutet das, dass
Sie zum Weitergeben von SPF nur den Umschlag-Absender auf etwas anderes setzen.
Zum Beispiel Ihre eigene kontrollierte Adresse, die alle SPF-Prüfungen bestehen wird. Aber
dann können Sie die Kopfzeile innerhalb der "Von"-Adresse sehen, der mit der Organisation
übereinstimmt, die Sie vorgeben wollen zu sein. Okay, Dann gibt es eine andere Technologie, die
dies beheben soll und das ist DKIM. Wie wir gesehen haben, reicht SPF nicht aus. Also DKIM.
Sorry für die Abkürzungen. Es heißt: Domainkeys identified mail. Sie müssen sich
den langen Namen nicht Mehrken, nur die Abkürzung. Und was es im Grunde genommen
macht, es verwendet Kryptographie, was schön ist, oder? Es ist Mathematik. Es ist für Angreifer
schwer zu knacken. Es signiert jede Email, sodass jede E.Mail, die über den DKIM
aktivierten Server versendet wird, eine Signatur erhält, die Sie als Empfänger kryptographisch
verifizieren können. Wie Sie sehen können, ist es eigentlich ziemlich schwierig zu sehen, weil
es nicht dafür gedacht ist, von Menschen verarbeitet zu werden. Es handelt sich um
Kryptographie. Sie ist dafür gedacht, von Computern verarbeitet zu werden. Aber der
wichtige Teil hier ist im Grunde, dass das gelbe Zeug diese kryptische Signatur ist. Aber er
grüne Teil ist das, was man Domain-Erkennung nennt. Und den roten Teil nennt man - ich weiß
es nicht mehr. Lachen! Aber im Grund ist es eine Idee, dass Sie mehrere Schlüssel für Ihre
Organisation haben können, zum Beispiel könnte die Organisation E-Mails von Ihrem
ursprünglichen SMTP-Server senden und dann können Sie einen Backup-Server haben, oder
Sie haben vielleicht einige Nachrichten von Google oder eine Marketingkampagne und
so weiter. Und dann könnte jede von ihnen unterschiedliche "Rot"-Parameter haben. Das
Problem ist, dass der Empfänger dann eine DNS-Abfrage ausführen, was das 2. Beispiel ist,
bei dem diese Kombination aus grün und rot verwendet wird. Und dann erhalten Sie den
öffentlichen Schlüssel und können diesen verwenden, um die Signatur zu überprüfen.
Das hört sich also wirklich gut an. Das Problem hier ist, dass es noch ein anderes Problem gibt.
Wie man löst man es? Ich denke, es ist einfach, wenn man die öffentliche Kryptographie.
versteht. Auf der Absenderseite müssen Sie zuerst ein öffentliches und ein privates
Schlüsselpaar generieren. Dann veröffentlichen Sie den öffentlichen Teil im DNS. Dann
verwenden Sie den privaten Schlüssel, um jede Nachricht zu signieren. Der Empfänger macht
jetzt sozusagen das Gegenteil. Sobald er die E-Mail erhalten hat, findet er anhand dieses roten
und grünen Teils den richtigen DNS-Eintrag heraus, führen ihn aus, erhalten den
öffentlichen Schlüssen und vergleichen dann, ob dieser öffentliche Schlüssel mit der Signatur
übereinstimmt. Das klingt doch ganz gut, oder? Was ist das Problem? Also wählt der Kunde den
Namen aus, Das Problem dabei ist, dass es mehrere Selektoren als DKIM sein können,
wenn Sie die Konfiguration durchführen. Sie können so viele Selektoren auswählen, wie Sie
wollen und der Empfänger weiß nicht, ob Sie tatsächlich einen Selektor hätten verwenden
sollen und welchen Selektor Sie hätten verwenden sollen. Das Problem liegt darin, dass
wenn wir nur über das normale DKIM sprechen, es für einen Penentrationstester oder einen
Angreifer schwierig ist, die vorhandene Signatur zu ändern. Aber es ist einfach, es zu entfernen.
Denn wenn man DKIM aus allen Kopfzeilen entfernt hat, weiß der Empfänger nicht, dass
sie da sein sollte, denn um das zu prüfen, müsste sie dort sein. Hier also zum Beispiel,
muss ich, statt die Signatur zu überprüfen, diesen grünen Teil kennen. Diese Domain-
Kennung und den Selektor, die Teil dieser Kopfzeile sind. Richtig. Das ist also ein großes
Problem. Und das bedeutet, dass wir, obwohl wir DKIM selbst nicht fälschen können, können
wir die DKIM einfach abschneiden und die Nachricht ohne sie senden. Und falls die DKIM
das Einzige wäre, das das System geschützt hat, würde es funktionieren. Es könnte also sein,
dass es kein grünes Häkchen oder was auch immer gibt, aber es wird beim Empfänger
ankommen. Eine andere Sache ist dieser Domain-Selektor. Warum müssen wir das
überhabt einstellen? Weil die beste Übung natürlich ist, dass der Umschlag-Absender
gleich der Kopfzeile und gleich diesem DKIM Domain-Sektor ist. Wenn Sie also von Alice
senden, dann sind alle drei Alice.org oder was auch immer. Das Problem ist, dass es im RFC
nicht erwähnt wird, dass dies der Fall sein sollte. Was also passiert genau, wenn es nicht
so ist? Zum Beispiel gibt es auf der rechten Seite eine echte Domain, die Gmail, Google
Mail, Google Suite verwendet hat. In diesem Fall signiert Google Suite standardmäßig alle
Nachrichten. Wenn Sie jedoch keine eigene Konfiguration vornehmen, wird sie signiert mit
der von ihm kontrollierten Domain "gappssmtp". Und das bedeutet, dass, obwohl
technisch gesehen etwas mit DKIM signiert wurde, es aber nicht so signiert wurde, dass
man es zu seiner Organisation zurückführen kann. Es ist etwas völlig anderes. Was genau
sollte der Empfänger in diesem Fall tun? Sollten Sie es einfach ignorieren? Sollten Sie die
Nachricht zurückweisen oder etwas ähnliches? Der richtige Weg wäre also, sie nicht
abzulehnen, sondern sie einfach als ungültig, zumindest nicht als gültige DKIM zu betrachten,
aber es kommt darauf an. Also werden einige Validierer, sobald sie irgendeine DKIM sehen,
diese validieren und sagen, das ist cool, das entspricht dem RFC. Aber nun kommt der
interessante Teil. Ändern von DKIM, wofür ich keine Zeit habe. Aber die Idee ist, dass dies in
manchen, nicht in allen Fällen so ist, aber manchmal kann man es tatsächlich ändern.
Der am einfachsten zu ändernde Teil in den Nachrichten sind die Kopfzeilen. Weil DKIM,
da es in den Kopfzeilen selbst platziert ist, nicht automatisch alte Kopfzeilen signiert. Das ist wie
das Henne-Ei-Problem. Es werden standardmäßig nur 1 oder 2 Kopfzeilen signiert
und Sie können weitere Kopfzeilen angeben, die signiert werden sollen, aber das passiert nicht
automatisch. Für den Angreifer ist es eine einfache Sache, eine andere Kopfzeile
hinzuzufügen. Wenn das Ihrem Plan in irgendeiner Weise hilft, dann ist das einfach
zu machen. Sie fügen einfach eine weitere Kopfzeile hinzu. Ein interessante Teil ist, obwohl
obwohl RFC, ist, wie ich vorhin erwähnt habe, dass einige Kopfzeilen wie "Gegenstand" oder
"Von", nur in einer Kopie vorhanden sein sollten. Aktuell könnte man mehr, als eine
"Von" Kopfzeile hinzufügen. Was in diesem Fall passiert ist ziemlich interessant. DKIM wird
einverstanden sein, wenn Sie DKIM mitteilen, dass die Kopfzeile "Von" beispielsweise signiert
werden soll. Dann wird es übereinstimmen und signiert die erste "Von" Kopfzeile von unten.
Aber ziemlich viele Software E-Mail Kunden in einer Software werden dem Benutzer eigentlich
nur zuerst von der anderen Seite, der oberen Seite angezeigt. Das bedeutet also, dass der
Angreifer die Kopfzeilen verfälschen oder überschreiben kann, indem er einfach neue
Kopfzeilen hinzufügt. Und dieses eigentliche Problem wird im DKIM RFC erwähnt und der
Schutz, den sie vorschlagen ist dieser Code Over-Signing, damit Sie den RFC lesen können.
Aber nicht jeder macht das tatsächlich. Und wie auch immer, gilt das nur für die Kopfzeilen.
Manchmal ist das also gut. Manchmal ist das nicht gut. Ändern des Nachrichtentextes ist
tatsächlich viel schwieriger. Im Grunde genommen ist die naive Art es zu tun durch
Kryptographie, was wir aber nicht tun wollen. Und ein anderer Weg führt über diesen
Parameter, der die Textkörperlänge angibt und das ist eigentlich wie fragwürdig die
Funktionalität ist, die DKIM hat. Manchmal kann man festlegen, dass der Hash für Signierung-
zwecke verwendet werden soll. Wir sollten nicht den ganzen Körper betrachten, sondern nur die
ersten Bytes. Das ist in einigen Fällen bei Mailinglisten tatsächlich nützlich, aber in den
meisten Fällen nicht nützlich. Die meisten E-Mail-Programme tun dies in der Praxis nicht.
Falls sie es tun, besteht die Gefahr, dass der Textkörper möglicherweise überschrieben wird.
Sie können einen anderen Mime-Typ hinzufügen und dann die Kopfzeilen ändern,
um zu zeigen, dass dieser andere Mime-Typ DKIM passieren wird. In diesem Fall wird zum
Beispiel der grüne Button oder was auch immer angezeigt, weil DKIM gültig sein wird. Nun gibt
es also die 3. Technologie, die DMARC genannt wird. Und auch hier steht der vollständige
Name, der lang ist, aber in diesem Fall tatsächlich etwas bedeutet. Es gibt 2 Schlüssel-
wörter: Berichterstattung und Konformität. Berichterstattung ist das Wort, mit dem die
meisten Administratoren vertraut sind, denn das ist es, was DMARC meiner Meinung oft an
sie verkauft. Berichterstattung bedeutet, dass man bei Problemen in diesem Fall, der anderen
Seite sagen kann, was in diesem Fall zu tun ist. Grundsätzlich sagen Sie Ihnen, dass Sie Ihnen
entweder einmal am Tag oder jedes Mal Berichte senden sollen. Für Penetrationstester
ist das nicht sehr nützlich. Möglicherweise könnten wir verwenden, um zu verstehen,
welche Art von Konfiguration auf der anderen Seite läuft. Aber im Moment ist diese Funktion
noch nicht so weit verbreitet. Aber der andere Teil, die Konformität, ist wirklich sehr, sehr
leistungsstark. Es korrigiert die großem Fehler, die ich in SPF und DKIM erwähnt habe. DKIM
hatte dieses massive Problem, dass wenn man einfach die Kopfzeilen entfernt, dann hat der
Empfänger keine Möglichkeit zu wissen, ob DKIM an erster Stelle stehen sollte. Wenn Sie
DKIM zusammen mit DMARC verwenden, ist das Problem behoben, denn DMARC gibt nur
an, dass Sie DMARC selbst haben. Das bedeutet, dass Sie automatisch mindestens
eines von SPF oder DKIM passieren sollte. Also hat DKIM als Maßnahme das Problem
automatisch gelöst. Die andere Sache, die sich ändert, ist die Änderung Semantik für SPF.
Falls Sie nun beide, SPF und DMARC haben, könnte SPF gegen die "Von" Kopfzeile sein.
Wie ich schon anmerkte, war das die größte Schwachstelle von SPF, denn wenn Sie selbst
SPF selbst verwenden, war es sogar der Hard-to-Fail-Modus usw. Das bedeutet, dass
Angreifer die "Von" Kopfzeilen immer noch modifizieren können und der Empfänger wird
es nicht besser wissen. Ein minimales Beispiel für DMARC ist also wirklich sehr, sehr klein.
Und ich denke, es ist einfach zu verstehen. Sie haben gerade eine DMARC Ablehnung. Sie müssen
die richtige Stelle für die Angabe herausfinden. Aber es ist einfach und alles, was Sie tun müssen, ist
diesen einen DNS-Eintrag zu erstellen. Und der Vorteil davon bestseht darin, wenn Sie DKIM
und DMARC nicht haben, wenn Sie es erstellt haben. Sorry, falls Sie DKIM nicht haben, aber Sie
haben DMARC erstellt. Das bedeutet, dass diese Domain keine E-Mails senden soll.
Denn der Empfänger sieht eine E-Mail als gültig an, sollte mindestens SPF oder DKIM gültig
sein. Wenn dies nicht der Fall ist, können sie nicht gültig sein. Das bedeutet also, dass die
meisten Domains da draußen darüber nachdenken sollten, die DMARC zu aktivieren.
Das ist genau das Richtige. OK. Es gibt noch mehr Stichworte. Die DMARC-Datensätze könnten viel
länger sein, aber es ist für die Penetratrionstester nicht von großem Nutzen.
So, ein wichtiger Teil hier ist wieder die Richtlinie, die diese drei Werte annehmen kann:
"keine", "Quarantäne" und "Ablehnung".Und wenn es "Quarantäne" ist, bedeutet das,
dass die Nachricht im Falle eines Fehlers, im Spam-Ordner landen sollte.
Wenn es "Ablehnung" ist, sollte sie direkt abgewiesen werden. Und wenn es "keine" ist, bedeutet es,
dass sie sich im Test-Modus befindet. Und das ist das Bild, das ich vorher gezeigt habe.
Es zeigt dass, obwohl DMARC die wirklich beste Technologie unter diesen 3 Technologien ist.
Sie ist nicht wirklich weit verbreitet. Unglücklicherweise für die Befürworter.
Eine ganz nette Tasche für alle Penetrationstester da draußen. Das bedeutet, dass man
tatsächlich die meisten E-Mails da draußen fälschen kann. Okay. Wie können wir das umgehen?
Was passiert, wenn jemand DMARC implementiert hat? Können Penetrationstester nun nichts tun?
nichts tun? Sie müssen nicht einmal Nachforschungen anstellen?
Nein, das ist nicht nötig. Also in der Praxis, wenn jemand sowohl DKIM als auch DMARC
implementiert hat, aber nicht SPF, also hat er nur zwei davon. Das ist wirklich eine coole Kombination.
DKIM ist sehr leistungsstark und DMARC behebt den Mangel. Das ist cool in der Theorie.
In der Praxis besteht das Problem darin, statt ihre eigenen E-Mails zu schützen, sollte die
Empfängerseite sowohl DKIM, als DMARC validieren. Unglücklicherweise tut dies eine
ganze Menge von Software immer noch nicht Eine solche Software ist Microsoft Exchange.
Und selbst wenn Sie nicht mit Microsoft Exchange arbeiten, stehen die Chancen gut, dass
einige der Partner, mit denen Sie kommunizieren, Microsoft Exchange ausführen.
Und standardmäßig gibt es keine Funktion zu DKIM.
Die meisten Systeme müssen tatsächlich SPF immer noch aus praktischen Gründen aktivieren.
Das ist gut für Penetrationstester. Wenn SPF und DMARC standardmäßig zusammen
aktiviert sind, dann behebt das wiederum eines der Hauptprobleme mit SPF, aber
es behebt nicht automatisch andere Probleme, weil nicht genug Potential für Fehlkonfigurationen
da ist. So. Und die interessante Tatsache ist, dass DMARC nur fordert, dass eine der anderen
Technologien SPF oderDKIM mitgegeben wird, um die E-Mail als gültig zu sehen.
Es gibt in DMARC keine Möglichkeit anzugeben, dass beide gültig sein sollen, oder dass DKIM
dem SPF vorgezogen werden soll, obwohl es viele andere Sektoren gibt.
In der Praxis bedeutet dies, dass die meisten Systeme alle drei aktivieren,
was eine gute praktische Lösung von Seiten der Penetrationstester ist.
Wir ignorieren DKIM komplett und konzentrieren uns nur auf SPF, was das schwächste Glied in
dieser Situation ist. Okay. Also nur eine Minute für Rekapitulation.
Ich bin nicht sicher, ob ich noch mehr Zeit habe. Viel Zeit habe ich nicht. Okay.
Okay. Entschuldigung. Yeah. Ein wirklich wichtiger Hinweis ist, wenn man die Systeme testet,
dass beide Szenarien berücksichtigt werden sollen. Konzentrieren Sie sich also nicht
nicht nur auf das Senden. Wenn es um das Testen von Alice geht, ist Alice die Organisation, die Ihr
Kunde ist. Konzentrieren Sie sich nicht nur auf das Testen von E-Mails, die als Alice versendet
werden, sondern auch auf die andere Seite. Denn es ist einfach, z.B. SPF und DMARC zu
implementieren, denn für beide brauchen Sie nur eine DNS-Konfiguration. Gerade eine für
jede. Aber sie zu testen, sie richtig zu validieren ist schwieriger.
Zunächst benötigen Sie die Software-Unterstützung, die man richtig konfigurieren muss.
In der Praxis könnte es sein, dass viele Organisationen, die DMARC oder SPF auf der
DNS-Seite für ausgehende E-Mailsaktiviert haben, es nicht richtig validieren.
Yeah Okay. Sorry ich habe keine Zeit dafür.
Das wars. Sorry. Vielleicht einige Fragen.
Applaus
Herald: Danke Andrew für diesen schönen Vortrag. Natürlich haben wir Zeit für ein paar Fragen.
Ich sehe schon eine Person. Mikrophon Nr.2
M2: Hey, vielen Dank. Kennen Sie einige gute Tools zur Überwachung von DMARC-
Berichten, die ich von meinen Empfängern bekommen habe? A: Yeah. Das ist eine wirklich gute
Frage. Wir als CERT empfehlen jedem, dies zu aktivieren. Aber leider sammeln alle Tools, die im
Internet verbreitet sind, einige Daten über Sie.
Sie verwenden diese für Marketingzwecke.
Das ist nicht gut für Ihre Privatsphäre.
Wenn Sie darüber besorgt sind, müssen Sie selbst etwas implementieren oder
Sie müssen vielleicht ein Open-Source-Projekt starten. Herald: OK, Mikrophone Nr. 1
M1: Danke für das gute Gespräch. Ich würde mich selbst als Administrator bezeichnen.
Mir wird geraten, den SPF-Eintrag zu kürzen, denn wenn er zu lang ist, wird er gelöscht.
Daher bekomme ich den Rat, den PTR-Eintrag zu löschen.
Aber in Ihrem Vortrag sagen Sie, dass er für Revers-DNS-Überprüfung nützlich ist,
was ich auch auch für nützlich halte.
Wie stehen Sie zu Verkürzung Ihres SPF und zum PTR-Datensatz im Allgemeinen?
A. Das hängt vom jeweiligen Anwendungsfall ab. Es kann sein, dass einige
Organisationen tatsächlich diesen langen SPF benötigen und daran
führt kein Weg vorbei. Was Sie tun können, ist, dieses Include einzuschließen. Verwenden Sie
Includes, da diese nicht vorhanden sind. Sie sind keine Macros, sie werden nicht erweitert.
Überlegen Sie, ob Sie wirklich so viele Datensätze brauchen, die so lang sind.
Häufige Probleme darin, sofern Sie nicht Google oder etwas Ähnliches verwenden,
benötigen Sie einen so langen SPF nicht wirklich.
Es ist wahrscheinlich ein Problem mit einigen.
Ja genau. Es ist wahrscheinlich ein Fehler bei den meisten Organisationen.
Herald: OK. Nun, sehr. Nur ganz kurz.
Nummer 1. M1: Aber auf der PTI-Rocker-Platte habe ich gehört, dass es mich dramatisch unter
den Standards gelandet ist. Aber sie ist nicht in den Standards enthalten .
A: Er ist im Standard. Nein. Der PTR-Eintrag selbst ist, wenn es wirklich Ihr Anwendungsfall ist.
Ich bin mir nicht bewusst, dass er automatisch irgendwo abgelegt wird. Müsste kein Problem sein.
Herald: Wir haben ein Menge weiterer Fragen hier.
Nummer 6, ganz, ganz hinten.
M6: Danke für Ihren Vortrag. Das hängt zwar nicht direkt damit zusammen, aber es könnt.
Falls der Mailserver DKIM, DKARC und SPF akzeptiert, ist alles in Ordnung. Aber vor allem bei
Google wird die E-Mail bei vielen Organisationen zugestellt, aber als Spam eingestuft.
Das bedeutet, dass Sie im Posteingang des Empfängers nicht angezeigt wird.
Haben Sie eine Lösung, um diese Problem gegen Google zu lösen?
A. Ja, Ok. Also, ich habe verschiedene Meinungen darüber, denn eine Sache, die tatsächlich
ermöglicht, was wir eigentlich tun sollten, ist, dass Sie so streng sind. Vielen Dank Google.
Denn das ist der einzige Grund, warum wir überhaupt einen hohen Prozentsatz
von SPF haben, der selbst falsch konfiguriert ist. Der einzige Grund, warum 70% Webseiten SPF
verwenden, ist, dass sie mit Google kommunizieren müssen. Und Google wird Ihre E-Mail
nicht akzeptieren, wenn SPF nicht auf der Grundlinie ist. So.
Eigentlich macht mir der Job, den ich mache, Spaß. Ich würde es vorziehen, dass Google das tut,
was es sagt, Ich verstehe die echten Administratoren, die dieses Problem haben. Google hat das
Werkzeug. Sie kenne es wahrscheinlich. Hier können Sie überprüfen, was es über Ihre
Domain denkt. Sie müssen dieses Problem also von Fall zu Fall prüfen.
Oftmals kommt es vor, dass es trotz DKIM,DMARC etc. nicht richtig konfiguriert ist.
Also ist es das, was es ist. Darum ging es im Vortrag. Sie haben es. und sie denken vielleicht, dass Sie
es richtig konfiguriert haben, aber es bist einige Fehler.
Herald: Okay. Geben wir dem Internet den Vorrang.
Signal Angel: Wir haben eine Frage aus dem Internet. Wenn wir versuchen, eine Adresse zu
überprüfen, wie wird mit E-Mail-Adressen ohne Antwort umgegangen.
A. Keine Antwort, Es tut mir leid. Können Sie es bitte noch einmal vorlesen?
Signal Angel: Wenn ich versuche, eine E-Mail Adresse zu überprüfen, wie geht man
dann mit No-reply-E-Mails um? A: Vielleicht ging es um die No-reply Kopfzeile?
Oder nicht vorhandene IP-Adressen? Signal Angel: Wie geht man mit E-Mails um?
No-reply-E-mail-Adressen. A: Ich werde versuchen, eine Antwort darauf zu geben, wie ich es
verstehe. Was also oft passiert ist, dass die E-Mail von nicht existierenden Adressen
gesendet wird. Das war vielleicht die Frage. Die Beispielfrage "keine Antwort"
ist nicht das Problem selbst. Keine Antwort. Das Problem ist, dass es sich nicht um eine echte
Adresse handelt. Es gibt keine solche Adresse. Richtig. Und deshalb habe ich keine Antwort
darauf. Denn laut RFC sollten Sie es praktisch trotzdem akzeptieren.
Ich sagte bereits, dass viele Mailsysteme diese Adressen bereits löschen, wenn sie von
nicht vorhandenen Adressen senden. Es sei denn, Sie sind Google oder etwas Großes.
Dann werden Sie auf die weiße Liste gesetzt. Sie können es einfach nicht tun.
Sie können keine E-Mails von einer nicht existierenden Adresse senden. Falls Sie in einer
erartigen Situation sind, erstellen Sie die Adresse entfernen Sie alle E-Mails, die dort eintreffen, aber
erstellen Sie die echte Adresse, damit Sie akzeptabel sind, wenn Sie auf der anderen Seite sind,
und diese E-Mail erhalten. Das hängt von diesem speziellen Anwendungsfall ab.
Überprüfen Sie also einfach, was los ist. Wenn Sie sie kontaktieren können, kontaktieren Sie sie.
Wenn Sie sie nicht kontaktieren, dann sollten Sie entscheiden, welches Risiko besteht, wenn Sie
dieselben Adressen weglassen. Sind sie wichtig für Sie? Laut RFC sollten Sie diese Adressen
also erhalten und verarbeiten. Herald: Okay. Mikrophon Nummer 4 bitte.
M4: Hey, danke für diesen Vortrag. Kennen Sie die Bemühungen, Probleme mit großen
E-mail-Versendern wie Online- Buchhändlern zu lösen, die sehr groß sind, weil sie anscheinend
keine eigenen SPF-Datensätze haben, zum Beispiel in der Kontrolle?
A: Ja. In vielen Fällen kann man einfach mit ihnen Kontakt aufnehmen.
Die Frage, ob sie nicht darüber nachgedacht haben oder ob ihnen vielleicht niemand gesagt hat, was
sie tun sollen oder vielleicht wissen sie nicht, wie sie es besser machen sollen. Das stimmt.
Das ist also eine der Sachen, die wir als CERT tun. Falls Sie dieses Problem mit einem großen
Unternehmen in einem bestimmten Land haben, schlage ich vor, das CERT zu kontaktieren.
Auch wenn es sich nicht um eine Regierungsorganisation handelt, zum Beispiel in Lettland, wenn es
sich um ein lettisches Unternehmen handelt. Wir würden die Trage vornehmen.
Wir würden versuchen mit ihnen zu reden, ihnen zu erklären, warum sie sich ändern müssen
und so weiter. Das ist vielleicht eine Möglichkeit für sie. Aber in der Praxis gilt: Wenn etwas für Sie
als Dritte als falsche Konfiguration erscheint, kann ich das in diesem Vortrag nicht erwähnen.
Wenn etwas nicht perfekt ist, heißt das nicht, dass es falsch ist.
Es könnte tatsächlich einen geschäftlichen Grund dafür geben. Richtig. Es ist zum Beispiel so,
wenn es sich um ein großes, ich weiß nicht, Amazon oder etwas in der Art handelt, und wenn sie es
getestet haben und wissen, dass sie, wenn sie eine sehr strenge Konfiguration haben, dass dann
ein gewisser Prozentsatz ihrer E-Mails einfach nicht ankommen. Nicht wegen ihrer Problems,
sofern wegen des Problems von jemand anderem. Richtig.
Aber dann gibt es tatsächlich einen echten Geschäftsfall, dass sie das nicht tun.
Es wäre dumm, wenn sie diese strikte Konfiguration ermöglichen würden, weil sie wissen, dass es
ihrem Geschäft schadet. Das macht Sinn, oder?
Herald: Okay. Leider läuft die Zeit für diejenigen aus, die an den Mikrofonen sitzen. Bitte stellen Sie
sich einfach bei dem Sprecher neben dem Pult auf. Er wird ganz sicher mit Ihnen sprechen.
Applaus