Re: [mailop] Success MiTM attack

[Matt Palmer via mailop]

On Tue, Oct 24, 2023 at 11:04:05AM +0200, Alessandro Vesely via mailop wrote:
> On Tue 24/Oct/2023 06:53:37 +0200 Matt Palmer via mailop wrote:
> > On Tue, Oct 24, 2023 at 03:11:06AM +0100, Richard Clayton via mailop wrote:
> > > In message <07d58480-7dde-4d15-a5ca-5bb6c8e10...@mtasv.net>, Matt Palmer
> > > via mailop  writes
> > > 
> > > > The relative "noisiness" of the attack, in fact, is a fairly
> > > > strong signal that it *isn't* lawful intercept; western law
> > > > enforcement agencies are typically very hesitant to do anything
> > > > that could "tip off" the target of their investigation.
> > > 
> > > In my, perhaps jaundiced, view the revelation of the attack (an
> > > expired cert) suggests that it was indeed LI ... it's the sort of
> > > thing that goes wrong with ad hoc arrangements.
> > 
> > I would contend that p(noisy hackers) >> p(noisy lawful intercept).
> > It's not that the cops don't screw up now and then, but rather that
> > their failures tend to have greater adverse consequences (media,
> > politicians, blown investigations, abrupt career termination, etc), so
> > they're more motivated to not make this sort of mistake.
> > 
> > Meanwhile, hackers (and I include most of the non-western nation states
> > here) don't have to worry about PR problems, so forgetting to clean up
> > after themselves is less of a concern.  The exception of course is opsec
> > failures that lead to lengthy terms of incarceration, but forgetting to
> > renew a cert isn't *that* kind of mistake.
> 
> Is that the way it went?  Let's Encrypt certificates get renewed
> automatically, so it's hard to "forget" to do it.

That's not an inherent function of Let's Encrypt, but rather of the ACME
client being used to request certificate issuance.

> In order to get those
> certificates, and to divert traffic toward their proxy, they must have had
> access to a local router or something.  When that was fixed, fake
> certificates failed to renew.  No?

That is not my understanding of the timeline, based on the original article. 
The traffic interception was detected *because* the certificate expired,
which caused investigation that ultimately found evidence of traffic
redirection.  In other words, the malicious certificate *could* have been
renewed, however the attacker failed to do so.

> I'm not clear what the role of an anonymous cipher would have been.

My understanding from the article is that the only role that anonymous
ciphers played was that it was evidence that TLS was not terminating at the
correct location, because the genuine endpoint did not present anonymous
ciphers as an option, while the intercepting endpoint did.

- Matt

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

