Taking Over DigitalOcean Domains via a Lax Domain Import System

This doesn&#x27;t help my impression of Digital Ocean at all (even if I am a paying customer currently). A few years ago you could impersonate Digital Ocean staff on their support pages with no effort. They grabbed the username from your email, so whatever you put in front of the @ becamse your username on the forums, visible to everyone. And the avatar came from one of those email-&gt;avatar services where you can sign up and set it to anything. So when I signed up with a username like digitalocean@mydomain.com, I ended up being called &quot;digitalocean&quot; on the support forums, and if I had wanted I could just change the avatar to the Digital Ocean logo and impersonate DO or anyone else.<p>I tried reporting it but got pretty much the same answer as this guy (though I did not get banned). Luckily they fixed it like a year later.<p>Great write-up, and interesting problem! I wonder if more hosting providers are vulnerable to the same problem.

This same thing happens with CloudFlare &amp; is being actively exploited. We reported it to them within the last two weeks and we were told that it&#x27;s expected behaviour and that they weren&#x27;t going to do anything about it.<p>I asked them to, at the absolute least, send an email notification to the prior-CloudFlare owner letting them know that the domain &quot;your CF account used to control is now being controlled by a new CF account&quot;. Better yet, implement a domain ownership validation scheme.<p>They told us that they wouldn&#x27;t be making any changes.<p>FWIW, on CloudFlare what happened to us was: we were moving registrars for ~100 domains, from GoDaddy to Route53. During this transition, the NS for the domains temporarily became blank; at this point CF automatically removed the domains from our CF account. The NS were then re-added to the domains on the Route53 side (&lt;4 hours of &#x27;no nameserver&#x27; time).<p>Apparently there are people out there that are looking for domains that are pointed to CF and then attempting to add them to their own CF account (automated I&#x27;m sure) -- which CF lets them do without any verification once they&#x27;ve been auto-removed from your [the original CF account] account.<p>Interestingly, the original account must be still stored in their system with the domain because we were able to re-add the domain to our original CF account without any verification; effectively &quot;stealing the domains back&quot; to our CF account, away from the thieve&#x27;s CF account.<p>In this case, the &quot;attackers&quot; (perhaps more appropriate, I call them &#x27;malicious actors&#x27;) were able to commandeer ~100 of our domains for ~2 months, for free; they redirected them to Russian websites, torrent sites, affiliate sites, etc.<p>Again, this is being <i>actively exploited</i> on CloudFlare, at the direct expense of CF customers -- but, according to CF, it&#x27;s not an issue...?!

I will never stop being infuriated by responses like this from companies - how many more megaleaks have to happen before they realize that they need to embrace white hats, not ban their accounts, not sue them, not swat them &#x2F; have them arrested, not silence them.<p>Great find &#x2F; writeup.

Hey Matthew,<p>I just wanted to let you know that I really appreciate your feedback, as well as the feedback from the other commenters here.<p>I understand that many here are concerned that banning the account seems, from this perspective, to have been an unjustified action. I do believe that there is a bit of a misunderstanding on the timeline of events here, as well as the source of the decision. To be clear, Cash supported the decision that I had made to ban the account in question, and there had been no communication between us and Matthew at this point. We began receiving a significant number of support requests to remove domains from this account, and I authorized the shutting down of this account as it was clear to me what was happening. I have been working with our engineers to see to the removal of the domains from the account as well.<p>I apologize if our actions seemed at any point rude or inappropriate, it was definitely not my intention. I want nothing more than to look out for the safety and wellbeing of our customers, and I chose what I believed to be the best action. I do want you to know that if I was aware that a security researcher had been working on testing a theory, I might have acted differently. That can, however, impact the reason behind a white hat test. You generally want the company to see you as normal user, so that you can see how they act in return. We do shut down users who are intentionally causing problems for other users, and I do think that was made evident here.<p>I do understand that opening a line of communication with Matthew may have been appropriate, and I consider that valuable feedback moving forward.<p>&lt;3 Jarland

Great article! I&#x27;m saddened by DO&#x27;s response and further wronging a white hat by banning you.<p>Let&#x27;s remember Linode offers 2x the RAM.

Something similar happened to me a few months ago with Cloudflare. I set up a new domain to use Cloudflare&#x27;s nameservers but did not immediately get around to setting it up on the admin panel. By the time I wanted to add the domain, someone else had already grabbed it and set up some sort of spam page.<p>Took a few emails to Cloudflare support to resolve this one. They also didn&#x27;t seem to care much about the security implications when I questioned them about it.<p>So this is far from a DO-specific issue...

Wonder what else might be vulnerable to this... CloudFlare seems like it may, they only have a handful of nameservers in any case.<p>Sort of hard to call it a vulnerability on DO&#x27;s part though - more of an issue with the admins. I think most DNS services operate in this way, really, route53 may be the exception, not the rule.

TO: ANY DIGITAL-OCEAN USER,<p>This is an absolutely terrible response from DO. If I had anything hosted here, I&#x27;d move away ASAP. Seriously, do it.

this post raises questions:<p>Was there a realization into how legitimate users may be affected by this action? Was there a plan to remove those domains from their account after making and disclosing their proof of concept?<p>Why not stop at 10 or 20, and then alert DO to the findings?<p>20 thousand was unnecessary.

Amazon S3 has similar problems. To host static website you need use your domain name as the S3 bucket name. Amazon does not verify ownership of your domain, and bucket names use global namespace.<p>Someone can easily block you from using S3 static website hosting by adding a bucket with your domain name before you do. Also if you delete a bucket and do not change your DNS, someone can recreate the bucket and will be serving files from your domain.

