[cf-dev] DNS takeover

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

[cf-dev] DNS takeover

Adrian.Kurt

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8179) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] DNS takeover

Daniel Mikusa
I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

Dan


On Thu, Jul 26, 2018 at 2:23 AM, <[hidden email]> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8180) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] DNS takeover

Adrian.Kurt

Hi Dan

 

Correct, it's exactly that case I'm talking about. If a DNS record pointing to a public CF cloud is not cleaned up properly an attacker can then take over that domain without any issues.

 

My idea would be to add a feature (which can be enabled on public CF offerings) that would verify the ownership of a domain using a TXT record. Of course you don't need that on private CF installations. There this step would be rather annoying.

 

Kind regards

Adrian

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Mikusa
Sent: Donnerstag, 26. Juli 2018 14:55
To: CF Developers Mailing List <[hidden email]>
Subject: Re: [cf-dev] DNS takeover

 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

 

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

 

Dan

 

 

On Thu, Jul 26, 2018 at 2:23 AM, <[hidden email]> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

 

_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8181) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_
Reply | Threaded
Open this post in threaded view
|

Re: [cf-dev] DNS takeover

gberche

Maybe a hint similar to what DNS providers gave to to DNS zone records owners in the blog you referenced (see image copied below) could be added to CF CLI cf delete-domain confirmation prompt

such as "If you want to use this domain within CF in the future, we recommend that you either keep this domain, or update DNS entry, in order to avoid HTTP requests to be misrouted in the future if someone else creates a domain with the same name. Really delete domain X? "




Guillaume.

On Thu, Jul 26, 2018 at 4:40 PM, <[hidden email]> wrote:

Hi Dan

 

Correct, it's exactly that case I'm talking about. If a DNS record pointing to a public CF cloud is not cleaned up properly an attacker can then take over that domain without any issues.

 

My idea would be to add a feature (which can be enabled on public CF offerings) that would verify the ownership of a domain using a TXT record. Of course you don't need that on private CF installations. There this step would be rather annoying.

 

Kind regards

Adrian

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of Daniel Mikusa
Sent: Donnerstag, 26. Juli 2018 14:55
To: CF Developers Mailing List <[hidden email]>
Subject: Re: [cf-dev] DNS takeover

 

I'm curious, how do you think this attack could be applied to CF (unless you're sitting on an actual attack, then don't post in here publicly and notify the security team)? 

 

CF isn't performing DNS management.  I can add any domain I want using `cf create-domain` or `cf create-shared-domain` (ex: `cf create-shared-domain google.com`), but unless there are wildcard DNS records, set up externally, for that domain pointing to the LB for my CF installation, I can't do anything with that domain (you technically can use it within CF, but no traffic will route to CF).

 

The only case where I could see this happening is if someone used a public CF provider, like PWS or Bluemix, then stopped using it but didn't clean up their DNS.  At that point, the DNS would be pointing to the public provider, but if the user deleted their account, including the org & custom domain, then the domain would not be in use.  I think (haven't tested) CF would permit some other user to add the domain to their account & deploy apps using that domain.

 

Dan

 

 

On Thu, Jul 26, 2018 at 2:23 AM, <[hidden email]> wrote:

Hi

 

I just stumbled on an article about DNS takeover attacks (https://thehackerblog.com/the-orphaned-internet-taking-over-120k-domains-via-a-dns-vulnerability-in-aws-google-cloud-rackspace-and-digital-ocean/index-2.html).

Are there any plans to add features to CF that would prevent this? E.g. do some txt DNS entry to verify the ownership of a domain on creation of new domains in CF.

 

Kind regards

Adrian

 


_._,_._,_

Links:

You receive all messages sent to this group.

View/Reply Online (#8190) | [hidden email] | [hidden email] | Mute This Topic | New Topic

Your Subscription | [hidden email] | Unsubscribe [[hidden email]]

_._,_._,_