Re: [mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

[Ángel via mailop]

On 2023-10-24 at 14:11 +, Gellner, Oliver via mailop wrote:
> As far as I know this feature is not new but exists since a long time
> (years). It treats all messages from senders which are not on your
> safe senders list as spam and looks something like this: 
> https://filestore.community.support.microsoft.com/api/images/4a70ef0e-8c01-4d47-973c-6776c61aca90
> Why Microsoft is sending those messages into the feedback loop is
> another question. In a perfect world there should be filters in place
> which suppress/flag reports from an account if the spam reports reach
> a certain percentage of all received emails of this account.

And even without keeping statistics for filtering them, automatically
moved messages by this option should not be feeding the FBL.



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

Re: [mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

[Michael Peddemors via mailop]

On 2023-10-24 05:38, Benoît Panizzon via mailop wrote:

Hi Team

One of our customer is forwarding his emails on our platform to his
hotmail email address.

Today, we started getting a Microsoft Spam complaint for almost every
email that was being forwarded to his hotmail account.

I contacted the customer and asked, why he was reporting so many emails
that were clearly not spam as 'junk'. Of course I immediately got a
complaint from Microsoft about me sending spam to this customer.

I got hold of that customer.

He told me, he enabled a new feature called (sorry, I got this in
German) 'Put email from unknown sender in junk folder'.

Is there such a new feature in Hotmail? If so, I believe we can just
ditch that feedback loop.



Or, you can disable forwarding to Hotmail, and tell your customer to use 
your tools/services directly ;)




--
"Catch the Magic of Linux..."

Michael Peddemors, President/CEO LinuxMagic Inc.
Visit us at http://www.linuxmagic.com @linuxmagic
A Wizard IT Company - For More Info http://www.wizard.ca
"LinuxMagic" a Registered TradeMark of Wizard Tower TechnoServices Ltd.

604-682-0300 Beautiful British Columbia, Canada

This email and any electronic data contained are confidential and intended
solely for the use of the individual or entity to which they are addressed.
Please note that any views or opinions presented in this email are solely
those of the author and are not intended to represent those of the company.

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

Re: [mailop] Success MiTM attack

[Bernardo Reino via mailop]

On Tue, 24 Oct 2023, Slavko via mailop wrote:


Dňa 24. 10. o 4:04 Ian Kelling via mailop napísal(a):


 Anyone know how to monitor C-T logs? I looked around a bit and didn't
 see how to actually do it for let's encrypt certs.


I recently installed https://github.com/SSLMate/certspotter

Hard to say any opinion yet, as i install it on one my sparse machine with 
debian old stable, thus somewhat old certspotter version, and it is too  soon 
to know something useful. First result i expect in next week or two, when 
some of my certs have to be renewed (i don't want to force that).


When  o tried recent debian's version of it on my desktop, it tooks minimal 
RAM (~30 MB) and consumes 10-30% of CPU (not permanently, but in waves), thus 
it is doing something. I will continue to try it...


I use certspotter (# apt install certspotter, in debian 12), and it's really a 
no-brainer. Every time a subdomain of mine gets a new/renewed certificate, I get 
the notification within seconds (I also use the crt.sh RSS feed, but this is, 
from the point of view of the user, rather "passive" (polling), while 
certspotter is, "active").


The good thing is that you can monitor any domain you want, so you learn a lot 
about internal domains, etc. (think recon).___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

[Gellner, Oliver via mailop]

On 24.10.2023 at 14:39 Benoît Panizzon via mailop wrote:

> One of our customer is forwarding his emails on our platform to his hotmail 
> email address.
> Today, we started getting a Microsoft Spam complaint for almost every email 
> that was being forwarded to his hotmail account.
> I contacted the customer and asked, why he was reporting so many emails that 
> were clearly not spam as 'junk'. Of course I immediately got a complaint from 
> Microsoft about me sending spam to this customer.
> I got hold of that customer.
> He told me, he enabled a new feature called (sorry, I got this in
> German) 'Put email from unknown sender in junk folder'.
> Is there such a new feature in Hotmail? If so, I believe we can just ditch 
> that feedback loop.

As far as I know this feature is not new but exists since a long time (years). 
It treats all messages from senders which are not on your safe senders list as 
spam and looks something like this: 
https://filestore.community.support.microsoft.com/api/images/4a70ef0e-8c01-4d47-973c-6776c61aca90
Why Microsoft is sending those messages into the feedback loop is another 
question. In a perfect world there should be filters in place which 
suppress/flag reports from an account if the spam reports reach a certain 
percentage of all received emails of this account.

But this is not related to forwarding. If you send an email directly to the 
Hotmail address it will be treated in the same way. Like every other approach 
that is based purely on whitelists it creates a large amount of false positives.

--
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

[mailop] New hotmail function: 'Put emails from unknown sender as Junk' causing false complaints?

[Benoît Panizzon via mailop]

Hi Team

One of our customer is forwarding his emails on our platform to his
hotmail email address.

Today, we started getting a Microsoft Spam complaint for almost every
email that was being forwarded to his hotmail account.

I contacted the customer and asked, why he was reporting so many emails
that were clearly not spam as 'junk'. Of course I immediately got a
complaint from Microsoft about me sending spam to this customer.

I got hold of that customer.

He told me, he enabled a new feature called (sorry, I got this in
German) 'Put email from unknown sender in junk folder'.

Is there such a new feature in Hotmail? If so, I believe we can just
ditch that feedback loop.

-- 
Mit freundlichen Grüssen

-Benoît Panizzon- @ HomeOffice und normal erreichbar
-- 
I m p r o W a r e   A G-Leiter Commerce Kunden
__

Zurlindenstrasse 29 Tel  +41 61 826 93 00
CH-4133 PrattelnFax  +41 61 826 93 01
Schweiz Web  http://www.imp.ch
__
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] dovecot lmtp and smtputf8

[Kevin Kelker via mailop]

+1


Last official statement we saw was, that it's being tracked internally as 
DOP-1045

https://www.dovecot.org/pipermail/dovecot/2019-March/115286.html




However, we'd be interested in the current state regarding this as well.


Best

Kevin


Von: Kamil Jońca 
Gesendet: Dienstag, 24. Oktober 2023 07:04:02
An: dove...@dovecot.org
Betreff: dovecot lmtp and smtputf8


Does dovecot handle smtputf8?
Last articles regarding this are several years old.
Anything changed?
KJ
___
dovecot mailing list -- dove...@dovecot.org
To unsubscribe send an email to dovecot-le...@dovecot.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Colin Johnston via mailop]

Manual user of certbot renew me and definitely will be checking kernel log cert 
log cert issue logs every 2.5 months since renewal for letsecrypt at normal 3 
months

Colin

Sent from my iPod

> On 24 Oct 2023, at 11:01, Jaroslaw Rafa via mailop  wrote:
> 
> Dnia 24.10.2023 o godz. 11:04:05 Alessandro Vesely via mailop pisze:
>> 
>> Is that the way it went?  Let's Encrypt certificates get renewed
>> automatically, so it's hard to "forget" to do it.
> 
> They don't have to. You can just run a simple ACME client (like 'bacme') one
> time, get a certificate and install it manually. Nothing forces you to
> configure automatic renewal. If you are configuring a server with the only
> purpose of intercepting traffic, it seems quite probable to forget (or not
> bother at all) about configuring automatic certificate renewal.
> -- 
> 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
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] [E] Re: AT's abuse_...@abuse-att.net Email Address Undeliverable