Bye bye digitalocean - account deletion request submitted 1178917. When you have reckless people like Cashan Stine (trust &amp; safety specialist - WTF is that title? sounds like a road safety officer?) that close accounts due to a security report then it won&#x27;t win any business from me or my clients.

I think most of the providers (e.g. DO, Linode, CloudFlare etc) do not check the authority of DNS due to the chicken-and-egg problem. The AWS way to handle this issue is definitely awesome but the infrastructure required is not worth for those companies who are providing &quot;free DNS service&quot; as an add-on to their existing customers. Anyway, IMO, it is your fault if you point to a nameserver but not utilizing it.

Banning his account was totally unjustified since he approached them first with the issue. A less ethical person could have tried to make money or sold this off on the back market. People like him should be rewarded not have their accounts banned. For all we know he just saved DO a lot of headache in sorting this issue had it gone wrong. I really wish the response from DO on this was different.

Thank you all for the conversation around this!<p>The security team at DigitalOcean has been working to ensure that DO is a safe place for security researchers to identify issues on the Internet as well as at DigitalOcean - security is in everyone&#x27;s interest. We encourage researchers to contact us when they want to use our platform for this type of work specifically so that we can avoid the types of pain that Matthew encountered while doing his experimentation.<p>Feel free to reach out to security@digitalocean.com and we will be happy to help.<p>Nick, DigitalOcean Security Director

&quot;I was walking down the street and I noticed your house wasn&#x27;t locked very well. So I stole all your stuff and put it in my own house.<p>Now I&#x27;m in prison because of this so it&#x27;s really hard for me to put it back.&quot;<p>The article writer is an idiot. He deliberately stole accounts because he could. Just because he then decided to blame the provider because he was able to do this does&#x27;t make it any more defensible.<p>If I mug you in the street, should I then post that because I was able to do so it&#x27;s all your fault? No. I&#x27;d go to prison....

Very interesting read, thanks. I&#x27;m surprised at the response from Digital Ocean, did you adequately explain what you had done?<p>The first person that replied looks like he just skim read your email or didn&#x27;t understand the fact you had sinkholed a lot of traffic.

I actually suggested this was possible on security.stackexchange.com a while back and was basically met with &quot;meh&quot;.<p><a href="http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;49612&#x2F;how-does-digitalocean-dns-verify-the-owner-of-a-domain" rel="nofollow">http:&#x2F;&#x2F;security.stackexchange.com&#x2F;questions&#x2F;49612&#x2F;how-does-d...</a>

TL;DR - If you own example.com and use DO as your nameserver, then anyone with a DO account can add DNS records for example.com.

An additional vector for this kind of attack is to create a zonefile for a subdomain off of a working, live domain administered by the same DNS server.<p>EG if foo.com is a working site on your DNS provider, try creating a zonefile for bar.foo.com and see if you can create an A record to point to your own server.<p>This used to be something shared web hosting services running CPanel&#x2F;WHM were particularly susceptible to. Clearly, the risks here are both phishing&#x2F;identity and cookie credential stealing.

I don&#x27;t think that setting up custom DNS for everyone as suggested by the author is quite as simple as it sounds.<p>It&#x27;s not enough to just come up with the custom nameservers. In order to use them in most TLDs they also need to be &quot;registered&quot; with the registry that operates the TLD.<p>So let&#x27;s say you have myDNSdomain.com. You get a new customer who owns NewCustomer.com and wants to you your DNS, so you create these nameservers for them:<p>ns237.myDNSdomain.com ns2323.myDNSdomain.com<p>In order for your new customer to be able to use those on their NewCustomer.com domain, you will need to go to your registrar and set up these nameservers. The registrar will then create the corresponding nameserver records with Verisign, the registry. Only then, the customer will be able to use the nameservers on his domain.

On the topic of having to pay for traffic to the sinkhole server: how about just closing ports 80 and 443? Then you only get a SYN, and answer with a NACK, that&#x27;s far less traffic than processing a complete HTTP(s) request.

Did anybody else click CrashChrome.com (or equivalent) in the sidebar?

I find myself asking WW$D where $ is any large tech company with a &quot;good&quot; reputation. What would Google have done? Lyft? Spotify? Blizzard? Use some imagination to apply a similarly dangerous security breach to these companies.<p>I feel like this question yields better context to ethical arguments because it makes us aware of the cognitive biases and view things from a more abstract perspective..<p>EDIT: Is there a way to include plain asterisks in HN posts?

As an aside, you can set up a security group in AWS that blocks inbound traffic on port 80 if you&#x27;d like to neuter the incoming requests.

Am I reading this right:<p>The only defence AWS has against this type of attack is the random (?) grouping of four different NS?

I made the mistake of applying for a job there once. I was discriminated against. Despite being in a protected class, I was so surprised to be so obviously discriminated against by them. (I&#x27;ve interviewed a lot, I don&#x27;t always get a follow up, this isn&#x27;t sour grapes, this was very different.) But of course the HR people are careful to not say things that are overtly discriminatory. But when a company insists on a VIDEO call rather than a phone call (despite asking them to do the first one by phone since I was not in a location with good bandwidth at the time they wanted the call)... and then visibly reacts to your image when they first see it, and then pretty much blows you off, despite being well qualified for the position... yeah, it&#x27;s not what they say.

Same thing happened to me after reporting SQL injection (in 2015!) on Vivaldi website. Polite email and blocked account.<p>Some companies do seem to prefer to learn about vulnerabilities from pastebin database dump.