Microsoft mishandling example.com

Posted by mrled 1 day ago

Comments

Comment by gruez 1 day 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.

Comment by dspillett 1 day 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”.

Comment by brulx126 1 day ago

Not just that, the new outlook app makes Microsoft a complete man-in-the-middle for your email account.

https://www.xda-developers.com/privacy-implications-new-micr...

Comment by kstrauser 1 day ago

I am so glad people are finally noticing and complaining about this. It's the same reason I won't use Spark or Superhuman. Those are neat services, but I can't abide storing the creds to perhaps the most security-sensitive service I use to a cloud provider. If they get hacked, then the attacker can access my email account, send phishing emails to my contacts, read and respond to password reset requests they make to other online services, etc. It would be disastrous.

No, I'll keep my credentials stored and used locally, thanks.

Comment by donmcronald 1 day ago

They store passwords and proxy everything at the same time they’re pushing OAuth, authenticators, passkeys, etc. for their own services. Everyone should have revolted when they bought Acompli and started doing this kind of thing.

Comment by amluto 1 day ago

This seems like it would completely break any attempt to track access from unauthorized users or devices — any IT department using a backend other than Microsoft’s would need to pretend that all access from MS’s servers is safe.

Comment by fc417fc802 9 hours ago

In response to discovering this any competent IT department would immediately move to ban the use of any offending apps and blacklist the MS servers from the relevant backends. Also I guess rather than drop the connections ideally you would want to accept the initial request, record the provided credentials, and then lock said account because the credentials have clearly been compromised and the user is now known to be making use of a banned app.

Comment by amluto 50 minutes ago

It’s also the case that, of the major cloud providers, one of them is quite notably poor at securing its own systems. If I were a company that cared about security, I would not want Microsoft holding credentials to my system.

Comment by encom 22 hours ago

So like Cloudflare for email.

Comment by koakuma-chan 1 day ago

And? Do you think Gmail is end to end encrypted?

Comment by gruez 1 day ago

My bank isn't end to end encrypted either, but that doesn't mean it's suddenly ok for Microsoft (or any other company) to suddenly start MITMing my online banking connections.

Comment by brulx126 1 day ago

I am talking about the fact that the new default email client on Windows will hand over all your email credentials to Microsoft. This has nothing to do with Gmail.

Comment by koakuma-chan 1 day ago

Oh you mean even if you don't use Microsoft's email? Now I get it.

Comment by delfinom 1 day ago

I think the concern is that it copies the emails of your non-Microsoft accounts that you added to the Outlook app, over to Microsoft servers

Comment by AlexandrB 1 day ago

Adding a bunch of middlemen that also see the data increases the risk.

Comment by butvacuum 1 day 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.

Comment by gruez 1 day ago

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

Are you talking about NTLM hashes? It's a weak hash, but not the same as "sending your password". The biggest difference is that even a weak hash can't be reversed if the password has high enough entropy.

Comment by butvacuum 1 day ago

yes, I meant to type hash. Not that it matters as even 10yr old integrated GPUs are enough to brute force 8 or 9 character NTLM(or any variant) passwords in a few hours. Not that you need to with Pass The Hash.

Comment by lazide 1 day ago

Not necessarily, the server can say it only supports basic auth and….

Comment by gruez 1 day ago

I don't think there's any evidence that windows sends cleartext passwords. The whole reason why NTLM is a thing is to avoid sending cleartext passwords.

Comment by lazide 1 day ago

Outlook appears to be

Comment by p_ing 1 day ago

The 'https://' disagrees with your 'sending clear text passwords' statement.

Comment by lazide 23 hours ago

It’s clear text to the receiving server, which is what we’re talking about, not one way hashed.

Comment by thedanbob 1 day 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.

Comment by RajT88 1 day ago

I bought a hardware password manager a while back and the bulk load tool sent all your creds to a cloud service. I have not used it since, and sent the manufacturer a nasty note.

It was the Ethernom Beamu, company now defunct.

Comment by spiffyk 1 day ago

