4 ms·

> 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 "m

by 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/
  - 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/
      - 3y ago
- 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.

by tyingq 3y ago

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/
- 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/
    - 3y ago
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.