zurück zum Artikel

Angriff via Mail

Stefan Frei

Eine Untersuchung zeigt, dass sich viele Mail-Server großer Firmen als Multiplikatoren für eine neue Art von Denial-of-Service-Angriff missbrauchen lassen.

Das Mail-Protokoll SMTP ist auf Robustheit ausgelegt, also darauf, dass keine Mails verloren gehen. Deshalb reglementieren die zugehörigen RFCs die Aufgaben und Zuständigkeitsbereiche der Mail-Server recht genau -- auch und gerade für den Fall, dass etwas schief läuft. Gerade diese Robustheit nutzt eine neue Art von Denial-of-Service-Angriffen, bei denen die Opfer mit tausenden von Benachrichtigungs-Mails bombardiert werden.

Kann ein Mail-Server eine Mail, für die er die Zuständigkeit übernommen hat, nicht zustellen, muss er den Absender über dieses Problem informieren (RFC-821, Seite 22). Dies geschieht normalerweise in Form einer so genannten Non-Delivery-Notification (NDN), die in etwa besagt: "Ihre Mail an NoName@irgendwo mit dem Betreff 'soundso' konnte nicht zugestellt werden." Je nach Mail-Server und dessen Konfiguration enthält diese NDN-Mail auch noch Teile des Originals.

Diese NDN geht an den Absender; konkret an die Mail-Adresse, die als "From" im Envelope der Mail angegeben wurde. Diese Adresse lässt sich beliebig fälschen, sodass der Mail-Server unter Umständen NDNs an unbeteiligte Dritte senden, die mit der Urspungs-Mail nichts zu tun haben. Nahezu jeder hatte solche Mails schon in seinem Postfach, wenn ein Virus sich mit seiner Absenderadresse an andere verschickte. Das ist schlimm genug -- richtig böse wird es jedoch, wenn Angreifer es schaffen, mit einer einzigen Mail tausende von NDNs auszulösen. Unsere Untersuchungen [1] haben gezeigt, dass genau das möglich ist.

Das SMTP-Protokoll sieht vor, eine E-Mail in einer SMTP-Sitzung gleichzeitig an mehrere Empfänger weiterzuleiten (CC, BCC). Dazu setzt ein Mail-Gateway in einer SMTP-Sitzung mehrere RCPT TO:-Befehle ab gefolgt von DATA und dem Inhalt der Mail. Das vermeidet die mehrfache Übertragung des gleichen Inhalts an denselben Mail-Server. Kann der Mail-Server die E-Mail nicht an alle Empfänger ausliefern, so muss er gemäss RFC-821 eine NDN generieren und an den Absender schicken.

Der einfache Ansatz, einem Server eine Mail mit 1000 ungültigen Adressen vorzuwerfen, scheitert in der Regel. Der Mail-Server wird für ihm unbekannte Benutzer einfach die Annahme verweigern ( 550 Unknown user ...). Er muss dann keine NDN erstellen, denn die Zuständigkeit bleibt beim Versender. Doch die meisten größeren Firmen betreiben mehrstufige Mail-Server, um schon in einer DMZ Spam und Viren auszufiltern. Dabei hat der vorgelagerte Server oft keine Informationen über die gültigen Mail-Adressen der Firma, sondern nimmt einfach alles an, was an die eigene Mail-Domain gerichtet ist. Stellt er dann beim Weiterleiten der Mails an die internen Server fest, dass eine Empfängeradresse ungültig ist, muss er laut RFC-821 den Absender benachrichtigen.

Leider definiert RFC-821 nicht genau, wie das zu geschehen hat, wenn eine E-Mail mehrere ungültige Empfänger hat. Somit bleibt es den Entwicklern der Server-Software überlassen, wie sie das implementieren. Unsere Untersuchung hat gezeigt, dass es leider viele Mail-Server gibt, die für jeden ungültigen Empfänger eine separate NDN erstellen. Das bedeutet, dass ein Angreifer durch eine einzige Mail mit einem gefälschten Absender tausende von NDN-Mails an sein Opfer schicken lassen kann. Außerdem enthalten die NDNs oft eine Kopie der ursprünglichen E-Mail inklusive allen Attachments und erzeugen damit auch beträchtlichen Datenverkehr.

