Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > de.comm.software.mailserver > #6926
| 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> |
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 | Next — Previous in thread | Next in thread | Find similar | Unroll 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