0:00:00.000,0:00:22.180 [Vorspann] 0:00:22.180,0:00:28.540 So, habt Ihr Euch jemals gefragt, wie man perfekt eine Email testen kann? Dann seid Ihr hier im 0:00:28.540,0:00:33.369 richtigen Podcast. Wir haben hier unseren nächsten Sprecher. Andrew arbeitet gerade für das 0:00:33.369,0:00:41.180 Nationale CERT in Lettland. Er ist ein Sicherheitsforscher. 0:00:41.180,0:00:50.120 Und er wird gleich über E-Mail Fälschungen sprechen und Strategien für modernes Anti-Spoofing.. 0:00:50.120,0:00:53.356 Die Bühne gehört Dir. 0:00:53.356,0:01:04.460 Applaus 0:01:04.460,0:01:14.490 Also Grüße. Ich bin Andrew und ich habe für das Lettische National CERT gearbeitet. Eines unserer aktuellen Ziele ist 0:01:14.490,0:01:21.440 die Verbesserung des Zustands der E-Mail-Sicherheit in unserem Land und 0:01:21.440,0:01:26.400 das erreichen wir hauptsächlich durch die Erhöhung der Sensibilisierung für dieses Problem und die Vermittlung bewährter Praktiken. 0:01:26.400,0:01:30.770 Und natürlich sind wir nicht die einzige Organisation, die dies tut. 0:01:30.770,0:01:34.420 Es gibt viel mehr Gruppen in anderen Ländern und es gibt verschiedene Nichtregierungsorganisationen, 0:01:34.420,0:01:39.299 die das Gleiche tun. Und konventionelle Einrichtungen. 0:01:39.299,0:01:46.060 Doch bisher sind, offen gesagt, unsere[br]kollektiven Fortschritte ziemlich enttäuschend 0:01:46.060,0:01:54.100 Daher ist hier zum Beispiel eine Statistik, die die Nutzung einer bestimmten 0:01:54.100,0:01:59.770 Technologie in Dänemark zeigt, was, wie Sie in diesem Vortrag erfahren werden, 0:01:59.770,0:02:06.770 ziemlich wichtig ist und ich hoffe, dass jeder diese Technologie verwendet. Auf der linken Seite 0:02:06.770,0:02:11.060 werden 20.000 Domains weltweit angezeigt, die wichtige Domains sind für 0:02:11.060,0:02:15.880 wichtige Organisationen, die es eigentlich besser wissen sollten. Und auf der rechten Seite 0:02:15.880,0:02:24.799 sehen wir die Top 50 der TOP 500 EU-Einzelhändler und in beiden Gruppen haben 2/3 0:02:24.799,0:02:29.799 DMARC bisher nicht einmal konfiguriert. Und von denen, die die Mehrheit konfiguriert haben, 0:02:29.799,0:02:36.350 haben nicht keine strengen Richtlinien aktiviert. Wenn es also nur eine wichtige Erkenntnis aus 0:02:36.350,0:02:41.459 diesem Vortrag gibt, hoffe ich, dass jeder damit beginnen sollte, DMARC zu verwenden. Es ist 0:02:41.459,0:02:49.120 wichtig, es auch für Domains zu verwenden, die keine E-Mails senden sollen. Eine Erklärung 0:02:49.120,0:02:56.760 für diese niedrige Akzeptanzrate ist meiner Meinung nach, dass es anscheinend zu viele 0:02:56.760,0:03:04.310 konkurrierende Technologien gibt. Das ist der Inhalt meines Vortrags. Und ich habe wirklich 0:03:04.310,0:03:12.449 mein Bestes gegeben, um ihn einzuschränken. Aber wie Sie sehen, gibt es 3 Abkürzungen, also 0:03:12.449,0:03:18.739 und SMTP und außerdem SPF, DKIM und DMARC, an deren Namen ich mich 0:03:18.739,0:03:25.570 nicht einmal erinnere. Aber trotzdem sind sie alle wichtig. Und natürlich dieses Problem, dass 0:03:25.570,0:03:28.949 es zu viele Schlagworte gibt, zu viele Technologien, und es ist nicht klar 0:03:28.949,0:03:34.590 welche wir davon verwenden sollten, das ist nicht spezifisch für E-Mails. Und wir haben dies 0:03:34.590,0:03:39.760 in der ganzen Branche und als Sicherheitsbranche denke ich, dass wir 0:03:39.760,0:03:47.880 inzwischen mindestens einen Weg gefunden haben , das Problem zu lösen. Und zwar mit Hilfe von 0:03:47.880,0:03:53.370 Penetrationstests. Also wenn der Penetrationstest richtig durchgeführt werden 0:03:53.370,0:03:58.190 und die Ergebnisse veröffentlicht werden, können wir mit dem Gespräch beginnen. Wir 0:03:58.190,0:04:03.510 können das Gespräch darüber führen, ob Ihre Organisation Technologie A oder B bevorzugt, 0:04:03.510,0:04:09.620 oder wir können stattdessen die Fragen beantworten, die wirklich wichtig sind, wie: 0:04:09.620,0:04:15.310 Ist es möglich, dass jemand für eine 3. Person die E-Mails ihrer Organisation fälscht und 0:04:15.310,0:04:20.989 solche E-Mail zum Beispiel an Ihre Kunden oder Ihre Partner oder an Medienorganisationen so 0:04:20.989,0:04:24.970 versendet, dass diese denken, dass die E-Mails wirklich von Ihrer Organisation 0:04:24.970,0:04:31.810 stammt? Deshalb sind Penetrationstester die wichtigste Zielgruppe für diesen Vortrag. 0:04:31.810,0:04:36.020 Ich hoffe jedoch, dass alle Blue-Teamer im Publikum diesen 0:04:36.020,0:04:40.650 Vortrag interessant finden. Ich bin sicher, dass Sie bereits alle Grundlagen über die 0:04:40.650,0:04:43.620 E-Mail und über diese Technologien kennen, aber wenn man das Problem aus den 0:04:43.620,0:04:50.440 verschiedenen Perspektiven des Angreifers betrachtet, kann man die Dinge ins rechte Licht 0:04:50.440,0:04:54.819 rücken. Es kann Ihnen helfen zu verstehen, worauf Sie sich beim Schutz Ihrer Umwelt 0:04:54.819,0:05:01.009 konzentrieren sollten. Und schließlich das SMTP Protokoll. Die Technologie, die in unseren 0:05:01.009,0:05:07.720 E-Mail-Konversationen steckt, ist eigentlich relativ leicht zu verstehen. 0:05:07.720,0:05:14.061 Und auch die Lehren, die man daraus gezogen hat. Diese Entwicklung von SMTP, wie es wurde 0:05:14.061,0:05:20.979 und wie es möglich ist, es zu fälschen, und all die Technologien, die versuchen, 0:05:20.979,0:05:27.530 Spoofing zu verhindern. Ich denke, es ist eine interessante Fallstudie und es sollte auch für 0:05:27.530,0:05:33.719 solche Leute interessant sein sie zu verfolgen, die neu im E-Mail-Bereich sind. Nun final zur 0:05:33.719,0:05:41.400 Bedrohungslandschaft. E-Mail Sicherheit ist ein ziemlich umfangreicher Themenbereich. Heute 0:05:41.400,0:05:47.650 werde ich mich auf einen kleinen Teil fokussieren. Dieser ist das erfolgreiche 0:05:47.650,0:05:54.689 Spoofing von E-Mails, also Manipulationsattacken. Ich weiß, dass viele Pentrationstester bereits teilweise 0:05:54.689,0:06:01.250 Phishing oder Spear-Phishing-Emulation in ihre Arbeiten einbeziehen. So viel ich weiß, tun sie 0:06:01.250,0:06:07.070 dies meist aus der Social-Engineering-Perspektive, indem sie beispielsweise Tools wie 0:06:07.070,0:06:13.090 das Social-Engineering-Toolkit verwenden und ich möchte nicht behaupten, dass es wichtig ist, 0:06:13.090,0:06:16.949 dies zu tun und dem Kunden zu zeigen, welche Risiken in dieser Hinsicht bestehen. Ich denke 0:06:16.949,0:06:23.860 jedoch, dass Sie mit Social Engineering dem Kunden einen Dienst erweisen, wenn dies das 0:06:23.860,0:06:28.099 Einzige ist, was Sie aus der E-Mail-Perspektive testen, denn aus der Perspektive der Kunden, 0:06:28.099,0:06:32.650 beispielsweise von Managern, die Ihre Berichte lesen, erwähnen Sie dann nur Social- 0:06:32.650,0:06:38.870 Engineering-Angriffe. Die logische Schlussfolgerung ist, dass der beste Weg, diese 0:06:38.870,0:06:44.650 Bedrohungen einzudämmen. darin besteht, Ihr Personal zu schulen, insbesondere diejenigen, 0:06:44.650,0:06:51.590 die am wenigsten technisch versiert sind, wie dies in diesem Vortrag zu sehen ist. 0:06:51.590,0:06:55.379 Es gibt ziemlich viele Angriffe und viele Organisationen sind anfällig für diese Angriffe. 0:06:55.379,0:07:00.230 Und hier hilft auch keine noch so große Benutzerschulung, denn wir können von den 0:07:00.230,0:07:03.889 Benutzer nicht erwarten, dass sie beispielsweise die Kopfzeilen manuell 0:07:03.889,0:07:10.699 überprüfen. Deshalb müssen wir unsere E-Mail-Infrastruktur tatsächlich verbessern. Daran 0:07:10.699,0:07:17.009 führt kein Weg vorbei. Bevor wir uns schließlich den eigentlich technischen Dingen zuwenden, 0:07:17.009,0:07:21.889 gibt es noch ein kleines Geheimnis. Ich denke, es könnte Leute helfen zu verstehen , die nicht 0:07:21.889,0:07:28.159 in der E-Mail-Branche arbeiten, warum wir solche Probleme haben, und für E-Mail- 0:07:28.159,0:07:38.040 Administratoren, die in der Vergangenheit die Verfügbarkeit ihres Systems und die 0:07:38.040,0:07:44.680 Zuverlässigkeit viel mehr schätzten, als die Sicherheit. Und das liegt daran, dass das keine 0:07:44.680,0:07:50.469 ideologische Entscheidung ist. Es ist eine sehr pragmatische. Wenn Sie also beispielsweise 0:07:50.469,0:07:56.090 ein E-Mail-Administrator in einer Organisation sind und einige ihrer Kunden keine Rechnungen 0:07:56.090,0:08:01.470 mehr erhalten, wird Ihr Management Sie finden, sie darüber informieren und Sie freundlich 0:08:01.470,0:08:06.210 bitten, das Problem so schnell wie möglich zu beheben, auch wenn es nicht Ihre Schuld ist. 0:08:06.210,0:08:13.509 Es könnte sein, dass das Problem möglicherweise auf einer anderen Seite liegt, 0:08:13.509,0:08:20.449 nicht auf Ihrem Server. Ein anderes Beispiel ist, dass Sie, dass einige Ihrer Mitarbeiter bald 0:08:20.449,0:08:24.969 keine E-Mails mehr empfangen können, oder E-Mails nicht früh genug erhalten, um das 0:08:24.969,0:08:30.190 Passwort wiederherzustellen oder um die E-Mail zu verifizieren oder ein 0:08:30.190,0:08:33.969 Mehrfaktor-Authentifizierungs-Token zu verwenden und sie können sich bei einigen 0:08:33.969,0:08:39.539 wichtigen Systeme nicht mehr einloggen. Dann müssen Sie das lösen. Aber wenn Ihr System 0:08:39.539,0:08:45.540 Sicherheitslücken hat, wenn es für Spoofing-Angriffe und so weiter anfällig ist, dann wird es 0:08:45.540,0:08:50.670 normalerweise weder den Anwendern, noch dem Management auffallen. Aber Sie haben 0:08:50.670,0:08:55.930 diese Schwachstelle. Deshalb sind Penetrationstester natürlich wichtig. Okay. 0:08:55.930,0:09:01.250 Jetzt können wir endlich anfangen, über die Technik zu sprechen. Wir starten mit der 0:09:01.250,0:09:07.190 kurzen Einführung in das SMTP-Protokoll. SMTP ist das Protokoll, das der gesamten E-Mail- 0:09:07.190,0:09:12.360 Kommunikation zugrunde liegt und es ist ziemlich einfach zu befolgen. Hier ist also 0:09:12.360,0:09:18.370 ein Datenfluss, der zeigt, was passiert, wenn eine Person E-Mails an eine andere Person 0:09:18.370,0:09:21.269 sendet. Zum Bespielt sendet Alice an Bob und sie arbeiten für unterschiedliche Unternehmen. 0:09:21.269,0:09:24.970 Sie verwenden unterschiedliche Domains. Was also passiert ist, dass beide sagen würden 0:09:24.970,0:09:29.290 benutze E-Mail-Clients wie Outlook oder Thunderbird. Alice sendet E-Mails. Sie geht 0:09:29.290,0:09:34.580 über dieses Protokoll SMTP an Alices Mail-Server. Wichtig ist aber zu beachten dass dies 0:09:34.580,0:09:41.740 ein Server für ausgehende E-Mails ist. Üblicherweise verfügen Organisationen über 0:09:41.740,0:09:44.790 2 Arten von Diensten, einen für eingehende und Transaktionen und einen für ausgehenden. 0:09:44.790,0:09:48.680 Und auch für kleine Organisationen kann es einer sein, aber auch hier ist es für 0:09:48.680,0:09:52.470 Penetrationstester wichtig, sich dies als unterschiedliche Systeme vorzustellen. Denn 0:09:52.470,0:09:56.680 selbst wenn es physisch ein einziger Computer ist, wird er eine unterschiedliche Konfiguration 0:09:56.680,0:10:00.620 für ausgehende und eingehende E-Mails haben. Als Penetrationstester müssen Sie also 0:10:00.620,0:10:04.899 überprüfen, ob beide in Ordnung sind. Wenn Alices Server nun versucht, E-Mails an Bobs 0:10:04.899,0:10:11.940 Server zu senden, gibt es eine Art von Problem, das darin besteht, dass der Server irgendwie 0:10:11.940,0:10:16.480 automatisch den richtigen Server zum Versenden von E-Mails finden muss. Dies 0:10:16.480,0:10:25.220 geschieht über diese blaue Box MX und DNS-spezfischen MX typen. 0:10:25.220,0:10:29.680 Das ist also etwas, das von Bobs Organisation gepflegt wird, 0:10:29.680,0:10:35.360 Bobs Organisation wird also, wenn sie E-Mails erhalten möchten, diesen DNS-Eintrag erstellen. 0:10:35.360,0:10:38.830 Und ich sage: Okay, wenn Sie uns eine E-Mail senden möchten, benutzen Sie bitte diesen 0:10:38.830,0:10:44.290 speziellen Server. Es sollte also auf Bobs verwiesen werden. Und jetzt kann Alices 0:10:44.290,0:10:50.670 Ausgangsserver, der die eingehende Serveradresse von Bob kennt, mit diesem 0:10:50.670,0:10:54.970 kommunizieren und Bob wird später seine E-Mail erhalten. Wir als Penetrationstester 0:10:54.970,0:10:59.839 versuchen eigentlich, zwischen dem Server von Alice und dem von Bob zu vermitteln. Dann 0:10:59.839,0:11:03.511 müssen wir über das 2. Beispiel nachdenken, das umgekehrt ist. Sie denken vielleicht, dass 0:11:03.511,0:11:07.110 es sich um ein sinnloses Beispiel handelt, weil wir im Grunde nur die Richtung des 0:11:07.110,0:11:11.449 Datenverkehrs ändern. Aber das Wichtigste hier ist, dass wir als Penetrationstester verstehen, 0:11:11.449,0:11:17.220 dass unser Kunde nur einen Teil der Transaktion kontrolliert. Falls unser Kunde, 0:11:17.220,0:11:20.760 sagen wir mal, für den Rest dieser Präsentation Alice oder Alices Organisation ist, 0:11:20.760,0:11:26.750 dann werden im 2. Beispiel, wenn wir eine E-Mail von Bob an Alice senden, nur E-Mails 0:11:26.750,0:11:34.600 gesendet. Grundsätzlich läuft ein Teil dieser Transaktion im 1. Beispiel über Alices Server. 0:11:34.600,0:11:40.980 Wenn wir E-Mails von Alice an Bob senden, wäre dies nicht der Fall. Wenn es also etwas 0:11:40.980,0:11:45.940 verwirrend ist, ist das in Ordnung. Wir werden etwas später darauf zurückkommen. Und 0:11:45.940,0:11:51.600 schließlich gibt es noch ein 3. Beispiel, das ähnlich, aber nicht ganz so aussieht. Und zwar 0:11:51.600,0:11:56.260 nur, wenn Alice kommuniziert. Alice ist unser Kunde. Und wenn sie mit ihren Kollegen 0:11:56.260,0:12:01.070 kommuniziert, die in der gleichen Organisation sind, denselben E-Mail-Server und die gleiche 0:12:01.070,0:12:04.320 Domain haben, wird es in diesem Beispiel logischerweise 2 E-Mail-Server geben, ein 0:12:04.320,0:12:09.000 Ausgangsserver und ein Eingangsserver. 0:12:09.000,0:12:15.850 Aber beide gehören unserem Kunden. Also können Sie im Moment, wenn Sie sich mit 0:12:15.850,0:12:20.149 E-Mail nicht auskennen, versuchen darüber nachzudenken, welche dieser 3 Szenarien 0:12:20.149,0:12:27.740 leichter zu schützen sind. Später werden wir sehen, sie es tatsächlich abläuft. Okay. 0:12:27.740,0:12:31.769 Dann müssen wir uns ansehen, was tatsächlich gesendet wird, wenn eine E-Mail versandt wird. 0:12:31.769,0:12:38.410 Also noch einmal, es wird das SMTP-Protokoll verwendet und es ist ein wirklich gutes 0:12:38.410,0:12:44.790 Protokoll. Wie Sie sehen können, handelt es sich nur um Text. Es handelt sich also um ein 0:12:44.790,0:12:48.029 reines Textprotokoll und es ist sehr einfach zu bedienen, weil man einfach eine Telnet- 0:12:48.029,0:12:54.410 Verbindung zum richtigen Server öffnet und man versuchen kann, die Befehle einfach mit 0:12:54.410,0:12:58.680 den Händen aufzuschreiben. Um zu versuchen, etwas zu zerstückeln oder zu modifizieren, oder 0:12:58.680,0:13:05.149 zu versuchen, verschiedene Typen auszuprobieren und in Echtzeit zu sehen, wie 0:13:05.149,0:13:11.209 es weitergeht. Auf der linken Seiten sehen wir hier also 2 Teile, die durch SMTP definiert sind. 0:13:11.209,0:13:14.720 Als erstes kommt der SMTP-Umschlag, den Sie im Grund mit dem Server verbinden. Sagen Sie 0:13:14.720,0:13:22.070 "Hallo". Dann sagen Sie, was der Absender der E-Mail und der Empfänger der E-Mail 0:13:22.070,0:13:26.980 angegeben haben. "Mail von" ist der Absender. Empfänger ist zum Beispiel Bob. Und dann 0:13:26.980,0:13:32.160 beginnt der 2. Teil mit Daten und endet mit "Beenden". Und das ist der Teil, der sich 0:13:32.160,0:13:35.480 Inhalt/Nachricht nennt. Wenn Sie also ein bisschen damit herumspielen wollen, wird dies 0:13:35.480,0:13:38.029 durch einen anderen Standard definiert, der für Penetrationstester nicht so wichtig ist. Aber 0:13:38.029,0:13:43.890 wenn Sie sich die Details ansehen möchten, dann könnte es wichtig sein. Und diese interne 0:13:43.890,0:13:49.069 Nachricht, die entweder Inhalt oder SMTP genannt wird, enthält wiederum 2. Teile. Der 0:13:49.069,0:13:53.300 eine Teil ist die Kopfzeile und der andere der Hauptteile. Und ich denke, dass einige Leute 0:13:53.300,0:13:57.569 vielleicht nicht mit der E-Mail vertraut sind, aber wahrscheinlich ist jeder Zuhörer mit HTTP 0:13:57.569,0:14:02.600 vertraut und das sieht ganz ähnlich aus. Also leicht zu verstehen. Aber der interessante Teil 0:14:02.600,0:14:08.550 ist, dass sie vielleicht bemerkt haben, dass wir 0:14:08.550,0:14:14.350 Alices und Bobs Adressen zweimal haben. Das stimmt. Zum Beispiel ist Alices Adresse in der 0:14:14.350,0:14:19.709 zweiten Zeile "Mail von". Und dann haben wir die gleiche Adresse. Alice @ ihre Organisation in 0:14:19.709,0:14:26.810 der Kopfzeile "Von". Die roten Bereiche sind die Kopfzeilen. Und das gleiche gilt für Bob. Und 0:14:26.810,0:14:33.471 warum ist das so? Nun, es kommt darauf an, wie wir E-Mails sehen. Ich als eine normale 0:14:33.471,0:14:39.139 Person, die E-Mails in den letzten Jahren benutzt hat, sehe sie normalerweise so, wie 0:14:39.139,0:14:44.980 auf der linken Seite beschrieben, wie eine Art Postkarte. Auf der Postkarte steht also jemand, 0:14:44.980,0:14:48.980 der sie abgeschickt hat. Der Absender. Da ist dann noch der Empfänger. Das bin ich 0:14:48.980,0:14:53.569 normalerweise. Ich empfange. Und dann ist da noch eine Nachricht. Zumindest habe ich das so 0:14:53.569,0:14:58.670 wahrgenommen, bevor ich etwas mehr darüber gelernt habe. Aber E-Mail Administratoren und 0:14:58.670,0:15:04.610 die Standardgremien sehen diese Situation, wie sie rechts dargestellt ist. Da ist ein Umschlag 0:15:04.610,0:15:10.480 und darin befindet sich diese Nachricht oder vielleicht eine Postkarte. Sie haben also 2 0:15:10.480,0:15:15.350 Adressen in diesem Szenario. Sie haben die Adresse von und an wen sie sich den Umschlag 0:15:15.350,0:15:20.730 senden. Dies ist beispielsweise der Teil, den die Post einsehen wird. Aber das Postbüro wird im 0:15:20.730,0:15:24.589 Allgemeinen nicht in Ihrem Umschlag nachsehen und sehen, dass sich dort eine 0:15:24.589,0:15:28.880 weitere Nachricht, die interne Nachricht befindet, die eigentliche für den Empfänger 0:15:28.880,0:15:33.889 bestimmt ist. Man könnte also eigentlich sogar noch mehr machen und man könnte sogar den 0:15:33.889,0:15:40.060 ganzen Umschlag mit der Nachricht der Postkarte in einen anderen Umschlag stecken. 0:15:40.060,0:15:46.500 Und das klingt für mich als normalen Menschen verrückt, aber tatsächlich ist das bei E-Mail. 0:15:46.500,0:15:50.029 möglich. Und in dem RFC, dem Standarddokument, gibt es einige Beispiele, 0:15:50.029,0:15:56.939 warum das notwendig ist. Warum solche Dinge erlaubt sind. Aber sie sind doch verwirrend. 0:15:56.939,0:16:03.009 Und so als Ergebnis sehen wir in diesem ersten Beispiel , dass wir im Allgemeine die gleiche 0:16:03.009,0:16:07.940 Adresse zweimal angeben. Aber als Penetrationstester sollten wir uns die Frage 0:16:07.940,0:16:12.170 stellen: Ist das aktuell erforderlich? Ist das immer wahr, oder handelt es sich nur um 0:16:12.170,0:16:17.120 Wunschdenken? Und es ist tatsächlich ein Wunschdenken. Standards schreiben nicht 0:16:17.120,0:16:20.870 ausdrücklich vor, dass Sie die gleiche Adresse für den Empfänger oder für das "Von" des 0:16:20.870,0:16:27.140 Absenders auf dem Umschlag und innerhalb einer Nachricht angeben. Es gibt also 0:16:27.140,0:16:32.300 tatsächlich viel mehr Kopfzeilen als die, die ich gezeigt habe. Die, die ich gezeigt habe, sind 0:16:32.300,0:16:38.519 meiner Meinung nach nur die, mit denen wir alle Erfahrung haben, denn wenn man nur 0:16:38.519,0:16:42.850 E-Mail benutzt, sind das normalerweise die Dinge, die man sieht oder man sieht das 0:16:42.850,0:16:45.920 Datum, den Betreff, den Inhalt, wer Dir etwas gesendet hat und an wen es gesendet wurde. 0:16:45.920,0:16:52.680 Üblicherweise Du selbst. Und dort könnten es natürlich auch mehrere Empfänger geben. 0:16:52.680,0:16:57.800 Oh ja. Und die Frage ist dann noch eine andere: 0:16:57.800,0:17:03.769 Was ist eigentlich, wenn wir aus irgendeinem Grund etwas versehentlich angegeben haben 0:17:03.769,0:17:07.300 oder vor allem, wenn wir unterschiedliche Adressen in diesem Umschlag angegeben 0:17:07.300,0:17:11.890 haben, welche der Benutzer sehen wird. Der Empfänger, das ist eigentlich die Kopfzeile. Ok. 0:17:11.890,0:17:18.010 Wie ich schon sagte, gibt es tatsächlich Standards, die mehr Kopfzeilen erlauben. Und 0:17:18.010,0:17:22.510 es gibt aktuell 3 Kopfzeilen "Von", "Absender", "Antwort an", die semantisch wirklich nahe 0:17:22.510,0:17:25.880 beieinander liegen und im Standard ist eigentlich erklärt, wann man welche Überschrift 0:17:25.880,0:17:31.080 verwenden sollte. Und das Lustige für mich ist, dass zum Beispiel die "Von" Überschrift ist, 0:17:31.080,0:17:34.040 diejenige ist, in der wir sehen, was sie beinhaltet. Wenn Sie den RFC lesen, werden Sie 0:17:34.040,0:17:39.310 sehen, dass man nicht mehr als eine solche Kopfzeile haben sollte, aber die Kopfzeile selbst 0:17:39.310,0:17:44.450 könnte mehrere Adressen beinhalten. Persönlich habe ich noch nie eine E-Mail 0:17:44.450,0:17:48.020 erhalten, die von verschiedenen Personen stammen würde, aber das ist erlaubt. Aber das 0:17:48.020,0:17:53.110 Wichtigste, was Sie hier noch einmal verstehen müssen, ist dies bereits erwähnte 0:17:53.110,0:17:57.530 Rückwärtskompatibilität. Obwohl die Standards erklären, wie Sie die Haupt-Kopfzeile 0:17:57.530,0:18:02.480 verwenden sollten, und dass Sie in der Praxis nicht mehr als eine dieser Kopfzeilen haben 0:18:02.480,0:18:07.130 sollten, können Sie bei einer Zustimmung zu fehlerhaften E-Mails diese mit mehreren 0:18:07.130,0:18:12.480 Kopfzeilen in der selben Kopfzeile senden. Sie könnten Kopfzeilen senden, die laut RFC kein 0:18:12.480,0:18:17.040 "Von" enthält, aber einen "Absender". Das ist nicht korrekt. In der Praxis wird es. 0:18:17.040,0:18:21.240 funktionieren. Die meisten Organisationen, die meisten E-Mail-Dienste werden Ihr Bestes tun, 0:18:21.240,0:18:27.550 ihre völlig fehlerhafte E-Mail nach besten Kräften zu analysieren, weil sie wirklich daran 0:18:27.550,0:18:33.720 interessiert sind, die Supportkosten zu senken. Wenn etwas also nicht funktioniert, wird man 0:18:33.720,0:18:37.580 zu Ihnen kommen. Es ist also besser, dafür zu sorgen, dass meistens alles funktioniert. 0:18:37.580,0:18:42.160 Für Penetrationstester bedeutet das natürlich, dass Sie damit herumspielen können, weil es 0:18:42.160,0:18:45.670 verschiedene Implementierungen gibt und es genau darauf ankommt, welche Gefahr besteht. 0:18:45.670,0:18:49.480 Wenn beispielsweise 2 Kopfzeilen angezeigt werden oder für einen Algorithmus verwendet, 0:18:49.480,0:18:53.830 hängt dies von der jeweiligen Implementierung ab. Da es so viele Implementierungen gibt, sind 0:18:53.830,0:18:59.150 diese auf unterschiedliche Weise miteinander verbunden. Sie können und sollten als 0:18:59.150,0:19:03.720 Penetrationstester verschiedene Dinge ausprobieren, zum Beispiel die gleiche 0:19:03.720,0:19:09.270 Kopfzeile mehrmals hinzufügen. OK. Nachdem wir nun diese Grundlagen behandelt haben, 0:19:09.270,0:19:13.990 wollen wir uns ansehen, Wie Sie versuchen würden, zum Beispiel eine E-Mail zu fälschen. 0:19:13.990,0:19:18.360 Ja, genau. Und hier sind wir wieder, wir kommen zurück zu diesem Diagramm, das wir 0:19:18.360,0:19:23.930 schon einmal gesehen haben. Und beispielsweise in dem 1. Beispiel, wo Alice eine 0:19:23.930,0:19:29.960 E-Mail an Bob gesendet hat. Sagen wir mal, wir sind Chuck. Wir sind also eine dritte Partei. Wir 0:19:29.960,0:19:33.700 sind lizenzierte Penetrationstester, wir haben eine Vereinbarung, die uns erlaubt, dies zu tun 0:19:33.700,0:19:38.920 und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In diesem Beispiel versuchen 0:19:38.920,0:19:44.440 wir, die Nachricht von Alice zu fälschen. Unsere Absicht ist es, dass Bob will, dass Bob eine 0:19:44.440,0:19:52.580 E-Mail erhält. Es sollte für Bob so aussehen, dass die E-Mail von Alice gesendet 0:19:52.580,0:19:57.580 wurde. Also ein Risiko. Okay. Ich möchte das Risiko nicht übernehmen. Ich denke, Sie können 0:19:57.580,0:20:01.430 das verstehen. Ich kann mir vorstellen, dass gefälschte Nachrichten eines der Probleme 0:20:01.430,0:20:06.330 sind, die wir in Lettland gesehen haben. Sie wurden gegen Regieurngsbehörden eingesetzt. 0:20:06.330,0:20:13.660 Und als jemand gefälschte Nachrichten per E-Mail an andere Leute, Organisationen etc. 0:20:13.660,0:20:19.510 sendete und versucht hat, sich als jemand anderes auszugeben. Und natürlich können Sie 0:20:19.510,0:20:23.710 sich vorstellen, dass das keine gute Sache ist. Aber das Interessante hier ist, dass Chuck zwar 0:20:23.710,0:20:28.450 angreift, es aber von Ihrer Perspektive abhängt. Es könnte wie ein Angriff auf Alice oder Bob 0:20:28.450,0:20:32.480 aussehen. In diesem Fall werden E-Mails nicht durch Alices Systeme geleitet. Wie Sie sehen 0:20:32.480,0:20:37.590 können, sendet Chuck E-Mails an Bobs Posteingangsserver. Nun gibt es eine 2. Art von 0:20:37.590,0:20:44.490 Angriffsart, die wir uns ansehen werden. Wenn wir eine E-Mail in die andere Richtung senden, 0:20:44.490,0:20:48.540 von Bob an Alice. Und unser Kunde ist Alice. Und in diesem Fall versuchen wir wieder, Chuck 0:20:48.540,0:20:52.900 zu sein. Wir senden E-Mails. in diesem Fall wird die E-Mail durch das System 0:20:52.900,0:20:58.570 von Alice geleitet. Die interessante Frage ist daher, was einfacher zu schützen ist. 0:20:58.570,0:21:03.790 Es könnte den Anschein haben, dass seit dem 2. Beispiel, die E-Mail tatsächlich durch die 0:21:03.790,0:21:07.270 Systeme von Alice läuft. Das bedeutet, dass Alice mehr Befugnisse hat, etwas zu tun, um 0:21:07.270,0:21:11.880 einige zusätzliche Kontrollen und Abgleiche usw. durchzuführen. Aber wie wir in Zukunft 0:21:11.880,0:21:16.190 sehen werden, ist es tatsächlich einfacher, das 1. Beispiel zu schützen. Auch wenn unser Kunde 0:21:16.190,0:21:21.710 Alice ist, versuchen wir Alice zu schützen. Aber in der Praxis ist es einfacher, dieses Beispiel zu 0:21:21.710,0:21:26.540 schützen und in die Praxis umzusetzen, in dem jemand E-Mail verkauft und versucht, sich als 0:21:26.540,0:21:32.800 Alice auszugeben. Okay. Oh, ja. Es gibt noch das 3. Beispiel: Wenn Alice mit ihren Kollegen 0:21:32.800,0:21:37.690 innerhalb derselben Organisation kommuniziert, sind wir Chuck. 0:21:37.690,0:21:41.821 In diesem Fall werden wir die E-Mail nur an den Posteingangsserver von Alice senden, nicht an 0:21:41.821,0:21:47.590 Postausgangsserver. Richtig. Das ist wichtig zu beachten. Im Prinzip ist dieses 3. Beispiel am 0:21:47.590,0:21:54.460 einfachsten zu erkennen weil Alices Organisation vermutlich weiß, dass ihre E-Mails 0:21:54.460,0:21:59.790 immer von einem, von diesem bestimmten Postausgangsserver kommen sollen. Richtig. 0:21:59.790,0:22:03.790 Wenn wir beispielsweise eine E-Mail von Alices Kollegen senden, sollte der Posteingangsserver im 0:22:03.790,0:22:08.780 Prinzip auch ohne Standards oder ähnliches, die volle Leistung haben. 0:22:08.780,0:22:15.610 Aber in der Praxis gibt es tatsächlich ziemlich oft eine spezielle Whitelist für Alices eigene Organisation. 0:22:15.610,0:22:24.140 Es finden keine Überprüfungen statt, falls der Posteingangsserver von Alice E-Mails empfängt, 0:22:24.140,0:22:28.880 die wiederum von Alice stammen. 0:22:28.880,0:22:34.610 Übrigens gibt es dieses Beispiel, das wir in den letzten Jahren gesehen haben. 0:22:34.610,0:22:38.730 Ich denke, das ist nicht spezifisch für Lettland. Deshalb ist hier als Beispiel eine kanadische Adresse und auch 0:22:38.730,0:22:43.590 andere, wie Sie sehen können. Es handelt sich hierbei um gefälschte E-Mails, wie Ransomware-Sachen. 0:22:43.590,0:22:48.290 Im Grunde sagen sie Ihnen, dass Sie in diesem Fall Ihren Computer oder Ihre E-Mails gehackt haben. Und 0:22:48.290,0:22:53.820 alle möglichen Aktivitäten arrangiert haben oder Sie erpresst. 0:22:53.820,0:22:59.160 Und senden Sie uns bitte das Geld. Ihr Geld. Ich meine Ihr Geld in Bitcoins an deren Adresse. 0:22:59.160,0:23:04.520 Soweit diese E-Mails. Der interessante Teil dieser E-Mails besteht darin, dass sie normalerweise 0:23:04.520,0:23:08.920 dazu dienen; Ihnen zu beweisen, dass Sie Zugang zu Ihrem E-Mail-Konto haben. 0:23:08.920,0:23:13.210 Sie senden E-Mails von Ihrer Adresse an Ihre Adresse. 0:23:13.210,0:23:20.100 Bei vielen Menschen funktioniert das, Sie sehen also, dass jemand Ihr Konto gehackt hat, weil Sie eine 0:23:20.100,0:23:22.730 E-Mail von sich selbst erhalten haben. 0:23:22.730,0:23:28.620 Wie Sie also später sehen werden, ist es sehr einfach, solche E-Mails zu fälschen, falls keine 0:23:28.620,0:23:34.100 Schutzvorkehrungen vorgenommen wurden. Das Wichtigste ist also, dass ich hoffe, dass niemand in 0:23:34.100,0:23:38.120 diesem Publikum auf einen solchen Betrug hereinfällt. 0:23:38.120,0:23:43.910 Aber vielleicht haben Sie Freunde oder Kollegen, die Sie kontaktiert haben und Ihnen von solchen E-Mails 0:23:43.910,0:23:48.230 erzählt haben. Aber eines der Dinge, die neben der Überprüfung der Passwörter zum Einsatz kommen 0:23:48.230,0:23:53.110 sollte, ist eine effektivere Authentifizierung zu nutzen. Vielleicht könnten Sie Ihnen sagen, dass sie Ihre E-Mail 0:23:53.110,0:23:57.770 Administratoren oder ihr IT-Team kontaktieren und nach dem Anti-Spoofing-Schutz fragen sollten. 0:23:57.770,0:24:03.470 Denn wenn sie solche E-Mails empfangen können und diese nicht gefiltert werden, 0:24:03.470,0:24:09.020 stimmt etwas nicht. Okay. 0:24:09.020,0:24:16.990 Und nun sehen wir uns eine gefälschte SMTP-Konversation an, also ein ähnliches Beispiel wie eben. 0:24:16.990,0:24:22.090 Aber in diesem Beispiel jetzt sind wir tatsächlich Chuck, also wird dies von Chuck an Bob gesendet. 0:24:22.090,0:24:25.920 Aber wir tun so, als wären wir Alice. Die Frage ist, können Sie den Unterschied zu der vorherigen 0:24:25.920,0:24:30.110 erkennen? Und es ist schwer, den Unterschied zu erkennen, da es keinen Unterschied gibt, da es 0:24:30.110,0:24:33.230 sich um das gleiche Gespräch handelt. 0:24:33.230,0:24:39.540 Der Punkt hier ist also, dass das SMTP-Protokoll an sich eigentlich keinen Schutz bietet. 0:24:39.540,0:24:43.640 Oh ja, Sie könnten es einfach zum Beispiel tun, wenn Sie dieser Typ sind, der die gefälschten Lösegeldbrief verschickt. 0:24:43.640,0:24:49.580 verschickt. Sie können diesen Text einfach aufschreiben und ihn einfach an Telnet senden. 0:24:49.580,0:24:55.830 Das funktioniert bei vielen Organisationen. Aber nicht bei allen. Und natürlich kennen die E-Mail- 0:24:55.830,0:25:01.210 Administratoren sich damit aus. Sie wissen, dass SMTP in diesem Fall nicht sehr zuverlässig ist. 0:25:01.210,0:25:05.070 Das ist leicht zu fälschen und so weiter. Und es gäbe viele Versuche, einen gewissen Schutz hinzuzufügen, 0:25:05.070,0:25:11.520 einfach auf Ad-hoc-Art. Also ohne Standards. Fügen Sie einfachen paar zusätzliche Filter und ähnliches in 0:25:11.520,0:25:15.950 Ihre eigene Mail ein. Und einige dieser Schutzmaßnahmen verstoßen tatsächlich gegen RFC, 0:25:15.950,0:25:20.640 Aber wen interessiert das schon? RFC ist ja kein heiliger Text, den ich zum Beispiel absolut 0:25:20.640,0:25:26.260 befürworte. Also machen Sie weiter. Aber das Problem ist, dass es nicht genügend Informationen gibt. 0:25:26.260,0:25:31.640 Wenn Sie also zurückdenken, sind wir Bob und versuchen, unsere Systeme zu schützen. 0:25:31.640,0:25:35.100 Wir sind also Bob, irgendein Systemadministrator, oder Bob ist der Systemadministrator und wir 0:25:35.100,0:25:39.730 versuchen, einige zusätzliche Regeln und so etwas hinzuzufügen. 0:25:39.730,0:25:44.590 Was können wir dann eigentlich tun? Ein Beispiel, das ich hier aufgelistet habe, ist die Durchführung dieses 0:25:44.590,0:25:49.980 SMTP-Rückrufs. Das bedeutet, dass wir E-Mails von Alice erhalten. Wir prüfen tatsächlich, ob 0:25:49.980,0:25:56.970 diese E-Mail überhaupt vorhanden ist. Denn viele Spammer senden einfach E-Mail von nicht 0:25:56.970,0:26:02.000 existierenden E-Mails. Und es wird funktionieren, wenn Sie nur einen einfachen 0:26:02.000,0:26:08.640 SMTP-Server haben. SMTP-Callback bedeutet also, dass Sie, eine E-Mail erhalten, 0:26:08.640,0:26:13.300 Wenn Sie beispielsweise E-Mails von Alice erhalten, versuchen Sie, einen separaten 0:26:13.300,0:26:17.220 Prozess zu starten. Dieser wird eine Verbindung zu Alices Server herzustellen, etc. 0:26:17.220,0:26:24.500 Und er wird versuchen, ihr eine E-Mail zu senden. Wenn ein Server sagt, "Ja, das ist OK", 0:26:24.500,0:26:27.540 eine solche E-Mail existiert und so weiter, dann ist es nicht so, als hätten Sie die Konversation 0:26:27.540,0:26:31.290 tatsächlich beendet. Aber dann kann Ihr System automatisch feststellen, dass diese E-Mail auch 0:26:31.290,0:26:36.570 wirklich existiert. Eine andere Möglichkeit, dies zu tun, ist durch Überprüfung dieses "Hello". 0:26:36.570,0:26:42.030 Und das ist die erste Zeile und in der ersten Zeile sollte normalerweise der Hostname des 0:26:42.030,0:26:48.000 Servers stehen, der die E-Mail sendet. 0:26:48.000,0:26:52.580 Interessanter Teil. Laut RFC sollten Sie also nicht überprüfen, ob man es verifizieren kann. 0:26:52.580,0:26:56.540 Und wenn es sich um eine zufällige Zeichenfolge handelt, sollten Sie es akzeptieren. 0:26:56.540,0:27:04.520 Aber viele Server werden zunächst versuchen, diesen Hostname zu überprüfen, von dem Sie 0:27:04.520,0:27:07.800 sagen, dass Sie dieser Hostname sind. Zunächst ob es tatsächlich auf dieselbe IP-Adresse 0:27:07.800,0:27:12.800 verweist und dann machen Sie das Gegenteil. Sie nehmen die IP-Adresse und versuchen, 0:27:12.800,0:27:18.880 eine umgekehrte DNS-PTR-Abfrage auszuführen. Und Sie werden versuchen 0:27:18.880,0:27:23.150 herauszufinden, ob diese IP-Adresse wirklich auf diesen Hostname antwortet. Also nochmal. 0:27:23.150,0:27:26.520 Als Penetrationstester sollten wir uns über diese Schutzmaßnahmen, Ad-Hoc- 0:27:26.520,0:27:31.040 Schutzmaßnahmen im Klaren sein. Denn wenn Sie sie nicht kennen, werden Sie versuchen 0:27:31.040,0:27:34.700 etwas auszuführen und es wird bei Ihnen nicht funktionieren. Aber Sie einfach, wenn Sie 0:27:34.700,0:27:40.470 kennen und erkannt haben, dass diese Organisation sie verwendet. Sie sind leicht zu 0:27:40.470,0:27:44.530 umgehen, so dass sie keinen guten Schutz bieten. Sie sollen vor massenhaftem 0:27:44.530,0:27:52.910 Missbrauch durch Spam schützen. Ok. Also bietet SMTP, wie wir gesehen haben, keinen 0:27:52.910,0:27:59.380 Schutz. Welche Ergänzungen zum Protokoll können also nachträglich tatsächlich verwendet 0:27:59.380,0:28:06.860 werden, um uns zu schützen? Eines dieser Protokolle ist SPF. SPF versucht wie ein Spiegel 0:28:06.860,0:28:12.870 MX-System sein. Das MX-System ist ein gemischtes System, das Alice grundsätzlich 0:28:12.870,0:28:18.150 benutzen kann, damit Alices Server automatisch den Server finden kann, der Bob und seinem 0:28:18.150,0:28:24.580 Posteingangsserver gehört. SPF ist also das Gegenteil davon. Da ist also eine Idee, das 0:28:24.580,0:28:30.270 System automatisch auf dem Posteingangsserver von Bob auszuführen. 0:28:30.270,0:28:35.720 Wenn Bob nun die E-Mail erhalt, können sie wieder eine DNS-Abfrage ausführen und 0:28:35.720,0:28:41.820 herausfinden, welche IP-Adressen eigentlich zu Alices Postausgangsserver gehören. Das 0:28:41.820,0:28:45.780 stimmt. Ich denke, es ist einfach zu verstehen, dass dies tatsächlich ein sinnvoller Weg ist. Es 0:28:45.780,0:28:52.570 ist eine Ergänzung. Und das eine Feld, das in diesem Beispiel überprüft wird, ist der 0:28:52.570,0:28:59.360 Absender des Umschlags. OK. Und hier ist ein Beispiel für minimale SPF-Syntax. Wie wir 0:28:59.360,0:29:04.610 sehen können, ist es meiner Meinung nach leicht zu verstehen, auch wenn man die Syntax 0:29:04.610,0:29:08.470 nicht kennt. Die Syntax besteht darin, dass sie IP-Adresse aufgelistet wird, die die IP-Adresse 0:29:08.470,0:29:12.780 des Postausgangsservers ist. Und dann steht da noch dieses "alle", was wiederum leicht zu 0:29:12.780,0:29:18.700 verstehen ist. In diesem Fall bedeutet es, das dies das einzige Mal ist. Wenn Sie also eine 0:29:18.700,0:29:22.980 Nachricht erhalten, kommt diese von dieser IP-Adresse, Das ist cool. Ich akzeptiere es. Wenn es 0:29:22.980,0:29:27.190 etwas anderes ist, dann lösche ich es einfach. Und es gibt mehrere Möglichkeiten, die IP- 0:29:27.190,0:29:31.610 Adresse anzugeben. Sie könnten einfach die IP-Adresse angeben. Sie könnten ein IP-Subnetz 0:29:31.610,0:29:37.070 angeben, Sie könnten einen DNS-Hostname angeben. Es ist also nur für den Administrator. 0:29:37.070,0:29:44.750 Für einen Penetrationstest ist es grundsätzlich nicht viel anders, für Administratoren ist es 0:29:49.620,0:29:56.160 einfacher, diese Systeme zu warten. Und dann gibt es diese Qualifikanten. Das ist etwas, das 0:29:56.160,0:30:00.100 man den Methoden voranstellt. Hier in diesem Beispiel hat IPv4 keinen Qualifikanten. Es gibt 0:30:00.100,0:30:03.910 kein Plus oder Minus oder so etwas. Das liegt daran, dass das Plus standardmäßig 0:30:03.910,0:30:12.600 angenommen wird. Dadurch wird standardmäßig alles, was im SPF-Eintrag 0:30:12.600,0:30:15.850 aufgeführt ist, mit einem legitimen SMTP-Ausgangsserver übereinstimmen sollte. Es 0:30:15.850,0:30:20.380 gibt jedoch andere Optionen, die Sie verwenden können. Minus verwenden, das heißt "Fehler". 0:30:20.380,0:30:26.710 Und das bedeutet, wenn etwas mit diesem Datensatz übereinstimmt, das ist 0:30:26.710,0:30:32.090 normalerweise die letzte Möglichkeiten, dann senden Sie bitte die Mail ab. Es ist nicht echt. Es 0:30:32.090,0:30:37.150 ist eine gefälschte Mail. Un dann ist da noch die 3. Option, bei der es sich um eine Software 0:30:37.150,0:30:42.690 handelt, die für die Testphase gedacht ist. Wenn Sie also gerade mit der Implementierung von 0:30:42.690,0:30:47.730 SPF beginnen, könnte es welche geben. Problematisch könnte sein, dass Sie vergessen, 0:30:47.730,0:30:52.750 einige SMTP-Server hinzuzufügen. Weil Sie das noch nicht getan haben, denken Sie vielleicht, 0:30:52.750,0:30:56.360 Sie haben nur einen SMTP-Postausgangsserver. Aber in Wirklichkeit haben Sie tatsächlich 0:30:56.360,0:31:03.600 mehrere Möglichkeiten, E-Mail zu senden. Wenn Sie in diesem Fall beginnen würden, den 0:31:03.600,0:31:07.230 oben genannten SPF-Eintrag mit der "Fail"-Strong-Richtlinie festzulegen, könnten Ihre 0:31:07.230,0:31:13.460 Benutzer die Nachricht nicht mehr senden. Deshalb ist das Testen gut. Hier sind einige 0:31:13.460,0:31:16.400 andere Beispiele, die etwas komplizierter sind. Eines davon wurde aufgenommen. Anstatt also 0:31:16.400,0:31:19.270 die Richtlinie selbst zu definieren, weil Sie in diesem Beispiel einen Drittanbieter verwenden, 0:31:19.270,0:31:24.720 zum Beispiel Google, dann schließen Sie einfach das ein, was Google veröffentlicht hat. Und das 0:31:24.720,0:31:31.530 Interessante daran ist de Verwendung von SPF. Wenn wir uns nur die Anzahl der Domains 0:31:31.530,0:31:36.890 ansehen, die eine Art Richtlinie definiert haben, dann sieht die Zahl ziemlich gut aus. Ich denke, 0:31:36.890,0:31:42.290 das gilt zum Beispiel für die beliebtesten Domains, ungefähr 70 %. Aber das Problem 0:31:42.290,0:31:45.710 ist, dass die meisten von ihnen entweder schlecht konfiguriert sind, oder nur die Softfail- 0:31:45.710,0:31:51.790 Option benutzen. Und was die Softfail praktisch tut, ist nichts. Auch wenn es eine Richtlinie für 0:31:51.790,0:31:56.700 Softfail gibt, können Sie in den meisten Fällen Ihre E-Mail fälschen und sie wird trotzdem 0:31:56.700,0:32:00.720 ankommen, weil der Empfänger denkt, dass sie sich nur im Testmodus befindet. Sie sollten E- 0:32:00.720,0:32:07.940 Mails nicht automatische löschen. Ja. Eigentlich ist der Prozentsatz nicht so groß. Aber das 0:32:07.940,0:32:13.910 Wichtigste für uns als Penetrationstester ist es, dies zu verstehen. Was sollen wir also tun, wenn 0:32:13.910,0:32:18.420 wir diese SPF sehen? Bedeutet das, dass wir jetzt keine E-Mail mehr fälschen können? Nein, 0:32:18.420,0:32:24.670 das bedeutet es nicht. Damit ist das Spiel für uns vorbei. Wir können einige Sachen tun. 0:32:24.670,0:32:30.060 Also zunächst einmal ist diese Softtail, die ich erwähnt habe. Und dass bedeutet im Grunde, 0:32:30.060,0:32:33.830 dass Sie einige Regeln, Regeln, Regeln haben und am Ende setzen Sie typischerweise nur 0:32:33.830,0:32:41.460 diese Softfail ein. Falls wir als Penetrationstester also versuchen, von einer unbekannten IP- 0:32:41.460,0:32:46.330 Adresse aus zu fälschen, die nicht in den vorherigen Regeln aufgeführt ist, dann tun sie 0:32:46.330,0:32:51.520 nichts. Machen Sie nichts. Ich meine, lassen Sie keine E-Mail fallen. Das ist doch gut für uns, 0:32:51.520,0:32:56.720 oder? Das bedeutet, dass wir tatsächlich auf die gleiche Art und Weise fälschen können und es 0:32:56.720,0:33:02.250 wird meistens funktionieren. Eine Anmerkung hier ist, dass einige Systeme nicht nur diese 0:33:02.250,0:33:06.590 binäre Klassifikation benutzen, egal ob etwas gut oder schlecht ist, sondern sie versuchen 0:33:06.590,0:33:11.320 eine Bewertung vorzunehmen. Und dann kann es sein, dass Sie, Ihre E-Mail nicht automatisch 0:33:11.320,0:33:16.370 löschen, obwohl Sie diese Softfail haben. Aber vielleicht fügen Sie ihr eine verdächtige Ebene 0:33:16.370,0:33:22.540 hinzu. Aber wichtig ist, das es nicht automatisch zu Ende ist. 0:33:22.540,0:33:29.970 Eine andere Sache ist dieses Include. Also Include ist sehr praktisch, wenn man mit 0:33:29.970,0:33:36.330 Drittparteien arbeitet. Aber das Problem ist, dass es für einige Leute nicht das ist, was es 0:33:36.330,0:33:43.100 scheint. Zumindest wird im Standard erwähnt, dass es ein schlecht gewählter Name war. Und 0:33:43.100,0:33:48.110 der Grund dafür ist, dass es sich nicht um ein Macro handelt. Um also zu verstehen, was 0:33:48.110,0:33:52.720 passiert, wenn dies eingeschlossen ist, sollten Sie nicht einfach alles von innen kopieren und 0:33:52.720,0:33:58.340 auf der obersten Ebene einfügen. Das ist nicht die Funktionsweise. Es wird versuchen, alle 0:33:58.340,0:34:05.480 darin enthaltenen Prüfungen durchzuführen. Aber wenn dies fehlschlägt, wird die Nachricht 0:34:05.480,0:34:10.250 nicht automatisch gelöscht. Es wird auf die oberste Ebene gehen und versuchen, die 0:34:10.250,0:34:14.510 anderen Regeln auszuführen. Das Problem dabei ist, dass es in 2 der häufigsten Fälle, 0:34:14.510,0:34:20.570 entweder vergessen hat, dieses Minus zu ergänzen, oder Ihr Administrator hat es 0:34:20.570,0:34:26.470 vergessen. In diesem Fall, selbst wenn Sie dieses Minus eingeschlossen haben, wird es 0:34:26.470,0:34:34.089 nicht funktionieren. Ich denke, dass es funktionieren würde, weil, wenn der Empfänger 0:34:34.089,0:34:39.569 es mit "Minus" überprüft hat, "all inside include" nicht dasselbe bedeutet wie auf der obersten 0:34:39.569,0:34:43.799 Ebene. Und das Zweite wäre, wenn Sie alles außer der Software hinzugefügt hätten. Und 0:34:43.799,0:34:47.809 einige Admins könnten das denken. Aber das ist okay, weil ich Gmail mit einbeziehe, und GMail 0:34:47.809,0:34:54.409 diesen schwerwiegenden Fehler hat. Auf diesem Weg funktioniert es nicht. Und dann 0:34:54.409,0:35:00.000 ist, glaube ich vielleicht der häufigste Fall, dass man oft diese Art von SPF-Einträgen sieht. Aber 0:35:00.000,0:35:03.569 da ist viel Zeug in den IP-Adressen. Es gibt diese A-Rekorde, es gibt einen MX. Es gibt einen 0:35:03.569,0:35:07.890 Zeiger. Im Grund genommen alles, was den Administratoren einfällt und der Grund dafür 0:35:07.890,0:35:12.990 ist, dass sie einfach nicht sicher sind, wie es funktioniert. Sie wissen nicht, was sie eingeben 0:35:12.990,0:35:17.100 sollen. Eine Sache, die darauf hinweist, ist zum Beispiel, 0:35:17.100,0:35:24.840 ob es einen MX-Eintrag im SPF gibt. Die meisten Organisationen, sofern sie nicht sehr klein sind 0:35:24.840,0:35:27.930 und nur einen Server haben, haben verschiedene Server, verschiedene IP-Adressen 0:35:27.930,0:35:31.059 für ausgehende Mails und für eingehende Mails. Das heißt, dass es für Organisationen 0:35:31.059,0:35:34.500 keinen praktischen Grund gibt, MX in SPF aufzunehmen, denn keine E-Mail sollte durch 0:35:34.500,0:35:41.109 ihren Posteingangsserver werden. Und ein anderer Fall könnte sein, dass die 0:35:41.109,0:35:45.900 Administratoren verstehen, wie es funktioniert. Ihre Architektur ist aber wirklich 0:35:45.900,0:35:51.470 chaotisch und sie senden E-Mails von vielen, vielen unterschiedlichen Stellen senden, was 0:35:51.470,0:35:55.730 für Penetrationstester gut ist. 0:35:55.730,0:36:03.359 Das bedeutet, dass sie nicht gut organisiert sind. OK. Und dann gibt es noch einen 0:36:03.359,0:36:09.220 Schwachpunkt, der darin besteht, dass die Granularität nicht sehr gut geeignet ist. Das 0:36:09.220,0:36:13.799 einzige, was Sie tun können, sind mehrere dieser Datensatztypen. Aber alles was sie tun, 0:36:13.799,0:36:19.650 ist die Auflösung der IP-Adresse. Aber wie Sie sich vorstellen können. ist die IP in vielen Fällen 0:36:19.650,0:36:24.230 nicht nur mit dem Mailserver verknüpft. Auf einer IP kann möglicherweise ein Mailserver 0:36:24.230,0:36:28.069 und eine Webserver oder eine Datenbank oder etwas anderes vorhanden sein. Das bedeutet, 0:36:28.069,0:36:32.339 dass Sie als Penetrationstester dieses ausnutzen können. Nicht den Mailserver selbst, 0:36:32.339,0:36:36.740 denn der Mailserver ist üblicherweise ziemlich unauffällig. Es gibt nicht viele Schwachstellen. 0:36:36.740,0:36:42.740 Sie können sie einfach ausbessern, und das wars. Aber diese anderen Systeme, zum 0:36:42.740,0:36:46.680 Beispiel das Web, lassen sich in den meisten Fällen leicht ausnutzen. In gewisser Weise kann 0:36:46.680,0:36:50.809 man die Privilegien erhöhen, indem man sich Zugriff verschafft auf einem anderen Server mit 0:36:50.809,0:36:59.859 dieser IP-Adresse oder IP-Bereich. Sie können mit dem Versenden von E-Mails beginnen. Sie 0:36:59.859,0:37:04.950 werden alle SPF-Filter passieren. OK. Ein Beispiel ist "Shared Hosting", was sehr häufig 0:37:04.950,0:37:10.359 der Fall ist. Das Problem besteht darin, dass Sie in diesem Fall eine IP des SMTP-Servers haben. 0:37:10.359,0:37:15.900 Vielleicht ist das ein Server, der nur zum Versenden von E-Mails verwendet wird. Aber 0:37:15.900,0:37:18.849 der Server selbst arbeitet nicht nur für Sie. Er arbeitet für viele Domains, vielleicht Hunderte 0:37:18.849,0:37:24.289 bis Tausende. Das heißt, als Angreifer könne Sie mindestens einen von ihnen ausnutzen, oder 0:37:24.289,0:37:26.940 für Shared Hosting kaufen. Sie können Kunde dieses Shared Hosting werden. Sie müssen 0:37:26.940,0:37:31.750 nicht einmal etwas nutzen. Und dann können Sie möglicherweise eine E-Mail starten, die in 0:37:31.750,0:37:38.140 Bezug auf SPF genauso gut aussieht, wie die eigene. Und das andere ist die falsche 0:37:38.140,0:37:44.960 Überprüfung. Und das ist wahrscheinlich das schlimmste Problem mit SPF. Es gibt, wie ich 0:37:44.960,0:37:49.640 bereits erwähnt habe, mindestens 2 Identifikatoren. Der Umschlagabsender, der 0:37:49.640,0:37:53.740 externe also, der den Absender angibt. Und dann gibt es eine interne, die normalerweise 0:37:53.740,0:37:58.589 die "Von" Kopfzeile ist. Aber von diesen beiden überprüft SPF nur, ob SPF die einzige 0:37:58.589,0:38:03.140 Technologie ist, die Sie verwenden. SPF überprüft nur den ersten: den Umschlag- 0:38:03.140,0:38:09.059 Absender. Und wie ich bereits erwähnt habe, sehen tatsächliche Benutzer, die die E-Mail 0:38:09.059,0:38:13.279 erhalten, in den meisten Fällen keinen Umschlag-Absender. Sie werden 0:38:13.279,0:38:17.559 beispielsweise dies sehen und eine "Von" oder eine der anderen Kopfzeilen. Dieses Verhalten 0:38:17.559,0:38:22.830 wird tatsächlich durch DMARC behoben, was die Technologie ist, die ich erwähnt habe. Aber 0:38:22.830,0:38:27.319 die Mehrheit der SPF-Installationen, Domains, die SPF nutzen, haben kein DMARC. Also sind 0:38:27.319,0:38:31.329 dadurch nicht geschützt. Selbst wenn deren SPF großartig für Angreifer ist, bedeutet das, dass 0:38:31.329,0:38:36.630 Sie zum Weitergeben von SPF nur den Umschlag-Absender auf etwas anderes setzen. 0:38:36.630,0:38:40.430 Zum Beispiel Ihre eigene kontrollierte Adresse, die alle SPF-Prüfungen bestehen wird. Aber 0:38:40.430,0:38:49.010 dann können Sie die Kopfzeile innerhalb der "Von"-Adresse sehen, der mit der Organisation 0:38:49.010,0:38:56.776 übereinstimmt, die Sie vorgeben wollen zu sein. Okay, Dann gibt es eine andere Technologie, die 0:38:56.776,0:39:02.309 dies beheben soll und das ist DKIM. Wie wir gesehen haben, reicht SPF nicht aus. Also DKIM. 0:39:02.309,0:39:11.450 Sorry für die Abkürzungen. Es heißt: Domainkeys identified mail. Sie müssen sich 0:39:11.450,0:39:15.099 den langen Namen nicht Mehrken, nur die Abkürzung. Und was es im Grunde genommen 0:39:15.099,0:39:20.223 macht, es verwendet Kryptographie, was schön ist, oder? Es ist Mathematik. Es ist für Angreifer 0:39:20.223,0:39:24.640 schwer zu knacken. Es signiert jede Email, sodass jede E.Mail, die über den DKIM 0:39:24.640,0:39:29.870 aktivierten Server versendet wird, eine Signatur erhält, die Sie als Empfänger kryptographisch 0:39:29.870,0:39:35.059 verifizieren können. Wie Sie sehen können, ist es eigentlich ziemlich schwierig zu sehen, weil 0:39:35.059,0:39:39.940 es nicht dafür gedacht ist, von Menschen verarbeitet zu werden. Es handelt sich um 0:39:39.940,0:39:44.160 Kryptographie. Sie ist dafür gedacht, von Computern verarbeitet zu werden. Aber der 0:39:44.160,0:39:48.300 wichtige Teil hier ist im Grunde, dass das gelbe Zeug diese kryptische Signatur ist. Aber er 0:39:48.300,0:39:55.880 grüne Teil ist das, was man Domain-Erkennung nennt. Und den roten Teil nennt man - ich weiß 0:39:55.880,0:40:02.269 es nicht mehr. Lachen! Aber im Grund ist es eine Idee, dass Sie mehrere Schlüssel für Ihre 0:40:02.269,0:40:07.160 Organisation haben können, zum Beispiel könnte die Organisation E-Mails von Ihrem 0:40:07.160,0:40:12.390 ursprünglichen SMTP-Server senden und dann können Sie einen Backup-Server haben, oder 0:40:12.390,0:40:17.650 Sie haben vielleicht einige Nachrichten von Google oder eine Marketingkampagne und 0:40:17.650,0:40:21.759 so weiter. Und dann könnte jede von ihnen unterschiedliche "Rot"-Parameter haben. Das 0:40:21.759,0:40:26.970 Problem ist, dass der Empfänger dann eine DNS-Abfrage ausführen, was das 2. Beispiel ist, 0:40:26.970,0:40:32.532 bei dem diese Kombination aus grün und rot verwendet wird. Und dann erhalten Sie den 0:40:32.532,0:40:36.993 öffentlichen Schlüssel und können diesen verwenden, um die Signatur zu überprüfen. 0:40:36.993,0:40:43.799 Das hört sich also wirklich gut an. Das Problem hier ist, dass es noch ein anderes Problem gibt. 0:40:43.799,0:40:48.730 Wie man löst man es? Ich denke, es ist einfach, wenn man die öffentliche Kryptographie. 0:40:48.730,0:40:52.440 versteht. Auf der Absenderseite müssen Sie zuerst ein öffentliches und ein privates 0:40:52.440,0:40:56.270 Schlüsselpaar generieren. Dann veröffentlichen Sie den öffentlichen Teil im DNS. Dann 0:40:56.270,0:41:00.480 verwenden Sie den privaten Schlüssel, um jede Nachricht zu signieren. Der Empfänger macht 0:41:00.480,0:41:04.380 jetzt sozusagen das Gegenteil. Sobald er die E-Mail erhalten hat, findet er anhand dieses roten 0:41:04.380,0:41:09.000 und grünen Teils den richtigen DNS-Eintrag heraus, führen ihn aus, erhalten den 0:41:09.000,0:41:12.526 öffentlichen Schlüssen und vergleichen dann, ob dieser öffentliche Schlüssel mit der Signatur 0:41:12.526,0:41:19.170 übereinstimmt. Das klingt doch ganz gut, oder? Was ist das Problem? Also wählt der Kunde den 0:41:19.170,0:41:27.309 Namen aus, Das Problem dabei ist, dass es mehrere Selektoren als DKIM sein können, 0:41:27.309,0:41:31.670 wenn Sie die Konfiguration durchführen. Sie können so viele Selektoren auswählen, wie Sie 0:41:31.670,0:41:37.170 wollen und der Empfänger weiß nicht, ob Sie tatsächlich einen Selektor hätten verwenden 0:41:37.170,0:41:41.599 sollen und welchen Selektor Sie hätten verwenden sollen. Das Problem liegt darin, dass 0:41:41.599,0:41:48.690 wenn wir nur über das normale DKIM sprechen, es für einen Penentrationstester oder einen 0:41:48.690,0:41:52.630 Angreifer schwierig ist, die vorhandene Signatur zu ändern. Aber es ist einfach, es zu entfernen. 0:41:52.630,0:41:57.619 Denn wenn man DKIM aus allen Kopfzeilen entfernt hat, weiß der Empfänger nicht, dass 0:41:57.619,0:42:03.550 sie da sein sollte, denn um das zu prüfen, müsste sie dort sein. Hier also zum Beispiel, 0:42:03.550,0:42:08.640 muss ich, statt die Signatur zu überprüfen, diesen grünen Teil kennen. Diese Domain- 0:42:08.640,0:42:14.712 Kennung und den Selektor, die Teil dieser Kopfzeile sind. Richtig. Das ist also ein großes 0:42:14.712,0:42:20.818 Problem. Und das bedeutet, dass wir, obwohl wir DKIM selbst nicht fälschen können, können 0:42:20.818,0:42:26.700 wir die DKIM einfach abschneiden und die Nachricht ohne sie senden. Und falls die DKIM 0:42:26.700,0:42:31.499 das Einzige wäre, das das System geschützt hat, würde es funktionieren. Es könnte also sein, 0:42:31.499,0:42:37.310 dass es kein grünes Häkchen oder was auch immer gibt, aber es wird beim Empfänger 0:42:37.310,0:42:43.040 ankommen. Eine andere Sache ist dieser Domain-Selektor. Warum müssen wir das 0:42:43.040,0:42:48.280 überhabt einstellen? Weil die beste Übung natürlich ist, dass der Umschlag-Absender 0:42:48.280,0:42:52.430 gleich der Kopfzeile und gleich diesem DKIM Domain-Sektor ist. Wenn Sie also von Alice 0:42:52.430,0:42:59.029 senden, dann sind alle drei Alice.org oder was auch immer. Das Problem ist, dass es im RFC 0:42:59.029,0:43:04.029 nicht erwähnt wird, dass dies der Fall sein sollte. Was also passiert genau, wenn es nicht 0:43:04.029,0:43:09.619 so ist? Zum Beispiel gibt es auf der rechten Seite eine echte Domain, die Gmail, Google 0:43:09.619,0:43:17.470 Mail, Google Suite verwendet hat. In diesem Fall signiert Google Suite standardmäßig alle 0:43:17.470,0:43:22.430 Nachrichten. Wenn Sie jedoch keine eigene Konfiguration vornehmen, wird sie signiert mit 0:43:22.430,0:43:28.369 der von ihm kontrollierten Domain "gappssmtp". Und das bedeutet, dass, obwohl 0:43:28.369,0:43:32.579 technisch gesehen etwas mit DKIM signiert wurde, es aber nicht so signiert wurde, dass 0:43:32.579,0:43:36.406 man es zu seiner Organisation zurückführen kann. Es ist etwas völlig anderes. Was genau 0:43:36.406,0:43:40.069 sollte der Empfänger in diesem Fall tun? Sollten Sie es einfach ignorieren? Sollten Sie die 0:43:40.069,0:43:43.859 Nachricht zurückweisen oder etwas ähnliches? Der richtige Weg wäre also, sie nicht 0:43:43.859,0:43:49.380 abzulehnen, sondern sie einfach als ungültig, zumindest nicht als gültige DKIM zu betrachten, 0:43:49.380,0:43:53.829 aber es kommt darauf an. Also werden einige Validierer, sobald sie irgendeine DKIM sehen, 0:43:53.829,0:44:01.228 diese validieren und sagen, das ist cool, das entspricht dem RFC. Aber nun kommt der 0:44:01.228,0:44:06.710 interessante Teil. Ändern von DKIM, wofür ich keine Zeit habe. Aber die Idee ist, dass dies in 0:44:06.710,0:44:11.339 manchen, nicht in allen Fällen so ist, aber manchmal kann man es tatsächlich ändern. 0:44:11.339,0:44:17.190 Der am einfachsten zu ändernde Teil in den Nachrichten sind die Kopfzeilen. Weil DKIM, 0:44:17.190,0:44:21.304 da es in den Kopfzeilen selbst platziert ist, nicht automatisch alte Kopfzeilen signiert. Das ist wie 0:44:21.304,0:44:26.170 das Henne-Ei-Problem. Es werden standardmäßig nur 1 oder 2 Kopfzeilen signiert 0:44:26.170,0:44:30.910 und Sie können weitere Kopfzeilen angeben, die signiert werden sollen, aber das passiert nicht 0:44:30.910,0:44:35.569 automatisch. Für den Angreifer ist es eine einfache Sache, eine andere Kopfzeile 0:44:35.569,0:44:40.400 hinzuzufügen. Wenn das Ihrem Plan in irgendeiner Weise hilft, dann ist das einfach 0:44:40.400,0:44:43.940 zu machen. Sie fügen einfach eine weitere Kopfzeile hinzu. Ein interessante Teil ist, obwohl 0:44:43.940,0:44:49.180 obwohl RFC, ist, wie ich vorhin erwähnt habe, dass einige Kopfzeilen wie "Gegenstand" oder 0:44:49.180,0:44:53.093 "Von", nur in einer Kopie vorhanden sein sollten. Aktuell könnte man mehr, als eine 0:44:53.093,0:44:59.367 "Von" Kopfzeile hinzufügen. Was in diesem Fall passiert ist ziemlich interessant. DKIM wird 0:44:59.367,0:45:04.150 einverstanden sein, wenn Sie DKIM mitteilen, dass die Kopfzeile "Von" beispielsweise signiert 0:45:04.150,0:45:11.279 werden soll. Dann wird es übereinstimmen und signiert die erste "Von" Kopfzeile von unten. 0:45:11.279,0:45:16.807 Aber ziemlich viele Software E-Mail Kunden in einer Software werden dem Benutzer eigentlich 0:45:16.807,0:45:23.940 nur zuerst von der anderen Seite, der oberen Seite angezeigt. Das bedeutet also, dass der 0:45:23.940,0:45:29.546 Angreifer die Kopfzeilen verfälschen oder überschreiben kann, indem er einfach neue 0:45:29.546,0:45:33.089 Kopfzeilen hinzufügt. Und dieses eigentliche Problem wird im DKIM RFC erwähnt und der 0:45:33.089,0:45:38.885 Schutz, den sie vorschlagen ist dieser Code Over-Signing, damit Sie den RFC lesen können. 0:45:38.885,0:45:44.919 Aber nicht jeder macht das tatsächlich. Und wie auch immer, gilt das nur für die Kopfzeilen. 0:45:44.919,0:45:49.499 Manchmal ist das also gut. Manchmal ist das nicht gut. Ändern des Nachrichtentextes ist 0:45:49.499,0:45:54.069 tatsächlich viel schwieriger. Im Grunde genommen ist die naive Art es zu tun durch 0:45:54.069,0:45:58.140 Kryptographie, was wir aber nicht tun wollen. Und ein anderer Weg führt über diesen 0:45:58.140,0:46:05.118 Parameter, der die Textkörperlänge angibt und das ist eigentlich wie fragwürdig die 0:46:05.118,0:46:08.789 Funktionalität ist, die DKIM hat. Manchmal kann man festlegen, dass der Hash für Signierung- 0:46:08.789,0:46:13.790 zwecke verwendet werden soll. Wir sollten nicht den ganzen Körper betrachten, sondern nur die 0:46:13.790,0:46:18.866 ersten Bytes. Das ist in einigen Fällen bei Mailinglisten tatsächlich nützlich, aber in den 0:46:18.866,0:46:24.500 meisten Fällen nicht nützlich. Die meisten E-Mail-Programme tun dies in der Praxis nicht. 0:46:24.500,0:46:28.869 Falls sie es tun, besteht die Gefahr, dass der Textkörper möglicherweise überschrieben wird. 0:46:28.869,0:46:34.245 Sie können einen anderen Mime-Typ hinzufügen und dann die Kopfzeilen ändern, 0:46:34.245,0:46:37.569 um zu zeigen, dass dieser andere Mime-Typ DKIM passieren wird. In diesem Fall wird zum 0:46:37.569,0:46:42.634 Beispiel der grüne Button oder was auch immer angezeigt, weil DKIM gültig sein wird. Nun gibt 0:46:42.634,0:46:47.640 es also die 3. Technologie, die DMARC genannt wird. Und auch hier steht der vollständige 0:46:47.640,0:46:52.424 Name, der lang ist, aber in diesem Fall tatsächlich etwas bedeutet. Es gibt 2 Schlüssel- 0:46:52.424,0:46:56.660 wörter: Berichterstattung und Konformität. Berichterstattung ist das Wort, mit dem die 0:46:56.660,0:47:01.619 meisten Administratoren vertraut sind, denn das ist es, was DMARC meiner Meinung oft an 0:47:01.619,0:47:08.390 sie verkauft. Berichterstattung bedeutet, dass man bei Problemen in diesem Fall, der anderen 0:47:08.390,0:47:13.309 Seite sagen kann, was in diesem Fall zu tun ist. Grundsätzlich sagen Sie Ihnen, dass Sie Ihnen 0:47:13.309,0:47:16.886 entweder einmal am Tag oder jedes Mal Berichte senden sollen. Für Penetrationstester 0:47:16.886,0:47:20.509 ist das nicht sehr nützlich. Möglicherweise könnten wir verwenden, um zu verstehen, 0:47:20.509,0:47:25.000 welche Art von Konfiguration auf der anderen Seite läuft. Aber im Moment ist diese Funktion 0:47:25.000,0:47:30.309 noch nicht so weit verbreitet. Aber der andere Teil, die Konformität, ist wirklich sehr, sehr 0:47:30.309,0:47:35.251 leistungsstark. Es korrigiert die großem Fehler, die ich in SPF und DKIM erwähnt habe. DKIM 0:47:35.251,0:47:39.381 hatte dieses massive Problem, dass wenn man einfach die Kopfzeilen entfernt, dann hat der 0:47:39.381,0:47:43.109 Empfänger keine Möglichkeit zu wissen, ob DKIM an erster Stelle stehen sollte. Wenn Sie 0:47:43.109,0:47:49.377 DKIM zusammen mit DMARC verwenden, ist das Problem behoben, denn DMARC gibt nur 0:47:49.377,0:47:55.269 an, dass Sie DMARC selbst haben. Das bedeutet, dass Sie automatisch mindestens 0:47:55.269,0:47:59.220 eines von SPF oder DKIM passieren sollte. Also hat DKIM als Maßnahme das Problem 0:47:59.220,0:48:03.576 automatisch gelöst. Die andere Sache, die sich ändert, ist die Änderung Semantik für SPF. 0:48:03.576,0:48:08.599 Falls Sie nun beide, SPF und DMARC haben, könnte SPF gegen die "Von" Kopfzeile sein. 0:48:08.599,0:48:13.150 Wie ich schon anmerkte, war das die größte Schwachstelle von SPF, denn wenn Sie selbst 0:48:13.150,0:48:17.319 SPF selbst verwenden, war es sogar der Hard-to-Fail-Modus usw. Das bedeutet, dass 0:48:17.319,0:48:21.440 Angreifer die "Von" Kopfzeilen immer noch modifizieren können und der Empfänger wird 0:48:21.442,0:48:26.710 es nicht besser wissen. Ein minimales Beispiel für DMARC ist also wirklich sehr, sehr klein. 0:48:26.710,0:48:31.210 Und ich denke, es ist einfach zu verstehen. Sie haben gerade eine DMARC Ablehnung. Sie müssen 0:48:31.210,0:48:36.890 die richtige Stelle für die Angabe herausfinden. Aber es ist einfach und alles, was Sie tun müssen, ist 0:48:36.890,0:48:40.740 diesen einen DNS-Eintrag zu erstellen. Und der Vorteil davon bestseht darin, wenn Sie DKIM 0:48:40.740,0:48:46.190 und DMARC nicht haben, wenn Sie es erstellt haben. Sorry, falls Sie DKIM nicht haben, aber Sie 0:48:46.190,0:48:50.680 haben DMARC erstellt. Das bedeutet, dass diese Domain keine E-Mails senden soll. 0:48:50.680,0:48:57.550 Denn der Empfänger sieht eine E-Mail als gültig an, sollte mindestens SPF oder DKIM gültig 0:48:57.550,0:49:02.279 sein. Wenn dies nicht der Fall ist, können sie nicht gültig sein. Das bedeutet also, dass die 0:49:02.279,0:49:07.480 meisten Domains da draußen darüber nachdenken sollten, die DMARC zu aktivieren. 0:49:07.480,0:49:15.471 Das ist genau das Richtige. OK. Es gibt noch mehr Stichworte. Die DMARC-Datensätze könnten viel 0:49:15.471,0:49:22.019 länger sein, aber es ist für die Penetratrionstester nicht von großem Nutzen. 0:49:22.019,0:49:26.009 So, ein wichtiger Teil hier ist wieder die Richtlinie, die diese drei Werte annehmen kann: 0:49:26.009,0:49:31.184 "keine", "Quarantäne" und "Ablehnung".Und wenn es "Quarantäne" ist, bedeutet das, 0:49:31.184,0:49:39.109 dass die Nachricht im Falle eines Fehlers, im Spam-Ordner landen sollte. 0:49:39.109,0:49:42.619 Wenn es "Ablehnung" ist, sollte sie direkt abgewiesen werden. Und wenn es "keine" ist, bedeutet es, 0:49:42.619,0:49:47.960 dass sie sich im Test-Modus befindet. Und das ist das Bild, das ich vorher gezeigt habe. 0:49:47.960,0:49:52.400 Es zeigt dass, obwohl DMARC die wirklich beste Technologie unter diesen 3 Technologien ist. 0:49:52.400,0:49:59.655 Sie ist nicht wirklich weit verbreitet. Unglücklicherweise für die Befürworter. 0:49:59.655,0:50:05.070 Eine ganz nette Tasche für alle Penetrationstester da draußen. Das bedeutet, dass man 0:50:05.070,0:50:14.550 tatsächlich die meisten E-Mails da draußen fälschen kann. Okay. Wie können wir das umgehen? 0:50:14.550,0:50:18.480 Was passiert, wenn jemand DMARC implementiert hat? Können Penetrationstester nun nichts tun? 0:50:18.480,0:50:23.526 nichts tun? Sie müssen nicht einmal Nachforschungen anstellen? 0:50:23.526,0:50:29.039 Nein, das ist nicht nötig. Also in der Praxis, wenn jemand sowohl DKIM als auch DMARC 0:50:29.039,0:50:33.859 implementiert hat, aber nicht SPF, also hat er nur zwei davon. Das ist wirklich eine coole Kombination. 0:50:33.859,0:50:38.470 DKIM ist sehr leistungsstark und DMARC behebt den Mangel. Das ist cool in der Theorie. 0:50:38.470,0:50:44.680 In der Praxis besteht das Problem darin, statt ihre eigenen E-Mails zu schützen, sollte die 0:50:44.680,0:50:49.751 Empfängerseite sowohl DKIM, als DMARC validieren. Unglücklicherweise tut dies eine 0:50:49.751,0:50:53.932 ganze Menge von Software immer noch nicht Eine solche Software ist Microsoft Exchange. 0:50:53.932,0:50:57.920 Und selbst wenn Sie nicht mit Microsoft Exchange arbeiten, stehen die Chancen gut, dass 0:50:57.920,0:51:02.049 einige der Partner, mit denen Sie kommunizieren, Microsoft Exchange ausführen. 0:51:02.049,0:51:05.700 Und standardmäßig gibt es keine Funktion zu DKIM. 0:51:05.700,0:51:12.619 Die meisten Systeme müssen tatsächlich SPF immer noch aus praktischen Gründen aktivieren. 0:51:12.619,0:51:16.609 Das ist gut für Penetrationstester. Wenn SPF und DMARC standardmäßig zusammen 0:51:16.609,0:51:21.502 aktiviert sind, dann behebt das wiederum eines der Hauptprobleme mit SPF, aber 0:51:21.502,0:51:25.864 es behebt nicht automatisch andere Probleme, weil nicht genug Potential für Fehlkonfigurationen 0:51:25.864,0:51:32.119 da ist. So. Und die interessante Tatsache ist, dass DMARC nur fordert, dass eine der anderen 0:51:32.119,0:51:37.970 Technologien SPF oderDKIM mitgegeben wird, um die E-Mail als gültig zu sehen. 0:51:37.970,0:51:42.749 Es gibt in DMARC keine Möglichkeit anzugeben, dass beide gültig sein sollen, oder dass DKIM 0:51:42.749,0:51:45.680 dem SPF vorgezogen werden soll, obwohl es viele andere Sektoren gibt. 0:51:45.680,0:51:50.019 In der Praxis bedeutet dies, dass die meisten Systeme alle drei aktivieren, 0:51:50.019,0:51:54.950 was eine gute praktische Lösung von Seiten der Penetrationstester ist. 0:51:54.950,0:51:59.849 Wir ignorieren DKIM komplett und konzentrieren uns nur auf SPF, was das schwächste Glied in 0:51:59.849,0:52:05.170 dieser Situation ist. Okay. Also nur eine Minute für Rekapitulation. 0:52:05.170,0:52:11.559 Ich bin nicht sicher, ob ich noch mehr Zeit habe. Viel Zeit habe ich nicht. Okay. 0:52:11.559,0:52:17.140 Okay. Entschuldigung. Yeah. Ein wirklich wichtiger Hinweis ist, wenn man die Systeme testet, 0:52:17.140,0:52:22.270 dass beide Szenarien berücksichtigt werden sollen. Konzentrieren Sie sich also nicht 0:52:22.270,0:52:27.599 nicht nur auf das Senden. Wenn es um das Testen von Alice geht, ist Alice die Organisation, die Ihr 0:52:27.599,0:52:33.569 Kunde ist. Konzentrieren Sie sich nicht nur auf das Testen von E-Mails, die als Alice versendet 0:52:33.569,0:52:38.670 werden, sondern auch auf die andere Seite. Denn es ist einfach, z.B. SPF und DMARC zu 0:52:38.670,0:52:43.961 implementieren, denn für beide brauchen Sie nur eine DNS-Konfiguration. Gerade eine für 0:52:43.961,0:52:48.779 jede. Aber sie zu testen, sie richtig zu validieren ist schwieriger. 0:52:48.779,0:52:52.643 Zunächst benötigen Sie die Software-Unterstützung, die man richtig konfigurieren muss. 0:52:52.643,0:52:56.585 In der Praxis könnte es sein, dass viele Organisationen, die DMARC oder SPF auf der 0:52:56.585,0:53:01.500 DNS-Seite für ausgehende E-Mailsaktiviert haben, es nicht richtig validieren. 0:53:01.500,0:53:07.960 Yeah Okay. Sorry ich habe keine Zeit dafür. 0:53:07.960,0:53:16.009 Das wars. Sorry. Vielleicht einige Fragen. 0:53:16.009,0:53:24.601 Applaus 0:53:24.601,0:53:29.719 Herald: Danke Andrew für diesen schönen Vortrag. Natürlich haben wir Zeit für ein paar Fragen. 0:53:29.719,0:53:33.839 Ich sehe schon eine Person. Mikrophon Nr.2 0:53:33.839,0:53:40.150 M2: Hey, vielen Dank. Kennen Sie einige gute Tools zur Überwachung von DMARC- 0:53:40.150,0:53:44.339 Berichten, die ich von meinen Empfängern bekommen habe? A: Yeah. Das ist eine wirklich gute 0:53:44.339,0:53:49.940 Frage. Wir als CERT empfehlen jedem, dies zu aktivieren. Aber leider sammeln alle Tools, die im 0:53:49.940,0:53:55.190 Internet verbreitet sind, einige Daten über Sie. 0:53:55.190,0:53:59.670 Sie verwenden diese für Marketingzwecke. 0:53:59.670,0:54:04.412 Das ist nicht gut für Ihre Privatsphäre. 0:54:04.412,0:54:07.880 Wenn Sie darüber besorgt sind, müssen Sie selbst etwas implementieren oder 0:54:07.880,0:54:12.180 Sie müssen vielleicht ein Open-Source-Projekt starten. Herald: OK, Mikrophone Nr. 1 0:54:12.180,0:54:16.428 M1: Danke für das gute Gespräch. Ich würde mich selbst als Administrator bezeichnen. 0:54:16.428,0:54:23.609 Mir wird geraten, den SPF-Eintrag zu kürzen, denn wenn er zu lang ist, wird er gelöscht. 0:54:23.609,0:54:28.859 Daher bekomme ich den Rat, den PTR-Eintrag zu löschen. 0:54:28.859,0:54:34.930 Aber in Ihrem Vortrag sagen Sie, dass er für Revers-DNS-Überprüfung nützlich ist, 0:54:34.930,0:54:39.549 was ich auch auch für nützlich halte. 0:54:39.549,0:54:42.920 Wie stehen Sie zu Verkürzung Ihres SPF und zum PTR-Datensatz im Allgemeinen? 0:54:42.920,0:54:47.530 A. Das hängt vom jeweiligen Anwendungsfall ab. Es kann sein, dass einige 0:54:47.530,0:54:51.230 Organisationen tatsächlich diesen langen SPF benötigen und daran 0:54:51.230,0:54:55.799 führt kein Weg vorbei. Was Sie tun können, ist, dieses Include einzuschließen. Verwenden Sie 0:54:55.799,0:55:01.479 Includes, da diese nicht vorhanden sind. Sie sind keine Macros, sie werden nicht erweitert. 0:55:01.479,0:55:07.755 Überlegen Sie, ob Sie wirklich so viele Datensätze brauchen, die so lang sind. 0:55:07.755,0:55:12.119 Häufige Probleme darin, sofern Sie nicht Google oder etwas Ähnliches verwenden, 0:55:12.119,0:55:16.970 benötigen Sie einen so langen SPF nicht wirklich. 0:55:16.970,0:55:20.499 Es ist wahrscheinlich ein Problem mit einigen. 0:55:20.499,0:55:26.660 Ja genau. Es ist wahrscheinlich ein Fehler bei den meisten Organisationen. 0:55:26.660,0:55:36.489 Herald: OK. Nun, sehr. Nur ganz kurz. 0:55:36.489,0:55:40.496 Nummer 1. M1: Aber auf der PTI-Rocker-Platte habe ich gehört, dass es mich dramatisch unter 0:55:40.496,0:55:43.489 den Standards gelandet ist. Aber sie ist nicht in den Standards enthalten . 0:55:43.489,0:55:48.859 A: Er ist im Standard. Nein. Der PTR-Eintrag selbst ist, wenn es wirklich Ihr Anwendungsfall ist. 0:55:48.859,0:55:53.599 Ich bin mir nicht bewusst, dass er automatisch irgendwo abgelegt wird. Müsste kein Problem sein. 0:55:53.599,0:55:56.380 Herald: Wir haben ein Menge weiterer Fragen hier. 0:55:56.380,0:55:59.349 Nummer 6, ganz, ganz hinten. 0:55:59.349,0:56:07.420 M6: Danke für Ihren Vortrag. Das hängt zwar nicht direkt damit zusammen, aber es könnt. 0:56:07.420,0:56:13.800 Falls der Mailserver DKIM, DKARC und SPF akzeptiert, ist alles in Ordnung. Aber vor allem bei 0:56:13.800,0:56:18.779 Google wird die E-Mail bei vielen Organisationen zugestellt, aber als Spam eingestuft. 0:56:18.779,0:56:24.089 Das bedeutet, dass Sie im Posteingang des Empfängers nicht angezeigt wird. 0:56:24.089,0:56:28.069 Haben Sie eine Lösung, um diese Problem gegen Google zu lösen? 0:56:28.069,0:56:33.630 A. Ja, Ok. Also, ich habe verschiedene Meinungen darüber, denn eine Sache, die tatsächlich 0:56:33.630,0:56:38.787 ermöglicht, was wir eigentlich tun sollten, ist, dass Sie so streng sind. Vielen Dank Google. 0:56:38.787,0:56:42.859 Denn das ist der einzige Grund, warum wir überhaupt einen hohen Prozentsatz 0:56:42.859,0:56:47.879 von SPF haben, der selbst falsch konfiguriert ist. Der einzige Grund, warum 70% Webseiten SPF 0:56:47.879,0:56:52.829 verwenden, ist, dass sie mit Google kommunizieren müssen. Und Google wird Ihre E-Mail 0:56:52.829,0:56:56.690 nicht akzeptieren, wenn SPF nicht auf der Grundlinie ist. So. 0:56:56.690,0:57:04.269 Eigentlich macht mir der Job, den ich mache, Spaß. Ich würde es vorziehen, dass Google das tut, 0:57:04.269,0:57:09.527 was es sagt, Ich verstehe die echten Administratoren, die dieses Problem haben. Google hat das 0:57:09.527,0:57:15.239 Werkzeug. Sie kenne es wahrscheinlich. Hier können Sie überprüfen, was es über Ihre 0:57:15.239,0:57:19.323 Domain denkt. Sie müssen dieses Problem also von Fall zu Fall prüfen. 0:57:19.323,0:57:23.559 Oftmals kommt es vor, dass es trotz DKIM,DMARC etc. nicht richtig konfiguriert ist. 0:57:23.559,0:57:28.576 Also ist es das, was es ist. Darum ging es im Vortrag. Sie haben es. und sie denken vielleicht, dass Sie 0:57:28.576,0:57:31.259 es richtig konfiguriert haben, aber es bist einige Fehler. 0:57:31.259,0:57:35.249 Herald: Okay. Geben wir dem Internet den Vorrang. 0:57:35.249,0:57:40.170 Signal Angel: Wir haben eine Frage aus dem Internet. Wenn wir versuchen, eine Adresse zu 0:57:40.170,0:57:43.819 überprüfen, wie wird mit E-Mail-Adressen ohne Antwort umgegangen. 0:57:43.819,0:57:49.999 A. Keine Antwort, Es tut mir leid. Können Sie es bitte noch einmal vorlesen? 0:57:49.999,0:57:55.170 Signal Angel: Wenn ich versuche, eine E-Mail Adresse zu überprüfen, wie geht man 0:57:55.170,0:58:04.529 dann mit No-reply-E-Mails um? A: Vielleicht ging es um die No-reply Kopfzeile? 0:58:04.529,0:58:10.650 Oder nicht vorhandene IP-Adressen? Signal Angel: Wie geht man mit E-Mails um? 0:58:10.650,0:58:14.809 No-reply-E-mail-Adressen. A: Ich werde versuchen, eine Antwort darauf zu geben, wie ich es 0:58:14.809,0:58:21.532 verstehe. Was also oft passiert ist, dass die E-Mail von nicht existierenden Adressen 0:58:21.532,0:58:25.294 gesendet wird. Das war vielleicht die Frage. Die Beispielfrage "keine Antwort" 0:58:25.294,0:58:29.789 ist nicht das Problem selbst. Keine Antwort. Das Problem ist, dass es sich nicht um eine echte 0:58:29.789,0:58:34.339 Adresse handelt. Es gibt keine solche Adresse. Richtig. Und deshalb habe ich keine Antwort 0:58:34.339,0:58:38.816 darauf. Denn laut RFC sollten Sie es praktisch trotzdem akzeptieren. 0:58:38.816,0:58:43.627 Ich sagte bereits, dass viele Mailsysteme diese Adressen bereits löschen, wenn sie von 0:58:43.627,0:58:46.420 nicht vorhandenen Adressen senden. Es sei denn, Sie sind Google oder etwas Großes. 0:58:46.420,0:58:50.150 Dann werden Sie auf die weiße Liste gesetzt. Sie können es einfach nicht tun. 0:58:50.150,0:58:54.779 Sie können keine E-Mails von einer nicht existierenden Adresse senden. Falls Sie in einer 0:58:54.779,0:59:00.309 erartigen Situation sind, erstellen Sie die Adresse entfernen Sie alle E-Mails, die dort eintreffen, aber 0:59:00.309,0:59:03.640 erstellen Sie die echte Adresse, damit Sie akzeptabel sind, wenn Sie auf der anderen Seite sind, 0:59:03.640,0:59:08.269 und diese E-Mail erhalten. Das hängt von diesem speziellen Anwendungsfall ab. 0:59:08.269,0:59:12.099 Überprüfen Sie also einfach, was los ist. Wenn Sie sie kontaktieren können, kontaktieren Sie sie. 0:59:12.099,0:59:16.220 Wenn Sie sie nicht kontaktieren, dann sollten Sie entscheiden, welches Risiko besteht, wenn Sie 0:59:16.220,0:59:23.920 dieselben Adressen weglassen. Sind sie wichtig für Sie? Laut RFC sollten Sie diese Adressen 0:59:23.920,0:59:28.660 also erhalten und verarbeiten. Herald: Okay. Mikrophon Nummer 4 bitte. 0:59:28.660,0:59:33.040 M4: Hey, danke für diesen Vortrag. Kennen Sie die Bemühungen, Probleme mit großen 0:59:33.040,0:59:40.630 E-mail-Versendern wie Online- Buchhändlern zu lösen, die sehr groß sind, weil sie anscheinend 0:59:40.630,0:59:47.450 keine eigenen SPF-Datensätze haben, zum Beispiel in der Kontrolle? 0:59:47.450,0:59:53.253 A: Ja. In vielen Fällen kann man einfach mit ihnen Kontakt aufnehmen. 0:59:53.253,0:59:56.711 Die Frage, ob sie nicht darüber nachgedacht haben oder ob ihnen vielleicht niemand gesagt hat, was 0:59:56.711,1:00:01.770 sie tun sollen oder vielleicht wissen sie nicht, wie sie es besser machen sollen. Das stimmt. 1:00:01.770,1:00:05.249 Das ist also eine der Sachen, die wir als CERT tun. Falls Sie dieses Problem mit einem großen 1:00:05.249,1:00:10.619 Unternehmen in einem bestimmten Land haben, schlage ich vor, das CERT zu kontaktieren. 1:00:10.619,1:00:14.470 Auch wenn es sich nicht um eine Regierungsorganisation handelt, zum Beispiel in Lettland, wenn es 1:00:14.470,1:00:18.700 sich um ein lettisches Unternehmen handelt. Wir würden die Trage vornehmen. 1:00:18.700,1:00:21.892 Wir würden versuchen mit ihnen zu reden, ihnen zu erklären, warum sie sich ändern müssen 1:00:21.892,1:00:26.289 und so weiter. Das ist vielleicht eine Möglichkeit für sie. Aber in der Praxis gilt: Wenn etwas für Sie 1:00:26.289,1:00:30.060 als Dritte als falsche Konfiguration erscheint, kann ich das in diesem Vortrag nicht erwähnen. 1:00:30.060,1:00:34.400 Wenn etwas nicht perfekt ist, heißt das nicht, dass es falsch ist. 1:00:34.400,1:00:39.460 Es könnte tatsächlich einen geschäftlichen Grund dafür geben. Richtig. Es ist zum Beispiel so, 1:00:39.460,1:00:42.229 wenn es sich um ein großes, ich weiß nicht, Amazon oder etwas in der Art handelt, und wenn sie es 1:00:42.229,1:00:46.700 getestet haben und wissen, dass sie, wenn sie eine sehr strenge Konfiguration haben, dass dann 1:00:46.700,1:00:51.697 ein gewisser Prozentsatz ihrer E-Mails einfach nicht ankommen. Nicht wegen ihrer Problems, 1:00:51.697,1:00:55.762 sofern wegen des Problems von jemand anderem. Richtig. 1:00:55.762,1:00:59.759 Aber dann gibt es tatsächlich einen echten Geschäftsfall, dass sie das nicht tun. 1:00:59.759,1:01:04.489 Es wäre dumm, wenn sie diese strikte Konfiguration ermöglichen würden, weil sie wissen, dass es 1:01:04.489,1:01:08.970 ihrem Geschäft schadet. Das macht Sinn, oder? 1:01:08.970,1:01:13.479 Herald: Okay. Leider läuft die Zeit für diejenigen aus, die an den Mikrofonen sitzen. Bitte stellen Sie 1:01:13.479,1:01:17.755 sich einfach bei dem Sprecher neben dem Pult auf. Er wird ganz sicher mit Ihnen sprechen. 1:01:17.755,1:01:21.195 Applaus