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

Groups > de.comm.software.mailserver > #6927

Re: SMTP smuggling

Show all headers | View raw

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.

Back to de.comm.software.mailserver | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

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

csiph-web