Rocksolid Light

groups  faq  privacy  How to post  login

Message-ID:  

Ships are safe in harbor, but they were never meant to stay there.


rocksolid / de.comm.software.mailserver / SMTP smuggling

SubjectAuthor
* SMTP smugglingMarco Moock
`* Re: SMTP smugglingArno Welzel
 +- Re: SMTP smugglingMarco Moock
 `* Re: SMTP smugglingTim Ritberg
  `* Re: SMTP smugglingMarco Moock
   `- Re: SMTP smugglingTim Ritberg

1
Subject: SMTP smuggling
From: Marco Moock
Newsgroups: de.comm.software.mailserver
Date: Sun, 24 Dec 2023 11:07 UTC
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: mm+sol...@dorfdsl.de (Marco Moock)
Newsgroups: de.comm.software.mailserver
Subject: SMTP smuggling
Date: Sun, 24 Dec 2023 12:07:37 +0100
Message-ID: <um93dp$avrg$2@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Sun, 24 Dec 2023 11:07:37 -0000 (UTC)
Injection-Info: solani.org;
logging-data="360304"; mail-complaints-to="abuse@news.solani.org"
Cancel-Lock: sha1:pszsaiJ9Dm5PZhoOqfR8Upil1x0=
X-User-ID: eJwFwYEBgDAIA7CXQGip5wgb/59ggqBzKgkmFuu2SibZ/sigCPcZfyfuaj+zPjcOhI5SGX//6RA/
X-Newsreader: Claws Mail 4.2.0 (GTK 3.24.38; x86_64-pc-linux-gnu)
View all headers

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

Subject: Re: SMTP smuggling
From: Arno Welzel
Newsgroups: de.comm.software.mailserver
Date: Mon, 25 Dec 2023 14:31 UTC
References: 1
Path: i2pn2.org!i2pn.org!paganini.bofh.team!2.eu.feeder.erje.net!feeder.erje.net!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: use...@arnowelzel.de (Arno Welzel)
Newsgroups: de.comm.software.mailserver
Subject: Re: SMTP smuggling
Date: Mon, 25 Dec 2023 15:31:26 +0100
Lines: 63
Message-ID: <kuti1uFc1odU2@mid.individual.net>
References: <um93dp$avrg$2@solani.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net omUj7GUkUEo8kB0LOcIwMQ8jOnHOCvs81sAmrorw3VxLjglusU
Cancel-Lock: sha1:ct6ZO9zzIAhYT6J/ivtHnEhoDQ0= sha256:VRDs5fRBUCm4lz6obBKgWxzVQ9FQ0vd6KXN5ocNjJsM=
Content-Language: de-DE
In-Reply-To: <um93dp$avrg$2@solani.org>
View all headers

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

Subject: Re: SMTP smuggling
From: Marco Moock
Newsgroups: de.comm.software.mailserver
Date: Mon, 25 Dec 2023 15:08 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: mm+sol...@dorfdsl.de (Marco Moock)
Newsgroups: de.comm.software.mailserver
Subject: Re: SMTP smuggling
Date: Mon, 25 Dec 2023 16:08:44 +0100
Message-ID: <umc5ts$b2u2$1@solani.org>
References: <um93dp$avrg$2@solani.org>
<kuti1uFc1odU2@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 25 Dec 2023 15:08:44 -0000 (UTC)
Injection-Info: solani.org;
logging-data="363458"; mail-complaints-to="abuse@news.solani.org"
Cancel-Lock: sha1:QYELAPHPQg3EuBF6Cm6aIBd42jM=
X-User-ID: eJwFwQcBwDAMAzBKznM2Onn8IVQKo7DTGfS4uNnIlalA73l1zn3TW2qSP9XbCrWigIEDezwREXc=
X-Newsreader: Claws Mail 4.2.0 (GTK 3.24.38; x86_64-pc-linux-gnu)
View all headers

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.

