Deshalb können E-Mails gefälscht werden

Manchmal ist es einfach, Phishing-E-Mails zu erkennen, indem man den Absender kontrolliert. Dies ist jedoch nicht immer der Fall. Es ist möglich, eine gefälschte E-Mail wie eine Echte aussehen zulassen. Wenn ein Angreifer weiß, wie man so etwas macht, ist das Ziel wirklich in Schwierigkeiten. Die meisten Leute hätten sich sowieso keine Gedanken beim Öffnen von schädlichen Links oder Dateien gemacht, die sie in einer E-Mail scheinbar von ihrem Chef oder ihrem Top-Kunden erhalten haben. Es ist nämlich schwer, ihnen die Schuld zu geben, besonders wenn es keine Möglichkeit gibt, um gefälschte Mails von echten E-Mails zu unterscheiden

Aber warum ist es überhaupt möglich, eine perfekt gefälschte E-Mail zu erstellen? Andrew Konstantinovs Vortrag über die E-Mail-Authentifizierung für Penetrationstester auf dem 36. Chaos Communication Congress beantwortet genau diese Frage und gibt einen Einblick auf die Wirksamkeit des Schutzes vor E-Mail-Spoofing.

Problem 1: Die E-Mail muss ankommen

E-Mail ist eine der wichtigsten Kommunikationsmethoden der modernen Welt und jedes Unternehmen ist im täglichen Betrieb stark auf die E-Mail angewiesen. Obwohl wir bei einem reibungslosen Ablauf nicht viel über die Technologie nachdenken, können Sie sich sicher sein, dass jeder das Verschwinden einer E-Mail bemerken wird. Daher hat die Zuverlässigkeit in der Regel oberste Priorität für jeden E-Mail-Server-Administrator. Die E-Mail muss einfach gesendet und zugestellt werden, egal was passiert.

Dies impliziert, dass der E-Mail-Server jeder Organisation so kompatibel wie möglich mit allen anderen Elementen der Welt sein muss. Und darin liegt das Problem: E-Mail-Standards sind stark veraltet.

Problem 2: Das E-Mail-Protokoll ohne Authentifizierung

Das Hauptprotokoll, das sowohl für die Client-zu-Server- als auch für die Server-zu-Server-E-Mail-Kommunikation verwendet wird, ist SMTP. Dieses Protokoll wurde erstmals 1982 eingeführt und zuletzt im Jahr 2008 aktualisiert, also vor gut mehr als einem Jahrzehnt. Und wie viele andere alte Standards ist SMTP ein Sicherheits-Albtraum.

Schauen wir uns zunächst an, woraus die typische E-Mail-Nachricht besteht:

• SMTP-Umschlag: Dieser Teil wird für die Server-zu-Server-Kommunikation verwendet und wird in E-Mail-Clients niemals angezeigt. Es gibt die Absender- und Empfängeradressen an.
• Headers: Die E-Mail-Clients zeigen die Headers an. Hier finden Sie die vertrauten Felder „Von“, „An“, „Datum“ und „Betreff“, die Sie in jeder E-Mail sehen.
• Nachricht: Der E-Mail-Text und andere Inhalte.

Inhalt einer E-Mail-Nachricht. Bildquelle

Das Hauptproblem des Standards ist die fehlende Authentifizierungsmöglichkeit. Die Verantwortung für das Adressfeld des Absenders – sowohl im SMTP-Umschlag als auch im Header – liegt vollständig beim Server des Absenders. Was noch schlimmer ist, die Adresse des Absenders im SMTP-Umschlag muss nicht mit der im Header übereinstimmen (und der Benutzer sieht nur letzteres).

Obwohl der Standard einen Header pro E-Mail festlegt, begrenzt SMTP das Limit des Headers nicht. Wenn eine Nachricht mehr als einen Header enthält, wählt der E-Mail-Client einfach eine aus, die dem Benutzer angezeigt werden soll.

Man braucht keinen professionellen Hacker, um hier viel Raum für Probleme zu sehen.

