Re: [mailop] [External] Re: RackSpace Security Issue

[Kevin A. McGrail via mailop]

Here, here!

On 12/5/2022 5:11 PM, William Kern via mailop wrote:
best wishes to the poor sysadmins at Rackspace who are not having a 
good weekend/week.

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

Re: [mailop] TBTB: TLS Reporting really works

[Slavko via mailop]

Dňa 5. decembra 2022 21:57:42 UTC používateľ "Gellner, Oliver via mailop" 
 napísal:

>The reason for this might be that most report addresses are parsed by scripts, 
>not read by humans, and the scripts aren’t subsceptible to buy the advertised 
>products. The spammers would need to create spam content in valid DMARC or 
>TLSRPT formats, ie insert the spam messages as values into the XML / JSON 
>tags, so that eventually a human reads it. This sounds like a lot of extra 
>work with little benefit.

Perhaps, but i am (my MTA) getting SPAMs to Mozilla MID like addresses
for years. Recently i start to get SPAMs to names not common in our country
(our country TLD), including English service accounts (invoice, or so) and even
to our XMPP's JIDs (which newer had email account), etc, etc. In other words,
by my experiences, the spammers are able to try anything what at least
looks as valid email address, scraped from anywhere... Thus why not try
those report addresses? I do not complain, i am only surprised...

I will guess, that multiple (many?) small/personal MTAs will have these
reports enabled, but have parsing triggered manualy, as there are multiple
tools for that, eg. on github...

>To test the script with other TLS reports you can try to get the mailservers 
>of mail.ru, Socketlabs or companies that use MDaemon to send emails to you

I am not as interested in these reports. After i will get some other than from
google and it fails to parse, it will wait in queue for some days, thus i can
fix/improve my script, as i did with DMARC reports, which i initaly did on
RFC base and then i lower my (or script's) expectations. Now it works
and i do not remember when it fails last -- many months ago.

regards


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

Re: [mailop] RackSpace Security Issue

[Robert Schoneman via mailop]

Kevin’s full article goes in to some more detail about the possibility 
Rackspace Cloud Office suffers security breach | by Kevin Beaumont | Dec, 2022 
| 
DoublePulsar

From: mailop  On Behalf Of William Kern via mailop
Sent: Monday, December 5, 2022 5:11 PM
To: mailop@mailop.org
Subject: Re: [mailop] RackSpace Security Issue

thanks all, It seems we will all have to wait for the after action report to 
find out what really happened and what are the consequences. In the meantime, 
we can only express best wishes to the poor s
[cid:image001.png@01D908CE.0ED0F240]
External (mailop@mailop.org)
[cid:image002.png@01D908CE.0ED0F240]
  Report This 
Email
  FAQ  Protection by 
INKY


thanks all,

It seems we will all have to wait for the after action report to find out what 
really happened and what are the consequences.

In the meantime, we can only express best wishes to the poor sysadmins at 
Rackspace who are not having a good weekend/week.

-bill
On 12/5/2022 1:22 PM, Louis Laureys via mailop wrote:

This is the only thing I came across:
https://cyberplace.social/@GossiTheDog/109446533829121659

Louis

Op maandag 5 december 2022 om 19:50, schreef William Kern via mailop:

I was contacted by a website customer over the weekend, who is affected by the 
RackSpace Exchange "security issue".

At this point, they are transitioning to O365 so they should be fine going 
forward, but aside from email interruption they are not sure how they are 
affected.

Their main concern is email disclosure.

I'm trying to 'google' around but most of what I am finding are 'Rackspace is 
down' and complaints they aren't saying much.

Does anyway have additional info?

Since I also have customers who run their own Exchange servers, I'm curious if 
there is some new exploit out there, that they should be worried about.

Sincerely

William "Bill" Kern

PixelGate Networks.

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



___

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] RackSpace Security Issue

[William Kern via mailop]

thanks all,

It seems we will all have to wait for the after action report to find 
out what really happened and what are the consequences.


In the meantime, we can only express best wishes to the poor sysadmins 
at Rackspace who are not having a good weekend/week.


-bill

On 12/5/2022 1:22 PM, Louis Laureys via mailop wrote:


This is the only thing I came across:
https://cyberplace.social/@GossiTheDog/109446533829121659

Louis

Op maandag 5 december 2022 om 19:50, schreef William Kern via mailop:

I was contacted by a website customer over the weekend, who is
affected by the RackSpace Exchange "security issue".

At this point, they are transitioning to O365 so they should be
fine going forward, but aside from email interruption they are not
sure how they are affected.

Their main concern is email disclosure.

I'm trying to 'google' around but most of what I am finding are
'Rackspace is down' and complaints they aren't saying much.

Does anyway have additional info?

Since I also have customers who run their own Exchange servers,
I'm curious if there is some new exploit out there, that they
should be worried about.

Sincerely

William "Bill" Kern

PixelGate Networks.

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


___
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] TBTB: TLS Reporting really works

[Gellner, Oliver via mailop]

