top | item 46731996

Microsoft mishandling example.com

249 points| mrled | 1 month ago |tinyapps.org

89 comments

order

gruez|1 month ago

>Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" "https://prod.autodetect.outlook.cloud.microsoft/autodetect/d...":

Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account? I'm sure they pinky promise they keep your credentials secure, but this feels like it breaks all sorts of security/privacy expectations.

dspillett|1 month ago

> Hold up, does this mean outlook sends your full credentials to Microsoft when you try to set up an outlook account?

Not just an “outlook account” - any account in outlook, with default settings at least.

I run a mail server, mainly for me but a couple of friends have accounts on there too, and a while ago one friend reported apparently being locked out and it turned out that it was due to them switching Outlook versions and it was connecting via a completely different address to those that my whitelists expected sometimes at times when they weren't even actively using Outlook. Not only were active connections due to their interactive activity being proxied, but the IMAP credentials were stored so the MS server could login to check things whenever it wanted (I assume the intended value-add there is being able to send new mail notifications on phones/desktops even when not actively using mail?).

> but this feels like it breaks all sorts of security/privacy expectations.

It most certainly does. The behaviour can be tamed somewhat, but (unless there have been recent changes) is fully enabled by default in newer Outlook variants.

The above-mentioned friend migrated his mail to some other service in a huf as I refused to open my whitelist to “any old host run by MS” and he didn't want to dig in to how to return behaviour back to the previous “local connections only, not sending credentials off elsewhere where they might be stored”.

butvacuum|1 month ago

Basically everything microsoft makes that touches http will send your username and your password to any server that asks for Basic Authentication.

It looks like Microsoft Edge had the _ability to disable_ this added in 2020 or 2021, but it isn't currently the default and the Group Policy unintuitively only applies to unencrypted HTTP Connections.

thedanbob|1 month ago

It's more common than you might think. I know of at least one popular email client that stores your credentials on their servers to enable features like multi-account sync and scheduled sending.

tga|1 month ago

Most likely, and nobody cares.

Already many years ago I remember installing a firewall on my phone and noticing in surprise that Outlook was not connecting at all to my private mail server, but instead only sending my credentials to their cloud and downloading messages from there.

The only Android mail client not making random calls to cloud servers was (back then) K-9 Mail.

dec0dedab0de|1 month ago

I think outlook is pretty much a saas product these days.

Neil44|1 month ago

I think the curl -u switch just requires the password field to be filled, there obviously isn't a legit user account test@example.com with a password of password either at microsoft or at the Japanese imap server.

nhinck2|1 month ago

Yeah since the Windows 11 2023h2 update.

DANmode|1 month ago

See also: Windows 11 telemetry

GranPC|1 month ago

> Microsoft's Autodiscover service misconfiguration can be confirmed via curl -v -u "email@example.com:password" "https://prod.autodetect.outlook.cloud.microsoft/autodetect/d..."

Wait, does their autodetect send email and password to their servers, instead of just domain???

irusensei|1 month ago

Not surprised. They used to have training material incentivizing professionals to use .local as TLD for Active Directory realms. Thats a reserved domain for Multicast DNS.

Working on Linux automation systems we would need to make sure to disable anything related to Avahi in our images otherwise name resolution would fail for some customers.

ndriscoll|1 month ago

Haven't they been telling people to do that since before it became reserved? If so, the problem is more that you can't "reserve" something that's already in wide use, and mdns should've used something like .mdns.

It's like when .dev became a gTLD, knowingly breaking a bunch of setups for a mix of vanity and a cash grab. Obviously dropped the ball on the engineering side.

szszrk|1 month ago

My company used .local for EVERYTHING. I took it as normal at the time, until I got into problems with VMWARE products.

Support patiently explained .local is reserved for something else and kindly provided Wikipedia links.

They never responded why they used .local in their docs, trainings, webinars they provided, though :)

p_ing|1 month ago

Usage of .local for AD predated mDNS. That advice stopped with the advent of mDNS in favor of 'corp.<registered_domain>.<tld>'.

philo23|1 month ago

Just a guess but why do I get the feeling it’s because someone who setup sei.co.jp in Azure Entra (aka Azure AD) some how managed to add/claim the domain “example.com” against their companies tenant.

It’s clearly not using the DNS records for discovery because they don’t exist, the only other option I can see is some weird fall through or hard coded value and it seems like an odd one to pick.

Thaxll|1 month ago

