SMTP smuggling

[Marco Moock]

Hallo zusammen!

Aus aktuellem Anlass befasse ich mich mit SMTP-Smuggling.
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

TLDR: Der RFC schreibt CRLF.CRLF als Ende des DATA-Befehls vor, aus
Kompatibilitätsgründen akzeptieren einige MTAs aber auch LF.LF (oder
ggf. andere Kombinationen).

Wenn einer nun CRLF erfordert, aber <LF>.<LF> in der Nachricht zulässt
und ignoriert, kann ein anderer MTA dahinter (z.B. wegen Mailertable,
Aliasen etc.) das anders sehen und ggf. eine weitere Mail draus
generieren.

Auf der Website wird das Verhalten mit den Ausgangsservern
gängiger Mailanbieter beschrieben, mir kam aber noch was anderes in den
Kopf:

Ein weiterer MTA hinter dem eigenen MX:

Der Angreifer kann den direkt per ncat/telnet ansteuern und damit
beliebige Zeichen eingeben.

Nehmen wir mal an, der MX interpretiert nur CRLF und LF wird einfach
übernommen als Teil des Body (LF im Body ist ja ebenfalls nicht
RFC-konform, wenn ich mich nicht irre).

Das Ziel sei eine Mailadresse, für die der MX relayen darf (der
eigentliche MDA steht dahinter und wird per SMTP über einen weiteren
MTA erreicht, klassisches Anwendung der mailertable).
Der MTA dahinter interpretiert aber <LF>.<LF> (oder was anderes) als
Ende von DATA und den geschmuggelten Teil als neue Nachricht.

Annahme 2: Der MX darf über den 2. MTA relayen.

Dann würde doch der 2. MTA die 2. Nachricht einfach ans Ziel schicken
(das kann dann jede x-beliebige Adresse sein).

Der weniger schlimme Fall, wenn Annahme 2 nicht zutrifft:
Eine weitere Mail an eine lokale Mailbox des 2. MTA wäre so möglich -
das eher geringe Problem.

Problem 3: Man kann damit Bounces generieren für Backscatter, wenn das
Ziel extern ist und MX auf dem 2. MTA NICHT relayen darf.

Stimmt das oder habe ich da nen Denkfehler?

[Arno Welzel]

Post by Marco Moock
Hallo zusammen!
Aus aktuellem Anlass befasse ich mich mit SMTP-Smuggling.
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
TLDR: Der RFC schreibt CRLF.CRLF als Ende des DATA-Befehls vor, aus
Kompatibilitätsgründen akzeptieren einige MTAs aber auch LF.LF (oder
ggf. andere Kombinationen).
Wenn einer nun CRLF erfordert, aber <LF>.<LF> in der Nachricht zulässt
und ignoriert, kann ein anderer MTA dahinter (z.B. wegen Mailertable,
Aliasen etc.) das anders sehen und ggf. eine weitere Mail draus
generieren.

Danke für den Hinweis.

Ein Workaround für Postfix ist da auch verlinkt:
<https://www.postfix.org/smtp-smuggling.html>

Post by Marco Moock
Auf der Website wird das Verhalten mit den Ausgangsservern
gängiger Mailanbieter beschrieben, mir kam aber noch was anderes in den
Der Angreifer kann den direkt per ncat/telnet ansteuern und damit
beliebige Zeichen eingeben.
Nehmen wir mal an, der MX interpretiert nur CRLF und LF wird einfach
übernommen als Teil des Body (LF im Body ist ja ebenfalls nicht
RFC-konform, wenn ich mich nicht irre).

Ja, genau das ist das Problem mit "SMTP smuggling". Ein Mailserver
ignoriert das eingehende <LF>.<LF> und leitet das einfach weiter an den
MX für die Zieladresse der ersen Mail.

Der MX für die Zieladresse beachtet aber auch <LF> statt <CRLF> und
verarbeitet auch die zweite E-Mail.

[...]