Unsere Untersuchung an über 12.000 zufällig ausgewählten Mail-Servern hat ergeben, dass sich circa 5 Prozent dieser Systeme derart missbrauchen lässt. Diese Server akzeptieren alle Mails für ihren Domainnamen, haben keine erkennbare Obergrenze der Empfängeranzahl pro Mail und generieren pro ungültigen Empfänger eine NDN inklusive Kopie des Originals mit allen Attachments. Bei größeren Organisationen sieht das Verhältnis noch schlechter aus. So lassen sich sehr viele Mailserver namhafter staatlicher Behörden im In- und Ausland sowie circa 30 Prozent der Fortune-500-Firmen für solche NDN-Attacken missbrauchen.

Folgendes Beispiel zeigt die Dimension dieser Schwachstelle: In einem Experiment wurde an 105 Server je eine Mail mit 1000 ungültigen CC-Adressen und einem 10-KByte-Attachment verschickt. Das Gesamtvolumen des Versands betrug 3,6 MByte. Innerhalb weniger Stunden generierten diese Server über 80.000 Mails mit einem Gesamtvolumen von über 1,2 GByte. Diese 80.000 Mails hätten einen beliebigen Mail-Server unserer Wahl treffen können.

Außerdem könnte man dabei die Größe und Zahl der Mails noch weiter nach oben setzen. Als Worst-Case-Szenario stelle man sich einen Wurm vor, der aufgrund der beim User gefundenen Mail-Adressen gezielt solche Mails versendet und damit eine wahre NDN-Lawine durchs Netz rollen lässt.

Eine Analyse der untersuchten Systeme lässt folgenden Schluss zu: Vor allem Organisationen mit mehrstufigen Mail-Systemen sind anfällig. Die Untersuchung zeigte klar, dass besonders die gängigen Anti-Spam- und Antivirus-Gateway-Produkte missbraucht werden können, wenn nicht ein vorgelageter Mailserver ungültige Mails ablehnt. Aus den Daten der Experimente ergibt sich folgende Top-10-Liste der Mail-Server die jeweils mehr als eine NDN verschickten:

Diese Versionen wurden aus den Received-Zeilen der NDN-Mails ermittelt. Erste Tests zeigten, dass gängige Mail-Server wie Sendmail, Postfix und Exim in ihrer Standardkonfiguration nur jeweils eine NDN mit allen ungültigen Empfängeradressen versenden. Dass diese Server trotzdem in unserer Liste auftauchen, legt den Schluss nahe, dass hier eine Wechselwirkung mit anderen Programmen für die unerwünschte Vervielfachung sorgt. So könnten beispielsweise zusätzliche Virenscanner eine einzelne Auslieferung der Mails erzwingen. Weitere Tests werden dies genauer untersuchen müssen.

Die primären Opfer -- also die Empfänger der provozierten NDN-Mails -- können sich kaum schützen. Wird Hans.Dampf@alle.gassen.de mit NDN-Mails zugeflutet, kann höchstens der für ihn zuständige Server die Annahme von Mails von bestimmten Servern verweigern, die sich als Multiplikatoren erwiesen haben. Das muss der Adminstrator dann jedoch von Hand einrichten.

Die missbrauchten Mail-Server, die die NDN-Mails versenden, haben ebenfalls unter dem erhöhten Mail-Aufkommen zu leiden und können unter Umständen Kapazitätsprobleme bekommen.

Mittelfristig muss es darum gehen, alle Mail-Server im Internet gegen diese Art von Mißbrauch abzusichern. Die wirksamste Gegenmaßnahme ist es, Mails an ungültige Adressen gar nicht erst anzunehmen. Leider ist dies in vielen konkreten Szenarien nicht einfach möglich, da vorgelagerte Gateways auf Spam und Viren filtern, aber dabei keinen Zugang zu User-Datenbanken haben. Hier lohnt es, darüber nachzudenken, ob und wie man die Informationen über die aktuell gültigen Adressen exportieren und dem Mail-Gateway bereitstellen kann.

Ist dies nicht möglich, gilt es, die Verstärkerfunktion der Gateways abzuschalten. Am besten wäre es, wenn der Mail-Server "All in One"-Notifications versendet, also den Absender in einer einzigen Mail darüber unterrichtet, dass die Zustellung von 1000 E-Mails nicht geklappt hat. Mail-Server wie Exim, Postfix und Sendmail machen das in der Default-Konfiguration ihrer aktuellen Versionen. Wie das im Zusammenspiel mit Antiviren-Software zu realisieren ist, muss man im Einzelfall untersuchen.