[Lili Crowley via mailop]

contacting you off list.

*Lili Crowley*

she/her

Postmaster








On Tue, Oct 24, 2023 at 12:38 AM Justin Frechette via mailop <
mailop@mailop.org> wrote:

> My apologies as the email had a typo of the domain in the subject and body.
> I did send my email to abuse_...@abuse-att.net (as noted in the bounce).
>
> Justin
>
> On Tue, Oct 24, 2023 at 12:20 AM Justin Frechette <
> jus...@justinfrechette.com> wrote:
>
>> AT,
>>
>> I am unable to send email to abuse_...@abuse-att.net for blocklist
>> mitigation. It worked Friday but attempts today are failing. If possible,
>> could you please review the following IPs for blocklist removal for breach
>> notifications?
>>
>> 74.202.227.59
>> 74.202.227.60
>> 74.202.227.61
>>
>> Thank you,
>> Justin Frechette
>> iContact
>>
>> The original message was received at Tue, 24 Oct 2023 00:13:50 -0400
>> from mlpi433.enaf.sfdc.sbc.com
>> 
>> [144.160.20.149]
>>
>>- The following addresses had permanent fatal errors -
>> 
>> (reason: 550 5.1.1 : Recipient address
>> rejected: User unknown in local recipient table)
>>
>>- Transcript of session follows -
>> ... while talking to a51-eastus2-prod-mtavm.az.3pc.att.com
>> 
>> .:
>> >>> DATA
>> <<< 550 5.1.1 : Recipient address rejected:
>> User unknown in local recipient table
>> 550 5.1.1 ... User unknown
>> <<< 554 5.5.1 Error: no valid recipients
>>
> ___
> mailop mailing list
> mailop@mailop.org
>
> https://urldefense.com/v3/__https://list.mailop.org/listinfo/mailop__;!!Op6eflyXZCqGR5I!F7-IE1a70j3TOZTC1pUEjBM3Bap-ABWt08egjbBxh3yiTxrWXaFHQIE_mdtt-okyCgXlBBu1OBDlnIJv-_Y$
>
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Jaroslaw Rafa via mailop]

