Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Jaroslaw Rafa via mailop]

Dnia  1.01.2024 o godz. 23:10:22 Jaroslaw Rafa via mailop pisze:
> 
> This is basically equal to the new configuration setting
> "smtpd_forbid_unauth_pipelining = no" which is a default for Postfix
> versions >= 3.9.

Sorry, of course I made a mistake here. I meant
"smtpd_forbid_unauth_pipelining = yes" which is equal to
"smtpd_data_restrictions = reject_unauth_pipelining, ..." and is a default
in Postfix >= 3.9.

"smtpd_forbid_unauth_pipelining = no" turns that restriction off.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Slavko via mailop]

Dňa 1. januára 2024 21:31:19 UTC používateľ Marco Moock via mailop 
 napísal:

>True, although, that can be used to send mail to local mailboxes only.
>To relay to an external sender, MX must be allowed to relay via the
>final destination MTA.

I will consider that by "relay to an external sender" you mean external
recipient...

a) local mailbox is enough, that is always target ;-)
b) smuggled message was relayed without notice over at least one
   hop (in described case MX MTA)
c) all MTAs before MX relayed message to external recipient

In other words, for attacker it is almost every time external recipient.
But relaying itself doesn't imply external... AFAIK term "relay" is in RFC
described as transfer from one MTA to another (without defining
reason).

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Jaroslaw Rafa via mailop]

Dnia  1.01.2024 o godz. 21:53:59 Gellner, Oliver via mailop pisze:
> 
> Yes, but as with Postfix the update alone does not fix the vulnerability.
> You have to additionally change the config as instructed.  The vendors and
> distributions don’t do this automatically as this changes the behavior of
> the MTA.

It was usually always advised in Postfix documentation to have the following
setting in the config:

smtpd_data_restrictions = reject_unauth_pipelining, 

From what has been recently said in the Postfix mailing list, having this
setting in the config blocks this attack (*unless* both sending and
receiving side support BDAT format and the attacker will smuggle the second
message using that format (but BDAT support can be disabled using another
setting in the configuration).

This is basically equal to the new configuration setting
"smtpd_forbid_unauth_pipelining = no" which is a default for Postfix
versions >= 3.9.

So if you were using the "recommended" configuration from the start, your
MTA is not vulnerable to this attack (minus the BDAT case) even if you don't
patch Postfix.
-- 
Regards,
   Jaroslaw Rafa
   r...@rafa.eu.org
--
"In a million years, when kids go to school, they're gonna know: once there
was a Hushpuppy, and she lived with her daddy in the Bathtub."
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Gellner, Oliver via mailop]

On 01.01.2024 at 20:38 Marco Moock wrote:

Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:

To exploit the issue, an email message needs to traverse two MTAs
that treat the EOM marker differently. The MTAs do not need to be in
a special trust relationship or allowed to relay to each other.

Sorry for the second reply, but how does this work?

Let’s assume we have two MTAs: One belonging to Hotmail and a second belonging 
to Cisco. The MTAs are completely unrelated to each other.
Hotmails MTA will treat . as part of the message body whereas Ciscos 
MTA will see . as end-of-message (both in violation of the RFC).

An attacker now signs up for an account at Hotmail and submits the following 
message:

MAIL FROM:
RCPT TO:
DATA
From: 
To: 

Some Text…
.
MAIL FROM:
RCPT TO:
BDAT length LAST
From: Microsoft Support 
To: 
Subject: Phishing attack

Wire me all your money asap
QUIT

Hotmails MTA will accept this as one message, add its usual headers and deliver 
it to the MX of cisco.tld. Ciscos MTA will however see an incoming connection 
that delivers two messages: One from realacco...@hotmail.tld, a second from 
supp...@microsoft.com. The second message is the smuggled message.

Of course the attacker could as well send a message from supp...@microsoft.com 
to vic...@cisco.tld directly from his botnet, VPS or whatever, but this would 
get rejected by every MTA that honors the DMARC policy of microsoft.com. The 
smuggled message on the other hand passes the SPF and thereby DMARC checks 
successfully.

At least for sendmail, a fix is available in the current snapshot,
but the fix is just an additional feature (srv_features) that changes it
it, so it only accepts CRLF.

