E-Mail-Codierung: Ich sehe was, was du nicht siehst ...

E-Mail-Codierung:
Ich sehe was, was du nicht siehst ...

E-Mails lassen sich so codieren, dass verschiedene Programme unterschiedlich mit ihnen umgehen. Das kann dazu führen, dass ein Virenscanner eine Mail auf die eine Weise interpretiert und keine Malware entdeckt, das Mailprogramm des Empfängers jedoch die Mail auf eine andere Weise interpretiert und die Malware damit verfügbar macht. Diese Fälle gibt es in der Praxis tatsächlich, wie wir hier anhand konkreter Beispiele zeigen.

Vor langer langer Zeit, als das Internet noch klein und unbedeutend war, wurde das Konzept von elektronischer Post erfunden: die E-Mail. Ursprünglich konnten damit nur Texte übertragen werden und auch nur im Zeichensatz ASCII, also ohne deutsche Umlaute oder gar chinesische Schriftzeichen.

Doch nach ein paar Jahren stellte sich heraus, dass man gerne mehr hätte und so wurde der MIME-Standard entwickelt, der die Nutzung anderer Zeichensätze und auch Dateianhänge ermöglichte. Um aber die Kompatibilität zu bestehenden Systemen zu gewährleisten, wurden diese neuen Eigenschaften vom Sender in das alte Format gepackt. Das heißt, eine E-Mail bestand weiterhin für den Transport nur aus ASCII-Zeichen und wurde dann vom Mailprogramm des Empfängers wieder decodiert um so Umlaute anzuzeigen und Zugriff auf angehängte Dateien zu erlauben.

Allerdings kann man Mails konstruieren, die fehlerhaft mit MIME codiert sind und bei denen das Resultat der Decodierung abhängig von der jeweiligen Software-Implementation ist. Das kann zum Beispiel dazu führen, dass ein Virenscanner die Mail auf die eine Weise interpretiert und keine Malware entdeckt, das Mailprogramm des Empfängers jedoch die Mail auf eine andere Weise interpretiert und die Malware damit verfügbar macht. Und diese Fälle gibt es in der Praxis tatsächlich, wie an einigen Beispielen gezeigt werden soll.

Einführung in die MIME-Codierung

Um die Beispiele zu verstehen, muss man ein paar Grundlagen der MIME-Codierung kennen. Diese demonstrieren wir mit einer Mail, welche den EICAR-Testvirus als Dateianhang beinhaltet. Codiert mit MIME sieht diese Mail wie folgt aus:

From: angreifer@example.com
To: opfer@example.com
Subject: Das ist ein Virus
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary=foo

--foo
Content-type: application/octet-stream; name="eicar.com"
Content-Transfer-Encoding: base64

WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLV
NUQU5EQVJELUFOVElWSVJVUy1URVNULUZJTEUhJEgrSCo=
--foo--

Erkennbar sind bei dieser Mail zwei wesentliche Punkte, die es ermöglichen, eine strukturierte Mail mit binären Dateianhängen in reinen ASCII-Text umzuwandeln:

  • Durch Nutzung eines Content-Transfer-Encoding können Daten so umgewandelt werden, dass sie nur noch ASCII-Zeichen enthalten und auch die Zeilenlänge begrenzt ist. Für binäre Daten wird üblicherweise die Base64-Codierung benutzt, während bei Text mit nur wenigen Umlauten oder langen Zeilen Quoted-Printable benutzt wird.
  • Mit einem Content-Type von "multipart/..." wird definiert, dass die Mail aus mehreren Teilen besteht. Die Trennung zwischen diesen Teilen erfolgt durch das angebene Boundary. In diesem Falle bedeutet das Boundary von "foo", dass als Trenner zwischen den Teilen eine Zeile mit "--foo" fungiert und dass der letzte Teil mit "--foo--" abgeschlossen wird. Basierend auf diesen Grundlagen erkennt man vielleicht schon, dass es prinzipiell möglich ist, widersprüchliche Angaben zum Content-Transfer-Encoding oder Boundary zu machen. Und wo Widersprüche existieren, sind verschiedene Interpretationen möglich.

Widersprüchliche Angaben zum Encoding

Es ist möglich, verschiedene Angaben zum Content-Transfer-Encoding zu machen, wie folgender Auszug aus einer entsprechend manipulierten Mail zeigt:

Content-type: application/octet-stream; name="eicar.com"
Content-Transfer-Encoding: base64
Content-Transfer-Encoding: quoted-printable

WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVEl
WSVJVUy1URVNULUZJTEUhJEgrSCo=


Hier wurde zum einen behauptet, dass die Daten mit base64 codiert sind, zum anderen aber wurde quoted-printable behauptet. Tatsächlich sind die Daten base64 codiert, aber je nach benutztem Mailprogramm fällt die Interpretation unterschiedlich aus: Die meisten (wie z. B. das verbreitete Thunderbird) benutzen die erste Angabe und sehen damit den Virus. Aber einige benutzen die zweite Angabe und sehen daher nur Müll als Dateianhang.

