Hacker News new | past | comments | ask | show | jobs | submit
Beyond just IPs, there is a giant class of "DNS record pointing to X shared cloud resource that organization no longer controls" issues. The bigger the company, the more widespread the problem. These resource names get released back into a common pool that anyone can register.

Think:

* CNAME pointing to an S3 bucket, and the S3 bucket gets released

* CNAME pointing to Azure Website/WebApp Instance

* A record to an non-elastic IP, and the box gets rebooted

* DNS name using a Route53 name server that no longer part of the org's AWS account

* CNAME pointing to a Heroku/Shopify/GitHub pages account and the account gets deleted/deactivated freely up those names for registration

* MX record pointing to old transaction email provider start up that dies, and someone else registers that domain name...

Why does that happen?

* Decentralization of IT means people spinning up infrastructure not knowing what they are doing

* Great a spinning up infra, but when decomissioning they forget about DNS

* Lots of subsidiaries, lots of brands, different groups, operating in different geographies. All this makes it difficult to discover and enforce proper policies

* Geo-specific websites/apps (Think of all the country-specific websites Coke runs)

* Using some 3rd party vendor and never telling security about it (Marketing spinning up some landing pages on some fly-by-night martech provider or wordpress host, and never turning them off)

I am the Field CTO at a venture backed Israeli cyber security company in this space. I was literally talking to a major computer part company yesterday about the dozen or so Indonesian gambling websites that are "running" on their domain names using their pagerank and links. This is a weekly conversation

> CNAME pointing to a Heroku/Shopify/GitHub

At least Gitlab (similar to Github pages, I never used Github Pages, always Gitlab Pages) gives you a verification TXT record in your Gitlab Account, which needs to stay in DNS as TXT. So if I used to host hi.example.com on Gitlab (& my own TXT record was hosted, and publicly visible), now I don't own example com, or gitlab account got deleted (but still left DNS CNAME records intact) and scammer gets the domain, when he grabs domain and adds hi.example.com to his Gitlab Account to scam people, his Gitlab Account will have his own TXT record. (now) His hi.example.com can never point to "my" gitlab project or page.

https://docs.gitlab.com/ee/user/project/pages/custom_domains...

loading story #42799847
> * CNAME pointing to Azure Website/WebApp Instance

Microsoft has made it possible to have your webapps CNAME record be unique to your AzureAD tenant and never to be reused.

This prevents these kinds of attacks.

More info here: https://techcommunity.microsoft.com/blog/azurenetworkingblog...

What types of actions can you do to correct and prevent this class of errors? I think you could probably enforce deployment and shutdown checklists, perhaps, or have automated DNS checking software to see if any of the issues exist (I bet you guys have a solution for that) but there are so many human-error problems in manufacturing, and I kinda consider the large-scale deployment of apps to have similar issues and failure modes on the human side.
loading story #42796782
loading story #42796824
loading story #42796953
Relevant, dangling cloud resources.

DEF CON 32 - Secrets & Shadows: Leveraging Big Data for Vulnerability Discovery - Bill Demirkapi

https://www.youtube.com/watch?v=-KXgcWuv-Ug&t=288s

Do these Indonesian gambling sites somehow exploit the AMP cache? The apex domain of my blog was recently hijacked by such a site. I was only using the blog.* subdomain. One day I noticed on the Google search console that someone had verified themselves as a co-owner, and there was an entry for an AMP page (this was the gambling page). Putting a parking page at the apex url seemed to stop the redirects to the AMP page - and that's the solution I have for now.

I am still curious though - how does AMP make such exploits easier? Would you happen to know?

> A record to an non-elastic IP, and the box gets rebooted

Oh mate, I've seen that happen with a company that was selling security-adjacent services, which were running on servers with just random IPs ffs