36C3 - Email authentication for penetration testers

[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