Yes, but as with Postfix the update alone does not fix the vulnerability. You 
have to additionally change the config as instructed. The vendors and 
distributions don’t do this automatically as this changes the behavior of the 
MTA.

—
BR Oliver

dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 01.01.2024 um 20:25:54 Uhr schrieb Slavko via mailop:

> Dňa 1. januára 2024 19:38:08 UTC používateľ Marco Moock via mailop
>  napísal:
> >Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:
> >  
> >> To exploit the issue, an email message needs to traverse two MTAs
> >> that treat the EOM marker differently. The MTAs do not need to be
> >> in a special trust relationship or allowed to relay to each other.
> >>  
> >  
> 
> >Sorry for the second reply, but how does this work?
> >
> >
> >Assumption:
> >2nd MTA doesn't allow MX to relay through it.
> >
> >If the MX ignores LF and a second intra-site MTA acknowledges it, it
> >would reply with "Relying denied" if the recipient address of the
> >second mail is not local (Cw) or is allowed to be relayed through
> >that MTA in any other way (e.g. access db To:j...@example.org RELAY).
> >
> >Please explain me how unauthenticated relaying works here.
> >I am aware that this creates a bounce an can be used for backscatter
> >(without checking DKIM nor SPF because MX sees only one message  
> 
> Consider to have 2 MTA, the first one receives message from public
> net and does all checks and then delivers to second MTA for final
> delivery. Thus, the second MTA doesn't need to check that again,
> trusts the first one and just does final delivery. If both treats end
> of DATA differently, the first can see only one message (thus does
> only one check), but second MTA see two (or even more) messages, but
> trusts that first MTA's checks, thus just delivers them all. No SPF
> nor DMARC checks happens with smuggled message(s).

True, although, that can be used to send mail to local mailboxes only.
To relay to an external sender, MX must be allowed to relay via the
final destination MTA.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 01.01.2024 um 15:56:02 Uhr schrieb John Covici via mailop:

> Thanks much -- that version is not in my repository yet, but I will
> keep an eye out for it.

That is a snapshot - a release for testing - and such releases are
normally not in the normal repos of the distributions.

I dunno when the final 8.18.x release is being planned.
It also includes several other changes, so I assume it won't be
available in LTS versions where such changes are unwanted, like in
Debian.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[John Covici via mailop]

Thanks much -- that version is not in my repository yet, but I will
keep an eye out for it.

On Mon, 01 Jan 2024 13:53:57 -0500,
ml+mailop--- via mailop wrote:
> 
> On Mon, Jan 01, 2024, John Covici via mailop wrote:
> > I use sendmail  8.17.1.9 under gentoo -- any patch for that one to fix this?
> 
> Upgrade to 8.18.0.2,:
> https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz
> https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Slavko via mailop]

Dňa 1. januára 2024 19:38:08 UTC používateľ Marco Moock via mailop 
 napísal:
>Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:
>
>> To exploit the issue, an email message needs to traverse two MTAs
>> that treat the EOM marker differently. The MTAs do not need to be in
>> a special trust relationship or allowed to relay to each other.
>

>Sorry for the second reply, but how does this work?
>
>
>Assumption:
>2nd MTA doesn't allow MX to relay through it.
>
>If the MX ignores LF and a second intra-site MTA acknowledges it, it
>would reply with "Relying denied" if the recipient address of the
>second mail is not local (Cw) or is allowed to be relayed through that
>MTA in any other way (e.g. access db To:j...@example.org RELAY).
>
>Please explain me how unauthenticated relaying works here.
>I am aware that this creates a bounce an can be used for backscatter
>(without checking DKIM nor SPF because MX sees only one message

Consider to have 2 MTA, the first one receives message from public
net and does all checks and then delivers to second MTA for final
delivery. Thus, the second MTA doesn't need to check that again,
trusts the first one and just does final delivery. If both treats end of
DATA differently, the first can see only one message (thus does only
one check), but second MTA see two (or even more) messages, but
trusts that first MTA's checks, thus just delivers them all. No SPF
nor DMARC checks happens with smuggled message(s).

Or vice versa. First is MSA, which checks, that sender (MAIL FROM)
is allowed for that (authenticated) user and if yes, allows to
relay that (one) message, but confused receiver will again see two
(or more) messages. The smuggled message can thus bypass sender
checking on MSA and if smuggled message uses another domain
hosted on the same system, its SPF will pass, and thus its DMARC
will pass...

regards


-- 
Slavko
https://www.slavino.sk/
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Andreas S. Kerber via mailop]

