4 ms·

I’m sorry if I’m just dumb or don’t understand. This is dns record pointing at an azure resource that’s been removed, and the attacker resolves your entire zon

I’m sorry if I’m just dumb or don’t understand. This is dns record pointing at an azure resource that’s been removed, and the attacker resolves your entire zone then goes and tries to provision an azure resource with the same public name or IP. How is this different for any other provider, like Shopify, wordpress, etc?

jiggawatts 3y ago
It’s a wider range of systems that can potentially be affected, including security-critical corporate apps. However, Azure has made strides recently to stop subdomain takeover. The article is breathless hysteria to drive sales for their security services. Azure now randomises some domain names, requires additional verification, and/or warns you automatically if you’ve made a mistake. Actually the whole thing made me realise that even the “modern” cloud is just a copy of what we used to do on-prem. E.g.: why is there a DNS Zone Resource in the first place!? Ask yourself what sense it makes for DNS to point at something that doesn’t exist, or for an app to have a DNS name without a parent zone! You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. DNS ought to work the same way in the cloud: resources should just “have” DNS addresses and those should vanish with the resource if it’s cleaned up. We’re all still stuck in a 1970s mindset. Heck, I’ve just seen Azure adopt the Unix cron “standard” (lol) for scheduling. Meanwhile Windows Server had a far superior and much more flexible task scheduler for two and a half decades. Nope. Got to copy an even older and worse system into a cloud in 2023!
- Arnavion 3y ago
  >You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. >DNS ought to work the same way in the cloud: resources should just “have” DNS addresses and those should vanish with the resource if it’s cleaned up. Yes, those are what Azure DNS calls alias records. If you use Azure DNS then you can use them. Otherwise you have to resort to CNAME records. Alias records also have the benefit that they flatten automatically to save the client one or more hops.
  - jiggawatts 3y ago
    That's true, but those "alias records" are created as a sub-resource of the DNS Zone parent resource. In Windows Server Active Directory integrated DNS zones, the records are registered and maintained by the computers themselves. So if a server is assigned 10.1.2.3 as its IP address, it'll register itself in DNS without someone having to go into the DNS Server and add an alias record for it. Similarly, certificates shouldn't be "under" a Key Vault, they should be linked to the DNS record. It should all work like DHCP + ACME as seen in Let's Encrypt. Within a single cloud, there's no need to emulate the traditional system boundaries. E.g.: If I create a virtual machine with DNS name "foo.bar.com" and a public IP address of "1.2.3.4" it should register itself into that zone, and then un-register itself if the VM is deleted. It should also get a matching certificate (for free!) without any TXT records or manual steps. Weirdly, some things already work this way, inconsistently. Azure Front Door automatically issues certificates. App Service auto-registers itself in DNS, mostly. Virtual Machines can register themselves for Private DNS Zones, but won't get certificates... unless they're AD domain joined and have an Enterprise PKI available. It's such a mess.
tyingq 3y ago
> How is this different for any other provider, like Shopify, wordpress, etc? I'm sure some other providers have the issue, but it's not someone taking over "mybrand.wordpress.com", it's someone taking over "subdomain.mybrand.com" because there's a dangling pointer from "subdomain.mybrand.com" to something like "app-contogreat-dev-001.azurewebsites.net". Where anybody using Azure can recreate "app-contogreat-dev-001.azurewebsites.net". I'm sure that pattern applies to more than just Azure, but I imagine there's also many that protect against that in different ways.
- eddythompson80 3y ago
  That’s not even possible because azure will require you to verify ownership of “subdomain.mybrand.com” by setting a custom TXT value on it. That TXT value is tied to your subscription. So even if you had verified ownership for “subdomain.mybrand.com” before and just left the TXT value there, then deleted the “app-contogreat-dev-001.azurewebsites.net” and someone else created it. traffic for “subdomain.mybrand.com” won’t flow there until you update the TXT record for the new subscription. Obviously you wouldn’t notice that if you recreated the app in the same anccount and got confused and published a bogus vulnerability report. Or if your attacker has access to your subscription too.
  - deleted 3y ago
    [deleted]
  - deleted 3y ago
    [deleted]
  - tyingq 3y ago
    ¯\_(ツ)_/¯ There's some live examples up: https://beta.recruitmentgenius.com/explanation https://beta.recruitmentgenius.com/explanation $ host beta.recruitmentgenius.com beta.recruitmentgenius.com is an alias for rgproxy-prod.azurewebsites.net. Edit: Also see: https://intra.temp.ejobs.careers.gov.on.ca/ https://intra.temp.ejobs.careers.gov.on.ca/ https://ingestor-us-int.sasedl.trendmicro.com/ https://ingestor-us-int.sasedl.trendmicro.com/ https://jira.dlsstudios.com/ https://jira.dlsstudios.com/