"Sie war über das Aussehen ihrer Großmutter erstaunt." (Illustration von Gustave Doré)

Interessant wird es, wenn man die Virenscanner oder Intrusion Detection und Prevention Systeme (IDS/IPS) untersucht, welche ja den eigentlichen Empfänger vor Gefahren schützen sollen. So benutzt das in vielen kommerziellen Produkten zu findende IDS snort die zweite Angabe (also quoted-printable) und findet daher die Malware nicht. Und eine Untersuchung verschiedener Virenscanner mit Hilfe von virustotal zeigt, dass etwa ein Drittel der Scanner ebenfalls nur auf die letzte Angabe vertraut und damit die Malware nicht findet.

Bei der Untersuchung von Webmailern zeigte sich interessantes Verhalten bei AOL-Mail und Yahoo!-Mail. In beiden Fällen benutzte der eingebaute Virenscanner die letzte Angabe und sah daher die Malware nicht. Die Webmail-Applikation hingegen selber benutzte zur Anzeige und zum Download die erste Angabe, wodurch man ohne Probleme die Malware herunterladen konnte.

Widersprüchliche Angaben zum Boundary

Auch der Trenner zwischen den einzelnen Teilen einer Mail kann genutzt werden, um Mails zu erzeugen, die auf unterschiedliche Weise interpretiert werden können:

Mime-Version: 1.0
Content-type: multipart/mixed; boundary=foo
Content-type: multipart/mixed; boundary=bar

--foo
Content-type: text/plain

--bar
Content-type: application/octet-stream; name=eicar.com

Content-Transfer-Encoding: base64


WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVEl
WSVJVUy1URVNULUZJTEUhJEgrSCo=
--bar--
--foo--

Hier werden zwei verschiedene Trenner definiert und auch eingesetzt. Und natürlich sind sich auch hier die untersuchten Programme nicht einig, welches denn nun die korrekte Angabe ist. Einige benutzten die erste Angabe und sehen daher nur den folgenden Müll als Inhalt der Mail:

--bar
Content-type: application/octet-stream; name=eicar.com
Content-Transfer-Encoding: base64

WDVPIVAlQEFQWzRcUFpYNTQoUF4pN0NDKTd9JEVJQ0FSLVNUQU5EQVJELUFOVEl
WSVJVUy1URVNULUZJTEUhJEgrSCo=
--bar--

Andere benutzen die zweite Angabe und sehen daher die Malware. Auffällig ist wieder, dass sich IDS wie snort anders als typische Mailprogramme wie Thunderbird verhalten und dass sie daher nicht geeignet sind, entsprechende Empfänger zu schützen. Und beim Testen von Webmailern ist aufgefallen, dass bei GMX der Virenscanner die erste Angabe benutzt und die Malware nicht sieht, die Webmail-Applikation hingegen die zweite Angabe verwendet und dadurch Zugriff auf die Malware bietet.

Was kann man dagegen tun?

Eine Möglichkeit wäre es, im Virenscanner oder IDS alle möglichen Varianten der Umgehung zu berücksichtigen und sämtliche Kombinationsmöglichkeiten auszuprobieren. Das wären jedoch alleine bei den hier gezeigten Beispielen vier Möglichkeiten und die Menge an Varianten steigt mit jeder Interpretationsmöglichkeit rapide an.

Eine Alternative wäre es daher, potentielle Umgehungsversuche zu finden und in diesem Fall die Daten als gefährlich einzustufen. Damit steigt jedoch das Risiko, aus Versehen gutartige, wenn auch ungewöhnlich codierte Daten als gefährlich einzustufen. Die Firewall genugate wehrt die hier beschriebenen Angriffe ab, indem entweder offensichtlich kaputte Mails als Umgehungsversucht blockiert werden oder aber die widersprüchlichen Angaben vor der Weiterleitung entfernt werden. Letzteres führt dazu, dass die Firewall und der Empfänger die Mail in der gleichen Weise interpretieren – also entweder den Dateianhang sehen oder harmlosen Datenmüll.

Weiterführende Informationen

Auf der Webseite des Autors sind (in Englisch) weitere Möglichkeiten der Umgehung beschrieben bzw. die hier aufgeführten Beispiele detaillierter ausgeführt, insbesondere:

Lesen Sie auch: Firewalls – schnell oder sicher?

Bildquelle: © fotohansel/Fotolia.com


Diskutieren Sie mit

Sie können diesen Artikel sofort ohne Registrierung als Gast-User kommentieren.

Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.



Registrieren Sie sich jetzt! Mit einem User Account genießen Sie Vorteile:
Ihr Kommentar wird sofort im genublog veröffentlicht und Sie werden über Reaktionen auf Ihre Kommentare informiert.

Bereits registrierte User gelangen hier zum Login.