Subject: Re: SMTP smuggling
From: Tim Ritberg
Newsgroups: de.comm.software.mailserver
Date: Sun, 31 Dec 2023 15:50 UTC
References: 1 2
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.tota-refugium.de!.POSTED!not-for-mail
From: tim...@server.invalid (Tim Ritberg)
Newsgroups: de.comm.software.mailserver
Subject: Re: SMTP smuggling
Date: Sun, 31 Dec 2023 16:50:22 +0100
Message-ID: <ums2ju$kp5v$1@tota-refugium.de>
References: <um93dp$avrg$2@solani.org> <kuti1uFc1odU2@mid.individual.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Sun, 31 Dec 2023 15:50:22 -0000 (UTC)
Injection-Info: tota-refugium.de;
logging-data="681151"; mail-complaints-to="abuse@news.tota-refugium.de"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:gtS3k5Z1ve3PJHu+5DHnNbvtkMA=
Content-Language: de-DE
X-User-ID: eJwFwQERACAIA8BKINvQOIJH/wj+M+TqhChwOK5AEdLQa5bS52QY3u5+F37TIo5hl7pg9QEEbhBn
In-Reply-To: <kuti1uFc1odU2@mid.individual.net>
View all headers

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

Subject: Re: SMTP smuggling
From: Marco Moock
Newsgroups: de.comm.software.mailserver
Date: Mon, 1 Jan 2024 08:53 UTC
References: 1 2 3
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.solani.org!.POSTED!not-for-mail
From: mm+sol...@dorfdsl.de (Marco Moock)
Newsgroups: de.comm.software.mailserver
Subject: Re: SMTP smuggling
Date: Mon, 1 Jan 2024 09:53:08 +0100
Message-ID: <umtuhk$irin$13@solani.org>
References: <um93dp$avrg$2@solani.org>
<kuti1uFc1odU2@mid.individual.net>
<ums2ju$kp5v$1@tota-refugium.de>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Injection-Date: Mon, 1 Jan 2024 08:53:08 -0000 (UTC)
Injection-Info: solani.org;
logging-data="618071"; mail-complaints-to="abuse@news.solani.org"
Cancel-Lock: sha1:XJsCsw6Z1Ayof4ylnUJWaudm52E=
X-User-ID: eJwFwYkRwDAIA7CVcIh5xiFcvf8IleiB2LzBuBRV4qdlIdCd2dLivpG5T4/z2dgeQ4NdPPYDG4wQdA==
X-Newsreader: Claws Mail 4.2.0 (GTK 3.24.38; x86_64-pc-linux-gnu)
View all headers

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?

Subject: Re: SMTP smuggling
From: Tim Ritberg
Newsgroups: de.comm.software.mailserver
Date: Mon, 1 Jan 2024 10:31 UTC
References: 1 2 3 4
Path: i2pn2.org!i2pn.org!weretis.net!feeder8.news.weretis.net!reader5.news.weretis.net!news.tota-refugium.de!.POSTED!not-for-mail
From: tim...@server.invalid (Tim Ritberg)
Newsgroups: de.comm.software.mailserver
Subject: Re: SMTP smuggling
Date: Mon, 1 Jan 2024 11:31:42 +0100
Message-ID: <umu4ae$k8vs$1@tota-refugium.de>
References: <um93dp$avrg$2@solani.org> <kuti1uFc1odU2@mid.individual.net>
<ums2ju$kp5v$1@tota-refugium.de> <umtuhk$irin$13@solani.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Mon, 1 Jan 2024 10:31:42 -0000 (UTC)
Injection-Info: tota-refugium.de;
logging-data="664572"; mail-complaints-to="abuse@news.tota-refugium.de"
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:FHlb793iUimpzTTrwVC8TPMGGq8=
In-Reply-To: <umtuhk$irin$13@solani.org>
X-User-ID: eJwFwYERACEIA7CV5G0rjCN43X+ET7gVmgNRoOnnPY28WTdZ8HQXv1Pg5VqK1DswxqqaaP8hEREh
Content-Language: de-DE
View all headers

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


rocksolid / de.comm.software.mailserver / SMTP smuggling

1
server_pubkey.txt

rocksolid light 0.9.12
clearnet tor