-
-
So, habt Ihr Euch jemals gefragt, wie man perfekt eine Email testen kann? Dann seid Ihr hier im
-
richtigen Podcast. Wir haben hier unseren nächsten Sprecher. Andrew arbeitet gerade für das
-
Nationale CERT in Lettland. Er ist ein Sicherheitsforscher.
-
Und er wird gleich über E-Mail Fälschungen sprechen und Strategien für modernes Anti-Spoofing..
-
Die Bühne gehört Dir.
-
Applaus
-
Also Grüße. Ich bin Andrew und ich habe für das Lettische National CERT gearbeitet. Eures unserer aktuellen Ziele ist
-
idie Verbesserung des Zustands der E-Meil-Sicherheit in unserem Land und
-
das erreichen wir hauptsächlich durch die Erhöhung der Sensibilisierung für dieses Problem und die Vermittlung bewährter
-
Praktiken. Und natürlich sind wir nicht die einzige Organisation, die dies tut.
-
Es gibt viel mehr Gruppen in anderen Ländern und es gibt verschiedene
-
Nichtregierungsorganisationen, die das Gleiche tun. Und konventionelle Einrichtungen.
-
Doch bisher sind, offen gesagt, unsere
kollektiven Fortschritte ziemlich
-
enttäuschend. Daher ist hier zum Beispiel eine Statistik, die die Nutzung einer bestimmten
-
Technologie in Dänemark zeigt, was , wie Sie in diesem Vortrag erfahren werden, ziemlich
-
wichtig ist und ich hoffe, dass jeder diese Technologie verwendet. Auf der linken Seite
-
werden 20.000 Domains weltweit angezeigt, die wichtige Domains sind für
-
wichtige Organisationen, die es eigentlich besser wissen sollten. Und auf der rechten Seite
-
sehen wir die Top 50 der TOP 500 EU-Einzelhändler und in beiden Gruppen haben 2/3
-
Dänemark bisher nicht einmal konfiguriert. Und von denen, die die Mehrheit konfiguriert haben,
-
haben nicht keine strengen Richtlinien aktiviert. Wenn es also nur eine wichtige Erkenntnis aus
-
diesem Vortrag gibt, hoffe ich, dass jeder damit beginnen sollte, Dänemark zu verwenden. Es ist
-
wichtig, es auch für Domains zu verwenden, die keine E-Mails senden sollen. Eine Erklärung
-
für diese niedrige Akzeptanzrate ist meiner Meinung nach, dass es anscheinend zu viele
-
konkurrierende Technologien gibt. Das ist der Inhalt meines Vortrags. Und ich habe wirklich
-
mein Bestes gegeben, um ihn einzuschränken. Aber wie Sie sehen, gibt es 3 Abkürzungen, also
-
und SMTP und außerdem SPF, DKIM und DMARC und aktuelle 2, an deren Namen ich mich
-
nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass
-
es zufiele Schlagworte gibt, zu viele Technologien, und es ist nicht klar
-
welche wir davon verwenden sollten, das ist nicht spezifisch für E-Mails. Und wir haben das
-
in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir
-
inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar
-
Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt wurde
-
und die Ergebnisse veröffentlicht wurden, können wir mit dem Gespräch beginnen. Wir
-
können das Gespräch darüber führen, ob Ihre Organisation Technologie A oder B bevorzugt,
-
wir können stattdessen die Fragen beantworten, die wirklich wichtig sind, wie:
-
Ist es möglich, dass jemand für eine 3. Person die E-Mails ihrer Organisation fälscht und
-
solche E-Mail zum Beispiel an Ihre Kunden oder Ihre Partner oder an Medienorganisationen so
-
zu versenden, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation
-
stammen? Deshalb sind Penetrationstester die wichtigste Zielgruppe für diesen Vortrag.
-
Ich hoffe jedoch, dass alle Blue-Teamer im Publikum diesen
-
Vortrag interessant finden. Ich bin sicher, dass Sie bereits alle Grundlagen über die
-
E-Mail und über diese Technologien kennen, aber wenn man das Problem aus den
-
verschiedenen Perspektiven des Angreifers betrachtet, kann man die Dinge ins rechte Licht
-
rücken. Es kann Ihnen helfen zu verstehen, worauf Sie sich beim Schutz Ihrer Umwelt
-
konzentrieren sollten. Und schließlich das SMTP Protokoll. Die Technologie, die in unseren
-
E-Mail-Konversationen steckt, ist eigentlich relativ leicht zu verstehen.
-
Und auch die Lehren, die man daraus gezogen hat. Diese Entwicklung von SMTP, wie es wurde
-
und wie es möglich ist, es zu fälschen, und all die Technologien, die versuchen,
-
Spoofing zu verhindern. Ich denke, es ist eine interessante Fallstudie und es sollte auch für
-
solche Leute interessant sein sie zu verfolgen, die neu im E-Mail-Bereich sind. Nun final zur
-
Bedrohungslandschaft. E-Mail Sicherheit ist ein ziemlich umfangreicher Themenbereich. Heute
-
werde ich mich auf einen kleinen Teil fokussieren. Dieser ist das erfolgreiche
-
Spoofing von E-Mails, also Manipulationsattacken. Ich weiß, dass viele Pentrationstester bereits teilweise
-
Phishing oder Spear-Phishing-Emulation in ihre Arbeiten einbeziehen. So viel ich weiß, tun sie
-
dies meist aus der Social-Engineering-Perspektive, indem sie beispielsweise Tools wie
-
das Social-Engineering-Toolkit verwenden und ich möchte nicht behaupten, dass es wichtig ist,
-
dies zu tun und dem Kunden zu zeigen, welche Risiken in dieser Hinsicht bestehen. Ich denke
-
jedoch, dass Sie mit Social Engineering dem Kunden einen Dienst erweisen, wenn dies das
-
Einzige ist, was Sie aus der E-Mail-Perspektive testen, denn aus der Perspektive der Kunden,
-
beispielsweise von Managern, die Ihre Berichte lesen, erwähnen Sie dann nur Social-
-
Engineering-Angriffe. Die logische Schlussfolgerung ist, dass der beste Weg, diese
-
Bedrohungen einzudämmen. darin besteht, Ihr Personal zu schulen, insbesondere diejenigen,
-
die am wenigsten technisch versiert sind, wie dies in diesem Vortrag zu sehen ist.
-
Es gibt ziemlich viele Angriffe und viele Organisationen sind anfällig für diese Angriffe.
-
Und hier hilft auch keine noch so große Benutzerschulung, denn wir können von den
-
Benutzer nicht erwarten, dass sie beispielsweise die Kopfzeilen manuell
-
überprüfen. Deshalb müssen wir unsere E-Mail-Infrastruktur tatsächlich verbessern. Daran
-
führt kein Weg vorbei. Bevor wir uns schließlich den eigentlich technischen Dingen zuwenden,
-
gibt es noch ein kleines Geheimnis. Ich denke, es könnte Leute helfen zu verstehen , die nicht
-
in der E-Mail-Branche arbeiten, warum wir solche Probleme haben, und für E-Mail-
-
Administratoren, die in der Vergangenheit die Verfügbarkeit ihres Systems und die
-
Zuverlässigkeit viel mehr schätzten, als die Sicherheit. Und das liegt daran, dass das keine
-
ideologische Entscheidung ist. Es ist eine sehr pragmatische. Wenn Sie also beispielsweise
-
ein E-Mail-Administrator in einer Organisation sind und einige ihrer Kunden keine Rechnungen
-
mehr erhalten, wird Ihr Management Sie finden, sie darüber informieren und Sie freundlich
-
bitten, das Problem so schnell wie möglich zu beheben, auch wenn es nicht Ihre Schuld ist.
-
Es könnte sein, dass das Problem möglicherweise auf einer anderen Seite liegt,
-
nicht auf Ihrem Server. Ein anderes Beispiel ist, dass Sie, dass einige Ihrer Mitarbeiter bald
-
keine E-Mails mehr empfangen können, oder E-Mails nicht früh genug erhalten, um das
-
Passwort wiederherzustellen oder um die E-Mail zu verifizieren oder ein
-
Mehrfaktor-Authentifizierungs-Token zu verwenden und sie können sich bei einigen
-
wichtigen Systeme nicht mehr einloggen. Dann müssen Sie das lösen. Aber wenn Ihr System
-
Sicherheitslücken hat, wenn es für Spoofing-Angriffe und so weiter anfällig ist, dann wird es
-
normalerweise weder den Anwendern, noch dem Management auffallen. Aber Sie haben
-
diese Schwachstelle. Deshalb sind Penetrationstester natürlich wichtig. Okay.
-
Jetzt können wir endlich anfangen, über die Technik zu sprechen. Wir starten mit der
-
kurzen Einführung in das SMTP-Protokoll. SMTP ist das Protokoll, das der gesamten E-Mail-
-
Kommunikation zugrunde liegt und es ist ziemlich einfach zu befolgen. Hier ist also
-
ein Datenfluss, der zeigt, was passiert, wenn eine Person E-Mails an eine andere Person
-
sendet. Zum Bespielt sendet Alice an Bob und sie arbeiten für unterschiedliche Unternehmen.
-
Sie verwenden unterschiedliche Domains. Was also passiert ist, dass beide sagen würden
-
benutze E-Mail-Clients wie Outlook oder Thunderbird. Alice sendet E-Mails. Sie geht
-
über dieses Protokoll SMTP an Alices Mail-Server. Wichtig ist aber zu beachten dass dies
-
ein Server für ausgehende E-Mails ist. Üblicherweise verfügen Organisationen über
-
2 Arten von Diensten, einen für eingehende und Transaktionen und einen für ausgehenden.
-
Und auch für kleine Organisationen kann es einer sein, aber auch hier ist es für
-
Penetrationstester wichtig, sich dies als unterschiedliche Systeme vorzustellen. Denn
-
selbst wenn es physisch ein einziger Computer ist, wird er eine unterschiedliche Konfiguration
-
für ausgehende und eingehende E-Mails haben. Als Penetrationstester müssen Sie also
-
überprüfen, ob beide in Ordnung sind. Wenn Alices Server nun versucht, E-Mails an Bobs
-
Server zu senden, gibt es eine Art von Problem, das darin besteht, dass der Server irgendwie
-
automatisch den richtigen Server zum Versenden von E-Mails finden muss. Dies
-
geschieht über diese Bluebox und eine Mischung aus DNS-spezfifischen DNS-
-
Eintragstypen und -mischungen. Das ist also etwas, das von Bobs Organisation gepflegt wird,
-
Bobs Organisation wird also, wenn sie E-Mails erhalten möchten, diesen DNS-Eintrag erstellen.
-
Und ich sage: Okay, wenn Sieuns eine E-Mail senden möchten, benutzen Sie bitte diesen
-
speziellen Server. Es sollte also auf Bobs verwiesen werden. Und jetzt kann Alices
-
Ausgangsserver, der die eingehende Serveradresse von Bob kennt, mit diesem
-
kommunizieren und Bob wird später seine E-Mail erhalten. Wir als Penetrationstester
-
versuchen eigentlich, zwischen dem Server von Alice und dem von Bob zu vermitteln. Dann
-
müssen wir über das 2. Beispiel nachdenken, das umgekehrt ist. Sie denken vielleicht, dass
-
es sich um ein sinnloses Beispiel handelt, weil wir im Grunde nur die Richtung des
-
Datenverkehrs ändern. Aber das Wichtigste hier ist, dass wir als Penetrationstester verstehen,
-
dass unser Kunde nur einen Teil der Transaktion kontrolliert. Falls unser Kunde,
-
sagen wir mal, für den Rest dieser Präsentation Alice oder Alices Organisation ist,
-
dann werden im 2. Beispiel, wenn wir eine E-Mail von Bob an Alice senden, nur E-Mails
-
gesendet. Grundsätzlich läuft ein Teil dieser Transaktion im 1. Beispiel über Alices Server.
-
Wenn wir E-Mails von Alice an Bob senden, wäre dies nicht der Fall. Wenn es also etwas
-
verwirrend ist, ist das in Ordnung. Wir werden etwas später darauf zurückkommen. Und
-
schließlich gibt es noch ein 3. Beispiel, das ähnlich, aber nicht ganz so aussieht. Und zwar
-
nur, wenn Alice kommuniziert. Alice ist unser Kunde. Und wenn sie mit ihren Kollegen
-
kommuniziert, die in der gleichen Organisation sind, denselben E-Mail-Server und die gleiche
-
Domain haben, wird es in diesem Beispiel logischerweise 2 E-Mail-Server geben, ein
-
Ausgagnsserver und ein Eingangsserver.
-
Aber beide gehören unserem Kunden. Also können Sie im Moment, wenn Sie sich mit
-
E-Mail nicht auskennen, versuchen darüber nachzudenken, welche dieser 3 Szenarien
-
leichter zu schützen sind. Später werden wir sehen, sie es tatsächlich abläuft. Okay.
-
Dann müssen wir uns ansehen, was tatsächlich gesendet wird, wenn eine E-Mail versandt wird.
-
Also noch einmal, es wird das SMTP-Protokoll verwendet und es ist ein wirklich gutes
-
Protokoll. Wie Sie sehen können, handelt es sich nur um Text. Es handelt sich also um ein
-
reines Testprotokoll und es ist sehr einfach zu bedienen, weil man einfach eine Telnet-
-
Verbindung zum richtigen Server öffnet und man versuchen kann, die Befehle einfach mit
-
den Händen aufzuschreiben. Um zu versuchen, etwas zu zerstückeln oder zu modifizieren, oder
-
zu versuchen, verschiedene Typen auszuprobieren und in Echtzeit zu sehen, wie
-
es weitergeht. Auf der linken Seiten sehen wir hier also 2 Teile, die durch SMTP definiert sind.
-
Als erstes kommt der SMTP-Umschlag, den Sie im Grund mit dem Server verbinden. Sagen Sie
-
"Hallo". Dann sagen Sie, was der Absender der E-Mail und der Empfänger der E-Mail
-
angegeben haben. "Mail von" ist der Absender. Empfänger ist zum Beispiel Bob. Und dann
-
beginnt der 2. Teil mit Daten und endet mit "Beenden". Und das ist der Teil, der sich
-
Inhalt/Nachricht nennt. Wenn Sie also ein bisschen damit herumspielen wollen, wird dies
-
durch einen anderen Standard definiert, der für Penetrationstester nicht so wichtig ist. Aber
-
wenn Sie sich die Details ansehen möchten, dann könnte es wichtig sein. Und diese interne
-
Nachricht, die entweder Inhalt oder SMTP genannt wird, enthält wiederum 2. Teile. Der
-
eine Teil ist die Kopfzeile und der andere der Hauptteile. Und ich denke, dass einige Leute
-
vielleicht nicht mit der E-Mail vertraut sind, aber wahrscheinlich ist jeder Zuhörer mit HTTP
-
vertraut und das sieht ganz ähnlich aus. Also leicht zu verstehen. Aber der interessante Teil
-
ist, dass sie vielleicht bemerkt haben, dass wir
-
Alices und Bobs Adressen zweimal haben. Das stimmt. Zum Beispiel ist Alices Adresse in der
-
zweiten Zeile "Mail von". Und dann haben wir die gleiche Adresse. Alice @ ihre Organisation in
-
der Kopfzeile "Von". Die roten Bereiche sind die Kopfzeilen. Und das gleiche gilt für Bob. Und
-
warum ist das so? Nun, es kommt darauf an, wie wir E-Mails sehen. Ich als eine normale
-
Person, die E-Mails in den letzten Jahren benutzt hat, sehe sie normalerweise so, wie
-
auf der linken Seite beschrieben, wie eine Art Postkarte. Auf der Postkarte steht also jemand,
-
der sie abgeschickt hat. Der Absender. Da ist dann noch der Empfänger. Das bin ich
-
normalerweise. Ich empfange. Und dann ist da noch eine Nachricht. Zumindest habe ich das so
-
wahrgenommen, bevor ich etwas mehr darüber gelernt habe. Aber E-Mail Administratoren und
-
die Standardgremien sehen diese Situation, wie sie rechts dargestellt ist. Da ist ein Umschlag
-
und darin befindet sich diese Nachricht oder vielleicht eine Postkarte. Sie haben also 2
-
Adressen in diesem Szenario. Sie haben die Adresse von und an wen sie sich den Umschlag
-
senden. Dies ist beispielsweise der Teil, den die Post einsehen wird. Aber das Postbüro wird im
-
Allgemeinen nicht in Ihrem Umschlag nachsehen und sehen, dass sich dort eine
-
weitere Nachricht, die interne Nachricht befindet, die eigentliche für den Empfänger
-
bestimmt ist. Man könnte also eigentlich sogar noch mehr machen und man könnte sogar den
-
ganzen Umschlag mit der Nachricht der Postkarte in einen anderen Umschlag stecken.
-
Und das klingt für mich als normalen Menschen verrückt, aber tatsächlich ist das bei E-Mail.
-
möglich. Und in dem RFC, dem Standarddokument, gibt es einige Beispiele,
-
warum das notwendig ist. Warum solche Dinge erlaubt sind. Aber sie sind doch verwirrend.
-
Und so als Ergebnis sehen wir in diesem ersten Beispiel , dass wir im Allgemeine die gleiche
-
Adresse zweimal angeben. Aber als Penetrationstester sollten wir uns die Frage
-
stellen: Ist das aktuell erforderlich? Ist das immer wahr, oder handelt es sich nur um
-
Wunschdenken? Und es ist tatsächlich ein Wunschdenken. Standards schreiben nicht
-
ausdrücklich vor, dass Sie die gleiche Adresse für den Empfänger oder für das "Von" des
-
Absenders auf dem Umschlag und innerhalb einer Nachricht angeben. Es gibt also
-
tatsächlich viel mehr Kopfzeilen als die, die ich gezeigt habe. Die, die ich gezeigt habe, sind
-
meiner Meinung nach nur die, mit denen wir alle Erfahrung haben, denn wenn man nur
-
E-Mail benutzt, sind das normalerweise die Dinge, die man sieht oder man sieht das
-
Datum, den Betreff, den Inhalt, wer Dir etwas gesendet hat und an wen es gesendet wurde.
-
Üblicherweise Du selbst. Und dort könnten es natürlich auch mehrere Empfänger geben.
-
Oh ja. Und die Frage ist dann noch eine andere:
-
Was ist eigentlich, wenn wir aus irgendeinem Grund etwas versehentlich angegeben haben
-
oder vor allem, wenn wir unterschiedliche Adressen in diesem Umschlag angegeben
-
haben, welche der Benutzer sehen wird. Der Empfänger, das ist eigentlich die Kopfzeile. Ok.
-
Wie ich schon sagte, gibt es tatsächlich Standards, die mehr Kopfzeilen erlauben. Und
-
es gibt aktuell 3 Kopfzeilen "Von", "Absender", "Antwort an", die semantisch wirklich nahe
-
beieinander liegen und im Standard ist eigentlich erklärt, wann man welche Überschrift
-
verwenden sollte. Und das Lustige für mich ist, dass zum Beispiel die "Von" Überschrift ist,
-
diejenige ist, in der wir sehen, was sie beinhaltet. Wenn Sie den RFC lesen, werden Sie
-
sehen, dass man nicht mehr als eine solche Kopfzeile haben sollte, aber die Kopfzeile selbst
-
könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail
-
erhalten, die von verschiedenen Personen stammen würde, aber das ist erlaubt. Aber das
-
Wichtigste, was Sie hier noch einmal verstehen müssen, ist dies bereits erwähnte
-
Rückwärtskompatibilität. Obwohl die Standards erklären, wie Sie die Haupt-Kopfzeile
-
verwenden sollten, und dass Sie in der Praxis nicht mehr als eine dieser Kopfzeilen haben
-
sollten, können Sie bei einer Zustimmung zu fehlerhaften E-Mails diese mit mehreren
-
Kopfzeilen in der selben Kopfzeile senden. Sie könnten Kopfzeilen senden, die laut RFC kein
-
"Von" enthält, aber einen "Absender". Das ist nicht korrekt. In der Praxis wird es.
-
funktionieren. Die meisten Organisationen, die meisten E-Mail-Dienste werden Ihr Bestes tun,
-
ihre völlig fehlerhafte E-Mail nach besten Kräften zu analysieren, weil sie wirklich daran
-
interessiert sind, die Supportkosten zu senken. Wenn etwas also nicht funktioniert, wird man
-
zu Ihnen kommen. Es ist also besser, dafür zu sorgen, dass meistens alles funktioniert.
-
Für Penetrationstester bedeutet das natürlich, dass Sie damit herumspielen können, weil es
-
verschiedene Implementierungen gibt und es genau darauf ankommt, welche Gefahr besteht.
-
Wenn beispielsweise 2 Kopfzeilen angezeigt werden oder für einen Algorithmus verwendet,
-
hängt dies von der jeweiligen Implementierung ab. Da es so viele Implementierungen gibt, sind
-
diese auf unterschiedliche Weise miteinander verbunden. Sie können und sollten als
-
Penetrationstester verschiedene Dinge ausprobieren, zum Beispiel die gleiche
-
Kopfzeile mehrmals hinzufügen. OK. Nachdem wir nun diese Grundlagen behandelt haben,
-
wollen wir uns ansehen, Wie Sie versuchen würden, zum Beispiel eine E-Mail zu fälschen.
-
Ja, genau. Und hier sind wir wieder, wir kommen zurück zu diesem Diagramm, das wir
-
schon einmal gesehen haben. Und beispielsweise in dem 1. Beispiel, wo Alice eine
-
E-Mail an Bob gesendet hat. Sagen wir mal, wir sind Chuck. Wir sind also eine dritte Partei. Wir
-
sind lizenzierte Penetrationstester, wir haben eine Vereinbarung, die uns erlaubt, dies zu tun
-
und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In diesem Beispiel versuchen
-
wir, die Nachricht von Alice zu fälschen. Unsere Absicht ist es, dass Bob will, dass Bob eine
-
E-Mail erhält. Es sollte für Bob so aussehen, dass die E-Mail von Alice gesendet
-
wurde. Also ein Risiko. Okay. Ich möchte das Risiko nicht übernehmen. Ich denke, Sie können
-
das verstehen. Ich kann mir vorstellen, dass gefälschte Nachrichten eines der Probleme
-
sind, die wir in Lettland gesehen haben. Sie wurden gegen Regieurngsbehörden eingesetzt.
-
Und als jemand gefälschte Nachrichten per E-Mail an andere Leute, Organisationen etc.
-
sendete und versucht hat, sich als jemand anderes auszugeben. Und natürlich können Sie
-
sich vorstellen, dass das keine gute Sache ist. Aber das Interessante hier ist, dass Chuck zwar
-
angreift, es aber von Ihrer Perspektive abhängt. Es könnte wie ein Angriff auf Alice oder Bob
-
aussehen. In diesem Fall werden E-Mails nicht durch Alices Systeme geleitet. Wie Sie sehen
-
können, sendet Chuck E-Mails an Bobs Posteingangsserver. Nun gibt es eine 2. Art von
-
Angriffsart, die wir uns ansehen werden. Wenn wir eine E-Mail in die andere Richtung senden,
-
von Bob an Alice. Und unser Kunde ist Alice. Und in diesem Fall versuchen wir wieder, Chuck
-
zu sein. Wir senden E-Mails. in diesem Fall wird die E-Mail durch das System
-
von Alice geleitet. Die interessante Frage ist daher, was einfacher zu schützen ist.
-
Es könnte den Anschein haben, dass seit dem 2. Beispiel, die E-Mail tatsächlich durch die
-
Systeme von Alice läuft. Das bedeutet, dass Alice mehr Befugnisse hat, etwas zu tun, um
-
einige zusätzliche Kontrollen und Abgleiche usw. durchzuführen. Aber wie wir in Zukunft
-
sehen werden, ist es tatsächlich einfacher, das 1. Beispiel zu schützen. Auch wenn unser Kunde
-
Alice ist, versuchen wir Alice zu schützen. Aber in der Praxis ist es einfacher, dieses Beispiel zu
-
schützen und in die Praxis umzusetzen, in dem jemand E-Mail verkauft und versucht, sich als
-
Alice auszugeben. Okay. Oh, ja. Es gibt noch das 3. Beispiel: Wenn Alice mit ihren Kollegen
-
innerhalb derselben Organisation kommuniziert, sind wir Chuck.
-
In diesem Fall werden wir die E-Mail nur an den Posteingangsserver von Alice senden, nicht an
-
Postausgangsserver. Richtig. Das ist wichtig zu beachten. Im Prinzip ist dieses 3. Beispiel am
-
einfachsten zu erkennen weil Alices Organisation vermutlich weiß, dass ihre E-Mails
-
immer von einem, von diesem bestimmten Postausgangsserver kommen sollen. Richtig.
-
Wenn wir beispielsweise eine E-Mail von Alices Kollegen senden, sollte der Posteingangsserver im
-
Prinzip auch ohne Standards oder ähnliches, die volle Leistung haben.
-
Aber in der Praxis gibt es tatsächlich ziemlich oft eine spezielle Whitelist für Alices eigene Organisation.
-
Es finden keine Überprüfungen statt, falls der Posteingangsserver von Alice E-Mails empfängt,
-
die wiederum von Alice stammen.
-
Übrigens gibt es dieses Beispiel, das wir in den letzten Jahren gesehen haben.
-
Ich denke, das ist nicht spezifisch für Lettland. Deshalb ist hier als Beispiel eine kanadische Adresse und auch
-
andere, wie Sie sehen können. Es handelt sich hierbei um gefälschte E-Mails, wie Ransomware-Sachen.
-
Im Grunde sagen sie Ihnen, dass Sie in diesem Fall Ihren Computer oder Ihre E-Mails gehackt haben. Und
-
alle möglichen Aktivitäten arrangiert haben oder Sie erpresst.
-
Und senden Sie uns bitte das Geld. Ihr Geld. Ich meine Ihr Geld in Bitcoins an deren Adresse.
-
Soweit diese E-Mails. Der interessante Teil dieser E-Mails besteht darin, dass sie normalerweise
-
dazu dienen; Ihnen zu beweisen, dass Sie Zugang zu Ihrem E-Mail-Konto haben.
-
Sie senden E-Mails von Ihrer Adresse an Ihre Adresse.
-
Bei vielen Menschen funktioniert das, Sie sehen also, dass jemand Ihr Konto gehackt hat, weil Sie eine
-
E-Mail von sich selbst erhalten haben.
-
Wie Sie also später sehen werden, ist es sehr einfach, solche E-Mails zu fälschen, falls keine
-
Schutzvorkehrungen vorgenommen wurden. Das Wichtigste ist also, dass ich hoffe, dass niemand in
-
diesem Publikum auf einen solchen Betrug hereinfällt.
-
Aber vielleicht haben Sie Freunde oder Kollegen, die Sie kontaktiert haben und Ihnen von solchen E-Mails
-
erzählt haben. Aber eines der Dinge, die neben der Überprüfung der Passwörter zum Einsatz kommen
-
sollte, ist eine effektivere Authentifizierung zu nutzen. Vielleicht könnten Sie Ihnen sagen, dass sie Ihre E-Mail
-
Administratoren oder ihr IT-Team kontaktieren und nach dem Anti-Spoofing-Schutz fragen sollten.
-
Denn wenn sie solche E-Mails empfangen können und diese nicht gefiltert werden,
-
stimmt etwas nicht. Okay.
-
Und nun sehen wir uns eine gefälschte SMTP-Konversation an, also ein ähnliches Beispiel wie eben.
-
Aber in diesem Beispiel jetzt sind wir tatsächlich Chuck, also wird dies von Chuck an Bob gesendet.
-
Aber wir tun so, als wären wir Alice. Die Frage ist, können Sie den Unterschied zu der vorherigen
-
erkennen? Und es ist schwer, den Unterschied zu erkennen, da es keinen Unterschied gibt, da es
-
sich um das gleiche Gespräch handelt.
-
Der Punkt hier ist also, dass das SMTP-Protokoll an sich eigentlich keinen Schutz bietet.
-
Oh ja, Sie könnten es einfach zum Beispiel tun, wenn Sie dieser Typ sind, der die gefälschten Lösegeldbrief verschickt.
-
verschickt. Sie können diesen Text einfach aufschreiben und ihn einfach an Telnet senden.
-
Das funktioniert bei vielen Organisationen. Aber nicht bei allen. Und natürlich kennen die E-Mail-
-
Administratoren sich damit aus. Sie wissen, dass SMTP in diesem Fall nicht sehr zuverlässig ist.
-
Das ist leicht zu fälschen und so weiter. Und es gäbe viele Versuche, einen gewissen Schutz hinzuzufügen,
-
einfach auf Ad-hoc-Art. Also ohne Standards. Fügen Sie einfachen paar zusätzliche Filter und ähnliches in
-
Ihre eigene Mail ein. Und einige dieser Schutzmaßnahmen verstoßen tatsächlich gegen RFC,
-
Aber wen interessiert das schon? RFC ist ja kein heiliger Text, den ich zum Beispiel absolut
-
befürworte. Also machen Sie weiter. Aber das Problem ist, dass es nicht genügend Informationen gibt.
-
Wenn Sie also zurückdenken, sind wir Bob und versuchen, unsere Systeme zu schützen.
-
Wir sind also Bob, irgendein Systemadministrator, oder Bob ist der Systemadministrator und wir
-
versuchen, einige zusätzliche Regeln und so etwas hinzuzufügen.
-
Was können wir dann eigentlich tun? Ein Beispiel, das ich hier aufgelistet habe, ist die Durchführung dieses
-
SMTP-Rückrufs. Das bedeutet, dass wir E-Mails von Alice erhalten. Wir prüfen tatsächlich, ob
-
diese E-Mail überhaupt vorhanden ist. Denn viele Spammer senden einfach E-Mail von nicht
-
existierenden E-Mails. Und es wird funktionieren, 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.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-