1. Home
  2. News
  3. Spam-Mail – Betreff: Vulnerability Report: (Email Spoofing)
  • Datenschutz

Spam-Mail – Betreff: Vulnerability Report: (Email Spoofing)

Haben Sie auch bereits eine E-Mail eines „John A.“ zum E-Mail-Spoofing erhalten, welche ggf. direkt in Ihrem Spam-Ordner gelandet ist? Dann ist diese Mail in Ihren Spams richtig und gut aufgehoben.

In der Mail von Herrn A., unter der Absender-Adresse (gekürzt) „johnhacker…@gmail.com“ – ja, die Mailadresse ist schon sehr seriös – fragt er netterweise erstmal, wie es uns gut. Er schreibt weiterhin, dass er noch keine Rückmeldung erhalten habe, zu dem durchgeführten Update der betroffenen Webseite. Außerdem weist er nochmals auf die Zahlung der Prämie hin, die man doch an ihn zahlen solle, da er ja schließlich die vermeintliche Sicherheitslücke auf der Webseite entdeckt hat.

Es folgt nun die angeblich zuvor gesendete Mail, ca. vor einer Woche. Darin stellt sich Herr A. als „security researcher“ vor und macht dann auf die Sicherheitslücken der Webseite aufmerksam. Als Webseite nennt er auch tatsächlich die (Unternehmens)Webseite des Empfängers mit der dazugehörigen Domain.

Durch die Nennung der Domain, scheint es vielleicht auf den ersten Blick, eine ernsthaft zu nehmende E-Mail zu sein, auf die man auch sofort reagieren sollte. Zudem sendet Herr A. die Mail nicht nur an eine Mailadresse des Unternehmens, sondern auch zeitgleich an die zuständige Landesbehörde für Datenschutz.

Wir haben Ihnen hier einmal die E-Mail beigefügt, die Herr A. versendet:

Nachfolgend erscheint sein angeblicher Fund auf der Webseite, dass kein DMARC eingerichtet sei. Ebenfalls sendet er – professionell wie er ist – auch einen Snapshot des Tools, welches anzeigt, dass DMARC nicht aktiviert ist.

Dies sieht dann wie folgt aus:

Was ist zu tun?

Hier empfehlen wir Ihnen diese Mail – wenn nicht bereits geschehen – als Spam zu melden. Bitte reagieren Sie nicht auf die Mail und zahlen natürlich auch keine „Belohnung“ an Herrn A. für seine „Bemühungen“.

Zumal auch ein Verstoß gegen das „Gesetz gegen den unlauteren Wettbewerb“ (UWG) bei derartigen Praktiken in Betracht kommt. Dies sollte man unserer Meinung nach nicht noch unterstützen.

Sollten Sie solche E-Mails erhalten und sich nicht sicher sein, wie Sie damit umgehen, so steht Ihnen die GINDAT GmbH bei Fragen gerne zur Verfügung.

Nachfolgend erläutern wir Ihnen noch die Techniken zum Spam / Spoofing, sowie den Begriff „DMARC“.

E-Mail-Spoofing

Zur Vermeidung von Spam/Spoofing, gibt es mehrere Techniken, die ein Domainbesitzer anwenden kann.

Alle basieren darauf, dass der Besitzer Richtlinien vorgibt, die von den Empfängern dann ausgewertet werden und damit Mails in der Regel mit mehr oder weniger Wahrscheinlichkeit als Spam einstufen.

SPF (Sender Policy Framework)

Einrichtung:

Hier wird ein DNS Eintrag erstellt, in dem alle Systeme genannt werden, die für die Domain Mails versenden dürfen.

Hier definiert der Besitzer einer Domain, welche Systeme im Namen der Domain (nach dem @ Zeichen) Mails versenden dürfen.

Das sind in der Regel die Mailserver, aber auch Webserver oder Drittanbieter wie z.B. Newsletterversand-Dienstleister.

Die Einrichtung erfordert relativ wenig Aufwand, da nur eine Liste aller authorisierten Systeme aufgestellt werden und der DNS Eintrag erstellt werden muss.

Dienste-Anbieter haben in der Regel Anleitungen, wie der SPF angepasst werden muss, damit Mailversand über den jeweiligen Dienst funktioniert.

Probleme:

Es kann durch SPF eine Zahl an False Positives entstehen. Vor allem wenn Weiterleitungen auf Mailboxen eingerichtet sind.

Wenn der Server die Mail weiterleitet bleibt die Absenderadresse die Originaladresse, daher versendet dann z.B. ein T-Online Mailserver, Mails für die ursprüngliche Absenderdomain und dieser Server ist nicht im SPF autorisiert.

SPF darf nur eine begrenzte Zahl an weiteren DNS-Abfragen auslösen. Wenn also viele Drittanbieter-Dienste genutzt werden, die eigene SPF-Einträge inkludieren, kann es dazu kommen, dass der Eintrag nicht mehr korrekt aufgelöst wird.

Hier lohnt es sich bestimmte Dienste auf Subdomains abzuspalten, damit ein eigener SPF erstellt werden kann. (z.B. newsletter.domain.tld für Newsletterversand)

DKIM

Hier wird ein kryptografischer Schlüssel genutzt, mit dem die Mails beim Versand signiert werden.