I would expect such a feature to use end-to-end encryption for the data, so that only the user can see the credentials. It does, right? Right?

Comment by gruez 1 day ago

>>multi-account sync and scheduled sending

>I would expect such a feature to use end-to-end encryption for the data

How would "end-to-end encryption" when such features by definition require the server to have access to the credentials to perform the required operations? If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".

Comment by treyd 1 day ago

> If by "end to end" you actually mean it's encrypted all the way to the server, that's just "encryption in transit".

This is what Zoom claimed was e2ee for a little while before getting in trouble for it.

Comment by kingstnap 20 hours ago

This is what Google also claims as end to end encrypted in their Gmail end to end thing. Many people including me mentioned this in the comments.

https://news.ycombinator.com/item?id=45458482

Its entirely their end to their end encrypted. You don't get any privacy.

Comment by fc417fc802 9 hours ago

Use our new open source (modification and redistribution not permitted) app to exchange end-to-end encrypted (from your client to our server) messages with your friends! Having all your data on our service protects your data sovereignty (we do not provide for export or interop) by guaranteeing that you always have access to your full history! Usage also protects your privacy (we analyze your data for marketing purposes) by preventing unscrupulous third parties from analyzing your data for marketing purposes.

If we had competent regulators this sort of blatant willful negligence would constitute false advertising.

Comment by tom1337 1 day ago

Do you mean Spark? I get why they need to do it that way but I also hate that they have to do it that way because it sucks for privacy.

Comment by tga 1 day 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.

Comment by Neil44 1 day 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.

Comment by gruez 1 day ago

>I think the curl -u switch just requires the password field to be filled

Yeah you're right, if you don't specify the password (eg. -u user), it prompts you for it

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

But presumably the fact it's there at all suggests it's a required parameter? Maybe "password" is just a placeholder, but it's unclear based on the command line transcript alone.

Comment by dec0dedab0de 1 day ago

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

Comment by DANmode 14 hours ago

What gave it away, the intrusive ads in your free inbox the last ten years,

or the “See Plans and Pricing” on the homepage?

Christ, my poor grandmother…

Comment by nhinck2 1 day ago

Yeah since the Windows 11 2023h2 update.

Comment by DANmode 15 hours ago

See also: Windows 11 telemetry

Comment by 1718627440 1 day ago

Always has been.

Comment by GranPC 1 day 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???

Comment by stronglikedan 1 day ago

See replies to a similar question here (in case you haven't already): https://news.ycombinator.com/item?id=46732623

Comment by technion 22 hours ago

Autodiscover has always been an interesting security problem. I wrote this years ago:

https://lolware.net/blog/2020-09-02-autodiscover-circus/

Comment by 1 day ago

Comment by irusensei 1 day 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.

Comment by ndriscoll 1 day 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.

Comment by WorldMaker 1 day ago

Seems more a reason to never use stuff you don't actually control and are reserved for future purposes. Everyone knew who was in charge of DNS TLDs and that while they were being at first conservative in how many they assigned, they reserved the right to assign as many as they wanted.

But also, yes Microsoft documentation used .local before mDNS reserved it, and IIRC Microsoft was also involved in suggesting it for mDNS as mDNS came out of the multi-company standardization efforts from Apple's Bonjour. That said, my impression of most of that documentation from that time is that it was incorrectly using .local as a fake TLD where they should have been using .example or .example.com and also pointing people to the RFCs that those were not valid choices in a real setup. A problem with such documentation is that it is too easy to take literally. A follow up problem was sort of the "accidental security through obscurity" benefits of using non-globally resolvable addresses becomes "best practice" through essentially stubbornness and status quo (related to all the recent rediscussions on HN about NAT44 is not a firewall except by accident and you can have very good firewalls that aren't NAT44).

Comment by RulerOf 17 hours ago

> my impression of most of that documentation from that time is that it was incorrectly using .local as a fake TLD

When setting up Active Directory on Windows Server 2003, there was a note in the wizard that explicitly called out .local as a domain suffix that would prevent DNS lookups from hitting the public internet, which many people (myself included) took as an endorsement.

