In comp.lang.python, Barry <ba...@barrys-emacs.org> wrote: > It is possible to sign an ip address in a certificate, but that is not > often done.
It's bad practice. I've never seen one in the wild. > Getting to reuse the IP address that example.com was using will not help > the attacker unless they can make a cert that signs the dns name. > And that means they hacked the CA which is a big problem. You misunderstand the attack. Some web searching suggests the term is "dangling DNS record". Big co Acme Example, with example.com, has a website for the regular public on www.example.com, gets mail at mail.example.com, serves DNS from ns1., ns2. and ns3.example.com. The IT staff watch those domaines very carefully. One day marketing says, "We've got a big CES show this year, let's make a website for the press at ces.example.com." They tell execs the execs tell the IT guys the IT guys say "Okay, what does it point to?" and Marketing gives them the IP address of the blog site they just rented. IT sets up an A record. IT does not watch _that_ carefully. Two years later Marketing stops paying the bill on the blog site, and ces.example.com has a "dangling" DNS record, it exists but no longer points to a valid resource. Attacker gets the IP address that points to (maybe they churn through a bunch of temporary accounts until they do) and now with the right IP to match ces.example.com they go off to get a SSL cert for that. $500 bug bounty write up here for someone who found a dangling record, but didn't churn for the record to exploit it: https://gist.github.com/TheBinitGhimire/9ebcd27086a11df1d7ec925e5f604e03 Another variant of this, which probably doesn't get you an SSL cert, is a dangling CNAME. These can be easier to get. If ces.example.com was a CNAME to cesdemosite2017.com then when cesdemosite2017.com expires, it's trivial to re-register it and squat "as" ces.example.com. The most insidious version is a DNS delegation. If ces.example.com is an NS record (unlikely for a marketing site, but plausible for some other scenarios) and it goes to ns1.parternership.net, when parternership.net expires the attacker can grab that, create a new ns1.parternership.net and give themselves finan.ces.example.com then start spitting out bogus bills with it. The CAA record adds a smidgen more protection against those attacks. (I don't think that's what it is designed for, but a good defense works against more than just the original attack method.) I also found this in my search, which is exactly the sort of threat CAA was meant to handle: https://en.wikipedia.org/wiki/Comodo_Cybersecurity#Dangling_markup_injection_vulnerability On 25 July 2016, Matthew Bryant showed that Comodo's website is vulnerable to dangling markup injection attacks and can send emails to system administrators from Comodo's servers to approve a wildcard certificate issue request which can be used to issue arbitrary wildcard certificates via Comodo's 30-Day PositiveSSL product. Bugs in automated systems that give out arbitrary certs are not common, but very very nasty. Elijah ------ DNS: the cause of, and solution to, all our Internet problems -- https://mail.python.org/mailman/listinfo/python-list