Damit werden 2 Dinge sichergestellt:

  1. Die Mail kommt von einem System, das Zugriff auf den privaten Schlüssel hat und ist damit sehr wahrscheinlich authorisiert.
  2. Die Mail wurde im Nachhinein nicht verändert, da DKIM auch einen Hash des Inhalts und einiger Headerfelder beinhaltet.

Einrichtung:

Die Einrichtung ist aufwändiger, als bei SPF.

Hier wird ein DNS Eintrag erstellt, in dem der öffentliche Schlüssel publiziert ist, mit dem ein Empfänger dann die Signatur überprüfen kann.

Die Server, die Mails versenden, müssen die DKIM Signatur hinzufügen. Einige Mailsysteme, wie z.B. Microsoft Exchange unterstützen DKIM aber nicht von Haus aus, hier müssen dann Drittanbieter-Lösungen genutzt werden.

Sollte man eine zentrale Email-Security-Lösung nutzen (vor allem Cloud Services), kann diese oft die DKIM Signatur übernehmen. Hier kann dann zentral für alle Mails, die über den Service versendet werden, die Signatur hinzugefügt werden.

Drittanbieter wie Newsletterversand-Dienstleister, haben in der Regel eigene DKIM Keys, deren DNS Eintrag man einfach seiner Domain hinzufügen kann.

Probleme:

Grundsätzlich sollte eine DKIM Signatur beim Weiterleiten einer Mail erhalten bleiben, da sich weder der Nachrichteninhalt, noch die (signierten) Header ändern. Damit ist das false Postivie Problem von SPF hier nicht gegeben.

Einige Systeme (Microsoft Exchange) ändern allerdings beim Durchgang der Mail tatsächlich die Header Felder und sorgen so für fehlschlagendes DKIM nach einer Weiterleitung.

DMARC

DMARC baut auf den beiden Techniken SPF und DKIM auf und definiert, wie die beiden Richtlinien vom Empfänger interpretiert werden sollen.

Generell sieht DMARC Mails als autorisiert an, wenn einer der beiden Mechanismen erfolgreich war. Somit kann die Zahl der False Positives reduziert werden und gleichzeitig Spoofing bekämpft werden.

Einrichtung:

Sobald SPF und DKIM bereits implementiert sind ist die Einrichtung sehr einfach.

Es muss nur ein DNS Eintrag mit den gewünschten Richtlinien erstellt werden.

Hinweis zu Cookies

Unsere Website verwendet Cookies. Einige davon sind technisch notwendig für die Funktionalität unserer Website und daher nicht zustimmungspflichtig. Darüber hinaus setzen wir Cookies, mit denen wir Statistiken über die Nutzung unserer Website führen. Hierzu werden anonymisierte Daten von Besuchern gesammelt und ausgewertet. Eine Weitergabe von Daten an Dritte findet ausdrücklich nicht statt.

Ihr Einverständnis in die Verwendung der Cookies können Sie jederzeit widerrufen. In unserer Datenschutzerklärung finden Sie weitere Informationen zu Cookies und Datenverarbeitung auf dieser Website. Beachten Sie auch unser Impressum.

Technisch notwendig

Diese Cookies sind für die einwandfreie Funktion der Website erforderlich und können daher nicht abgewählt werden. Sie zählen nicht zu den zustimmungspflichtigen Cookies nach der DSGVO.

Name Zweck Ablauf Typ Anbieter
CookieConsent Speichert Ihre Einwilligung zur Verwendung von Cookies. 1 Jahr HTML Website
fe_typo_user Dieser Cookie wird gesetzt, wenn Sie sich im Bereich myGINDAT anmelden. Session HTTP Website
PHPSESSID Kurzzeitiger Cookie, der von PHP zum zwischenzeitlichen Speichern von Daten benötigt wird. Session HTTP Website
__cfduid Wir verwenden eine "Content Security Policy", um die Sicherheit unserer Website zu verbessern. Bei potenziellen Verstößen gegen diese Policy wird ein anonymer Bericht an den Webservice report-uri.com gesendet. Dieser Webservice lässt über seinen Anbieter Cloudflare diesen Cookie setzen, um vertrauenswürdigen Web-Traffic zu identifizieren. Der Cookie wird nur kurzzeitig im Falle einer Bericht-Übermittlung auf der aktuellen Webseite gesetzt. 30 Tage/ Session HTTP Cloudflare/ report-uri.com
Statistiken

Mit Hilfe dieser Statistik-Cookies prüfen wir, wie Besucher mit unserer Website interagieren. Die Informationen werden anonymisiert gesammelt.

Name Zweck Ablauf Typ Anbieter
_pk_id Wird verwendet, um ein paar Details über den Benutzer wie die eindeutige Besucher-ID zu speichern. 13 Monate HTML Matomo
_pk_ref Wird verwendet, um die Informationen der Herkunftswebsite des Benutzers zu speichern. 6 Monate HTML Matomo
_pk_ses Kurzzeitiger Cookie, um vorübergehende Daten des Besuchs zu speichern. 30 Minuten HTML Matomo
_pk_cvar Kurzzeitiger Cookie, um vorübergehende Daten des Besuchs zu speichern. 30 Minuten HTML Matomo
MATOMO_SESSID Kurzzeitiger Cookie, der bei Verwendung des Matomo Opt-Out gesetzt wird. Session HTTP Matomo
_pk_testcookie Kurzzeitiger Cookie der prüft, ob der Browser Cookies akzeptiert. Session HTML Matomo