Das E-Mail-Protokoll bietet keine Möglichkeit, sicherzustellen, dass eine E-Mail tatsächlich vom angegebenen Absender stammt

Problem 3: Eingehende und ausgehende Fake Mails

Um die Sache noch komplizierter zu machen, sind an jeder E-Mail-Kommunikation zwei Parteien beteiligt, sodass sich dieses Nichtauthentifizierungsproblem in zwei Teilprobleme aufteilt.

Einerseits möchten Sie auf jeden Fall sicher sein, dass alle E-Mails, die Sie erhalten, tatsächlich von der angegebenen Adresse gesendet wurden. Andererseits möchten Sie wahrscheinlich verhindern, dass andere Personen E-Mails senden, die scheinbar von Ihrer Adresse stammen. Leider kann der Standard bei all dem nicht helfen.

Es ist keine Überraschung, dass das SMTP-Protokoll so häufig missbraucht wurde und deshalb neue Technologien entwickelt wurden, um die oben genannten Mängel zu beheben.

Lösungsversuch Nr. 1: Sender Policy Framework (SPF)

Die Idee hinter dem Sender Policy Framework ist ziemlich einfach: Der empfangende E-Mail Server überprüft, ob die Adresse des einliefernden Servers mit der Adresse des echten E-Mail-Servers übereinstimmt, der der Domäne zugeordnet ist.

Das ist leichter gesagt als getan. Der SMTP-Standard hat keine Möglichkeit, eine solche Prüfung durchzuführen, daher müsste jede Authentifizierungsmethode zusätzlich zu den vorhandenen Informationen hinzugefügt werden. Es dauerte ein Jahrzehnt, bis diese Technologie zum „vorgeschlagenen Standard“ wurde. Heutzutage verwenden nur etwa 55% der Top-1-Million-Server SPF, und die meisten verwenden recht lockere Richtlinien.

SPF ist auch hier mit vielen anderen Problemen konfrontiert, wie z. B. einer unübersichtlichen Architektur, die leicht zu Fehlkonfigurationen führt oder bestimme Umgehungsmöglichkeiten für andere Server, die sich auf derselben Adresse befinden schafft, usw. Der schwerwiegende Fehler von SPF besteht darin, dass nur die im SMTP-Umschlag angegebene Adresse überprüft wird und das Feld „Von“ in der Kopfzeile – das Feld, das ein Benutzer tatsächlich sieht – vollständig ignoriert wird.

Ergebnis:

• Mit SPF können Sie überprüfen, ob eine E-Mail von einem echten Server stammt.
• Die für Benutzer sichtbare Adresse kann weiterhin gefälscht werden.

Lösungsversuch Nr. 2 : DomainKeys Identified Mail (DKIM)

DomainKeys Identified Mail geht das Problem anders an: DKIM signiert den Nachrichten-Header und einen Teil des Nachrichtentexts kryptografisch mit einem privaten Schlüssel. Die Signatur kann dann mit einem öffentlichen Schlüssel überprüft werden, der im Domain Name System veröffentlicht ist.

Erwähnenswert ist jedoch, dass DKIM nicht die gesamte Nachricht verschlüsseln soll. Vielmehr wird ein kryptografisch signierter Anhang angehängt. Das ist ein Problem. Der kryptografische Teil ist schwer zu ändern, aber das vollständige Löschen der Signatur und das Erstellen einer gefälschten Nachricht ist einfach – und die Ergebnisse sind nicht nachweisbar.

DKIM ist schwer zu implementieren, da kryptografische Schlüssel ausgegeben und verwaltet werden müssen. Durch falsch konfiguriertes DKIM kann ein Angreifer außerdem die echte DKIM-Signatur in einer Nachricht beibehalten und gleichzeitig den Header und den Text vollständig ändern.

Ergebnis:

• Mit DKIM können Sie Nachrichten digital signieren und so sicherstellen, dass der empfangende Server wirklich eine Nachricht von Ihnen erhalten hat.
• Die Implementierung ist schwierig, da die Verwaltung von kryptografischen Schlüsseln erforderlich ist.
• Betrüger können die Signatur einfach löschen, während sie eine E-Mail in Ihrem Namen fälschen.
• Bestimmte Fehlkonfigurationen können zu gefälschten Nachrichten führen, die echte DKIM-Signaturen enthalten.