> Am 05.12.2022 um 15:15 schrieb Slavko via mailop :
>
> Yes, now i understand, thanks. I am surprised, that i don't see any
> SPAM on DMARC/TLS reports addresses and they are published
> about one year for TLS and for DMARC even longer.

The reason for this might be that most report addresses are parsed by scripts, 
not read by humans, and the scripts aren’t subsceptible to buy the advertised 
products. The spammers would need to create spam content in valid DMARC or 
TLSRPT formats, ie insert the spam messages as values into the XML / JSON tags, 
so that eventually a human reads it. This sounds like a lot of extra work with 
little benefit.


To test the script with other TLS reports you can try to get the mailservers of 
mail.ru, Socketlabs or companies that use MDaemon to send emails to you. 
However since there are only a few different senders of TLS reports, the 
overall quality of the reports is generally higher than that of DMARC reports 
where you have to be prepared for reports which not even remotely resemble what 
the RFC define.

—
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] RackSpace Security Issue

[Louis Laureys via mailop]

This is the only thing I came across:
https://cyberplace.social/@GossiTheDog/109446533829121659


Louis


Op maandag 5 december 2022 om 19:50, schreef William Kern via mailop:

> I was contacted by a website customer over the weekend, who is affected by the
> RackSpace Exchange "security issue".
> 
> At this point, they are transitioning to O365 so they should be fine going
> forward, but aside from email interruption they are not sure how they are
> affected.
> 
> Their main concern is email disclosure.
> 
> I'm trying to 'google' around but most of what I am finding are 'Rackspace is
> down' and complaints they aren't saying much.
> 
> Does anyway have additional info?
> 
> Since I also have customers who run their own Exchange servers, I'm curious if
> there is some new exploit out there, that they should be worried about.
> 
> Sincerely
> 
> William "Bill" Kern
> 
> PixelGate Networks.
> 
> ___
> mailop mailing list
> mailop@mailop.org
> https://list.mailop.org/listinfo/mailop
> [https://list.mailop.org/listinfo/mailop]___
mailop mailing list
mailop@mailop.org
https://list.mailop.org/listinfo/mailop

Re: [mailop] RackSpace Security Issue

[Richard via mailop]

> Date: Monday, December 05, 2022 10:50:48 -0800
> From: William Kern 
>
> I was contacted by a website customer over the weekend, who is
> affected by the RackSpace Exchange "security issue".
> 
> At this point, they are transitioning to O365 so they should be
> fine going forward, but aside from email interruption they are not
> sure how they are affected.
> 
> Their main concern is email disclosure.
> 
> I'm trying to 'google' around but most of what I am finding are
> 'Rackspace is down' and complaints they aren't saying much.
> 
> Does anyway have additional info?
> 
> Since I also have customers who run their own Exchange servers, I'm
> curious if there is some new exploit out there, that they should be
> worried about.
> 
> Sincerely
> 

See their status page:



for hints, such as they are. They have been updating that page every
12 to 24 hours.


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

Re: [mailop] [EXTERNAL] Re: TBTB: TLS Reporting really works

[Brotman, Alex via mailop]

> -Original Message-
> From: mailop  On Behalf Of Slavko via mailop
> Sent: Monday, December 5, 2022 9:09 AM
> To: mailop@mailop.org
> Subject: [EXTERNAL] Re: [mailop] TBTB: TLS Reporting really works
> 
> Dňa 5. decembra 2022 10:21:45 UTC používateľ Alessandro Vesely via mailop
>  napísal:
> 
> >Useless TLSRPT messages report successful connections only.
> 
> Yes, now i understand, thanks. I am surprised, that i don't see any SPAM on
> DMARC/TLS reports addresses and they are published about one year for TLS
> and for DMARC even longer.

I'd suspect this has to do with the typical target.  IOW, these messages 
usually go to systems, not humans.  Systems will just go "Nope, not a report.  
Discard".

> 
> >Hm... if I cannot read it as file I probably cannot parse it either, no?
> 
> In principle yes, but i meet emails which failed in text mode, but i 
> successfuly
> read them as bytes. I do not remember exact details (in mean if the problem
> was reading or parsing) as it was relative long time ago and from that time i
> always read mails as bytes. It can be Python internals related, or broken
> emails with wrong encoding declared (i relative often see that -- US-ASCII is
> not enough for us).
> 
> As addition, i always define policy when reading emails, to get new type
> EmailMessage object, as by default reading email results in old (Python 3.2
> compatible) Message object, which hasn't some nice new features...
> 

FWIW, I did open source a TLSRPT ingestion script.  It has at least one bug I 
know of, and probably needs a bit of work otherwise (which may be done, I need 
to validate).  https://github.com/Comcast/tlsrpt_processor

> BTW, i start to learn XSLT by your DMARC processing, thanks for inspiration 
> ;-)
> 
> regards
> 
> 
> 
> --
> Slavko
> https://urldefense.com/v3/__https://www.slavino.sk/__;!!CQl3mcHX2A!Ar
> aMQELGGC7cmE47p1Ke_3aw7Z57R-
> yNfyxBoPj_d91GVUscxnGl4WPKFFzI57QqUDGVw0A-gr4ZdrFBSos$

