[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