Des Weiteren sollte man das Quoting so weit als möglich reduzieren und lediglich die Informationen in die Benachrichtigung einbetten, die notwendig sind, eine Mail eindeutig zu identifizieren.

Kommt keine dieser Optionen in Frage, sollte man zumindest als Sofortmaßnahme den möglichen Verstärkungsfaktor begrenzen, indem man die maximale Zahl der möglichen Empfänger einer Mail festlegt beziehungsweise herabsetzt. RFC 821 empfiehlt zwar, dass ein Server nicht weniger als 100 Empfänger für eine Mail akzeptieren sollte (should). Doch diese Empfehlung stammt aus einer Zeit, als es primär darum ging, Last durch reguläre E-Mails zu reduzieren. Im Licht aktueller DoS-, Spam- und Wurm-Attacken sollte man sie nochmal überdenken. Aus unserer Sicht spricht auch nichts dagegen, schon heute in Einzelfällen mit deutlich niedrigeren Werten zu experimentieren. Die Seite zu Sofortmaßnahmen listet relevante Parameter für diverse Mail-Server.

Wir beobachten, dass diese Art von Angriffen bereits öffentlich diskutiert werden. Es gibt sogar erste Anzeichen, dass sie konkret für Denial-of-Service-Attacken eingesetzt werden. Die Situation ist durchaus ähnlich zu anderen Missständen im Netz wie den offenen Mail-Relays oder den Smurf-Attacken, bei denen falsch konfigurierte Router als Verstärker dienten -- nur dass wir bei den NDN-Angriffen erst die Spitze des Eisbergs sehen. Nur wenn jetzt möglichst schnell die betroffenen Server entsprechende Maßnahmen ergreifen, lässt sich ein Missbrauch in großem Stil vermeiden.

Wichtig ist in diesem Zusammenhang die Mitarbeit der Hersteller von Mail-Servern und Mail-Gateways. Insbesondere im Zusammenspiel mit Antiviren- und Anti-Spam-Software müssen sie verstärkt darauf achten, dass die Vervielfältigung von NDN-Mails unterbleibt. Des Weiteren helfen verbesserte Möglichkeiten, die Maximalgröße von NDNs zu reduzieren. Und schließlich sollte es einfach möglich sein, Listen mit gültigen E-Mail-Adressen aus externen Quellen zu importieren -- sei es als Textfile, über LDAP oder eine Datenbankanbindung.

[1] Stefan Frei, Ivo Silvestri, Gunter Ollmann, Mail Non-Delivery Notice Attacks [1]

[2] Sofortmaßnahmen

Stefan Frei arbeitet in Zürich für eine internationale Technologiefirma als Senior Security Consultant im Bereich Security Assessment Services. Schwerpunkte der Arbeit sind Security Research und Application Security Assessments für die größten Finanz-, Handels- und Telecombetriebe in Europa und Middle East. Homepage: www.techzoom.net [2]

IMail Im IMail Administrator:
Max Anzahl Empfänger: IMail Administrator > Services > SMTP > Advanced > Maximum Recipients per Message
Mercury Im Mercury Frontend:
Max NDN Größe: Configuration > General > For delivery failures return X lines of the message
Max Anzahl Empfänger: Configuration > Mercury SMTP Server > Compliance > Limit max number of failed RCPTs to ..
Postfix In der Konfigurationsdatei main.cf:
Max Anzahl Empfänger: smtpd_recipient_limit = X
Max NDN Grösse: bounce_size_limit = X
Exim In der Konfigurationsdatei src/configure.default:
Max Anzahl Empfänger: recipients_max = X,
recipients_max_reject = true
Microsoft Exchange siehe: Knowledge Base Artikel - 284204 [3] bzw. KB-126497 [4]
Microsoft SMTP Service Im Internet Services Manager, SMTP Virtual Server
Max Anzahl Empfänger: Properties > Messages > Limit number of recipients per message to X
Sendmail siehe Tweaking Configuration Options [5]
confMAX_RCPTS_PER_MESSAGE

(ju [6])

URL dieses Artikels:
https://www.heise.de/-270474

Links in diesem Artikel:
[1] http://www.techzoom.net/mailbomb
[2] http://www.techzoom.net
[3] http://support.microsoft.com/default.aspx?scid=kb;EN-US;284204
[4] http://support.microsoft.com/support/kb/articles/q126/4/97.asp
[5] http://www.sendmail.org/m4/tweaking_config.html
[6] mailto:ju@ct.de

Copyright © 2004 Heise Medien