Comment by UqWBcuFx6NV4r 16 hours ago

I feel like I remember this in 2008 as well. I could certainly be misremembering.

Comment by justsomehnguy 21 hours ago

> Haven't they been telling people to do that since before it became reserved

If you actually try to find an evidence for this (even time traveling to 2015 before the great wipe of most pre-Vista docs) you wouldn't find a confirmation for this. What you would find is what the official docs always recommended the root domain to be an official bought one on the public internet. And this excludes .local.

Comment by szszrk 1 day 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 :)

Comment by EvanAnderson 1 day ago

Things from docs making it into production is insidious. There were some early Sun docs that referenced a 129.9.0.0/16 network. Some helpful contractor in my locality, specializing in local government work, configured several police, fire, and city governments with that subnet internally back in the 90s. A few of them are still running that way today. I remember running into some oddball behavior with the Teredo adapter in Windows 7 that I traced back to it behaving differently because the PC's IP address didn't fall into RFC1918 space.

Comment by somat 1 day ago

Makes me remember the 192.1 addresses that were all over at one place I worked. "Um you know that is a valid internet address right?" "Yeah, but the guy who originally set the systems up was confused about the private address space, used the wrong one and we don't want to break anything so are not going to change it"

Good times.

Comment by PcChip 1 day ago

I’ve worked with hundreds of customers that use .local internal domains and vmware, what issues are you describing?

Comment by irusensei 1 day ago

My impression is that Ballmer IE6 era Microsoft didn't gave a shit about standards.

Comment by jve 1 day ago

Is standard you are talking about is Multicast DNS https://www.rfc-editor.org/rfc/rfc6762 from year 2013?

Comment by p_ing 1 day ago

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

Comment by EvanAnderson 1 day ago

The original Windows 2000 guidance for AD was corp.example.com, from my recollection. The silly .local thing (which does predate mDNS) happened as a result of the Small Business Server refresh for Active Directory.

Comment by philo23 1 day 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.

Comment by Thaxll 1 day ago

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

Comment by Daviey 1 day 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.

Comment by irusensei 1 day 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.

Comment by emmelaich 1 day 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.

Comment by dpifke 1 day 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.

Comment by andreldm 1 day 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.

Comment by charles_f 1 day ago

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

Comment by binaryturtle 1 day 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?

Comment by philipwhiuk 1 day ago

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

Comment by Neil44 1 day 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.

Comment by hu3 1 day 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.

Comment by tialaramex 1 day 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.

Comment by dc396 1 day 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.

Comment by jsheard 1 day ago

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

Comment by xaerise 9 hours ago

The correct one to use is .internal

It is reserved by ICANN since 2024-07-29.

https://en.wikipedia.org/wiki/.internal https://www.ietf.org/archive/id/draft-davies-internal-tld-00...

Comment by fc417fc802 8 hours ago

You can also safely use .home .corp and .mail as those have been explicitly rejected by ICANN on the basis that they would cause widespread naming conflicts. I have my devices configured to redirect queries against .home to a local nameserver, leaving .local open for avahi.

Comment by whizzter 1 day ago

.example is probably far safer than example.com.

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.

Comment by Cthulhu_ 1 day 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".

Comment by larrik 1 day ago

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

Comment by wongarsu 1 day ago

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

Comment by ThePowerOfFuet 1 day ago

$100K

Comment by thequux 1 day ago

$227k just to apply, and another few hundred thousand in legal, compliance, and contracting to reach delegation.

Source: I'm on the board of dotMeow and wrote the financial plan

Comment by lagniappe 1 day ago

I suspect you'd download a car.

Comment by onionisafruit 1 day 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.

Comment by butz 1 day ago

Nice to see tinyapps.org is still alive.

Comment by 1vuio0pswjnm7 1 day 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

Comment by 1 day ago

Comment by godzillabrennus 1 day 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?

Comment by 1 day ago

Comment by rurban 1 day 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.

Comment by whizzter 1 day 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.