Meine ASP.NET-Website verfügt über einen globalen Fehlerhandler, der eine E-Mail an mich (und einen anderen Entwickler) sendet, wenn in der Webanwendung ein Fehler auftritt. Wir haben kürzlich einen Fehler erhalten, der ein CC zu einer E-Mail-Adresse enthielt, von der wir noch nie gehört hatten. Das Gruselige ist, dass die Liste der Entwickler, an die die Fehler-E-Mail gesendet wird, im kompilierten ASP.NET-Code fest codiert ist. Wir sehen nicht, wie der CC hinzugefügt werden könnte.
Wir sind auch sehr verdächtig auf Foul Play, weil die Anfrage, die den Fehler verursacht hat, ein Versuch war, eines unserer Formulare zum Senden von Spam zu verwenden. Die IP-Adresse, die die Anfrage gesendet hat, ist auch auf Ссылка aufgeführt.
Unsere beste Vermutung ist, dass die Anfrage in irgendeiner Weise fehlerhaft war, dass sie einen CC-Header in die E-Mail eingefügt hat. Das Problem ist, dass wir nicht herausfinden können, wie das gemacht werden könnte. Wir verwenden System.Net.Mail, um die E-Mails zu senden, und es scheint sich vor solchen Dingen zu schützen. Der Betreff des MailMessage-Objekts akzeptiert nur eine einzelne Zeile, sodass Sie kein mehrzeiliges Subjekt mit einer CC-Zeile erstellen. Das Festlegen der An und CC-Adressen in der MailMessage scheint ziemlich robust. Und ich kann nicht sehen, wie Sie einen CC-Header im Nachrichtentext hinzufügen könnten. Ich kann dazu keine Informationen finden und würde gerne wissen, ob das ein echtes Problem ist.
BEARBEITEN: Jemand hat den Code angefordert. Es ist ein bisschen lang, aber hier ist es:
%Vor%Ich könnte sehen, dass dies das Ziel eines SEHR kreativen Angriffs ist ... Sie stopfen benutzergesteuerte Daten in Ihren Nachrichtentext ... An diesem Punkt, geschickter Gebrauch von binären Daten COULD führt zu einem BODY, der die richtigen Daten während der SMTP-Sitzung sendet, um sie formatiert zu bekommen JUST RIGHT ... Wenn ich das möchte, würde ich vorschlagen, den Body in alle ASCII umzuwandeln Schreiben Sie einen String-Sanitizer, der nur RFC-Zeichen erlaubt (filtert die URLs, den REFERRER, die Remote-Adresse und den UserAgent). Das sind Ihre wahrscheinlicheren Angriffspunkte.
Ein zweiter Gedanke könnte sein, eine grundlegende E-Mail in Code zu erstellen und den Körper, den Sie als Text-, HTML- oder PDF-Datei konstruiert haben, anhängen.
Beachten Sie, dass SMTP-ENVELOPE-Daten NICHT die gleichen wie Nachrichtendaten sind .... Wenn jemand geschickt genug war, um den richtigen Body zu senden, der dazu führte, dass eine CRLFCRLF.CRLFCRLF während des Body gesendet wurde Teil, der das Senden beenden würde, und wenn sie dann weiter Daten senden würden, könnten sie den gesamten MAIL von: RCPT TO :, DATA, etc ... senden (Zugegeben, dies ist ein unwahrscheinliches Szenario ...) ...
Ich würde es lieben, die RAW Quelle der E-Mail zu sehen, die Sie bekommen haben ... (Wie im Hex-Dump der tatsächlichen SMTP-Transaktion, nicht was Outlook von Ihnen sehen will oder was auch immer) .
Sie können auch versuchen, Ihren Körper mit QP oder B64 zu kodieren, bevor Sie die Nachricht senden .... Das könnte Ihr Problem lösen ...
Das ist ein interessanter Fall und ich freue mich auf das Ergebnis.
Ihr Code sieht sehr sicher aus, daher glaube ich nicht, dass das Problem auf Ihrer Seite ist.
IMO, jemand hat die SMTP-Nachricht abgefangen, während sie an den Mailserver gesendet wurde, und hat die zusätzliche CC: -Leitung eingefügt; oder der Mailserver wurde kompromittiert.
Wenn Sie keine Antwort finden, sollten Sie Microsoft direkt kontaktieren. Möglicherweise haben Sie in .NET Framework einen Exploit entdeckt.
Als Workaround, warum schreiben Sie die E-Mail-Nachricht nicht mit einer asymetrischen Beschreibung (zum Beispiel eine öffentliche Schlüsselbeschreibung)? Auf diese Weise kann nur der beabsichtigte Empfänger es lesen.
Auf diese Weise, selbst wenn die bösen Jungs eine Kopie Ihrer Nachricht (mit welchen Mitteln auch immer) erhalten, wird es ihnen jetzt nützlich sein.
Lass uns ehrlich sein, wenn du eine hochkarätige Website wie das FBI oder Google hast, werden viele sehr kreative Leute viel Zeit darauf verwenden und alles tun, um es zu kompromittieren. Es ist äußerst wichtig, detaillierte Fehlermeldungen zu schützen.
Tags und Links asp.net security smtp code-injection