Where does sei.co.jp comes from? Why Microsoft would use that domain in the first place?

Daviey|1 month ago

I'm willing to bet they were the first user to try and add example.com to their Outlook account, and MS then just assigned it to them without verifying they own the domain.

irusensei|1 month ago

It's not really the domain but the registration in the MS Office Cloud. If you query who owns example.com mail you get that company.

emmelaich|1 month ago

> The domain has a null MX record (indicating it doesn't accept email)

Not quite true, SMTP will use the A record if there is no MX.

dpifke|1 month ago

In this case, "null MX record" means MX exists, but does not specify a valid server:

   $ host -t mx example.com
   example.com mail is handled by 0 .
Senders should not fall back on the A record in this case.

andreldm|1 month ago

That’s why example.com states “Avoid use in operations”, not only that could create unnecessary traffic for them as well as leak information as in situations like this.

charles_f|1 month ago

Yeah, it feels more like a safety net than something you should purposefully use

binaryturtle|1 month ago

Why do you need to send a password when using their Autodiscover API? Would Outlook send the respective passwords for each email account to Microsoft?

philipwhiuk|1 month ago

I suspect they try to login and reverse engineer the IMAP config.

Neil44|1 month ago

curl -u just requires the field to be there, I suspect. No authentication takes place. You can send any password and the output doesn't change.

hu3|1 month ago

This is why I never use these IANA-reserved domains like .test, .example, .invalid, .localhost.

I always make up some impossible domains like domain.tmptest

Otherwise you're one DNS "misconfiguration" away from sending dev logs and auth tokens to some random server.

> Since at least February 2020, Microsoft's Autodiscover service has incorrectly routed the IANA-reserved example.com to Sumitomo Electric Industries' mail servers at sei.co.jp, potentially sending test credentials there.

tialaramex|1 month ago

It so happens that in this very specific case your obviously bad choice didn't make anything worse, that doesn't make it a good choice.

"Aha, the defective trucks only cause injuries to people who have their hands on the wheel at highway speeds, but I've never bothered holding the wheel at high speed, I just YOLO so I wouldn't be affected"

If people had used IANA's reserved TLDs they too would be unaffected because although Windows will stupidly try to talk to for example autodiscover.example that can't exist by policy and so the attempt will always fail.

dc396|1 month ago

As others have pointed out, using 'tmptest' works until someone buys tmptest -- unlikely, but people will buy anything these days.

I always use the ISO-3166 "user-assigned" 2-letter codes (AA, QM-QZ, XA-XZ, ZZ), with the theory being that ISO-3166 Maintenance Agency getting international consensus to move those codes back to regular country codes will take longer than the heat death of the universe, so using them for internal domains is probably safe.

jsheard|1 month ago

It's all fun and games until Donuts buys .tmptest for some reason.

Cthulhu_|1 month ago

Would that really make a difference in this case? It's a configuration error / bug in Microsoft's discovery server, they could have a fallback that goes "any unknown address, return this .jp address".

larrik|1 month ago

And then you fire off 100k emails, they all bounce, and your mail service shuts you off...

wongarsu|1 month ago

brb, just filing paperwork to apply for the .tmptest gTLD /s

onionisafruit|1 month ago

I gather this has little to do with “example.com” and more to do with any domain that doesn’t have an autodiscover subdomain.

butz|1 month ago

Nice to see tinyapps.org is still alive.

1vuio0pswjnm7|1 month ago

Now that example.com is hidden behind Cloudflare, how does the public know who is controlling the origin servers

The IPv4 for example.com used to be 93.184.216.34

Was there an announcement somewhere

1vuio0pswjnm7|1 month ago

The old nameservers for example.com still have not updated their zone files

   dq a example.com 199.43.135.53

godzillabrennus|1 month ago

This is the same company that mishandled the Office brand (abandoned it) and is mishandling the Xbox brand (what even is an Xbox anymore?). Are we surprised?

rurban|1 month ago

NSA probably. Gives them plausible deniability.

Maybe some of their targets did use example.com for some probing, and the NSA had a hand in Sumitomo Electric Industries' mail server.

whizzter|1 month ago

Reading the article, there is a huge flaw in the autodiscover protocol by Microsoft.

https://www.akamai.com/blog/security/autodiscovering-the-gre...

According to it, it seems that if someone registers autodiscover.com then example.com lacking autodiscover.example.com will make Outlook try checking if autodiscover.com has an entry.

It's just a braindead system.