Wow. Some random person was able to move a domain to their own account simply by whatsapp ing the registrar, telling them that they had bought the domain and were having trouble moving it.
That's it.
It makes me realize that Google's no humans policy -- is it a policy? -- is actually a strength here. My domains purchased through Google are safe from social engineering because, well, there are no humans to contact to ask them to manually move domains.
(p.s. That is not some kind of dare to hackers! I am not suggesting you prove me wrong.)
The no humans thing also just closes off any path for exceptions that occur outside of what is coded.
I bought a domain for a blogger blog ages ago. At the time google had no domain registry so they partnered with some company.
Years later and google starts hammering me with "hey your credit card is expired we're not going to renew your domain" ...
Fine right?
"Hey go update your payment information on admin.google.com"
Wait. I don't have a g-suite account... and on my personal account my payment info is up to date, so I figure maybe they migrated my email address or emailed me about it but nope.
Then comes circular system where if you forgot X you need Y and if you don't have Y you need X and links on pages that always lead to admin.google.com...
There was no place to find / get help from google. Blogger seems like the information there is wrong / hasn't been updated / abandoned. Just links that ran in circles.
I found the old registrar they partnered with and got them to help.
With Google as far as I could tell there was no way to resolve the issue in a situation where I"m even trying to give them money (granted a nominal amount).
I had a similar circular issue with Google. I solved it by shoulder tapping my GCP sales rep who pulled some strings. Luckily my company spends quite a bit so I had a back door. Without that or a twitter following I think you’re fucked.
Yep, similarly here. eNom successfully "extorted" $300 from me due to it. My fault ultimately in the end though. But it was a stressful couple days, and eNom and Google partnership soured my view of both of them. I no longer do business with eNom.
Because it’s as exactly as RileyJames said above. It was ultimately my own doing but was masked by the strange relationship eNom has/had with Google. It felt like extortion, but wasn’t in reality, just business practices that don’t put the customer first.
"In the end, E-HAWK was able to wrest back its hijacked domain in less than 48 hours, but only because its owners are on a first-name basis with many of the companies that manage the Internet's global domain name system. Perhaps more importantly, they happened to know key people at PDR - the registrar to which the thieves moved the stolen domain.
Dijkxhoorn said without that industry access, E-HAWK probably would still be waiting to re-assume control over its domain."
A different read: It was "humans"-based customer support that saved E-HAWK. A "no-humans" customer suppport system might have left E-HAWK powerless, waiting, hoping.
Analogising to the parent's example, if parent had a serious problem, a "no-humans" customer support system might result in helplessness, waiting, hoping for some human at Google to discover and fix parent's problem, unless parent happened to know key people at Google.
> It makes me realize that Google's no humans policy -- is it a policy? -- is actually a strength here. My domains purchased through Google are safe from social engineering because, well, there are no humans to contact to ask them to manually move domains.
I'd suppose that goes both ways. If someone does find a way to steal a domain that's managed by Google, who are you going to contact to get it back?
If google servers decided tomorrow to shut down your domain, because the anti-fraud algorithm decided that the use of the domain has patterns which it decided is indicative of fraud, what would you do? All there is a computer saying that it de-registered the domain name and all the support options becomes a circle of the computer saying that it de-registered the domain name.
To me that is a risk. Through I have no evidence for this, I think that the false positives of those algorithms are higher than the risk of a hacker managing to social engineer a high end registrar. The reason I think so is that there is very little incentive for google to eliminate false positives but a huge one for eliminating false negatives.
Google Domains does have phone/chat/mail support but I still would like to believe that their security practices are solid enough that they wouldn't fall for this most basic of social engineering attacks.
> It makes me realize that Google's no humans policy -- is it a policy? -- is actually a strength here. My domains purchased through Google are safe from social engineering because, well, there are no humans to contact to ask them to manually move domains.
Except Google actually has a lot of humans in the loop for Google Domains. I was having an issue transferring a domain and I clicked a button to chat and was talking with a real person in about a minute.
Granted, they may have better security procedures but they're still humans.
AWS Route53 user chiming in here. I have IAM accounts and soft-token 2FA, and I like how minimal the R53 panel is. This makes me feel like I have a handle on things because there are so few paths to make changes. It also makes me worried I'm missing something. 7 years and no hacks (that I've detected). Knock on wood.
I'm guessing your domain wasn't a huge target then. There was a dns hijacking bug in r53 like 3-4 years ago that was fairly trivial to use. It allowed an arbitrary attacker to register new records to redirect your traffic and take a higher priority in the routing table. I probably shouldn't say much more about it because I don't think it was publicized after they fixed it.
That wasn't reaaaaly an AWS hack. BGP hacks are still an issue since it is mostly an honor system! There are no safeguards against this except fast admin.
Well, there was that too. What I was referring to was a specific issue that allowed you to add entries for domains in r53 which were already in use (in r53). I can't remember the specifics too well, but I think it was an api validation issue on one of the endpoints. It wasn't a "I own your domain now" so much as "I receive some of your traffic sometimes".
The usual "registrar lock" is the clientTransferProhibited status you see on domains... that's easily removed by social engineering the registrar.
"Registry lock" is serverTransferProhibited, the kind where both your registrar and the main registry need to agree to transfer the domain to another registrar. For instance, you can buy a .ca domain from any registrar, but you need CIRA's compliance (the issuing body for all of .ca) to enact a registry lock. This explains it a bit better: https://cira.ca/ca-domains/optimize-your-ca/registry-lock
I'm having trouble tracking down how to do this for a .com though.
So what actually makes the "registry lock" robust against social engineering.
Reading CIRA's page it just says that to make changes the Registrar will talk to CIRA to have to lock removed on their behalf. Doesn't sound like there's any mandatory OOB check from CIRA back to the actual client.
Quite interesting. How did you do that and what did it take (cost, time, effort)? NearlyFreeSpeech.net started off on this a couple of years ago, and it seems like this is a very costly proposition (something like $80K for accreditation?) that also takes a lot of time.
The trick is to forgo ICANN scam and go with a ccTLD. With TRAFICOM (ex FICORA), it was a matter of filling a form. There could have been a small nominal fee but if there was, it must have been very low (under 100 eur).
To transfer the registration, but not to update records. Domain ownership is generally largely separate from zone management. Transferring a domain to someone else typically isn’t something you do often.
Registry Lock isn't something most retail registrars will offer, because generally, the vast majority of registrants don't really need it. It's not something you can just put into your domain management panel and roll out to everyone because of all the hoops required once enabled.
That said, Brian Krebs does need it on his domain(s) for obvious reasons - his domain is a massive target for hacking - and so it's enabled on his domain with specific procedures around how updates happen when required which I won't get into.
Beyond Registry Lock, the best way to secure your domains is to have them in an account with a random username (prevents guessing to aid in social engineering vs. "firstlast" or "flast"), a strong password and 2FA. Perhaps consider a unique account email address that you only use for that registrar account since losing control of that could result in losing control of your entire domains account and all the domains in it (assuming you didn't use 2FA).
On the Registrar side, look for one with good protections to ward off social engineering against the account and domains. In our case, we have a system that requires the account holder's specific consent (obtained via account email) to have a support person view personal information or access the account.
I would say because it's a small cost for the domain owner in return for protecting against what's potentially a pretty big emotional (and possibly reputational, financial) downside.
1) "registrar lock" - a service that requires the registrar to confirm any requested changes with the domain owner via whatever communications method is specified by the registrant.
2) "registry lock" - with a registry lock in place, your registrar cannot move your domain to another registrar on its own. Doing so requires manual contact verification by the appropriate domain registry.
So... I assume the "lock thingy" within most registrars' interfaces (I'm familiar with the one within Namesilo, the registrar I use), is the less restrictive "registrar lock" ?
For really important domains, there was MarkMonitor, the high-end registrar. But they've been acquired by an analytics company, so now it's necessary to wait a few years to see if they are still trustworthy.
It's useful to trademark your domain name. That gives you a very likely win if things ever get to the ICANN dispute process.
Confused, how do you get a registry lock then? Do you have to email your registrar? Why is there so little info on this? Or is this the same thing as clientTransferProhibited that is often provided?
You have to deal with the registry directly. Otherwise it's kind of pointless if registrar itself can lock/unlock it.
I have registry lock. I just asked my national domain registry to lock the domain. All that was needed was a strong proof of identity. (not just a photo of an ID, but doing a physical verification in person somewhere, like on the post office or sending a notarized letter) It was free.
But this is a national domain, where I have a high trust in the registry itself (registry manager makes the Turris router, btw, and some key software like knot dns server, etc), and that's also the reason why all my important stuff is linked to this domain.
No, some registrars are still the one that manage the communication with the registry. A big reason for the registry, registrar and registrant model is so that the registry do not interact directly with customers.
It also depend on the type of registry. .se for example allow registrars to set registry lock automatically but not unlock. Unlocking is a manual process and there is contractual conditions that the registrar must have verified the identity of the customer who is requesting the unlock, and the registrar must also sign to that fact. So far no registrar has failed yet to do so, thus the legal ramification of failing this has yet to be tested.
> With a registry lock in place, your registrar cannot move your domain to another registrar on its own. Doing so requires manual contact verification by the appropriate domain registry, such as Verisign — which is the authoritative registry for all domains ending in .com, .net, .name, .cc, .tv, .edu, .gov and .jobs.
Putting a 'registry' lock into place has upside and downside. As mentioned in the story the downside is in an emergency it's harder to make a change because of the friction of another step to make a change (and that means any change even DNS servers).
That said it still doesn't prevent social engineering. The implication in the article is that if you social engineer a CSR at a registrar the registrar having to have another step to get a domain unlocked (contact the registry ie in the case of .com et all Verisign) then someone will say 'hmm let's be sure on this'. In theory why would this happen? Once someone has been social engineered that's that, right? (I mean sure it's another step and sure that could mean someone thinks more but...)
Now let's say you take care of a domain using registry lock. What is the tradeoff if someone gains access to your dns servers and you need to change those servers but you can't do that easily because a domain is registry locked and now you need to depend on a registrar to contact the registry and get that done. How quickly will that happen?
My point is it's not a non-trivial decision to make at all and the downside has to be taken into consideration.
One last point. There are procedures in place if a domain is transferred to another registrar to get it back to the original registrar. The best advice is to setup some kind of manual monitoring (not dependent on a registrar) where you periodically check the registry whois for the domain and note any changes to it (dns or otherwise).
You mostly see registry lock offered by corporate registrars that have a high touch customer service flow, e.g. you have a dedicated person servicing your account.
Yeah, CloudFlare is one that offers it, but it seems firmly in "Request Quote/Call Sales" territory for pricing. It dates from when they first intro'd their original registrar offering [1] a few years ago, and they said right out:
>"CloudFlare Registrar is not designed for the masses. There are plenty of great mass-market registrars. However, if you’re an organization where losing your domains would be a front-page story, then CloudFlare Registrar is for you."
Of course, they later did introduce a mass market offering as well, but not with that set of features! :)
Tangent: The mass market offering from Cloudflare does not have a way to buy/register a new domain. It’s been way too long since that offering was made public and it’s still stuck with just transferring domains from another registrar into Cloudflare.
I've managed domains witha registry lock. It may depend on the registry, but when my boss didn't answer the validation call, the domain didn't get unlocked and we had to wait for the next day's change window (and remind the boss to pick up the phone) to get our nameservers changed.
I'm sure it's still possible to social engineer (it's a human driven process), but there are a lot fewer people authorized to make the changes, and they're probably better trained.
Ah yes, domains, my dad registered a domain for me and when he passed away; we missed a payment and the registrar swiftly decided to release the domain and now I lost it. Gone is my [firstname].com now the current owner of the domain tries to buy [firstname] from me on insta, twitter etc.
Names are hard, I was pretty bummed when I stopped being able to use swiley in #bitcoin-otc (I think because I lost a key or messed up with the nickname server)
This is about a Dutch registrar being social engineered. I specifically chose a Dutch registrar for my Dutch company, thinking that it would be so much harder for non-Dutch people (99% of the world) to social engineer a Dutch registrar. I guess not.
I usually register my important domains for several years in the future, and have the register lock on. Some registrars call it transfer lock.
I also Backorder my own domains on namejet, GoDaddy, etc just in case they ever do expire there’s still a chance to get them back.
If only there was a company that offered domain name insurance, to make sure you never lose your domain, it’s never stolen, dns isn’t hijacked, and the site never goes down (ddos attacks, etc.).
> had already protected their domain with a “registrar lock,” a service that requires the registrar to confirm any requested changes with the domain owner via whatever communications method is specified by the registrant.
Wrong. That is not true. Although some registrars might 'confirm any requested change' that is neither ubiquitous or required by ICANN etc.
Same thing happened to the high profile domain Sex.com by sending a fax. It was almost impossible to get back, and the criminal made millions in the meantime.
this is one of the things that Russians got right; you had to show up in person (and show your passport), or provide a notarized sale contract, if you want to transfer a .ru domain. At least that's how it used to be, could be different now
DNS takeover is a huge issue, but some kinds of mitigation like Registry Lock (as opposed to Registrar Lock aka clientTransferProhibited) also seem to be fairly inherently pricey. It requires multiple actual humans involved, like for .com having the right person actually pick up the phone at the registrar and get in touch with Verisign. Cloudflare offers it for example, but only for their enterprise class Custom Domain Protection [1] service, which they explicitly describe as "high touch" or "very manual", since the whole point is that it's a fully offline/out-of-band communication requirement.
In principle it seems to me that there could be a "per-incident" price model that would more accessible to more general DNS users who setup their core domain DNS and touch it once a decade, where a flat upfront $200 payment (spit balling) enables Registry Lock and two uses, after which the fee must be paid again for more. The idea here is that you'd directly be paying the $100/hour or whatever it costs a couple of engineers to take time for this each time, on the logic you'd be using it very infrequently. This would avoid ongoing subscription costs which might be easier to justify for non-enterprises, while still being feasible for a registrar. I don't know of anyone who does this though.
A lot I think ultimately really does come down to the registry itself and their specific security practices, as well as fundamental tensions between stopping alterations by unauthorized people while enabling recovery by authorized-but-forgot-password-or-token-broke-or[...]-people. Supporting hardware factors for example is great, but if support can just override them that's a hole. Conversely there needs to be some fallback procedure for if a token breaks (maybe a super long key written down and put in a vault, maybe based on payment information). Some methods can be real footguns too, my current registrar for example offers IP address/range restriction options, but it's not hard to see how that could come back around to bite you in the butt in an emergency if not used quite carefully. It's one of many tough problems due to the ongoing primitive state of electronic authentication I guess.
Edit to add: useful direct quote on Register vs Registry Lock from their initial enterprise-only CloudFlare registrar launch [2]:
>"Many registrars support Registrar Lock, which prevents the registry from altering information unless the lock is explicitly removed. The problem is, if an attacker compromises your registrar account, they can unlock it and make whatever changes they want."
>"Registry Lock prevents changes by any registrar until the lock is removed. Unlocking at the registry level requires out-of-band communication between the registrar and Verisign (the global registry operator for several top-level domains), and is thus very manual. Since most registrars are volume operations, it’s very difficult to find one that takes the time to literally pick up the phone and call Verisign every time someone makes a change to their DNS settings."
So yeah I'm sure that stops attackers real well, but not exactly scalable. "[I]f you’re an organization where losing your domains would be a front-page story..." indeed!
That's it.
It makes me realize that Google's no humans policy -- is it a policy? -- is actually a strength here. My domains purchased through Google are safe from social engineering because, well, there are no humans to contact to ask them to manually move domains.
(p.s. That is not some kind of dare to hackers! I am not suggesting you prove me wrong.)