Laut neueren Untersuchungen basieren fast 90% der Email-Angriffe auf falschen Absendern, sowohl von Marken (83%) als auch von Einzelpersonen (6%). Eine Art des Identitätsdiebstahls, der so genannte exakte Domain-Identitätsdiebstahl (Exact Domain Identity Theft), tritt auf, wenn Betrüger eine Domain im From-Feld der Nachricht verwenden, um sich als Teil einer anderen Organisation auszugeben.

Es gibt Möglichkeiten, Spammer und Phisher daran zu hindern, Ihre Domain zu fälschen. Die Email-Authentifizierung – Überprüfung, ob eine Email wirklich von der Domäne stammt – basiert auf wohlbekannten Standards, die wir in unserem Beitrag diskutiert haben. Diese Sicherheitsmechanismen sind relativ einfach einzurichten und bieten ein gutes Schutzniveau.

Wenn diese Methoden Spam fast vollständig blockieren, warum hören wir dann immer noch häufig davon? In der Praxis setzen sie nicht alle Unternehmen ein.

SPF, DKIM, DMARC

Die Umsetzung von SPF ist nur der Anfang, denn für einen wirksamen Schutz ist es auch notwendig, DMARC und folglich DKIM umzusetzen.

DMARC bietet drei Hauptelemente zu den bisher existierenden Email-Authentifizierungsstandards:

• Berichte: Empfänger, die an DMARC teilnehmen, erklären sich bereit, Email-Authentifizierungsberichte an sendende Domänen zu übermitteln
• Policy: Mit DMARC können die sendenden Domains beraten, wie ein Empfänger eine Email behandeln sollte, die die Authentifizierung fehlschlägt, anstatt dies dem Empfänger zu überlassen
• Identitätsausrichtung: DMARC priorisiert die benutzerlesbare Absenderadresse als Ursprung der Identität und berücksichtigt nur Authentifizierungsergebnisse für Identitäten, die an dieser Absenderadresse ausgerichtet sind

Probleme

Wie jeder Schutz sind auch diese ein zusätzliches Problem, das es für das reibungslose Funktionieren des Systems zu lösen gilt: Im Grossen und Ganzen entscheidet der Inhaber der Domain, was der Empfänger mit den in seinem Namen erhaltenen Emails macht.

Es gibt keinen schnellen und sicheren Weg, um zu testen, ob eine Konfiguration funktioniert oder nicht, ohne mehrere Parteien gleichzeitig einzubeziehen. Dadurch wird alles akademischer: Man muss sich vor ein Papier setzen und die Policy so gestalten, dass sie theoretisch funktionieren kann; einmal implementiert, muss man ihre tatsächliche Funktionsweise überwachen und auf jedes Problem reagieren.

Die erwähnten Schutzsysteme sind für eine gemeinsame IT-Abteilung schwer zu verstehen und zu implementieren, weil:

• es eine einmalige Einrichtung ist
• sobald eine Anpassung stattfindet und etwas nicht funktioniert, werden Sie mit Anrufen und Beschwerden überhäuft

Ausserdem gibt es einige spezifische technische Kritikpunkte:

• Protokolle sind voneinander abhängig: DMARC basiert auf SPF und DKIM, die ebenfalls heikel zu implementieren und anfällig für Fehler sind
• SPF Request Limit als Risiko: Eine Sicherheitsmassnahme, die viel Ärger verursachen kann, wenn sie unterschätzt wird

Dies erklärt zum Teil, warum viele Administratoren es vorziehen, eine Einführung zu vermeiden oder “pro forma” umzusetzen.

Analyse

Um herauszufinden, wie der Stand der Implementierung in den verschiedenen Unternehmen ist, die täglich mit Millionen von Benutzern kommunizieren, haben wir eine Beispielanalyse von interessanten Bereichen durchgeführt. Die Liste der Domains wird von OpenPage Rank zur Verfügung gestellt. Wir haben die Domänen ausgewählt (basierend auf TLDs, Schlüsselwörtern usw.), die öffentlichen DNS-Einträge untersucht und den verschiedenen gefundenen Richtlinien eine Sicherheitsbewertung zugewiesen.

Verfahren

Die Analyse der Aufzeichnungen umfasst sowohl die Identifizierung der vorhandenen Mechanismen (SPF, DKIM, DMARC) als auch die definierten Richtlinien.

In der Policyanalyse:

• es wird der verwendete Mechanismus identifiziert
• seine Konfiguration wird gewichtet: Zum Beispiel wird für SPF die Policy des all_qualifier analysiert, und nur wenn sie - ist, wird kein Punkt abgezogen
• eine Punktzahl wird der Richtlinie zugewiesen: +100 für die sicherste und -100 für die schwächste Richtlinie

Die gesammelten Informationen werden zur Analyse in einer MongoDB gespeichert:

Datensatz

Wir analysierten 414783 Domänen, ausgewählt nach bestimmten Top-Level-Domains:

Resultate

Einsatz von Sicherheitsmassnahmen

