 Habt ihr euch jemals gefragt, wie man perfekt eine E-Mail fälschen kann, dann seid ihr hier im richtigen Vortrag. Der nächste vortragende Andrew arbeitet gerade für das nationale Security Research in Letzland. Er ist ein Security-Forscher und spricht Research über Anti-Spoothing. So, und die Bühne ist jetzt da eine. Hallo, ich bin Andrew. Er arbeitet für Letzlands nationale Zeit. Es geht mir insbesondere darum, E-Mail-Security in unserem Land zu verbessern. Wir arbeiten viel um das Bewusstsein für diese Probleme zu verbessern. Und wir sind natürlich nicht die einzige Organisation, die das tut. Es gibt viele solche Institutionen in verschiedenen Ländern, viele Regierungsorganisationen und Nichtregierungsorganisationen, die das tun und kommerzielle und nicht kommerzielle. Aber für unseren kollektiven Fortschritt war er sehr, sehr niedrig. Hier gibt es etwa diese Statistik, wo wir eine spezifische Technologie ansehen, ob die adoptiert worden ist, nämlich DMARC. Dann seht ihr, das ist bei 20.000 Domänen über die Welt für wichtige Domänen, wichtige Organisationen, die es wirklich besser wissen sollten. Unter anderem die Top 500 EU Retailer Domains, Verkauferdomänen, benutzen ungefähr 12 kein DMARC und die dies aktiviert haben, die 80% haben das ohne Policies eingerichtet. Aber jeder sollte mindestens DMARC benutzen. Ja, das ist ein wichtiger Filter für Domänen, die diese Mails nicht schicken sollten. Eine Erklärung für diese Nichtregierungsrate ist, soweit ich denke, dass es scheinbar viele Technologien im Wettbewerb miteinander gibt. Und ich habe wirklich viel getan, um meinen Foto herunter zu kürzen. Aber ihr seht, bis auf SMTP 3 Abkürzungen erinnere ich, wo in Abkürzungen nicht mal den Vorständigen nahm. Das Problem ist, es gibt so viele Buzzwords, so viele Technologien und es ist nicht klar, welche davon wir nutzen sollten. Das ist nicht unbedingt ein spezifisches Problem für E-Mail, das haben wir in der sämtlichen Securityindustrie in das Problem. Und da haben wir einen Weg, um solche Fragen zu beantworten, das ist Penetration Testing. Wenn Penetration Test ordentlich ausgeführt wurde und die Resultate veröffentlicht wurden, können wir das Gespräch verschieben von WIRT A oder B als Technologie bevorzugt. Stattdessen zu der Frage, ist es für eine dritte Partei möglich, unsere Mails zu fälschen, um etwa an Kundinnen zu schreiben, an Medienorganisationen zu schreiben, so dass die der Meinung sind, dass die Mail tatsächlich von diesen Organisationen kommt. Also sind Penetration Test hier tatsächlich die Schlüssel zu hören. Also Leute aus den roten Tipps. Ich nehme an, ihr wisst schon alle Basics über Mail-Technologie. Und wenn man die Probleme jetzt aber nochmal aus der Perspektive der AngreiferInnen anseht, das kann sehr bereichernd sein. Das sollte sehr hilfreich dafür sein, um zu verstehen, auf was ihr euch fokussieren solltet. Und letztlich das SMTP-Protokoll, was als Technologie darunter läuft, um es es relativ einfach zu verstehen und die Direktionen, die man daraus lernen kann. Und von dieser ganzen Reise, wie SMTP entstanden ist, wie es möglich ist, das Spoofing und die sämtlichen Technologien, die das versuchen zu vermeiden, da ist es eine interessante Falschstudie, das sollte interessant auch für Leute sein, die Email-Technologie noch nicht gut verstehen. Die Landschaft davon, so Email-Security ist ein breites Thema. Und wir können uns heute nur mal einen kleinen Teil davon, nämlich erfolgreiche Emails zu fälschen. Ich kenne viele Pen-Tester in Unternehmen, die Fishing emulieren in ihrem Arbeit. Aber soweit ich weiß, tun Sie es jetzt primär als Social-Engineer mit einem Toolkit für Social-Engineering. Ich möchte nicht darüber streiten, ob das wichtig ist oder nicht, etwa Kunden zu demonstrieren, was das Problem und das Risiko ist. Aber ich glaube, ihr werdet den Kunden nicht gerecht, wenn das das Einzige ist, was sie tut, um Security zu testen. Denn für die Managerinnen, die No-Reports lesen, über Social-Engineering-Attacken lesen, ist die logische Schiffsvergerung, die das Personal und die Kunden auszubilden. Und wir sehen, es gibt viele Attacken, die überhaupt nicht durch Nutzer-Innen-Bildung zu vermeiden sind. Wir müssen halt unsere Email-Infrastruktur verbessern, deshalb gibt es keinen Weg drumherum. Und bevor wir uns wirklich in die Technik bewegen, gibt es ein kleines, schlecht verborgenes Geheimnis, um zu verstehen, warum wir so viele Probleme damit haben. Nämlich für E-Mail-Administratorinnen ist es historisch wichtiger, dass das System verlässlich und zugänglich ist, und zwar viel mehr als dessen Sicherheit. Das ist eher eine ideologische Entscheidung, etwa wenn man eine E-Mail-Administratorin ist in so einer Organisation, und manche, der kommt in dann keine Rechnungen mehr kriegen, dann wird das Management natürlich darüber schimpfen und sehr freundlich fragen, dass ihr das repariert. Und es könnte aber sein, dass das Problem gar nicht an deinem Ende ist, sondern auf dem anderen Ende. Oder etwa, wenn manche der Angestellten keine Mails empfangen können und schnell genug empfangen können, um Passwörter wiederherzustellen, oder für zwei Faktor-Authentifizierungs-Torgens, und die können sich nicht einloggen in wichtige Systeme, dann musst du schnell dafür eine Lösung finden. Aber wenn das E-Mail-System ein Sicherheitsproblem hat, etwa für Spoofing-Attacken verlässlich ist und sofort, dann werden weder ihr Nutzer enden noch das Management, das zu Kenntnis nehmen, obwohl diese Verletzlichkeit da ist. Und deswegen brauchen wir Pen-Teste. Jetzt können wir jetzt endlich anfangen, über die technischen Details zu reden. Wir fangen mit einer kurzen Intro in das SMTP-Protokoll an. SMTP ist das Protokoll, das unter allen E-Mail-Kommunikationen liegt. Das ist eigentlich leicht zu verfolgen. Hier ist zum Beispiel der Datenfluss, wenn eine Person, eine andere Person eine E-Mail schickt. Zum Beispiel schickt Alice, Bob eine E-Mail. Sie arbeiten für verschiedene Firmen, haben verschiedene Domain. Und was hier passiert ist, dass sie beide E-Mail-Klines nutzen, zum Beispiel Outlook oder Thunderbird, und Alice beim Senden durch das Protokoll SMTP geht. Und dann geht die E-Mail durch den Mail-Server von Alice und der ist Outgoing. Normalerweise haben Organisationen ein Outgoing und ein incoming E-Mail-Server für Ausgehende und Einkommende E-Mails. Für Penetration-Testers ist es wichtig, an diese beiden Systeme zu denken. Auch wenn es physisch eine Maschine ist, hat sie wahrscheinlich zwei verschiedene Konfigurationen für beide. Nun, wenn Alice, also der Server von Alice, eine E-Mail an Bob-Server schickt, dann gibt es ein Problem, dass der Server automatisch herausfinden muss, welcher der richtige Server ist, um diese E-Mail zu senden. Durch diese blaue Box, das Mx-Record im DNS, wird das Ganze realisiert. Das wird von Bob's Organisation verwaltet. Wenn also Bob's Organisation E-Mails empfangen will, dann entstellen sie im DNS das Mx-Record. Und da steht dann drin, wenn ihr uns eine E-Mail senden wollt, dann verwendet diesen Server. Da gibt es also ein Pointer auf Bob's Server. Daher kennt Alice das Server, Alice das Ausgehendserver, den eingehenden Server von Bob. Der Teil, den wir als Pentester versuchen anzugreifen, ist halt diese Brücke zwischen den Servern. Dann gibt es noch das zweite Beispiel in Gegenrichtung. Das ist vielleicht für euch überflüssig, weil wir jetzt einfach nur die Richtung umdrehen. Aber der wichtige Teil hier ist, dass wir als Pentester verstehen, dass unser Klein nur einen Teil dieser Transaktion kontrolliert. Wenn unser Klein zum Beispiel für den Rest unserer Präsentation Alice ist, Alice ist Organisation, dann ist im zweiten Beispiel, wenn wir von Bob's die E-Mail zu Alice senden, dann schicken wir E-Mails nur, hier im linken Teil wird der Teil der Transaktion durch Alice das Service gehen. Und im ersten Fall ist es nicht so, da ist es auf der rechten Seite. Wenn es ein bisschen verwirrend ist, ist okay, wir gehen noch mal, kommen noch mal drauf zurück. Letztendlich gibt es ein drittes Beispiel, das wir, das ähnlich aussieht, aber auch nicht ganz. Zum Beispiel wenn Alice mit ihrem Arbeitskollegen kommuniziert, die gleiche Konfiguration. Und in dem Beispiel gibt es auch wieder logisch zwei verschiedene E-Mails, einer für Ausgehen und einer für Ingehen, die E-Mails. Aber beide gehören halt der Seite von Alice' Organisation vom Kunden. Also ist es wichtig, dass man dran denkt, welches der Szenarien einfacher zu beschützen ist. Wir sehen später, wie das geschieht. Dann haben wir hier einen Blick auf, was eigentlich gesendet wird, wenn eine E-Mail gesendet wird, da wird S&P verwendet und das Protokoll ist echt hübsch. Ihr könnt ja sehen, das sind nur Texte, also das ist nur plain Text, keine Binäle hatten und man kann sehr leicht damit rumspielen, man kann einfach über Tellnet mit dem Server kommunizieren. Man kann die Kommandos einfach per Hand eintippen. Man kann Sachen auch per Hand in der Konsole modifizieren und in Echtzeit sehen, wie das sich auswirkt. Auf der linken Seite sehen wir hier zwei Teile die durch den S&P Standard definiert werden. Das ist der S&P Envelope, das ist der Umschlag. Das ist die Server Connection, man sagt Hallo, man spezifiziert den Sender und den Empfänger. Und der Sender Recipient ist der Adressat. Dann kommen die Daten und das ist der Content Message Teil. Da gibt es einen anderen Standard, der ist nicht besonders wichtig, aber wenn du die Details nachschlagen wollt, dann müsst ihr woanders schauen. Diese interne Message, die entweder Content oder SMT Message heißt, hat zwei Teile, Headers und den Body. Manche Leute kennen vielleicht E-Mail nicht, aber das Konzept HTTP ist euch ja bekannt und das sieht schon ähnlich aus und ist leicht zu verstehen. Ihr habt vielleicht schon bemerkt, dass wir die Adresse von Alice und Bob zweimal da drin haben. Zum Beispiel auf der zweiten Linie ist Alice schon spezifiziert und die gleiche Adresse haben wir auch im From-Header, später in einer Zeile. Das auch mit Bob. Warum ist das doppelt vorhanden? Also der Unterschied ist, wie wir eine E-Mail sehen. Ich als normaler Mensch, der E-Mail schon benutzt hat in der Vergangenheit, sehe es als, wie das Bild auf der linken Seite, wie eine Postkarte. Auf der Postkarte, da gibt es einen Absender, der draufsteht, einen Empfänger, der draufsteht, das bemerken sie ich. Und dann gibt es die Nachricht. Das ist, so nehme ich das wahr, bevor ich es wahrgenommen habe, bevor ich mehr gelernt habe. E-Mail Admins und die Standardisierungsbehörden sehen die Situation etwas anders, wie auf der rechten Seite. Es gibt einen Umschlag und in dem Umschlag ist die Nachricht drin als Postkarte vielleicht. Also hat man zwei Adressen in dem Szenario, die From-Adresse und die Empfängeradresse auf dem Umschlag. Das ist der Teil, den das Postamt sich anguckt, wenn man das so sagen will. Aber die gucken halt nicht rein. Und im Umschlag selbst gibt es eine weitere Nachricht. Diese interne Nachricht ist dann für den Empfänger gedacht. Man kann sogar noch mehr machen. Man könnte sogar den kompletten Umschlag mit der Message noch an einen weiteren Umschlag verpacken. Das klingt jetzt vielleicht etwas verrückt für einen normalen Menschen. Aber tatsächlich ist es so, dass E-Mail es erlaubt. Und im RFC dafür, da gibt es auch Beispiele, warum das vielleicht nötig ist, eine Nachricht zu verpacken und warum es erlaubt ist. Aber es ist schon verwirrend. Als Resultat ist es hier im ersten Beispiel so, dass wir generell die gleiche Adresse zweimal spezifizieren. Penetration-Tester. Die Frage, die wir uns stellen sollten, ist, muss das so sein? Ist es immer so? Oder ist es nur unsere Hoffnung, dass zweimal vorhanden ist? Nein, es ist mehr so. Unsere Hoffnung, der Standard, sagt es nicht spezifisch. Man könnte quasi die Sachen also verändern, als es nicht Pflicht, dass es der gleiche Wert ist. Es gibt noch mehr Header, als die, die ich gezeigt habe. Ich habe jetzt gezeigt, die Header gezeigt, die wir kennen, wenn man einfach E-Mail verwendet. Zum Beispiel das, was man im E-Mail klein sieht, das Datum, wer das gesendet hat, wer der Empfänger ist. Und da gibt es vielleicht mehrere Empfänger. Und eine weitere Frage ist, wenn wir aus irgendeinem Grund, vielleicht zufällig, verschiedene Adressen spezifiziert haben im Envelope, im Umschlag, welche davon wird dann der Nutzer sehen und der Nutzer sieht normalerweise den Header-Teil. Das sind die Sachen, die für den Nutzer auch gedacht sind. Also die Standard erlauben noch ein bisschen mehr, was an Headern vorhanden sein kann. Es gibt drei verschiedene Header für die Senderseite. Im Standard wird es erklärt, wann man welchen verwenden sollte und das Lustige, finde ich, ist, dass der From-Header mehrere Adressen enthalten könnte. Man sollte nicht mehr als einen haben. Ein Header. Aber im Header selbst könnte es mehrere Adressen geben. Ich habe noch nie eine E-Mail bekommen, die von verschiedenen Leuten kam, aber irgendwie ist es erlaubt. Das Wichtige, was man hier verstehen sollte, ist, dass es wichtig ist für Abwärtskompatibilität. Selbst wenn die Standards alles erklären und dass man nicht mehr als einen haben sollte und so weiter, ist es in der Praktis so, dass man auch falsch formatierte E-Mails senden könnte mit mehreren dieser Header zum Beispiel. Oder man könnte Header senden, dass in der E-Mail kein From-Header vorhanden ist, sondern nur einen Sender. Das ist eigentlich nicht korrekt. Aber die E-Mail-Kleins werden sich Mühe geben, besteffortmäßig die E-Mail trotzdem anzuzeigen, weil sich wollen die Support-Kosten niedrig halten. Denn wenn es nicht funktioniert, dann wendet man sich an den Support und das kostet. Für Penetration-Tester heißt das, dass man umspielen kann mit diesem Konzept, weil es verschiedene Implementierungen gibt. Und zum Beispiel, wenn man zwei Header hat für ein Datenfeld und welcher da verwendet wird, das kommt auch auf die Implementierung an. Es gibt so viele Implementierungen, die auch verschiedene Weisen mit einer Verbunden sind, dass man kann und natürlich auch sollte, als Penetration-Tester versuchen könnte, mehrere Sachen zu tun, wie zum Beispiel den gleichen Header mehrfach zu haben. Das sind jetzt die Basics. Lass uns nun mal reinschauen, wie man vielleicht sowas spufen, fälschen könnte. Hier sind wir wieder zum Szenario mit dem Diagramm, das wir vorher gesehen hatten. Zum Beispiel im ersten Beispiel, dass Alice eine Mail an Bob schickt. Und wenn wir jetzt Chuck sind, als dritte Partei, ein Pen-Tester zum Beispiel, der die Lizenz hat, das zu tun, und wir versuchen, eine gefälschte E-Mail an Bob zu senden. In dem Beispiel ist es so, dass wir Alice als Absender spufen. Und Bob soll die E-Mail bekommen. Und für ihn soll es so aussehen, als wäre die E-Mail von Alice gekommen. Das Risiko hier... Okay, da gehe ich nicht auf einen, das Risiko, den darf ich vorstellen. Zum Beispiel Fake News sind ein Problem, was wir in Lettland hatten. Das wurde gegen Regierungsorganisation verwendet, dass jemand Fake News als E-Mail versendet hat zu anderen Leuten oder Organisationen. Dann haben sie auch versucht, jemanden zu impersonieren, sich als jemand anders auszugeben, der von der Regierung kommt. Ihr könnt euch ja vorstellen, dass es keine gute Sache ist, wenn sowas möglich ist. Interessant hier ist aber, obwohl Chuck eine Attacke durchführt, kommt es auf deine Perspektive an, ob es für dich wie eine Attacke auf Alice oder Bob aussieht. Aber Chuck sendet direkt die E-Mail an den Server. Und der zweite Attacke... Ist, wenn wir eine E-Mail in die Gegenrichtung senden. Das heißt, wenn Bob eine Nachricht an Alice sendet. In diesem Fall versuchen wir, dass wir als Chuck eine E-Mail senden, dann sollte die E-Mail durch alles das System so durchgehen. Das ist die interessante Frage, gegen was können wir uns einfach verteidigen? Es könnte aussehen, dass bei deinem zweiten Beispiel die E-Mail durch unser System durchgeht, könnte man da extra Überprüfungen durchführen. Aber in der Realität ist es das erste Beispiel einfacher zu verteidigen ist. Wir wollen Alice verschützen, aber es ist einfacher, bei diesem Beispiel zu tun, jemanden zu verteidigen, der so tut, als wäre er Alice. Und dann ist das dritte Beispiel, wo Alice mit ihrem Kollegen kommuniziert in derselben Organisation, mit denselben Server. In diesem Fall senden wir diese E-Mail nur an Alice in Cumming Server, nicht an dem, der nach außen sendet. Und wieder, theoretisch ist dies das einfachste Beispiel, um das zu erkennen, weil Alice das Organisation weiß, dass ihre E-Mail jetzt immer von diesem spezifischen Server kommen sollte. Das heißt, wenn wir in der E-Mail von alles das Kollegen senden, dann sollten sie die auch ohne Standards in der Lage sein, das umzusetzen. Aber praktisch, manchmal, relativ häufig sogar, gibt es eine spezifische Weitlist für die Organisation von Alice. Das heißt, manche Überprüfungen passieren gar nicht, wenn die inkommende E-Mail eine E-Mail bekommt, die von ihrer eigenen Organisation kommt. Wir haben dieses Beispiel aus den letzten Jahren gesehen, das ist jetzt eine Kanadische Adresse, und die sind in dem Fall schon ransomware, und die sagen, hey, ich habe deinen Computer gehackt, und deine E-Mail gehackt, und die haben, und wollen, dass du ihnen Geld sendest in Bitcoins, in ihrer Adresse. Und diese E-Mail, das sind ein paar Details von dieser E-Mail, ist, dass sie normalerweise, um zu beweisen, dass sie die Zugang zu deinem E-Mail-Account haben, versuchen, senden sie die E-Mail von deiner Adresse an deiner Adresse. Und für viele Leute funktioniert das. Also, sie sehen, dass jemand die E-Mail gehackt hat, weil sie haben eine E-Mail von sich selber empfangen. Und in der späteren Welt, ihr seht, es ist relativ einfach, solche E-Mails zu senden, und zu fälschen. Keine Schutzmechtsname getroffen wurden. Ich hoffe, dass jetzt keine E-Mails auf solche Sachen hereinfällt. Aber wenn ihr Freunde habt, oder Kollegen, die darüber befragt haben, wie man solche E-Mails sie bekommen haben, ist eine der Sachen, die du tun kannst, tun musst, um neben Passwort überprüfen und so weiter. Es ist ihnen sagt, hey, ich sollten sie ihre E-Mail-Administratoren kontaktieren, und sie fragen, dass sie Anti-Spoofing-Support benutzen, wenn sie solche E-Mail-Adressen mit E-Mails bekommen und kein Field nicht gefiltert wird, dann ist irgendwas komisch. Okay, eine Spoofed-SMTP-Verbindung. Also, ein Beispiel, wie das letzte, jetzt sind wir Chuck. Chuck sendet diese Nachricht zu Bob, und kann man den Unterschied sehen, wie das anders ist als das vorherige, und es ist relativ schwer, diese Unterschiede zu sehen. Die Kommunikation, das Protokoll selber, hat überhaupt keine Prüfungsmethodiken. Du meinst, ganz dieser Typ, dieser Ransomware-Nachrichtensendet, kann man das einfach so in ein Tailnet-Grate reinschreiben und für viele funktioniert das, nicht bei allen. Und E-Mail-Administ kennen dieses Problem. Sie wissen, dass SMTP nicht zuverlässig ist in der Situation, und sie haben unterschiedliche Funktionalitäten versucht, sich dagegen zu schützen. So, ohne Standard, einfach zusätzliche Filter und so hinzuzufügen. Die eigenen E-Mail-Servas. Manche dieser Funktion zerstören den Standards. Aber wer soll's? Sie sind nicht eine heilige Schrift, sondern können einfach so umgangen werden. Aber das Interview sind nicht genug Informationen vorhanden. Zum Beispiel hier oben, wenn wir jetzt Bob senden, wir versuchen, unser System zu schützen. Das sind jetzt einfach mal Bob-System-Administrator. Und wir wollen zusätzliche Regeln hinzufügen und so weiter. Was können wir überhaupt machen? Ein Beispiel, den ich jetzt hier habe, ist ein SMTP-Callback hinzuzufügen. Das heißt, wenn wir eine E-Mail von Alice bekommen, dann schauen wir nach, einfach eine E-Mail von einer nicht vorhandenen E-Mail-Adresse. Und es funktioniert, wenn man ein Standard-E-Mail-SMTP-Server ist. Das SMTP-Callback ist, wenn wir eine E-Mail von Alice bekommen, dann schalten wir in neuen Prozessen. Der versucht zurück zu Alice-Server zu kontaktieren und versuchen, ihr eine E-Mail zuzusenden. Wenn das Server sagt, ja, alles in Ordnung, dann stürmen wir die Verbindung auf, wir senden die E-Mail nicht fertig, aber dann kann unser System automatisch herausfinden, dass diese E-Mail wirklich existiert. Eine andere Methodik ist dieses Hello Echo zu benutzen. Die erste Zeile sollte sagen, den Hostname der sendenden Server sagen. Laut Standard sollte man den nicht verifizieren und zufälliger Stringer sollte man die E-Mail trotzdem akzeptieren. Aber viele Server werden versuchen, ob dieser Hostname da drauf steht, dass der Hostname wirklich zu derselben IP-Adresse zeigt und dann werden sie das Gegenteil durchführen. Sie nehmen die IP-Adresse und versuchen, reverse DNS aufzurufen. Und sie werden versuchen zu schauen, ob die IP-Adresse das Hostname gehört. Pentester sollten wir diese technischen Verteidigungs-Mexikanalismen kennen. Sonst würde man was ausprobieren, das funktioniert nicht. Aber wenn man sie kennt und identifiziert, dass diese Organisation sie benutzt, kann man sie relativ einfach umgehen. Es gibt keine gute Sicherheit. Sie soll von Spam-Massenversenden an schützen, aber nicht von gezielten Angriffen. Sie selber, wie wir gesehen haben, hat keinerlei Schutz-Mechanismen. Also, welche Erweiterung sollen wir wirklich benutzen, um Sicherung zu zufügen? Ein dieser Protokolle ist SPF. Was macht SPF? SPF versucht den alles System nochmal ihr nachzumachen. Alles versucht, den Email zu Server von Bob zu finden. SPF ist der Gegenteil davon. Die Idee dabei ist, dass automatisch von Bob's einkommenden Server das ausführt. Und sie versuchen eine DNS-Abfrage zu machen und versucht daraus zu finden von welchen IP-Adressen gehören denn zu Alice's Outcoming Server. Und es ist relativ einfach zu verstehen für uns. Das ist voll ein. Und das eine Feld, was überprüft wird, ist dieser Envelope Sender. Das ist ein kleinste SPF-Syntax. Kein Beispiel. Selbst, wenn man die Syntax nicht versteht, hat eine IP-Adresse sollte eine IP-Adresse des sendenden Servers sein, der wirklich hier sind von sendenden Servers. Und ein Minus All, das bedeutet, dass der einzige ist. Das heißt, wenn ich eine E-Mail von einer Nachricht, diese E-Mail-Adresse bekommt, dann ist das in Ordnung. Wenn es irgendeine andere E-Mail-Adresse ist, dann lösche ich die einfach. Man kann das unterschiedlich spezifizieren. Man kann eine IP-Adresse spezifizieren. Man kann ein DNS-Namen spezifizieren. Ein Hausname. Und für einen solchen Tester kann man das supporten. Und dann gibt es diese qualifizierenden Elemente, das setzt man vor diese Methode. Zum Beispiel, in dieser Methode IPv4 hat kein Qualifizierer, kein Plus, kein Minus, kein Nix. Das heißt, standardmäßig wird Plus vermutet. Also, alles sollte im Mail Server entsprechen. Man kann aber auch Minus benutzen. Das ist Fail. Das heißt, wenn irgendwas darauf trifft, zum Beispiel Minus All, das ist am häufigsten benutzt. Wenn es zu diesem zugehört dann löscht die Mail. Dann sende sie nicht. Das ist eine falsche Mail. Und dann gibt es dieses dritte, diese Tilde, SoftFail. Das sollte benutzt werden wenn man anfängt SPF zu implementieren. Dann könnte es sein, dann ist es dort, man könnte zum Beispiel vergessen, dass ein SMTP-Server hinzugefügt wird. Ich will es auch nicht gemacht haben. Wir haben nur einen SMTP-Server, ein Outgoing-Server, aber in der Realität gibt es weitere, die man senden. Und in diesem Fall wenn ihr das wirklich sagt, Fail, dann kann man es senden. Darum ist es gut, es zu testen. Hier sind komplexere Beispiele, ein Beispiel ist Include. Das heißt, instead von die Qualität selber zu machen, zum Beispiel, die Google benutzt, sagt man, hey Include, das was Google, kopiere das was Google veröffentlicht. Und das ist hier SPF Benutzer. Wenn wir nur die Mail senden, die irgendeine Art von Policy haben, dann sieht die Zahl relativ gut aus. Also, die beliebtesten Domains sind 75%. Aber die meisten benutzen, sind entweder schlecht konfiguriert, oder sie benutzen diese Soft-Fail-Funktion. Was sie macht, nichts. Man kann immer noch selbst, wenn es ein Soft-Fail, die E-Mails buft. Wenn man trotzdem durchkommt, weil der Empfänger sagt, wir sollen jetzt die E-Mails noch nicht löschen, stellt die E-Mails trotzdem zu. Das heißt, der Prozentsatz ist gar nicht so gut. Aber das Wichtigste für uns als Pentester ist, zu verstehen, was machen wir, wenn wir diese sehen? Jetzt können wir E-Mails bufen. Aber das dauert immer noch nicht, dass alles zu Ende ist. Also zu allererst diese Software. Soft-Fail. Wir haben Regeln und Regeln, und dann kommt einfach dieses Soft-Fail-All. Wenn wir End-Penetration-Teste sind und versuchen, eine unbekannte E-Mail-Adresse zu spufen, die jetzt noch nicht vorhanden ist, dann macht nichts. Und nichts. Das heißt, löscht die E-Mails nicht. Das ist gut für uns. Wir können diese E-Mails spufen. So wie früher auch. Das wird wahrscheinlich durchgehen. Und die Anmerkung dabei ist, dass manches das Thema nicht nur diese binäre Klassifikation auch etwas gut oder schlecht ist, sondern sie versuchen, ein bisschen Scoring zu machen. Das heißt, selbst wenn es Soft-Fail werden sie nicht die E-Mails automatisch löschen, aber vielleicht fügen sie zusätzliche Informationen hin und einen Risiko-Level zu erhöhen. Das heißt, es ist doch nicht komplett zu Ende. Ein weiterer Punkt ist dieses Include oder Includieren Das ist sehr nett, wenn man die E-Mails von anderen benutzt, aber es ist nicht so, wie es ist im Standard. Es ist einfach ein schlechter Name dafür. Es ist nicht ein so... Man sollte nicht von drinnen reinkrepieren in den höchst verliegenden Level, sondern die versuchen alles Checks in dem Inneren zu überprüfen. Aber wenn es damit nicht klar kommt, dann wird es die E-Mails nicht sofort löschen, sondern es wird zum Level höher gehen. Und es wird dann versuchen, die Regeln durchzuführen. Das heißt, das Problem ist, dass in den häufigsten Fällen das entweder wenn man vergisst, dieses Minus All hinten dran zu setzen oder der an einem System-Administrator das vergessen hat, dann selbst wenn der Include Minus All am Ende hat, funktioniert es nicht. Also dann fehlt der, wenn es überprüft wird, dann fehlt das von dem Includierten, aber nicht ganz oben. Und das Zweite ist, dass wenn sie ein Soft-Fail ist, dann meinen Menschen, ich include Gmail und die haben dieses Hard Ding, aber es funktioniert so nicht. Und dann ein Beispiel, was das häufigste ist, ist, dass viele solche SPF-Records haben, Snipeer-Adressen und A-Records und MX und Pointer und alles Mögliche, was ein Administrator da hinschreiben kann. Der Grund ist, dass die meisten Administratoren nicht genau wissen, wie SPF funktioniert. Die wissen nicht genau, was reinkommt. Zum Beispiel ist, dass wenn da ein MX-Record drin ist, die meisten Organisationen, also die sind sehr klein, nur einen Server haben, haben unterschiedliche Server für unterschiedliche App-Adressen für Mails, die nach draußen gehen und Mails, die zurückkommen. Das heißt, es gibt keinen praktischen Grund, einen MX-Server in SPF hinzufügen, weil aus dem MX-Server keine Mails senden sollte. In anderer Fall könnte es sein, dass es nicht so gut organisiert, aber es ist wirklich, die Architektur ist komplett durcheinander, sie senden Mails von vielen, vielen unterschiedlichen Punkten. Das ist Rundverpenetrationssetzer, weil sie sind nicht so gut organisiert. Und dann gibt es noch andere Probleme, Herr Dritt, nämlich, dass die Granularität nicht ausreichend ist. Ihr könnt ja jetzt denken, ist sie doch reichlich aber um verschiedene App-Adressen aufzulösen. Die App-Adresse wird hier wahrscheinlich nicht nur zu einem Mails-Server gehören, sondern vielleicht noch ein Web-Server sein und noch andere Dinge tun. Das heißt, als Pentester können wir dieses irgendwas anderes gut benutzen. Das ist ziemlich unauffällig. Patchman ist dann weg, das ist okay. Aber bei einem Web-Server, das wäre in den meisten Fällen, dann können wir vielleicht die Privilegien auf eine gewisse Art und Weise erhöhen in einem gewissen Sinn und sind dann auf einer passenden IP-Range und kommen durch das SPF durch. Ein Beispiel ist geteiltes Hosting, der typische Fall. Das Problem mit Shared Hosting ist, man hat die IP-Adresse eines SMTP-Servers der vielleicht nur benutzt wird, um Mails zu schicken. Aber das Server wird nicht nur für dich benutzt, sondern auch für verschiedene andere Domänen, vielleicht für tausende Domänen. Das kann ich als Angreiferin benutzen. Oder ich werde einfach von diesem Shared-Hoster kunden, da muss ich nicht mal was exploiten. Und das sieht dann für SPF aus, als Kerne das von der legitimen Quelle. Noch ein möglicher Fehler ist den falschen Identifier zu prüben. Das ist wahrscheinlich das größte Problem in SPF. Wie ich vorher erwähnt hatte, gibt es mindestens zwei Identifiers den äußeren, der den Sender identifiziert und den internen, typischerweise der From-Header. Aber SPF wenn man SPF nur benutzt, dann wird nur der erste Sender in der Hölle benutzt, also der From-Header ist nicht geschützt, aber der User sieht halt nur den From-Header, der wird normalerweise den Sender-Header nicht sehen. Das wird jetzt gefilgt mit DMARC und die Mehrheit der SPF-Installation haben nicht DMARC konfiguriert. Also selbst wenn SPF gut konfiguriert ist, kann man sich dann als Angreiferin um etwas wohin zu schicken von einem anderen Namen einfach nur den Sender darauf anpassen, dass der durch den Check durchkommt und kann den From-Header aber wieder so anpassen, wie ich aussehen möchte. Es gibt noch eine andere Technologie die das versuchen soll zu fixen, nämlich DMARC. Also wie wir gesehen haben, ist SPF nicht genug. Ihr seht hier die falschen Buchstaben, aber sorry dafür also Dekim wir können euch einfach nur einen kurzen haben. Was es tut, es ist Benutzskriptografie, ist doch nett. Das ist eine kloge Sache, es ist schwer zu brechen für Angreiferin. Es bedeutet also jede Mail die von dem Server kommt die kriegt ein Key, also kann ich kriptografisch verreifizieren, ja die kam jetzt von diesem Server. Wie das aussieht ist schwer zu lesen, weil es ist natürlich nicht dafür gemeint dass Menschen das lesen können, sondern Computerhalt. Das Gelbe ist hier die kriptografische Signatur aber der grüne Anteil ist der Domain Identifier. Und der rote Anteil, ich weiß nicht mehr wie der heißt und die Idee ist, dass man verschiedene Keys haben kann für diese Organisationen in der man sitzt. Die Organisation könnte zum Beispiel Mails vom originalen SMTP Server haben von einem Backup Server und da möchte man vielleicht noch ein paar Mails von Google und ein paar von der Marketingkampagne schicken und die würden unterschiedliche rote Parameter haben. Da müsste also die Fängerin ein DNS Query laufen haben mit verschiedenen Mischungen von Rot und Grün, gucken sich den Public Key an und würden damit die Signatur verreifizieren. Klingt nett. Das Problem, na ja noch kein Problem ist, wenn man Public Key kriptografisch versteht, das ist relativ einfach zu verstehen, wir generieren halt einen Public Private Key Pa veröffentlichen den Public Key und benutzen den Private Key um die Nachrichten zu unterschreiben. Die Empfänger können dann also, wenn sie das Grün daran verstanden haben, den Public Key und sehen ihn in einem Texte-Record und können dann verreifizieren ob die Signatur passt. So, klingt nett. Was ist das Problem? Das Problem damit ist, könnte verschiedene Selectoren geben. Wenn man das konfiguriert, kann man so viele Selectoren definieren, wie man das möchte. Das heißt, die empfangene Person weiß nicht welcher Selektor wird benutzt, wird überhaupt einer benutzt. So eine existierende Signatur zu modifizieren ist schwierig, aber es ist ziemlich einfach, sie einfach zu entfernen. Wenn man jetzt also die Kim einfach entfernt, kann die Empfänger nicht wissen, ob das hätte da sein sollen. Um sie zu prüfen, muss sich das Grün und das rote Kim den domenial entfernten Selektor als Teil des Headers. Das ist ein großes Problem. Das heißt, wir können die Kim zwar nicht spufen, aber wir können es schlicht entfernen. Und wenn das der einzige Schutzmehrhändismus war, dann wird das wahrscheinlich funktionieren. Wird das zum Empfänger kommen? Und noch ein Problem ist, was ist dieser Domainselektor? Warum müssen wir den setzen? Die beste Praxis ist, dass der Hültenselektor ist wie das From und das sei bitte der Selektor wie der Die Kim Domainselektor. Etwa alle Alice.org oder sowas. Das Problem ist, das ist nicht im RFC drin. Was passiert also, wenn das nicht so ist? Also, auf der rechten Seite haben wir eine echte Domaine, also oben rechts hier in dem Beispiel seht ihr, wir haben Google Apps benutzt. Grundlegend wird Google erstmal alle Messages mit Die Kim mit, nämlich der Domaine, die es halt kontrolliert. Das bedeutet also, da ist etwas mit Die Kim signiert worden, aber das heißt nicht, dass man das zu der Organisation zurückverfolgen kann. Das wurde von etwas völlig anderem signiert. Der richtige Ansatz hier ist also nicht die Mail wegzuwerfen, sondern einfach nur sehen, nicht als validiert zu betrachten. So, das ist okay, matched RFC. Der interessante Anteil. Wie können wir Die Kim modifizieren? Ich habe nicht Zeit dafür, ins Detail zu gehen, aber in manchen Fällen, nicht in allen Fällen, kann man es tatsächlich modifizieren. Das Einfachste zu modifizieren in so einer Message ist der Header. Weil Die Kim selbst in den Headern vorkommt, kann es nicht alle Headern wegen Hennerei-Problem signieren. Also es ist einfacher hier für den Angreifer, einfach ein bisschen Header dazu schreiben, wenn das bei dem Plan hilft. Also fangen wir einfach ein dazu. Und was das RFC halt erwähnt, ist, man sollte eigentlich nur eine Kopie im Header haben. Das ist aber hier, aber es geht auch mit mehr. Wenn man Die Kim jetzt gesagt hat, der From Header sollte bitte signiert sein, dann wird er sich den ersten From Header von unten aussuchen. Aber die meiste Software, viele Clients werden von den User aber eher den ersten From Header von oben anzeigen. Bedeutet also für den Angreifer, die Angreiferin, dass sie einfach nur weitere From Header nach oben schreiben muss. Das ist, es gibt einen Schutz, der in Die Kim RFC erwähnt ist. Wir nennen ihn Oversigning und nicht alle tun das. Das geht halt nur auf die Header. Manchmal ist es gut, wenn man nicht so den eigentlichen Body der Message zu modifizieren, ist etwas schwieriger, denn wir wollen ja hier die Kryptografie nicht brechen, das ist zu schwierig. Und dann gibt es einen Parameter Body Length, also Größe dieser Message. Um den Herrsch rauszukriegen, holen wir nur die ersten paar Bytes zu einer Message an. Das ist mal ganz praktisch sein, aber für den meisten Teil ist das nicht so nützlich. Wenn es das tut, dann ist es offen für Attacken, wo einfach der Message Body überschrieben wird. Und es wird dann Die Kim passen. Und wird einen Green Button oder was auch immer anzeigen. Die dritte Technologie, die wir da haben, ist in DMAK, und hier gibt es wieder den langen Namen, der ist ziemlich lang, aber in diesem Fall bedeutet er sogar etwas. Zwei Teile sind da Keywords, Reporting. Das ist was die meisten Admins kennen, weil das so wird in DMAK halt verkauft. Reporting heißt, wenn man ein Problem hat, dann bekommt man in diesem Fall dann erzählt man der anderen Seite, was sie tun soll. Zum Beispiel sagt man ihnen, dass sie einem Report senden soll. Zum Beispiel einmal oder immer, wenn was passiert. Das ist für Penetration-Tester nicht nützlich, aber man kann dadurch verstehen, welche Konfiguration zum Beispiel vorliegt. Es ist aber nicht groß implementiert. Der andere Teil Conformance ist wirklich, wirklich mächtig. DMAK hatte das Problem, dass, wenn man den Header einfach entfernt, dann hat der Empfänger überhaupt keine Möglichkeit zu wissen, dass dieser Header hätte dasehen sollen. Und wenn man DMAK verwendet, mit DMAK zusammen, dann wird das Problem gefixt, weil DMAK spezifiziert, dass man, wenn man DMAK nur hat, dann sollte SPF oder DMAK schon bestehen, damit es überhaupt ankommt. Wenn man SPF und DMAK halt, heißt es, dass SPF gegen den From-Header läuft. Wenn man SPF selbst benutzt, dann kann immer noch der From-Header modifiziert werden und das erfährt der Empfänger nicht. Ein Mini-Beispiel für DMAK ist wirklich klein, das könnt ihr leicht verstehen. Wir sagen nur, DMAK und REJECT. Wir müssen nur die richtige Stelle finde es hinzuschreiben. Alles was man machen muss, ist einfach den S-Eintrag einlegen und auch wenn man SPF und DMAK hat und DMAK angelegt hat, dann heißt es effektiv, dass diese Domäne keine mehr zählen soll, weil man als SPF und DMAK valide sein sollte, damit PMER valide ist. Das bedeutet, dass die meisten Domäner draußen, zumindest im Betrachtshin sollten, DMAK zu enteblen. Das ist einfach das Richtige, was man tun sollte. Da gibt es draußen in der Welt mehrere Angriffe, aber für Pientration-Tester nicht interessant. Diese Policy kann drei Werte haben, Non-Quarantine oder REJECT. Wenn ein Fehlerfall auftritt, dann geht die Message in die E-Mail-Nachricht in den SPAM-Folder, REJECT heißt. Das Bild habe ich am Anfang gezeigt, das zeigt die Verteilung, obwohl die Technologie die beste ist, ist sie überhaupt nicht weit in Verwendung. Leider für die Pientration-Tester ist es natürlich gut, zu wissen, weil man kann die meisten Messer sehr einfach spufen. Wie schützen wir uns? Wie gehen wir da rum? Also, was passiert, wenn jemand DMAK implementiert hat? Heißt das, dass wir alles machen können und nichts nach forschen müssen? Nein, in der Praxis. Wenn jemand DMAK implementiert hat und SPF nicht, also nur zwei von drei haben, das ist eine coole Kombination. DMAK ist sehr mächtig und der Hauptfehler, den DMAK hat, wird von DMAK abgestellt. Das Problem ist aber, dass, wenn man seine Eingemäß schützen will, und sie validieren. Leider macht das nicht der Großteil der Software da draußen. Zum Beispiel Microsoft Exchange. Einige der Maschinen, mit denen man kommuniziert, haben Microsoft Exchange und die meisten Systeme müssen trotzdem SPF in der Praxis aktivieren. Das ist gut für Pientration-Tester. Wenn SPF und DMAK defaultmäßig aktiviert sind, dann wird wieder ein Problem gefixt. Aber andere Problemen nicht. Die Granularität ist nicht hoch genug und die Konfiguration ist vielleicht falsch. Aber interessant ist, dass DMAK nur eine der anderen Technologien verwendet, damit die E-Mail als Valide gilt. DMAK hat keine Möglichkeit zu spezifizieren, dass Deckem und SPF Valide sein sollen. In der Praxis heißt das, dass bei meisten Systemen alle anzuschalten aus der Sicht des Penetration-Testers nicht wichtig ist, also kein Mehrwert bietet und wir als Penetration-Tester uns auf zwei davon konzentrieren können. Eine Minute für eine Zusammenfassung, ich weiß nicht, ob ich noch genug Zeit habe. Nein, nicht viel Zeit mehr, sorry. Also eine weitere Information ist, wenn ihr Systeme testet, dann zieht beides hinein und betracht. Testet nicht nur Alice, testet auch Bob. Also nicht nur den Sender testen, sondern auch die Empfängerseite. Hier könnt ihr sehen, dass es leicht ist, zum Beispiel SPF und DMAK zu implementieren. Man braucht ja nur einen DNS-Eintrag, nur ein Record für jedes, aber zu testen und gut zu validieren ist sehr viel schwerer, man braucht Software-Support und man muss auch da noch konfigurieren. In der Praxis wird es so sein, dass viele Organisationen DMAK und SPF anhaben auf den S-Seite, aber sie validieren es einfach nicht ordentlich. Okay, sorry, ich habe leider keine Zeit mehr dafür. Also dann war es das jetzt. Sorry, vielleicht noch ein paar Fragen. Das war die deutsche Übersetzung des Vortrags vom 36. Chaos Communication Congress. Eure Übersetzer waren Blue Hubert, Franz T. und Wassago. Vielen Dank, wir freuen uns auf euer Feedback mit der Hashtag C3T auf Twitter. Das Frage ist eine gute Frage. Wir wollen, dass jeder das anschaltet, aber leider soweit ich weiß, die alle Tools im Internet sammeln Daten und sammeln sie von euch und für Privatsphäre ist das nicht gut, für Datenschutz. Da muss man selber was implementieren oder ein Projekt selber anfangen. Okay, Mikro 1. Danke für den Talk. Ich würde mich als Mail-Administratoren betrachten und mir wird häufig gesagt, das SPF-Record, das ich geschrieben habe, wäre zu lang. Insbesondere sagen wir Leute, ich möge den PTR-Record version und andere sagen mir, aber es wäre nützlich, um reverse DNS-Checkings zu implementieren. Wie stehst du zum Kürzen von dem SPF-Record und dem PTR-Record? Das kommt wirklich auf dein News-Case an. Es kann sein, dass einige das lange SPF erforderlich ist und man nichts machen kann, aber man kann es mit Includes arbeiten. Es sind keine Makros, die werden nicht expandiert und der eigene Record führt dann nicht länger, wenn man einen Clue Statement hat oder viele davon. Das Problem, also ich würde dir raten, dass du vielleicht neu überdenkst, ob man wirklich so viele Records braucht. Das allgemeine Problem ist, wenn man nicht gerade Google ist, dann braucht man normalerweise nicht so große SPF-Header. Es ist vielleicht ein Fehler für die meisten Organisationen. Nur kurz, bitte. On the PTR-Record. Auf dem PTR-Record. Ich dachte, es wäre aus einem Standard geschmissen worden? Nee, es ist im Standard. Der Record ist ich wüsste nicht, dass es irgendwie weggeschmissen würde, automatisch. Das sollte kein Problem sein. Wir haben noch ein paar Fragen, also Mikro 6. Ja, danke für den Talk. Es ist nicht direkt verbunden, aber vielleicht sollte es verbunden sein. Wenn der Mails aber die Kim DiMarc SPF akzeptiert und alles ist gut und etwa bei Google wird die Mail zwar empfangen, aber geht in die Spambox. Das heißt, sie wird, kommt zwar an, aber sie wird nicht angezeigt. Was ist denn das Problem? Es gibt verschiedene Meinungen. Eine Sache, die Google überhaupt ermöglicht. Danke Google. Es ist gut, dass sie so streng sind. Durch Google haben wir überhaupt so viele schlecht konfigurierte Organisationen. Google will, dass man SPF mindestens hat, sonst sind Google nicht so gut. In meinem Job habe ich ich finde es gut, dass Google das so tut, aber dadurch haben die Admins Probleme. Google hat ein Tool, das ich vielleicht kennt, womit man checken kann, ob die eigene Domain mittraggezogen wird. Selbst wenn man DiMarc und so weiter hat, dann ist vielleicht nicht konfiguriert. Das haben wir gerade im Talk gehabt. Ihr glaubt vielleicht, ihr habt es richtig konfiguriert, aber vielleicht doch nicht. Geben wir gerade Prios für das Internet. Wir haben eine Frage vom Internet. Wenn du versuchst, eine Adresse zu verifizieren, wie handelst du No-Reply-Adressen? No-Reply? Sorry? Kannst du das nochmal sagen? Da wird auch die Frage, wie verifizierst du No-Reply-Mail-Adressen? Also, du ... Es geht um No-Reply? Header? Oder was? Also, ich versuch's mal zu erklären, oder so wie ich's jetzt verstanden hab. Was oft passiert ist, dass ... Sorry? Dass eine E-Mail aus nicht existierenden Adressen gesendet wird, vielleicht meinst du das? Es gibt kein Reply und das ist ja kein Problem. Das Problem ist, dass es keine solche Adresse gibt und da hab ich keine Antwortfall. Dann kann man laut AfD ... sollte man nach RFC diese E-Mail trotzdem akzeptieren. Viele Mail-Systems dropen solche Adressen, wenn sie nicht existieren. Außer man ist Google und ist gewitelistet. Aber von nicht existierenden Adressen kannst du eigentlich keine E-Mail senden. Man sollte immer eine Adresse kreieren müssen. Wenn man als Empfänger ist, dann ... kann man ... Man sollte immer entscheiden, was das Risiko ist, wenn man so eine E-Mail wegwirft. Laut AfD sollte man diese Ad-Mails annehmen. Okay, Mikrofon 4, bitte. Danke für den Vortrag. Weißt du von Mühen, um Probleme zu lösen? Von etwa großen Buchverkäufer in dem Internet? Und sie sollten ihre eigenen SPF-Records unter Kontrolle haben. Man kann sie einfach kontaktieren. Vielleicht haben sie nicht darüber nachgedacht. Oder niemand hat ihnen gesagt, was sie tun sollen oder ihnen gesagt, wie sie es besser machen können. Das machen wir als Zert. Wir tun genau das. Wenn du ein Problem hast mit einer großen Firma in einem bestimmten Land, dann einfach das Zert kontaktieren, auch wenn es keine Regierungsorganisation ist. Wir würden zum Beispiel eine Triage machen mit den Leuten reden, ihnen das erklären. Vielleicht ist es eine Option, wenn etwas für dich so eine dritte Partei eine schlechte Konfiguration haben. Wenn irgendwas nicht sicher ist, dann heißt es ja nicht, dass es falsch ist. Vielleicht gibt es sogar ein Anwendungsfall, warum es so sein soll, wenn zum Beispiel Amazon eine große Firma irgendwas hat. Vielleicht haben sie etwas getestet oder einen Strick konfigurieren. Dann gehen einfach ein großer Anteil ihrer Emails unter, weil jemand anders was falsch gemacht hat. Da gibt es tatsächlich wirklich die Geschäftsfälle. Das wäre dumm, wenn sie einfach zustrickte Konfigurationen anschalten und wissen, dass dann wirklich ihr Business kaputt geht. Ist auch sinnvoll, oder? Wir sind leider durch mit der Zeit. Wir haben ein Mikrofon stehen, redet direkt mit dem Vortragen nach dem Talk.