Am Mon, Jan 01, 2024 at 06:53:57PM + schrieb ml+mailop--- via mailop:
> > I use sendmail  8.17.1.9 under gentoo -- any patch for that one to fix this?
> 
> Upgrade to 8.18.0.2,:

Additionally needs "Srv_Features:  o" for sendmail to only accept CR LF . CR LF 
as end of an SMTP message.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 01.01.2024 um 10:17:25 Uhr schrieb Randolf Richardson, Postmaster
via mailop:

> > > On 28.12.2023 at 20:29 Marco Moock via mailop wrote:
> > >
> > > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
> > >  
> > >> Has anyone detected or seen any evidence of SMTP smuggling in the
> > >> wild?
> > >>
> > >> I´m trying to get an independent read on how quickly the bad
> > >> actors have (or haven´t) picked up on this, yet.  
> > >
> > > According to the information I read, it affected some hosting
> > > solutions at 1und1/IONOS, but that has been fixed.  
> > 
> > The vulnerability is not super critical, but it has been fixed only
> > for a very small subset of affected systems. All kind of MTAs from
> > Postfix to Sendmail, Exim and various proprietary systems are
> > affected and the vulnerability generally remains unfixed until the
> > administrators adjust the configuration of their system. I haven´t
> > heard of any large scale exploitation in the past, but I imagine
> > that spammers will include the technique in their toolset for the
> > future.  
> 
>   It is critical because it invovles the use of a system for 
> unauthorized purposes -- namely, sending spam, distributing viruses 
> and other malicious software, etc.

Simply unauthenticated relaying.

> This justifies classifying SMTP Smuggling as a "security" issue,
> which I regard as critical.

True, but it is limited to certain configurations and it is not a
problem in all cases.

> > To exploit the issue, an email message needs to traverse two MTAs
> > that treat the EOM marker differently. The MTAs do not need to be
> > in a special trust relationship or allowed to relay to each other.  
> 
>   As I understand it, such techniques can be automated, which
> means that spamware could be created that takes advantage of the SMTP 
> Smuggling exploit.

That automation should be really, really easy.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:

> To exploit the issue, an email message needs to traverse two MTAs
> that treat the EOM marker differently. The MTAs do not need to be in
> a special trust relationship or allowed to relay to each other.

Sorry for the second reply, but how does this work?


Assumption:
2nd MTA doesn't allow MX to relay through it.

If the MX ignores LF and a second intra-site MTA acknowledges it, it
would reply with "Relying denied" if the recipient address of the
second mail is not local (Cw) or is allowed to be relayed through that
MTA in any other way (e.g. access db To:j...@example.org RELAY).

Please explain me how unauthenticated relaying works here.
I am aware that this creates a bounce an can be used for backscatter
(without checking DKIM nor SPF because MX sees only one message).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 01.01.2024 um 17:58:47 Uhr schrieb Gellner, Oliver via mailop:

> The vulnerability is not super critical, but it has been fixed only
> for a very small subset of affected systems. All kind of MTAs from
> Postfix to Sendmail, Exim and various proprietary systems are
> affected and the vulnerability generally remains unfixed until the
> administrators adjust the configuration of their system.

IIRC it can only be exploited if 2 MTAs at one site treat CRLF and LF
differently.
If all MTAs handle it the same way, it is not possible to abuse it.

Another situation could occur if one MTA (MX) accepts an message and
ignores LF, then forwards it to another external one (vacation,
aliases) that treats LF.LF as the DATA ending.
That could be used to allow unauthenticated relaying too, although the
recipients are limited to the MX servers of the RHS of the
alias/forward.
It can also be used to create bounces in that case.

At least for sendmail, a fix is available in the current snapshot,
but the fix is just an additional feature (srv_features) that changes it
it, so it only accepts CRLF.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[ml+mailop--- via mailop]