Die nachfolgende Abbildung zeigt, wie viele Domains insgesamt und gruppiert nach ausgewählten TLDs Schutzmechanismen implementieren.

Die nächste Abbildung zeigt im Detail für jede TDL den prozentualen Anteil der Domänen, die Schutzmechanismen verwenden.

Beobachtungen:

• eine sehr kleine Anzahl von Organisationen verwendet alle Sicherheitsmechanismen
• der am meisten implementierte Schutzmechanismus ist SPF
• das durchschnittliche Umsetzungsverhältnis SPF beträgt etwa 45%/55%.
• die .bank-Domains (um ein .bank-Registrant zu werden, muss Ihre Organisation eine von der Regierung regulierte Einheit sein) haben eine SPF Implementierungsrate von 75%/25%, viel eher als die durchschnittliche Domain
• die Implementierung in Bildungs- und Regierungs-TLDs befindet sich noch in einem frühen Stadium

Sicherheitniveau der Domains

Die folgende Abbildung zeigt die Anzahl der Domänen für jedes Niveau der Sicherheit.

Dieses wird auf der Grundlage des Vorhandenseins der Schutzmechanismen und der Qualität der Konfiguration berechnet.

Beobachtungen:

• etwa 70% der analysierten Domains schneiden schlecht ab
• etwa 25% der analysierten Domains haben eine akzeptable Richtlinie

SPF Konfigurationsqualität

Wir werfen nun einen genaueren Blick auf zwei spezifische SPF-Mechanismen (all und ip4_prefix), um die Kreativität einiger Administratoren mit den SPF-Policies zu zeigen.

Der All-Mechanismus

Die nächste zeigt, wie der wichtigste Mechanismus von SPF, die sogenannte all, in den analysierten Bereichen konfiguriert ist. Dieser obligatorische Mechanismus gibt an, was mit den nicht konformen E-Mails zu tun ist (abweisen, markieren oder ignorieren).

Dies ist ein gutes Beispiel dafür, was schief gehen kann: "v=spf1 +all" ist laut SPF-Organisation eine gültige Anweisung, aber laut Dokumentation: Der Domänenbesitzer denkt, dass SPF nutzlos ist und/oder sich nicht darum kümmert

Beobachtungen:

• 50% der .bank TDL bittet korrekt darum, die nicht konformen Mails zu verwefen
• nur 12% der TDLs fordern korrekterweise das Löschen der nicht konformen Mails
• 30% der TDLs bitten darum, die nicht konformen Mails zu verwerfen oder zu kennzeichnen
• 70% der Domains ignorieren grundsätzlich die konfigurierte SPF-Richtlinie

Der ip4_prefix-Mechanismus

Die gezeigte Abbildung illustriert die Konfiguration eines weiteren SPF-Mechanismus, des ip4. Dieser Mechanismus wird verwendet, um eine bestimmte Anzahl von Servern als gültige Mailserver für die Domäne zu markieren. Wir haben die Maske extrahiert, um zu berechnen, wie viele Server mit diesem Mechanismus auf der Whitelist stehen. Die Anzahl dieser Server sollte nur auf die Mailserver beschränkt werden. Beachten Sie, dass dieser Mechanismus optional ist.

Beobachtungen:

• 25% der Domains beschränken den ip4_prefix korrekt auf die kleinstmögliche Anzahl (32), wobei nur eine IP als gültiger Mail-Server markiert wird
• etwa 1000 Domains erlauben dank Big-Masks den Versand von Emails in ihrem Namen (v=spf1 mx a ip4:12.0.0.0.0/2 ip4:72.0.0.0/2)

Andere Mechanismen

Es wurden acht Mechanismen für SPF analysiert. Wir haben nur zwei im Detail gezeigt, um zu betonen, dass selbst das Vorhandensein der SPF-Policy keine Sicherheitsgarantie ist. Darüber hinaus sind die Absichten derjenigen, die ein ip4-Präfix auf 0 konfigurieren, immer fragwürdig.

Zusammenfassung

Mechanismen zum Schutz vor Identitätsdiebstahl, gerade im Mailbereich, gibt es seit vielen Jahren. Aber aus verschiedenen Gründen werden sie noch nicht in grossem Umfang eingesetzt und oft nur im Informationsmodus zwecks Reporting verwendet.

Unsere Untersuchung zeigt, dass die Implementierung solcher Systeme, selbst für sensible Bereiche, noch lange nicht abgeschlossen ist.

Über den Autor

Rocco Gagliardi ist seit den 1980er Jahren im Bereich der Informationstechnologie tätig. In den 1990er Jahren hat er sich ganz der Informationssicherheit verschrieben. Die Schwerpunkte seiner Arbeit liegen im Bereich Security Frameworks, Routing, Firewalling und Log Management.

Links

• http://dkim.org
• http://www.open-spf.org
• http://www.open-spf.org/SPF_Record_Syntax/
• https://assets.barracuda.com/assets/docs/dms/Spear_Phishing_Top_Threats_and_Trends.pdf
• https://dmarc.org
• https://github.com/tb0hdan/domains
• https://www.domcop.com/openpagerank/what-is-openpagerank