SMTP Smuggling Attack | MDaemon Technologies, Ltd.
  1. Forum
  2. MDaemon
  3. SMTP Smuggling Attack

SMTP Smuggling Attack

  • J

    Last week SEC Consult published an e-mail spoofing attack that can be used to smuggle unauthorized messages within an authorized message delivered via SMTP.   The attack has been named SMTP Smuggling.

        https://sec-consult.com/blog/detail/smtp-smuggling-spoofing-e-mails-worldwide/

    Earlier today three CVEs were posted for postifx, exim and sendmail describing an SMTP Smuggling attack

    CVE-2023-51764 postfix
    CVE-2023-51765 sendmail
    CVE-2023-51766 exim

    Quoting the description of the attack from https://www.postfix.org/smtp-smuggling.html

    Details

    The attack involves a COMPOSITION of two email services with specific differences in the way they handle line endings other than <CR><LF>:

    • One email service A that does not recognize malformed line endings in SMTP such as in <LF>.<CR><LF> in an email message from an authenticated attacker to a recipient at email service B, and that propagates those malformed line endings verbatim when it forwards that message to:

    • One different email service B that does support malformed line endings in SMTP such as in <LF>.<CR><LF>. When this is followed by "smuggled" SMTP MAIL/RCPT/DATA commands and message header plus body text, email service B is tricked into receiving two email messages: one message with the content before the <LF>.<CR><LF>, and one message with the "smuggled" header plus body text after the "smuggled" SMTP commands. All this when email service A sends only one message.

    Postfix is an example of email service B. Microsoft's outlook.com was an example of email service A.

    Impact

    • The "smuggled" SMTP MAIL/RCPT/DATA commands and header plus body text can be used to spoof an email message from any MAIL FROM address whose domain is hosted at email service A, to any RCPT TO address whose domain is hosted at email service B.

    • The spoofed email message will pass SPF-based DMARC checks at email service B, because the spoofed message has a MAIL FROM address whose domain is hosted at email service A, and because the message was received from an IP address for email service A.

     

    Four questions:

    1. Can MDaemon be used to smuggle outbound messages?  
      1. If yes, is there a workaround that can be deployed to prevent it?
    2. Does MDaemon accept smuggled inbound messages? 
      1. If yes, is there a workaround that can be deployed to prevent it?

    Happy Holidays.

    Jeffrey Altman

    0 likes
  • A
    MDaemon treats <LF>.<LF> and <LF>.<CR><LF> as message endings in addition to the standard <CR><LF>.<CR><LF>, so yes MDaemon is affected by the vulnerability.
     
    A user of some remote mail server that allows and preserves bare <LF> characters in a message can smuggle an additional message in theirs that has a forged From header to an MDaemon recipient.  We don't know what mail servers allow this, but we know they're not MDaemon, since MDaemon does not preserve bare <LF> characters (it converts them to <CR><LF>).
     
    MDaemon does not treat <CR>.<CR> or <CR>.<LF> or <CR>.<CR><LF> as message endings, so they cannot be used to smuggle additional messages to MDaemon recipients.  But it is possible that malicious MDaemon end users could use them to smuggle messages through their MDaemon server to recipients of vulnerable servers.
     
    We're considering what changes we'll make to handle this.
     

    --
    Arron Caruth

    0 likes
  • A

    MDaemon 23.5.2, which is currently in beta, includes an option to require messages to end with <CR><LF>.<CR><LF>.  This option is enabled by default.

    We are also considering additional changes.

    --
    Arron Caruth

    0 likes
Please login to reply this topic!