Lösungsversuch Nr. 3: Domain-based Message Authentication, Reporting and Conformance (DMARC)

Trotz des langen Namens ist das DMARC-Protokoll leichter zu verstehen als SPF oder DKIM. Es ist eine Erweiterung der beiden, die ihre auffälligsten Schwachstellen behebt.

Zunächst hilft DMARC dem Domänenadministrator bei der Festlegung des vom Server verwendeten Schutzmechanismus (SPF, DKIM oder beides), wodurch der die Fehler des DKIM-Mechanismus wirklich behebt. Zweitens wird auch SPF behoben, indem die im Feld „Von“ des Headers angegebene Adresse (die für einen Benutzer tatsächlich sichtbare Adresse) zusätzlich zur Absenderadresse im SMTP-Umschlag überprüft wird.

Der Nachteil ist, dass das DMARC-Protokoll relativ neu ist, noch kein richtiger Standard ist (RFC 7489 definiert es nicht als Standard oder als vorgeschlagenen Standard, sondern nur als „informativ“) und nicht so weit verbreitet ist, wie es sein sollte. Laut dieser Studie mit 20.000 Domains hatten bis 2019 nur 20% DMARC eingeführt, und nur 8,4% hatten strenge Richtlinien.

Leider ist DMARC noch nicht weit verbreitet und wird in vielen Fällen mit ohne Richtlinien verwendet. Bildquelle

Ergebnis:

• Behebt die wichtigsten Probleme von SPF und DKIM.
• Noch nicht weit verbreitet und daher nicht so effektiv wie es sein könnte.

So schützen Sie sich vor E-Mail-Spoofing

Zusammenfassend lässt sich sagen, dass das Fälschen von E-Mails immer noch möglich ist, da das SMTP-Protokoll nicht unter Sicherheitsaspekten entwickelt wurde, sodass ein Angreifer die Adresse eines beliebigen Absenders in eine gefälschte E-Mail einfügen kann. In den letzten Jahrzehnten sind bestimmte Schutzmechanismen entstanden – SPF, DKIM und DMARC. Damit diese Mechanismen jedoch effektiver sind, müssen sie von möglichst vielen E-Mail-Servern verwendet und korrekt implementiert werden, was leider noch nicht der Fall ist.

Darüber hinaus ist es wichtig zu berücksichtigen, dass einige Mail-Relay-Server aufgrund von Konfigurationsfehlern möglicherweise etwas zu den Buchstaben hinzufügen. Dadurch wird die DKIM-Prüfung automatisch nicht bestanden. Auch darf nicht vergessen werden, dass diese Technologien bei der Bewältigung von Massenbedrohungen hilfreich sind. Um Ihr Unternehmen jedoch vor raffinierten E-Mail-Angriffen zu schützen, sollten Sie sowohl auf Workstations als auch auf dem Mailserver zusätzliche Schutzlösungen einsetzen.

Hier einige Empfehlungen für den E-Mail-Schutz:

• Nutzen Sie mindestens SPF. Stellen Sie sicher, dass es richtig konfiguriert ist. Denken Sie auch daran, dass findige Angreifer den SPF umgehen können (weitere Details im Vortrag).
• Implementieren Sie DKIM für einen besseren Schutz. Es mag etwas schwieriger sein, aber es lohnt sich, darüber nachzudenken. Und noch einmal, stellen Sie sicher, dass es richtig konfiguriert ist (einige Tipps, wonach Angreifer suchen).
• Nutzen Sie im Idealfall DMARC, da es die meisten ausnutzbaren Fehler von SPF und DKIM behebt.
• Überprüfen Sie Ihre Konfiguration auch auf eingehende E-Mails.
• Verwenden Sie Sicherheitslösungen, die moderne Authentifizierungsmechanismen unterstützen. Verwenden Sie beispielsweise Kaspersky Security for Mail Server oder Kaspersky Security for Microsoft Office 365.