März 14, 2024
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Offence: Was ist E-Mail Spoofing? „Der Absender ist doch echt …“
E-Mail Spoofing oder Spoofing bezeichnet das Handeln z.B. eines Hackers, wenn dieser vorgibt eine E-Mail im Namen einer Firma bzw. Domäne zu verschicken, der er nicht angehörig ist. Ein kleines Beispiel dazu: Es wird im Namen von Telekom.de eine Rechnung an Firmen oder Privatpersonen verschickt, diese Rechnung kommt jedoch nicht von der Telekom, sondern vom Hacker. Die Domäne sieht jedoch beim genaueren Hinschauen richtig aus. Wie kann das also sein?
Da es sich bei E-Mail um eine Form der Kommunikation handelt, die dezentral das Senden und Empfangen von Nachrichten über Protokolle wie SMTP ermöglicht, gibt es keine zentrale Stelle, die gesendete Nachrichten auf Validität prüfen kann. Das führt dazu, dass sich Absender-Adressen leicht fälschen lassen. Dies muss man sich vorstellen wie das Eintragen einer falschen Absender-Adresse auf einem Brief. Für den Empfänger ist es ohne weitere Maßnahmen und Prüfungen nicht möglich zu bewerten, ob ein Brief tatsächlich vom angegebenen Absender versendet wurde. Bei E-Mails verhält es sich grundlegend genauso.
Für den Versand von E-Mails benötigt man grundsätzlich keinen E-Mail Server. Wir bedienen uns hier beispielsweise des Tools swaks
swaks --to y.knoll@prosec-networks.com --from spoofuser@spoofdomain.de --h-From: '"Spoof User" ' --server 104.47.7.138 -p 25 --header "Subject:Titel der E-Mail" --body ‘Guten Tag,\n\ndies ist der Start des Mailtests.\n\nMfg Spoof User’ --ehlo spoofdomain.com
| –to | E-Mail-Adresse des Empfängers |
| –from | E-Mail-Adresse des Absenders |
| –h-From | Anzeigename des Absenders bzw. gespoofte E-Mail-Adresse |
| –server | Der Mailserver der empfangenden Domäne |
| –header | Header Teil der E-Mail kann hier angepasst werden, primär geht es hierbei um das „Subject“ bzw. Betreff Feld |
| –body | Hier kann der Inhalt der E-Mail definiert werden |
| –ehlo | Name mit welchem der Absender sich beim empfangenden Mailserver anmeldet |
Beim Empfänger der E-Mail wird diese dann wie folgt angezeigt:
Technisch im Hintergrund sieht der Versand der E-Mail so aus:
So einfach?
Nein, ganz so einfach ist es nicht. Es müssen gewissen Voraussetzungen bzw. Fehlkonfigurationen gegeben sein, damit die Mail des Hackers nicht im Spam Ordner landet oder gar nicht ankommt.
Hierzu gibt es zwei DNS-Records, die eine Domäne hinterlegt haben sollte, damit ein solcher Spoofing Vorgang nicht möglich ist. Hierbei handelt es sich zum einen um den Sender Policy Framework (SPF) Record sowie den DomainKeys Identified Mail (DKIM) Record.
Das Sender Policy Framework (SPF) ist ein Verfahren, mit dem Mailserver überprüfen können, ob eine erhaltene E-Mail tatsächlich von einem berechtigtem Server stammt. Hierbei handelt es sich um einen vollautomatischen Mechanismus, welcher vom Endanwender unbemerkt ausgeführt wird.
Beispiel für einen SPF-Record
Hostname | Typ | Time to Live | Wert |
Example.org | TXT | 1 Stunde | v=spf1 ip4:192.0.0.1 ip4:192.0.0.2 -all |
Ein solcher Eintrag muss am DNS-Server der versendenden Domain hinterlegt werden. Den ersten Teil bildet der Hostname. Hierbei handelt es sich um die Domain oder Subdomain, für die der Record gilt. Typ beschreibt die Art von Eintrag. SPF Records werden als TXT Typ eingetragen. Time to Live weist den DNS Server an, den DNS Record für eine bestimmte Zeit im Cache zu halten.
Der Wert ist die eigentliche SPF-Syntax. Der Parameter „v“ beschreibt die genutzte SPF-Version, in diesem Falle Version 1. Danach werden im Beispiel zwei IPv4 Adressen als Adressen von Mailservern genannt. Hier könnten auch andere Einträge gesetzt werden wie z.B. A oder AAAA („a“) Mailserver-Records („mx“). Zudem können mit IP4 oder IP6 nicht nur einzelne IP-Adressen, sondern auch IP-Ranges angegeben werden.
Den Abschluss der SPF-Syntax bildet eine Direktive, die dem prüfenden Mail-Server Empfehlungen gibt, wie er mit E-Mails umgehen soll, die einen SPF-Check nicht bestehen. Im Falle des Beispiels wird empfohlen, dass der Mail-Server alle geprüften E-Mails, die nicht den Kriterien des SPF-Records entsprechen, als „Fail“ („-„) behandeln und gar nicht zustellen soll. Es gibt zusätzlich die Möglichkeit, einen „Softfail“ („~“) „Neutral“ („?“) oder „Pass“ („+“) zu definieren.
DKIM (DomainKeys Identified Mail) ist eine Methode der E-Mail-Authentifizierung. Durch DKIM werden versendete E-Mails signiert. Hierzu wird ein Schlüsselpaar aus öffentlichem und privatem Schlüssel verwendet. Der öffentliche Schlüssel wird als DNS-Eintrag am DNS-Server der versendenden Domain hinterlegt. Empfangende Mailserver können dann unter Zuhilfenahme dieses öffentlichen Schlüssels prüfen, ob die Signatur mit dem entsprechenden privaten Schlüssel erfolgt ist. Ein Versender einer E-Mail kann dadurch beweisen, dass seine E-Mail tatsächlich eine legitime E-Mail der entsprechenden Domain ist.
Wenn eine E-Mail versendet wird, fügt DKIM eine sogenannte DKIM-Signatur zum Header der E-Mail hinzu. Hierbei werden „Header“ der versendeten E-Mail mittels des privaten Schlüssels signiert. Es muss mindestens der „from“-Header als Signatur verwendet werden, weitere Header können optional ergänzt werden.
Wenn die E-Mail empfangen wird, fragt der empfangende Server den öffentlichen Schlüssel ab. Nur, wenn der Versender im Besitz des privaten Schlüssels ist, lässt sich die Signatur validieren. Der Empfänger kann dann prüfen, ob die Signatur mit der Prüfsumme übereinstimmt. Wenn die Übereinstimmung vorliegt, ist bewiesen, dass der Versender im Besitz des privaten Schlüssels des DKIM-Schlüsselpaars ist und somit sehr wahrscheinlich ein legitimer Absender ist.
Beispiel DKIM-Signatur:
v=1; a=rsa-sha256; d=example.net; s=brisbane;
c=relaxed/simple; q=dns/txt; i=foo@eng.example.net;
t=1117574938; x=1118006938; l=200;
h=from:to:subject:date:keywords:keywords;
z=From:foo@eng.example.net|To:joe@example.com|
Subject:demo=20run|Date:July=205,=202005=203:44:08=20PM=20-0700;
bh=MTIzNDU2Nzg5MDEyMzQ1Njc4OTAxMjM0NTY3ODkwMTI=;
b=dzdVyOfAKCdLXdJOc9G2q8LoXSlEniSbav+yuU4zGeeruD00lszZ
VoG4ZHRNiYzR
Quelle: Wikipedia
v: Version
a: Signatur Algorithmus, in diesem Fall RSA mit einem SHA 256-Hash
d: Domain des Versenders
s: Selektor. Identifikation des entsprechenden Records in den DNS-Einträgen. Dieser wird benötigt, wenn für eine Domain mehrere SPF-Record veröffentlicht werden
c: Canonicalization. Gibt an, wie strikt die Signaturprüfung erfolgt. Hier kann jeweils für die Optionen Header und Body der Wert „simple“ oder „relaxed“ angegeben werden. Bei diesen potentiellen Veränderungen handelt es sich um Änderungen an E-Mail-Header oder Body, die beim Versenden vom E-Mail-Server selbst vorgenommen werden. Die Option „simple“ sagt aus, dass nahezu keine Änderungen akzeptiert werden dürfen. Schon kleine Änderungen führen dann zum Fehlschlagen der Signaturprüfung. Die Option „relaxed“ lässt moderate Änderungen zu. Hierbei kann es sich z.B. um eine Konvertierung zu Lower Case und eine Entfernung von unnötigen Leerzeichen handeln.
q: Query-Methoden. Definiert das Verfahren, über das der öffentliche Schlüssel erfragt wird. Standardwert ist „dns/txt“
i: Identität des Senders
t: Timestamp der Signatur
x: Verfallszeitpunkt der Signatur
l: Body length count. Beschreibt die Anzahl der Oktette im Body, die Teil des Signatur-Hashes sind
h: Signed Header Fields. Gibt die Header-Felder an, für die die Signatur gebildet wird. Diese müssen mindestens das „from“-Feld enthalten. Weitere Header sind optional
z: Copied Header fields. Kopien der signierten Header
bh: Der Hash des Message-Bodies, entsprechen der Länge angegeben durch „l“
b: Der Hash gebildet aus den Header-Feldern
Beispiel eines DKIM-Eintrags:
Hostname | Typ | Time to live | Wert |
Mail._domainkey.example.com | TXT | 1 Stunde | v=DKIM1; p=76E629F05F70 |
Unter dem Hostnamen finden wir einen Eintrag, der sich in den Selektor „Mail“, den festen Part „_domainkey“ und den Domainname „example.com“ aufteilt. Über diesen Namen kann ein empfangender Server den Public Key anfragen. Der Eintrag stellt dann die eigentliche DKIM-Syntax dar. „v=DKIM1; p=76E629F05F709EF665853333EEC3F5ADE69A2362BECE40658267AB2FC3CB6CBE“
teils sich auf in den Parameter v, der für die genutzte DKIM-Version steht, und den Parameter „p“, der den öffentlichen Schlüssel angibt. Häufig findet man in DKIM-Records noch den Parameter k, der das Signierungs-Verfahren angibt.
Leadership vs. Management, wo genau liegen da die Unterschiede? Und was braucht es in beiden Bereichen, um den aktuellen Herausforderungen
Sollten Standard-Nutzer in deinem Tenant eine Azure App Registration durchführen dürfen? Die Antwort ist ganz klar “Nein” und dieser Artikel
Die schlechte Nachricht vorweg: In Deutschland gibt es keine zentrale landesweite Notrufnummer für gehackte Unternehmen oder Behörden. Darum ist es