Dnia 24.10.2023 o godz. 11:04:05 Alessandro Vesely via mailop pisze:
> 
> Is that the way it went?  Let's Encrypt certificates get renewed
> automatically, so it's hard to "forget" to do it.

They don't have to. You can just run a simple ACME client (like 'bacme') one
time, get a certificate and install it manually. Nothing forces you to
configure automatic renewal. If you are configuring a server with the only
purpose of intercepting traffic, it seems quite probable to forget (or not
bother at all) about configuring automatic certificate renewal.
-- 
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] Success MiTM attack

[Alessandro Vesely via mailop]

On Tue 24/Oct/2023 06:53:37 +0200 Matt Palmer via mailop wrote:

On Tue, Oct 24, 2023 at 03:11:06AM +0100, Richard Clayton via mailop wrote:

In message <07d58480-7dde-4d15-a5ca-5bb6c8e10...@mtasv.net>, Matt Palmer
via mailop  writes

The relative "noisiness" of the attack, in fact, is a fairly strong signal 
that it *isn't* lawful intercept; western law enforcement agencies are 
typically very hesitant to do anything that could "tip off" the target of 
their investigation.


In my, perhaps jaundiced, view the revelation of the attack (an expired 
cert) suggests that it was indeed LI ... it's the sort of thing that 
goes wrong with ad hoc arrangements.


I would contend that p(noisy hackers) >> p(noisy lawful intercept).  It's 
not that the cops don't screw up now and then, but rather that their 
failures tend to have greater adverse consequences (media, politicians, 
blown investigations, abrupt career termination, etc), so they're more 
motivated to not make this sort of mistake.


Meanwhile, hackers (and I include most of the non-western nation states 
here) don't have to worry about PR problems, so forgetting to clean up after 
themselves is less of a concern.  The exception of course is opsec failures 
that lead to lengthy terms of incarceration, but forgetting to renew a cert 
isn't *that* kind of mistake.



Is that the way it went?  Let's Encrypt certificates get renewed automatically, 
so it's hard to "forget" to do it.  In order to get those certificates, and to 
divert traffic toward their proxy, they must have had access to a local router 
or something.  When that was fixed, fake certificates failed to renew.  No?


I'm not clear what the role of an anonymous cipher would have been.


Best
Ale
--



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

Re: [mailop] Success MiTM attack

[Christof Meerwald via mailop]

On Tue, Oct 24, 2023 at 12:17:30PM +0800, Philip Paeps via mailop wrote:
> On 2023-10-24 10:04:25 (+0800), Ian Kelling via mailop wrote:
> > Philip Paeps via mailop  writes:
> >> On 2023-10-22 14:34:39 (+0530), Slavko via mailop wrote:
> >> Indeed: not directly related to mailops.  But a very instructive example
> >> of why monitoring C-T logs is a good idea.
> >
> > Anyone know how to monitor C-T logs? I looked around a bit and didn't
> > see how to actually do it for let's encrypt certs.
> 
> crt.sh provides a handy service you can poll.
> 
> They provide JSON output.

They also provide an Atom feed you can use with your favourite
RSS/Atom feed reader.


Christof

-- 

