Tell HN: Microsoft.com added 192.168.1.1 to their DNS record Is this bad? $ nslookup microsoft.com Non-authoritative answer: Name: microsoft.com Address: 192.168.1.0 Name: microsoft.com Address: 20.112.250.133 Name: microsoft.com Address: 20.231.239.246 Name: microsoft.com Address: 20.76.201.171 Name: microsoft.com Address: 20.70.246.20 Name: microsoft.com Address: 20.236.44.162 Name: microsoft.com Address: 192.168.1.1 |
I mean: I don't expect anything less from Microsoft than doing stuff like that and it cannot affect me for I nullroute microsoft.com from my unbound server (unboud takes wildcard when nullrouting or NXDOMAINing crap domains like microsoft.com or meta.com etc., which is sweet).
However I'd expect my trusty DNS resolver to also prevent me from anyone not on my private LANs to impersonate addresses reserved for private uses.
Does anyone know here if it's easily doable?
(See also the sibling comment about microsoft.com being IPv6 only as a result of a particular implementation of DNS rebinding protection: https://news.ycombinator.com/item?id=38704159)
Unbound's "private-address" and "private-domain" directives control this.
Similarly, bind9 has "deny-answer-addresses" (with an "except-from" option so you can specify local domains that are allowed to use them):
https://bind9.readthedocs.io/en/v9.18.20/reference.html#cont...
Not sure about others.
Public resolvers keep DNS answers intact because they can carry alt data like how dodgy a SMTP server is.
Now Microsoft owns all your home networks, only like the default address on every home router out there...
Only if you’re slumming around 192.168.x.x
Microsoft's mindnumbingly dense ClickOps culture strikes again.
at a serious org this would have involved at least some level of oversight or intervention
as of 1703035296:
ns1-39.azure-dns.com no longer has 192.168.1.0 for microsoft.com
1.1.1.1 still has 192.168.1.0 for microsoft.com
8.8.8.8 still has 192.168.1.0 for microsoft.com
76.76.2.0 no longer has 192.168.1.0 for microsoft.com
9.9.9.9 still has 192.168.1.0 for microsoft.com
208.67.222.222 still has 192.168.1.0 for microsoft.com
185.228.168.9 still has 192.168.1.0 for microsoft.com
76.76.19.19 still has 192.168.1.0 for microsoft.com
94.140.14.14 still has 192.168.1.0 for microsoft.comIf it’s that simple for a stray record to be included in the dns round robin it could have been bad if it was an external ip with a machine setup by a phisherman especially since control of a domain is all you need to get an ssl cert now.
Couple this with the fact that it’s Microsoft, one of the most relied on companies in our computer world, this is pretty darn horrible.
$ dig microsoft.com. | grep EDE
; EDE: 15 (Blocked)
resolver.log:Dec 20 00:43:57 router dnsmasq[8172]: possible DNS-rebind attack detected: microsoft.com $ ping -4 microsoft.com
ping: microsoft.com: Address family for hostname not supported
$ ping -6 microsoft.com
PING microsoft.com(2603:1030:c02:8::14 (2603:1030:c02:8::14)) 56 data bytes
64 bytes from 2603:1030:c02:8::14 (2603:1030:c02:8::14): icmp_seq=1 ttl=112 time=68.4 msAnyone have any theories on how this could happen?
https://theamazingworldofgumball.fandom.com/wiki/Awesome_Sto...
Name: microsoft.com
Address: 192.168.1.1
Name: microsoft.com
Address: 192.168.1.0
https://who.is/dns/microsoft.com
What are the potential ramifications of this?
Which entry is picked for use is generally random depending on the client.
Most systems will retry using another entry though on issues connecting through. That said, if you are on a network that is 192.168 based, trying to get to Microsoft.com may just send you to your local router!
[1] https://superuser.com/questions/1111582/does-microsoft-preve...
In theory this could be leveraged for hacking, but I think that would require setup in advance.
dig +trace +short microsoft.com
NS a.root-servers.net. from server 100.100.100.100 in 10 ms.
NS b.root-servers.net. from server 100.100.100.100 in 10 ms.
NS c.root-servers.net. from server 100.100.100.100 in 10 ms.
NS d.root-servers.net. from server 100.100.100.100 in 10 ms.
NS e.root-servers.net. from server 100.100.100.100 in 10 ms.
NS f.root-servers.net. from server 100.100.100.100 in 10 ms.
NS g.root-servers.net. from server 100.100.100.100 in 10 ms.
NS h.root-servers.net. from server 100.100.100.100 in 10 ms.
NS i.root-servers.net. from server 100.100.100.100 in 10 ms.
NS j.root-servers.net. from server 100.100.100.100 in 10 ms.
NS k.root-servers.net. from server 100.100.100.100 in 10 ms.
NS l.root-servers.net. from server 100.100.100.100 in 10 ms.
NS m.root-servers.net. from server 100.100.100.100 in 10 ms.
RRSIG NS 8 0 518400 20240101050000 20231219040000 46780 . fG/YHtUJu3YMAm9Mlzzvp3xG4UCPG01aYNnlyF1HfAHdZpR+L88CVUcz NFHq9M45KjB7ZTlSFt2JvEyK/8FcavZLOthkXRREbJQswjLCbhiPQCbq tQLF+tKaNYUihqawCfjgZy1i5YwYjmphbjfzwoKo1POtepf0YCIcuLBi nQFw4Lr79O6cjyg6qlYnqaK6z4Xi5qt6ocohJafjs86LuuRo2WvmJ1IK k0ZUoAC6Qyjz4MVhqHMvQGdp7EnzjoL8Y9PTXeUuD6Ixp/Aklj2psLjD TZDPYN1q+zDd1giFyuwNRX9DG1zrxzN2lzQiLWmGKrzP3DvFWL1L2Ts1 FWjy/Q== from server 100.100.100.100 in 10 ms.
;; UDP setup with 2001:502:7094::30#53(2001:502:7094::30) for microsoft.com failed: network unreachable.
;; UDP setup with 2001:502:7094::30#53(2001:502:7094::30) for microsoft.com failed: network unreachable.
;; UDP setup with 2001:502:7094::30#53(2001:502:7094::30) for microsoft.com failed: network unreachable.
A 20.112.250.133 from server 150.171.10.39 in 20 ms.
A 20.231.239.246 from server 150.171.10.39 in 20 ms.
A 20.76.201.171 from server 150.171.10.39 in 20 ms.
A 20.70.246.20 from server 150.171.10.39 in 20 ms.
A 20.236.44.162 from server 150.171.10.39 in 20 ms.
A 192.168.1.0 from server 150.171.10.39 in 20 ms.
$ export srch="192.168.1.0"; echo "as of $(date '+%s';):"; for dns in 1.1.1.1 8.8.8.8 76.76.2.0 9.9.9.9 208.67.222.222 185.228.168.9 76.76.19.19 94.140.14.14; do dig @${dns} microsoft.com +short | grep "${srch}" > /dev/null; if [ $? == 0 ]; then echo "${dns} still has ${srch} for microsoft.com"; else echo "${dns} no longer has ${srch} for microsoft.com"; fi; done
as of 1703033639:
1.1.1.1 still has 192.168.1.0 for microsoft.com
8.8.8.8 still has 192.168.1.0 for microsoft.com
76.76.2.0 still has 192.168.1.0 for microsoft.com
9.9.9.9 still has 192.168.1.0 for microsoft.com
208.67.222.222 still has 192.168.1.0 for microsoft.com
185.228.168.9 still has 192.168.1.0 for microsoft.com
76.76.19.19 still has 192.168.1.0 for microsoft.com
94.140.14.14 still has 192.168.1.0 for microsoft.com
$ pbpaste | sed 's;^; ;' | pbcopyWouldn't they have to break into my local machine first, plant an update service, and an update? That doesn't seem to scale well at all, and wouldn't it be easier to just break into the machine they want to 'update'?
I highly doubt that entry-level admins at Microsoft have access to DNS for their primary domain. My guess is that this incident is a lot more interesting than that.
And if not, whoever put the junior in that role is the person responsible for the problem.
As the story goes, after a junior admin wiped a production database. The boss was asked if he should be fired. To what he answered: "Fire him? No way! Not after such an expensive training." Now, he knows.
"It's only those who do nothing that make no mistakes, I suppose."
Now the persons that did it have some proof that they did something.
They will surely put some check in place because there should be another adage somewhere that says that you only learn to use the handrails after you fell in the stairs.
.... a DNAME[1] record
....... that pointed to apple.com
1: https://en.wikipedia.org/wiki/DNAME_record
this had some pretty disastrous results[2]
2: https://mashable.com/archive/apple-tunes-app-store-icloud-pr...
bad things happen everywhere
* Copilot told me
* Sabotage (internal or external)
This is the kind of thing you look at and put up a few guardrails to prevent it happening again.
Clearly the following is not in play for a root domain (Microsoft.com) but assigning a DNS entry to a class C address does have a purpose.
If you have an intranet server, giving it a DNS name allows for HTTPS serving, with an automatic, CA signed, certificate. (Using say LE with DNS challenge.)
I provide this simply as an example of how this might come about.
might as well throw in some automated poke-yoke or whatever too.
in that case there is no fault in any of the juniors or operators, the fault is in management for failing to implement infrastructure to force a critical process to have more than one control
> it could have been bad if it was an external ip with a machine setup by a phisherman
I.e. one of the IPs for microsoft.com belongs to $phisher, which means they control (a subset of the traffic going to) the domain. They can't add CNAME records for certificate validation, but LetsEncrypt for example offers HTTP-based validation.
Not sure how Microsoft sets up their certificate pinning, it might not be quite that easy.
https://en.wikipedia.org/wiki/Self-enquiry_(Ramana_Maharshi)
They use 1drv.ms as the domain in OneDrive emails, and sometimes it almost looks like the .ms ccTLD belongs to them - it very much doesn't, anyone can register a .ms domain.
windows.net being an Azure domain that third parties can have content under is fitting.
It sometimes looks like they want their users to be phished.
Microsoft is a smart company though, I really hope they can sort this out.
https://learn.microsoft.com/en-us/microsoft-365/enterprise/u...
https://learn.microsoft.com/en-us/azure/security/fundamental...
Nope. This is still Microsoft's fault while non-auth servers update.
I wasn't attempting to address blame since I figured that was obvious enough.