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.