On Mon, Jan 01, 2024, John Covici via mailop wrote:
> I use sendmail  8.17.1.9 under gentoo -- any patch for that one to fix this?

Upgrade to 8.18.0.2,:
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz
https://ftp.sendmail.org/snapshots/sendmail.8.18.0.2.tar.gz.sig
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[John Covici via mailop]

I use sendmail  8.17.1.9 under gentoo -- any patch for that one to fix this?

On Mon, 01 Jan 2024 12:58:47 -0500,
Gellner, Oliver via mailop wrote:
> 
> 
> > On 28.12.2023 at 20:29 Marco Moock via mailop wrote:
> >
> > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
> >
> >> Has anyone detected or seen any evidence of SMTP smuggling in the
> >> wild?
> >>
> >> I’m trying to get an independent read on how quickly the bad actors
> >> have (or haven’t) picked up on this, yet.
> >
> > According to the information I read, it affected some hosting solutions
> > at 1und1/IONOS, but that has been fixed.
> 
> The vulnerability is not super critical, but it has been fixed only for a 
> very small subset of affected systems. All kind of MTAs from Postfix to 
> Sendmail, Exim and various proprietary systems are affected and the 
> vulnerability generally remains unfixed until the administrators adjust the 
> configuration of their system.
> I haven’t heard of any large scale exploitation in the past, but I imagine 
> that spammers will include the technique in their toolset for the future.
> 
> > Although, it needs to have certain circumstances, so the sending server
> > (for example a submission server for the customer) must accept it as one
> > message and the receiving server (e.g. the outgoing relay) must
> > interpret it as 2 messages and the 1. server need to be allowed to
> > relay through the second one for the really bad attacks
> > (unauthenticated relaying).
> 
> To exploit the issue, an email message needs to traverse two MTAs that treat 
> the EOM marker differently. The MTAs do not need to be in a special trust 
> relationship or allowed to relay to each other.
> 
> —
> BR Oliver
> 
> 
> dmTECH GmbH
> Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
> Telefon 0721 5592-2500 Telefax 0721 5592-2777
> dmt...@dm.de * www.dmTECH.de
> GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
> Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher
> 
> Datenschutzrechtliche Informationen
> Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
> ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
> Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder 
> sich bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen 
> unter anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren 
> Rechten sowie die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
> hier.
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> 

-- 
Your life is like a penny.  You're going to lose it.  The question is:
How do
you spend it?

 John Covici wb2una
 cov...@ccs.covici.com
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Randolf Richardson, Postmaster via mailop]

> > On 28.12.2023 at 20:29 Marco Moock via mailop wrote:
> >
> > Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
> >
> >> Has anyone detected or seen any evidence of SMTP smuggling in the
> >> wild?
> >>
> >> I´m trying to get an independent read on how quickly the bad actors
> >> have (or haven´t) picked up on this, yet.
> >
> > According to the information I read, it affected some hosting solutions
> > at 1und1/IONOS, but that has been fixed.
> 
> The vulnerability is not super critical, but it has been fixed only for a 
> very small subset of affected systems. All kind of MTAs from Postfix to 
> Sendmail, Exim and various proprietary systems are affected and the 
> vulnerability generally remains unfixed until the administrators adjust the 
> configuration of their system.
> I haven´t heard of any large scale exploitation in the past, but I imagine 
> that spammers will include the technique in their toolset for the future.

It is critical because it invovles the use of a system for 
unauthorized purposes -- namely, sending spam, distributing viruses 
and other malicious software, etc.  This justifies classifying SMTP 
Smuggling as a "security" issue, which I regard as critical.

The're also the underlying threat to a healthy mail system getting 
blacklisted, which also justifies classifying this as "critical" in 
my opinion.

> > Although, it needs to have certain circumstances, so the sending server
> > (for example a submission server for the customer) must accept it as one
> > message and the receiving server (e.g. the outgoing relay) must
> > interpret it as 2 messages and the 1. server need to be allowed to
> > relay through the second one for the really bad attacks
> > (unauthenticated relaying).
> 
> To exploit the issue, an email message needs to traverse two MTAs that treat 
> the EOM marker differently. The MTAs do not need to be in a special trust 
> relationship or allowed to relay to each other.

