Download this update from mybrowser.microsoft.com. Oh, sorry, that was malware on a hijacked sub-domain. Oops If you saw a link to mybrowser.microsoft.com, would you have trusted it? Downloaded and installed an Edge update from it? How about identityhelp.microsoft.com to change your password? Well, you shouldn't have, because the pair were among sub-domains hijacked by vulnerability researchers to prove Microsoft is lax with its own …
Being pedantic, it does seem that bugs in MS's own website aren't covered by the bounty program...
Interestingly, I've noted with some clients their backup email servers - visible in their DNS records, also refer to servers - with similar generic names - on Google/AWS/Azure, which currently don't resolve to an actual host. So this isn't going to be a one off problem...
They're just too big to care. The person who decommissions the server probably has no clue who tell to decommission the sub-domain. And no one ever follows up to see if it has been done. Even if they knew who contact regarding decommissioning, they've probably left the company and their email addy is a dead end.
"They can detect those vulnerabilities by comparing DNS records and HTTP responses, just as we did."
Actually, not so simple. An HTTP response might well come from a hijacked subdomain. They have to ensure that the HTML itself is Microsoft created. Judging by their sloppiness so far, I'm guessing they would have a hard time determining theirs from not theirs.
I suspect that what is meant is that if you poke a dead/vulnerable alias, it will either not respond, or respond with a standard message effectively saying "no such website here", so is probably ripe for hijacking.
Any other response from the URL poked means it is still in use by "something", so they skip to the next possibility.
For MS, any such responding DNS entries are targets for removal.
The article is not about finding already compromised sub-domains, but about preventing future compromises from stale DNS records, though some sort of hunt and destroy for such is probably needed.
That whoever does hijack a domain like this can also get an SSL cert for it - all that's required for that is to be able to place a file in the site for the cert validator to check to "prove ownership" of the domain. So :
subdomain of microsoft,com - tick
has SSL cert (padlock icon in address bar) - tick
What could possibly go wrong !
TBH, having managed DNS before (but definitely not on such a grand scale), it's a PITA. When a business (customer in our case) wants something there an obvious trigger - register domain for customer, setup DNS. When that need goes away, no-one can be ar*ed telling you about it - so you need to run frequent checks so you can infer when a domain (or subdomain in this case) is no longer needed, and either nuke it, or invoke procedures to check and then nuke it.
We saw this 20-30 years ago with the initial explosion of the web - everyone was using hosting companies, and all it takes is for the greedy host to rent out the same IP address to some SPAMMER and suddenly everyone blocks you because you were on the same IP address. This is just the same, but the modern cloud equivalent using shared hosting services / DNS. It's an inherent fault, and it will (thankfully) push people away from using them.
I'm already blocking most email from generic SMTP servers Google/AWS/Azure that use a generic DKIM. So it looks like I'll start to block most web sites hosted on generic domain names on Google/AWS/Azure too. If you want your email delivered, set up your own email server and your own domain name and your own private DKIM. It you want people to go to your own web site, don't redirect.
For the technically curious: we have two SPAM rule classes: for non-generic SMTP we look for keywords/SPAM scores and quarantine emails based on that; for generic SMTP/DKIM we look for keywords and quarantine ALL EMAILS unless they match a particular keywords that leads use/whitelist for existing customer email addresses.
Who's got clutter in their DNS, reverse DNS, dead (literally) users in AD, AAD, LDAP, ACLs for long gone servrices, etc that was useful once, but no longer.
Bet there's loads of DevOps "Infrastructure as Code" scripts which create stuff, but almost no scripts to decommission something?
Bottom Line - People don't like tiding up (have teen daughters!), but someone the size of Microsoft should be better at it!
How to get junior system admins interested in cleaning up DNS: put some "easter eggs" in there deliberately so they can be "found" and eliminated.. These can include amateur pr0n as well as "potential blackmail material" and other fun things. And don't announce the grand prize, let them FIND the thing within the matrix of unmaintained sub-domains. First to find it gets the prize. And have more than one available, evn simple things like a free beer, half-day off, etc.
It’s a nice theory, but unless you’re also the person who manages the systems those records point to then how do you know if they’re dead or not? Doesn’t respond to ping? OK, but did it before? Is the thing at the other end always online or just when it’s in use? Does some legacy critical bit of code reference that record?
It gets even more tricky where multiple services use the same resources. Remove a service, but can you remove that resource? Is anything else using it? Are things documented so you know when the last service is switched off so the resource can be removed? Crucially, can you trust the documentation?
It’s very easy to descend into a view where there’s little risk of leaving old records where they are, but there’s potentially major risks if you remove them and they’re still in use. And if you’re in a blame culture, leave it and it’s the fault of someone else not telling you it’s no longer in use, remove it (and things go wrong) and it’s your fault.
Yes, use after free is certainly part of the problem. But it is not the root issue. The root issue is that, in its infinite wisdom and attention to security, it is allowing customers (attackers) to register domain names in the same namespace as it is using for its own business. Certainly, it needs to allow customers some name space to register their domains. But there is no excuse for using that same namespace for its business. None.
This is an architecture issue. Architect things properly, and sloppy housekeeping won't burn you down. Architect them poorly....
I'm no OpsE, but I don't quite understand the problem with subdomain maintenance, assuming that you are set up as a CA. I know my previous post arguing that everyone should be a CA had a mixed voting response, but this is precisely the class of thing that can and should be automated into oblivion. With your own CA, you can issue and revoke subdomain certs at will. If someone, somewhere, is on the hook to assert the continuing need for each subdomain in the business, then if they fail to assert, the automated process to remove the domain begins. (Warning email to them and their supervisor, wait X days...)
Yes, this is work to set up, but magnitudes less than cleaning up after a hijacking.
a) Because certificate revocation is broken and doesn't work (see https://scotthelme.co.uk/revocation-is-broken/)
b) Why do you need your own CA to do that? You would just need any CA that you can automate the revocation
c) If you've got the ability to create such an automated process then why don't you automate the process of removing the entries from the DNS? Better to have the subdomain nuked than just the cert for it.
sway.office.com
It seems that "sway" is a service that end-users can set up web-pages and back-ends on.
And guess what, spammers and scammers and other miscreants send messages saying that you have "new voice messages" and links to sway.office.com to retrieve them - I've received a few since early January.
The URL really is a legit, owned-by-Microsoft domain.
And with "office" taking over everything, the ruse is almost believable...
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