Post by Marco Moock
Dann würde doch der 2. MTA die 2. Nachricht einfach ans Ziel schicken
(das kann dann jede x-beliebige Adresse sein).

Korrekt.

Post by Marco Moock
Eine weitere Mail an eine lokale Mailbox des 2. MTA wäre so möglich -
das eher geringe Problem.
Problem 3: Man kann damit Bounces generieren für Backscatter, wenn das
Ziel extern ist und MX auf dem 2. MTA NICHT relayen darf.
Stimmt das oder habe ich da nen Denkfehler?

Ja, so würde ich das auch sehen.

[Marco Moock]

Post by Arno Welzel

Post by Marco Moock
Hallo zusammen!
Aus aktuellem Anlass befasse ich mich mit SMTP-Smuggling.
https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/
TLDR: Der RFC schreibt CRLF.CRLF als Ende des DATA-Befehls vor, aus
Kompatibilitätsgründen akzeptieren einige MTAs aber auch LF.LF (oder
ggf. andere Kombinationen).
Wenn einer nun CRLF erfordert, aber <LF>.<LF> in der Nachricht
zulässt und ignoriert, kann ein anderer MTA dahinter (z.B. wegen
Mailertable, Aliasen etc.) das anders sehen und ggf. eine weitere
Mail draus generieren.

Danke für den Hinweis.
<https://www.postfix.org/smtp-smuggling.html>

Post by Marco Moock
Auf der Website wird das Verhalten mit den Ausgangsservern
gängiger Mailanbieter beschrieben, mir kam aber noch was anderes in
Der Angreifer kann den direkt per ncat/telnet ansteuern und damit
beliebige Zeichen eingeben.
Nehmen wir mal an, der MX interpretiert nur CRLF und LF wird einfach
übernommen als Teil des Body (LF im Body ist ja ebenfalls nicht
RFC-konform, wenn ich mich nicht irre).

Ja, genau das ist das Problem mit "SMTP smuggling". Ein Mailserver
ignoriert das eingehende <LF>.<LF> und leitet das einfach weiter an
den MX für die Zieladresse der ersen Mail.
Der MX für die Zieladresse beachtet aber auch <LF> statt <CRLF> und
verarbeitet auch die zweite E-Mail.

Dann würde der MX die aber ablehnen. Es muss meines Erachtens einer
dahinter sein, der das <LF> interpretiert und der MX nicht, damit die
Mail ungeprüft über den MX kommt.
Der MX muss dann beim MTA dahinter wo die erste Mail hingeht relayen
dürfen.

Das geht natürlich auch umgekehrt über die Submission-Server (die dann
<LF> ignorieren) und die Ausgangsrelays (die dann <LF> interpretieren
und ne 2. Mail generieren).

Dürfte dann bei gleicher Version und Konfiguration von den MTAs kein
Problem sein.

[Tim Ritberg]

Post by Arno Welzel
Ja, genau das ist das Problem mit "SMTP smuggling". Ein Mailserver
ignoriert das eingehende <LF>.<LF> und leitet das einfach weiter an den
MX für die Zieladresse der ersen Mail.

Was ist, wenn man noch Amavis benutzt?

Tim

[Marco Moock]

Post by Tim Ritberg

Post by Arno Welzel
Ja, genau das ist das Problem mit "SMTP smuggling". Ein Mailserver
ignoriert das eingehende <LF>.<LF> und leitet das einfach weiter an
den MX für die Zieladresse der ersen Mail.

Was ist, wenn man noch Amavis benutzt?

Ändert das denn die Daten im DATA-Befehl bezüglich der Umbrüche bzw.
lehnt das in bestimmten Situationen ab, wenn die nicht RFC-konform sind?

[Tim Ritberg]

Post by Marco Moock
Ändert das denn die Daten im DATA-Befehl bezüglich der Umbrüche bzw.
lehnt das in bestimmten Situationen ab, wenn die nicht RFC-konform sind?

Es ist ein Proxy, das wäre also anzunehmen.

Tim