As I understand it, such techniques can be automated, which means 
that spamware could be created that takes advantage of the SMTP 
Smuggling exploit.

-- 
Postmaster - postmas...@inter-corporate.com
Randolf Richardson, CNA - rand...@inter-corporate.com
Inter-Corporate Computer & Network Services, Inc.
Vancouver, British Columbia, Canada
https://www.inter-corporate.com/


___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Gellner, Oliver via mailop]

> On 28.12.2023 at 20:29 Marco Moock via mailop wrote:
>
> Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:
>
>> Has anyone detected or seen any evidence of SMTP smuggling in the
>> wild?
>>
>> I’m trying to get an independent read on how quickly the bad actors
>> have (or haven’t) picked up on this, yet.
>
> According to the information I read, it affected some hosting solutions
> at 1und1/IONOS, but that has been fixed.

The vulnerability is not super critical, but it has been fixed only for a very 
small subset of affected systems. All kind of MTAs from Postfix to Sendmail, 
Exim and various proprietary systems are affected and the vulnerability 
generally remains unfixed until the administrators adjust the configuration of 
their system.
I haven’t heard of any large scale exploitation in the past, but I imagine that 
spammers will include the technique in their toolset for the future.

> Although, it needs to have certain circumstances, so the sending server
> (for example a submission server for the customer) must accept it as one
> message and the receiving server (e.g. the outgoing relay) must
> interpret it as 2 messages and the 1. server need to be allowed to
> relay through the second one for the really bad attacks
> (unauthenticated relaying).

To exploit the issue, an email message needs to traverse two MTAs that treat 
the EOM marker differently. The MTAs do not need to be in a special trust 
relationship or allowed to relay to each other.

—
BR Oliver


dmTECH GmbH
Am dm-Platz 1, 76227 Karlsruhe * Postfach 10 02 34, 76232 Karlsruhe
Telefon 0721 5592-2500 Telefax 0721 5592-2777
dmt...@dm.de * www.dmTECH.de
GmbH: Sitz Karlsruhe, Registergericht Mannheim, HRB 104927
Geschäftsführer: Christoph Werner, Martin Dallmeier, Roman Melcher

Datenschutzrechtliche Informationen
Wenn Sie mit uns in Kontakt treten, beispielsweise wenn Sie an unser 
ServiceCenter Fragen haben, bei uns einkaufen oder unser dialogicum in 
Karlsruhe besuchen, mit uns in einer geschäftlichen Verbindung stehen oder sich 
bei uns bewerben, verarbeiten wir personenbezogene Daten. Informationen unter 
anderem zu den konkreten Datenverarbeitungen, Löschfristen, Ihren Rechten sowie 
die Kontaktdaten unserer Datenschutzbeauftragten finden Sie 
hier.
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[A. Schulze via mailop]

Am 28.12.23 um 19:15 schrieb Tom Perrine via mailop:

Has anyone detected or seen any evidence of SMTP smuggling in the wild?

I’m trying to get an independent read on how quickly the bad actors have (or 
haven’t) picked up on this, yet.


known scanners (shodan, qualys & co) are generating most "hits" here

Andreas
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Any evidence of SMTP smuggling in the wild - yet?

[Marco Moock via mailop]

Am 28.12.2023 um 18:15:39 Uhr schrieb Tom Perrine via mailop:

> Has anyone detected or seen any evidence of SMTP smuggling in the
> wild?
> 
> I’m trying to get an independent read on how quickly the bad actors
> have (or haven’t) picked up on this, yet.

According to the information I read, it affected some hosting solutions
at 1und1/IONOS, but that has been fixed.

Although, it needs to have certain circumstances, so the sending server
(for example a submission server for the customer) must accept it as one
message and the receiving server (e.g. the outgoing relay) must
interpret it as 2 messages and the 1. server need to be allowed to
relay through the second one for the really bad attacks
(unauthenticated relaying).
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

[mailop] Any evidence of SMTP smuggling in the wild - yet?

[Tom Perrine via mailop]

Has anyone detected or seen any evidence of SMTP smuggling in the wild?

I’m trying to get an independent read on how quickly the bad actors have (or 
haven’t) picked up on this, yet.

Cheers,
Tom

___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop