3 ms·

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 ti

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/
- eddythompson80 3y ago
  Yes, in this example `beta.recruitmentgenius.com` is a CNAME to `rgproxy-prod.azurewebsites.net` [1] But it doesn’t matter if you set any domain as a CNAME for a *.azurewebsites.net resource in azure. Azure will not connect the 2 together until you take an extra step of going to the `rgproxy-prod` Resource in azure and explicitly set `beta.recruitmentgenius.com` as a domain for it. And when you try, azure will reject it and give you a random looking hash asking you to set a TXT record on your domain first, then come back and try [2]. You can cruise GitHub to see how many terraform and automated setup workflows this breaks. It was one of the more frustrating parts that always tricks up new developers in my org. They are confused because they setup DNS correctly, they ran the deployment script, but azure refused to setup the custom domain to their app. I don’t actually know what the random TXT hash is based on. I just know that I notice it’s always the same for a given subscription. So developers who share subscriptions don’t need to do it because someone would have done it before. Developers who get their own new subscription need to do it manually. [1] https://www.digwebinterface.com/?hostnames=beta.recruitmentgenius.com&type=&ns=resolver&useresolver=8.8.4.4&nameservers= https://www.digwebinterface.com/?hostnames=beta.recruitmentg... [2] https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain https://learn.microsoft.com/en-us/azure/app-service/app-serv...
  - tyingq 3y ago
    So, then, how did the example happen? Edit: From the article: "Microsoft also added an extra domain validation needed to add a custom domain to a web application, while this prevents attacks on web applications, it leaves vulnerable the most popular services such as traffic manager, Azure Kubernetes Service, and Azure Public IPs." So, either happened before MS added that extra validation, or involved the services listed above. Edit2: recruitmentgenius.com appears to be a real company, unrelated to "keytos". It doesn't seem likely they are colluding on this vulnerability story. There are other examples also, like: https://intra.temp.ejobs.careers.gov.on.ca/ https://intra.temp.ejobs.careers.gov.on.ca/ and https://ingestor-us-int.sasedl.trendmicro.com/ https://ingestor-us-int.sasedl.trendmicro.com/
    - eddythompson80 3y ago
      The only way I could think of that “attack” happening if the attacker happened to be the same user who initially setup the same account. I could easily be wrong of course, but the post doesn’t document the steps to reproduce that vulnerability. We don’t use Azure Kubernetes Services, nor Azure Public IPs services. So I’m not sure what those are. Or how throwing hem into the mix could expose an issue. We do use Azure Web Apps (which used to be called Azure Websites in 2014 as OP mentions) and I have to deal with domain validation bullshit for our org at least once every every 3 or 4 months depending on the year. And i know that the scenarios OP is describing is only feasible if the attacker is *within* your organization. Which they could do a lot more harm than just hijacking a DNS resolution endpoint.
      - what-the-grump 3y ago
        Yeah I’m trying to figure out if I have to go back and check anything deployed over the years. As far as I know you can register a domain name to only one tenant and you will get an ssl error even if you managed to clash the underlying cname.
progmetaldev 3y ago
Yes, they validate an asuid. subdomain as a TXT record. Also asuid.www. assuming you are also using the www. subdomin on your website. I always have a primary domain redirect on my applications if they only need to serve a single primary domain. Possibly I could see this being an issue if you are creating subdomains per-tenant, or something of that nature. Maybe I'm not understanding the issue correctly, but I've always had to validate my DNS records with Azure before I could assign a domain name to a resource such as an App Service.

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/

eddythompson80 3y ago
Yes, in this example `beta.recruitmentgenius.com` is a CNAME to `rgproxy-prod.azurewebsites.net` [1] But it doesn’t matter if you set any domain as a CNAME for a *.azurewebsites.net resource in azure. Azure will not connect the 2 together until you take an extra step of going to the `rgproxy-prod` Resource in azure and explicitly set `beta.recruitmentgenius.com` as a domain for it. And when you try, azure will reject it and give you a random looking hash asking you to set a TXT record on your domain first, then come back and try [2]. You can cruise GitHub to see how many terraform and automated setup workflows this breaks. It was one of the more frustrating parts that always tricks up new developers in my org. They are confused because they setup DNS correctly, they ran the deployment script, but azure refused to setup the custom domain to their app. I don’t actually know what the random TXT hash is based on. I just know that I notice it’s always the same for a given subscription. So developers who share subscriptions don’t need to do it because someone would have done it before. Developers who get their own new subscription need to do it manually. [1] https://www.digwebinterface.com/?hostnames=beta.recruitmentgenius.com&type=&ns=resolver&useresolver=8.8.4.4&nameservers= https://www.digwebinterface.com/?hostnames=beta.recruitmentg... [2] https://learn.microsoft.com/en-us/azure/app-service/app-service-web-tutorial-custom-domain https://learn.microsoft.com/en-us/azure/app-service/app-serv...
- tyingq 3y ago
  So, then, how did the example happen? Edit: From the article: "Microsoft also added an extra domain validation needed to add a custom domain to a web application, while this prevents attacks on web applications, it leaves vulnerable the most popular services such as traffic manager, Azure Kubernetes Service, and Azure Public IPs." So, either happened before MS added that extra validation, or involved the services listed above. Edit2: recruitmentgenius.com appears to be a real company, unrelated to "keytos". It doesn't seem likely they are colluding on this vulnerability story. There are other examples also, like: https://intra.temp.ejobs.careers.gov.on.ca/ https://intra.temp.ejobs.careers.gov.on.ca/ and https://ingestor-us-int.sasedl.trendmicro.com/ https://ingestor-us-int.sasedl.trendmicro.com/
  - eddythompson80 3y ago
    The only way I could think of that “attack” happening if the attacker happened to be the same user who initially setup the same account. I could easily be wrong of course, but the post doesn’t document the steps to reproduce that vulnerability. We don’t use Azure Kubernetes Services, nor Azure Public IPs services. So I’m not sure what those are. Or how throwing hem into the mix could expose an issue. We do use Azure Web Apps (which used to be called Azure Websites in 2014 as OP mentions) and I have to deal with domain validation bullshit for our org at least once every every 3 or 4 months depending on the year. And i know that the scenarios OP is describing is only feasible if the attacker is *within* your organization. Which they could do a lot more harm than just hijacking a DNS resolution endpoint.
    - what-the-grump 3y ago
      Yeah I’m trying to figure out if I have to go back and check anything deployed over the years. As far as I know you can register a domain name to only one tenant and you will get an ssl error even if you managed to clash the underlying cname.

progmetaldev 3y ago

Yes, they validate an asuid. subdomain as a TXT record. Also asuid.www. assuming you are also using the www. subdomin on your website. I always have a primary domain redirect on my applications if they only need to serve a single primary domain. Possibly I could see this being an issue if you are creating subdomains per-tenant, or something of that nature. Maybe I'm not understanding the issue correctly, but I've always had to validate my DNS records with Azure before I could assign a domain name to a resource such as an App Service.