Grinsekatz

#AfDLeak - wir gehen rein. tl;dr: knapp 10% der Mails im AfD Leak lassen sich technisch ziemlich eindeutig als echt bestätigen. Über den Rest lässt sich weder das noch das Gegenteil wirklich klar sagen. Ich schaue mir gerade die Daten aus dem AfD Leak an. Die "schmutzige Wäsche" wer wen rauswerfen will oder Drogen an Wahlkampfständen vertickt interessiert mich dabei weniger. Da schreiben andere schon genug. Spannend an dem Leak ist, dass bei einem Großteil der e-mail die DKIM Signaturen enthalten sind. Was heißt das? Eine DKIM Signatur wird vom e-mail Server des Absenders hinzugefügt. Damit kann ein Empfänger gegen einen (per DNS) veröffentlichten (public) Schlüssel prüfen: 1. ob die e-mail von einem für die Domain zuständigem Server kommt 2. ob sie unverändert[1] ist Nicht mehr, aber auch nicht weniger. Das ist immer wichtig zu behalten, es belegt z.B. nicht ob der Absendeserver den From: Header sauber filtert, nicht ob ein e-mail account gehackt wurde etc. Ich habe nun versucht sämtliche DKIM Signaturen in den Rohdaten zu verifizieren. Das ganze hat ein paar zu erwartenden Grenzen: Von den 421068 e-mails verfügen 104571 über Signaturen. Dass es nicht mehr sind ist nicht ungewöhnltich, nicht alle Absendeserver verwenden DKIM, und die Mails sind teils relativ alt und früher war es noch weniger verbreitet. Die dazu gehörenden öffentlichen DKIM Schlüssel sind teilweise widerrufen worden oder schlicht nicht mehr im DNS verfügbar. Wenn wir also zu einer Mail keinen passenden DKIM schlüssel finden heißt das NICHT, dass diese Mail gefälscht ist, nur dass wir sie nicht verifizieren können. Selbst aus einer Fehlerhaften Schlüsselprüfung können wir leider wenig schließen: die Keys zu rotieren ist normale Praxis - und alte Mails mit aktuellem Key prüfen schlägt erwartungsgemäß fehl. Fälschung und Keyrotation lassen sich ohne separate Quelle für alte Keys nicht unterscheiden. Im ersten Schritt habe ich mit einem python script alle aktuell verfügbaren öffentlichen DKIM schlüssel von Absenderservern in dem Leak gesichert. Für 3398 Domains konnte ich dabei 1838 verwendbare Pubkeys abrufen. Im zweiten Schritt habe ich alle 104571 verfügbaren Sigaturen geprüft. "Nur" 36111 sind dabei im ersten Prügang komplett in Ordnung (pass). Wenig überraschend sind nicht verfügbare schlüssel (durch DNS Fehler, aktuell kein Key hinterlegt, manche DNS server liefert sogar defekte Schlüssel aus...). Stärker überrascht hat mich erstmal ein Block von 45892 mail+key verfügbar, aber fail. Also bohren wir tiefer. Das teilt sich auf in 33944 Fehler bei der Prüfung des Mailinhalts und 11948 Fehler im Header. Wenn wir das nach Domains aufdröseln ergibt sich ein schärferes Muster: Allein 2/3 der Body-Error sind e-mails von paypal. Da ist die Failquote 99,5%. Ich vermute hier Keyrotation als Ursache, habe ich aber nicht untersucht und interessiert zumindest mich nicht weiter. Bei der domain "globalcitizen[.]org" haben 100,00% aller e-mails nicht-validierenden Header. Das erklärt alleine knapp 8k der 11k Header Fehler. "afdbundestagsfraktion[.}onmicrosoft[.}de" fällt mit einer Failquote von 99,6% im Body auf. Das sind durchgehend body hash Fehler. Das bedeutet: Prüfsumme vom Mailinhalt passt nicht, schon bevor man überhaupt die Signatur mit dem public Key vergleichen kann. Das sind insgesamt 2185 Fehlgeschlagene Prüfungen. Diese liegen ALLE im Postfach "bundesschiedsgericht@alternativefuer.de"[sic!]. Da wir hier von Microsoft Azure reden könnte die Ursache die sogenannte "Content conversion", einem anti-Feature von Microsoft Exchange den Inhalt von e-mails serverseitig für verschiedene Clients aufzubereiten ohne dass er sich sichbar ändert. Insgesamt fällt die Analyse weniger klar aus als ich mir im Vornherein erhofft habe. Wir wissen jetzt, dass 8,576% der e-mails echt und unmanipuliert sind. Über den Rest können wir zumindest mit einer einfachen "Massenauswertung" fast nichts sagen. Klare Indizien auf Manipulation konnte ich nicht finden, aber die doch relativ hohe aber erklärbare Rate an Fehlern und nicht signierten Mails lässt es eben auch nicht ausschließen. Ich denke unterm Strich sollte man bei Berichterstattung die die erhaltenen DKIM Signaturen als Argument in die eine oder die andere Richtung das ganze nicht ohne Beleg für die konkrete Mail zu ernst nehmen. Falls aus meiner Sicht interessante Dinge auftauchen werde ich auch Mails im Einzelfall prüfen (Vorschläge willkommen, kein versprechen dass ich es auch interessant finde). Aber mit dem "Schleppnetz" können wir nur sagen dass der Leak definitiv aus echten Daten besteht aber Manipulation nicht ausschließen. [1] streng genommen toleriert DKIM gewisse Veränderungen z.B. im Whitespace oder durch Maximallängen in Anhängen.