--
Alex Brotman
Sr. Engineer, Anti-Abuse & Messaging Policy
Comcast

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

[mailop] RackSpace Security Issue

[William Kern via mailop]

I was contacted by a website customer over the weekend, who is affected 
by the RackSpace Exchange "security issue".


At this point, they are transitioning to O365 so they should be fine 
going forward, but aside from email interruption they are not sure how 
they are affected.


Their main concern is email disclosure.

I'm trying to 'google' around but most of what I am finding are 
'Rackspace is down' and complaints they aren't saying much.


Does anyway have additional info?

Since I also have customers who run their own Exchange servers, I'm 
curious if there is some new exploit out there, that they should be 
worried about.


Sincerely

William "Bill" Kern

PixelGate Networks.

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

Re: [mailop] TBTB: TLS Reporting really works

[Slavko via mailop]

Dňa 5. decembra 2022 10:21:45 UTC používateľ Alessandro Vesely via mailop 
 napísal:

>Useless TLSRPT messages report successful connections only.

Yes, now i understand, thanks. I am surprised, that i don't see any
SPAM on DMARC/TLS reports addresses and they are published
about one year for TLS and for DMARC even longer.

>Hm... if I cannot read it as file I probably cannot parse it either, no?

In principle yes, but i meet emails which failed in text mode, but i
successfuly read them as bytes. I do not remember exact details (in
mean if the problem was reading or parsing) as it was relative long
time ago and from that time i always read mails as bytes. It can be
Python internals related, or broken emails with wrong encoding
declared (i relative often see that -- US-ASCII is not enough for us).

As addition, i always define policy when reading emails, to get
new type EmailMessage object, as by default reading email results
in old (Python 3.2 compatible) Message object, which hasn't some
nice new features...

BTW, i start to learn XSLT by your DMARC processing, thanks for
inspiration ;-)

regards



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

Re: [mailop] TBTB: TLS Reporting really works

[Alessandro Vesely via mailop]

On Sun 04/Dec/2022 19:17:39 +0100 Slavko via mailop wrote:

Dňa 4. decembra 2022 12:30:25 UTC používateľ Alessandro Vesely via mailop 
 napísal:


So useful that I decided to share the script I use to discriminate useful from 
useless reports.


Can you please be more verbose in what you see these reports useful
and which and why you consider some as useless?

I am receiving TLS reports for some time and i don't see them useful,
perhaps because i am getting too low number of emails from google (except
usual SPAMs), or because i do not use MTA-STS (no plans) nor DANE (yet),
i was only curious what i can see, when i setup it.



I consider blatant spam, I mean SA score > 9, an abuse.  As such I pass it to 
the firewall which blocks the offending IP for some time.  Now, I do have some 
correspondents on Gmail, and I don't know how Google manages sending IPs.  So I 
face the risk of blocking wanted mail that way.  That's where TLS reporting 
comes to my rescue.  Google tells me what IPs of theirs I did block.


Useless TLSRPT messages report successful connections only.



Here it is:
https://www.tana.it/sw/tlsrpt/


I have something similar too, with difference, that my script extract reports
and stores them as XML, which is then processed by nginx's xslt module to
make it readable in browser. The mails are feed directly into it from MTA,
thus i can see results, when i want/need (not often).



I see.  I use XSLT to print DMARC reports.

For TLSRPT, maybe because I never had TLS failures proper, the only interesting 
data I found in those reports is the failing IP number.




My script is more strict to processing content, as RFC requires gzip,
thus anything non-gzip compressed is reported as error. I do not rely on
content type, but i check gzip header directly (first three bytes). As i am
getting reports only from google, i didn't encounter any troubles with
its automated processing.



I received an application/octet-stream report from Microsoft.  So I added code 
to also read an unknown zip type.  Zlib does check the zip header in that case:


windowBits can also be greater than 15 for optional gzip decoding.
Add 32 to windowBits to enable zlib and gzip decoding with automatic
header detection, or add 16 to decode only the gzip format (the zlib
format will return a Z_DATA_ERROR).
http://www.zlib.net/manual.html

I just added some better logging to the script.



As i have similar design for DMARC reports (which i see more useful), i
can state that TLS reports are more simple to process than DMARC, as
here are not old RFC with differences in formats. But i don't like its JSON
format... I guess, that your script evolved from DMARC processing too.



Yeah, somewhat.  I agree that DMARC reports look more useful.



I learned from DMARC report troubles, that i have read email as bytes,
not as string (doesn't matter if from stdin or from file), to make script more
robust in case some garbage (not printable char) is in it. I strongly suggest
to consider that too, working with bytes is the same after you read it...



Hm... if I cannot read it as file I probably cannot parse it either, no?

Thanks for reviewing the script.

Best
Ale
--






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