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


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

Re: SMTP smuggling

From Arno Welzel <usenet@arnowelzel.de>
Newsgroups de.comm.software.mailserver
Subject Re: SMTP smuggling
Date 2023-12-25 15:31 +0100
Message-ID <kuti1uFc1odU2@mid.individual.net> (permalink)
References <um93dp$avrg$2@solani.org>

Show all headers | View raw


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

Back to de.comm.software.mailserver | Previous | NextPrevious 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