https://cmeerw.org sip:cmeerw at cmeerw.org
mailto:cmeerw at cmeerw.org   xmpp:cmeerw at cmeerw.org
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Jasper Spaans via mailop]

On 24/10/2023 04:04, Ian Kelling via mailop wrote:

Anyone know how to monitor C-T logs? I looked around a bit and didn't
see how to actually do it for let's encrypt certs.
There is a link in the original article pointing 
tohttps://github.com/SSLMate/certspotterwhich you can run yourself.
We've been using the paid (hosted) version for years now and it works 
like a charm, informing us within minutes through email whenever 
something in our setup (or a third party like statuspage!) refreshes a 
certificate.  (And, I'm happy to say that we've never encountered certs 
having been issued that we could not identify)

Not affiliated, just a fan :)


Best regards,
Jasper
___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] Success MiTM attack

[Slavko via mailop]

Dňa 24. 10. o 4:04 Ian Kelling via mailop napísal(a):


Anyone know how to monitor C-T logs? I looked around a bit and didn't
see how to actually do it for let's encrypt certs.


I recently installed https://github.com/SSLMate/certspotter

Hard to say any opinion yet, as i install it on one my sparse machine 
with debian old stable, thus somewhat old certspotter version, and it is 
too  soon to know something useful. First result i expect in next week 
or two, when some of my certs have to be renewed (i don't want to force 
that).


When  o tried recent debian's version of it on my desktop, it tooks 
minimal RAM (~30 MB) and consumes 10-30% of CPU (not permanently, but in 
waves), thus it is doing something. I will continue to try it...


regards

--
Slavko

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

Re: [mailop] Success MiTM attack

[Matt Corallo via mailop]

On 10/23/23 9:43 PM, Matt Palmer via mailop wrote:

On Mon, Oct 23, 2023 at 10:04:25PM -0400, Ian Kelling via mailop wrote:

Philip Paeps via mailop  writes:

On 2023-10-22 14:34:39 (+0530), Slavko via mailop wrote:
Indeed: not directly related to mailops.  But a very instructive example
of why monitoring C-T logs is a good idea.


Anyone know how to monitor C-T logs? I looked around a bit and didn't
see how to actually do it for let's encrypt certs.


You *can* do it yourself, by scraping CT logs and looking for certs of
interest, but most people won't want to go to that level of hassle, and
instead will use an existing hosted service.  A search for "certificate
transparency monitoring service" will turn up quite a few, there's also a
list of services that's maintained at
https://certificate.transparency.dev/monitors/.


Last I tried that list zero of them actually worked (though admittedly this was a year ago or so). 
Censys I couldn't figure out (probably have to pay them?), Cloudflare seemed to only work if you 
actually used cloudflare, which I don't, couldn't get crt.sh to send mail, etc, etc. Facebook looked 
promising but it wanted to send me a facebook message, which, uhhh, its 2023, who checks those anymore?


Any recommendations for one that actually works (like, sign up, enter some domains and an email, it 
sends emails, nothing more, not thousands of dollars a year).


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

Re: [mailop] Success MiTM attack

[Matt Corallo via mailop]

On 10/23/23 7:11 PM, Richard Clayton via mailop wrote:

In message , Matt
Corallo via mailop  writes



On 10/23/23 3:26 AM, Jaroslaw Rafa via mailop wrote:



However, all this discussion is hardly related to email, as - as many have
noted - there's hardly any certificate checking at all between MTAs.


Indeed, MTAs mostly use DNSSEC/DANE which would have prevented this issue
entirely! MUAs much less
so, however.


I see nearly 100 MTA-STS reports (including most large mailbox
providers) every day ... that's about doubled over a year


Apologies, not quite sure I understood your point here - MTA-STS wasn't a topic of conversation, as 
far as I can tell. MTA-STS would not have prevented or materially mitigated this attack, DANE would 
have. (MTA-STS also happens to be a rather nuts rube goldberg machine, but that's a separate matter)


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