jiggawatts 3y ago

It’s a wider range of systems that can potentially be affected, including security-critical corporate apps. However, Azure has made strides recently to stop subdomain takeover. The article is breathless hysteria to drive sales for their security services. Azure now randomises some domain names, requires additional verification, and/or warns you automatically if you’ve made a mistake. Actually the whole thing made me realise that even the “modern” cloud is just a copy of what we used to do on-prem. E.g.: why is there a DNS Zone Resource in the first place!? Ask yourself what sense it makes for DNS to point at something that doesn’t exist, or for an app to have a DNS name without a parent zone! You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. DNS ought to work the same way in the cloud: resources should just “have” DNS addresses and those should vanish with the resource if it’s cleaned up. We’re all still stuck in a 1970s mindset. Heck, I’ve just seen Azure adopt the Unix cron “standard” (lol) for scheduling. Meanwhile Windows Server had a far superior and much more flexible task scheduler for two and a half decades. Nope. Got to copy an even older and worse system into a cloud in 2023!

Arnavion 3y ago
>You don’t have an “IP address service”, resources just have addresses and then you can query for a flat list of them if you like. >DNS ought to work the same way in the cloud: resources should just “have” DNS addresses and those should vanish with the resource if it’s cleaned up. Yes, those are what Azure DNS calls alias records. If you use Azure DNS then you can use them. Otherwise you have to resort to CNAME records. Alias records also have the benefit that they flatten automatically to save the client one or more hops.
- jiggawatts 3y ago
  That's true, but those "alias records" are created as a sub-resource of the DNS Zone parent resource. In Windows Server Active Directory integrated DNS zones, the records are registered and maintained by the computers themselves. So if a server is assigned 10.1.2.3 as its IP address, it'll register itself in DNS without someone having to go into the DNS Server and add an alias record for it. Similarly, certificates shouldn't be "under" a Key Vault, they should be linked to the DNS record. It should all work like DHCP + ACME as seen in Let's Encrypt. Within a single cloud, there's no need to emulate the traditional system boundaries. E.g.: If I create a virtual machine with DNS name "foo.bar.com" and a public IP address of "1.2.3.4" it should register itself into that zone, and then un-register itself if the VM is deleted. It should also get a matching certificate (for free!) without any TXT records or manual steps. Weirdly, some things already work this way, inconsistently. Azure Front Door automatically issues certificates. App Service auto-registers itself in DNS, mostly. Virtual Machines can register themselves for Private DNS Zones, but won't get certificates... unless they're AD domain joined and have an Enterprise PKI available. It's such a mess.

tyingq 3y ago

> How is this different for any other provider, like Shopify, wordpress, etc? I'm sure some other providers have the issue, but it's not someone taking over "mybrand.wordpress.com", it's someone taking over "subdomain.mybrand.com" because there's a dangling pointer from "subdomain.mybrand.com" to something like "app-contogreat-dev-001.azurewebsites.net". Where anybody using Azure can recreate "app-contogreat-dev-001.azurewebsites.net". I'm sure that pattern applies to more than just Azure, but I imagine there's also many that protect against that in different ways.

eddythompson80 3y ago
That’s not even possible because azure will require you to verify ownership of “subdomain.mybrand.com” by setting a custom TXT value on it. That TXT value is tied to your subscription. So even if you had verified ownership for “subdomain.mybrand.com” before and just left the TXT value there, then deleted the “app-contogreat-dev-001.azurewebsites.net” and someone else created it. traffic for “subdomain.mybrand.com” won’t flow there until you update the TXT record for the new subscription. Obviously you wouldn’t notice that if you recreated the app in the same anccount and got confused and published a bogus vulnerability report. Or if your attacker has access to your subscription too.
- deleted 3y ago
  [deleted]
- deleted 3y ago
  [deleted]
- tyingq 3y ago
  ¯\_(ツ)_/¯ There's some live examples up: https://beta.recruitmentgenius.com/explanation https://beta.recruitmentgenius.com/explanation $ host beta.recruitmentgenius.com beta.recruitmentgenius.com is an alias for rgproxy-prod.azurewebsites.net. Edit: Also see: https://intra.temp.ejobs.careers.gov.on.ca/ https://intra.temp.ejobs.careers.gov.on.ca/ https://ingestor-us-int.sasedl.trendmicro.com/ https://ingestor-us-int.sasedl.trendmicro.com/ https://jira.dlsstudios.com/ https://jira.dlsstudios.com/