Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > de.comm.software.mailserver > #6925 > unrolled thread

SMTP smuggling

Back to article view | Back to de.comm.software.mailserver

Contents

  SMTP smuggling Marco Moock <mm+solani@dorfdsl.de> - 2023-12-24 12:07 +0100
    Re: SMTP smuggling Arno Welzel <usenet@arnowelzel.de> - 2023-12-25 15:31 +0100
      Re: SMTP smuggling Marco Moock <mm+solani@dorfdsl.de> - 2023-12-25 16:08 +0100
      Re: SMTP smuggling Tim Ritberg <tim@server.invalid> - 2023-12-31 16:50 +0100
        Re: SMTP smuggling Marco Moock <mm+solani@dorfdsl.de> - 2024-01-01 09:53 +0100
          Re: SMTP smuggling Tim Ritberg <tim@server.invalid> - 2024-01-01 11:31 +0100

#6925 — SMTP smuggling

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?

-- 
Gruß
Marco

Spam und Werbung bitte an ichwillgesperrtwerden@nirvana.admins.ws

[toc] | [next] | [standalone]

#6926

Marco Moock, 2023-12-24 12:07:

> 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>

> 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).

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 doch der 2. MTA die 2. Nachricht einfach ans Ziel schicken
> (das kann dann jede x-beliebige Adresse sein).

Korrekt.

> 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?

Ja, so würde ich das auch sehen.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#6927

Am 25.12.2023 um 15:31:26 Uhr schrieb Arno Welzel:

> Marco Moock, 2023-12-24 12:07:
> 
> > 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>
> 
> > 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).  
> 
> 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.

[toc] | [prev] | [next] | [standalone]

#6945

Am 25.12.23 um 15:31 schrieb 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

[toc] | [prev] | [next] | [standalone]

#6946

Am 31.12.2023 um 16:50:22 Uhr schrieb Tim Ritberg:

> Am 25.12.23 um 15:31 schrieb 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?

[toc] | [prev] | [next] | [standalone]

#6947

Am 01.01.24 um 09:53 schrieb 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

[toc] | [prev] | [standalone]

Back to top | Article view | de.comm.software.mailserver

csiph-web