Slashdot Mirror
MelbourneIT Lapse Permitted Panix Hijack
McSpew writes "Netcraft reports MelbourneIT's CTO, Bruce Tonkin, has admitted the Panix domain hijacking occurred because of a loophole in MIT's domain transfer process. He doesn't go into detail about what that loophole was, or how it was closed. As a Panix user, I'd like more detail, and I'd like to know what can be done to stop this sort of nonsense happening to other domains."
I'd like to know what can be done to stop this sort of nonsense happening to other domains
You'll never stop this sort of stuff, there is always someone smarter and more determined to find loopholes than the overworked, caffeine addicted guy paid to write the code.
Melbourne IT, which sells its domains through Yahoo and many other hosting firms, defended its claim of 24/7 customer service for resellers and technical contacts (although not retail customers), but said it will evaluate whether it can improve.
Translation: We won't commit to doing a damn thing, and frankly we're only interested in the people who pay us to fuck up. Nonethless, we're attempting to put it nicely, so be grateful.
Si tacuisses philosophus mansisses. If you had kept quiet, you would have remained a philosopher.
Someone screwed up.
The loophole that led to this error has been closed.
And they fired the guy.
It's the battle of the minds, and everyone's unarmed.
They also have all the integrity to be expected of the major ".cx" registrar.
For quite some time, on the NS redelegatiom page of the MelbIT web site, you could enter in either a hostname, or an IP address, or both, to chose your new nameservers. Great for those of us having to move IP ranges or whatnot.
The problem is, the web form did nothing at all with the IP addresses you put in. It completely ignored them. You had to call up Melbourne IT and speak to somebody to get the mess sorted out. That one caused me a day of pain.
Other times, the staff members have stated facts that clearly went against all of their procedures on the web page for redelegation and/or key retreival. "Sorry, no, even though thats what the web page says, it REALLY means the opposite"
She'll be right mate - no one at MelbourneIT would lose their job even if they transferred google by mistake on a weekend and did nothing about it until 9am Monday.
If your registrar doesn't support locking, find another one that does. GoDaddy, EV1servers, etc do.
"Loophole" really means somebody at MelbourneIT didn't perform end-to-end tests of their registration server; that, or was only looking for primary adherence to the spec, and didn't check if their implementation could be fucked with.
Big Daddy, Johnny, Burp, Aunt Zelda, Scott, Slurp, Big Momma
In a word - Fosters.
A feeling of having made the same mistake before: Deja Foobar
I'm confused. They were the receiving registrar of the transfer. However, it was the other registrar, that the domain was transfered from, that seems to me more at fault. Most registrars allow customers to "lock" a domain, which means that it cannot be transferred without the customer notifying the current registrar. Panix says they locked the domain. If that is so, then it should not have been transferable without their permission, no matter what loopholes were in Melbourne's system.
Translation: We are committed to solutions which enhance your whole internet experience and lifestyle. Please see our website if you have any questions concerning customer service.
404 - Page not found
A feeling of having made the same mistake before: Deja Foobar
Given that it's down to the registry (not the registrar) to actually commit any transfer request, and there are several stages of validation on this, isn't it down to them to NOTICE if something didn't go right?
... right?
If I'm reading the linked description of the transfer process right, in part 2 (allegedly where it fell over) the "gaining registrar is not permitted by the policy to initiate a transfer without approval from the registrant".
Not permitted BY THE POLICY? That's an awful lot of trust to put into each and every registrar never making a mistake or having a design flaw in their systems. Surely they should just bounce every transfer request that doesn't follow some sort of authorization procedure
Why are the registrars responsible for this step, and not the central registry itself? There's an awful lot of trust involved here, and this could happen with any registrar that happened to have a bug in their systems. I bet there's a way to exploit this from many registrars other than Melbourne IT that just haven't been found yet.
Here is a basic explanation of what happened from what I have read.
ICANN recently changed the rules for domain name transfers so that rather than requiring confirmation for domain name transfers, they are transferred automatically if the owner does not object within a set period of time (a few weeks IIRC). This is meant to "streamline the domain transfer process". In this regard, I believe that ICANN is partially to blame for this hijacking. These policy changes need to be reviewed. You can, of course, lock your domain against this occurring, but it is a simple error to neglect to do this.
Melbourne IT is also more or less to blame for this hijacking (depending on who you believe). It has been confirmed that one of their resellers allowed someone to create an account with a stolen credit card number, and initiate the domain transfer process. Panix claims that Melbourne IT failed to send the notification of transfer to them or their registrar. They also state that they had asked that their domain be locked against transfers, but this did not occur. If this is the case, then this is a serious issue with Melbourne IT.
Mebourne IT has also been accused of being unavailable for contact over the weekend, despite promising 24/7 service. The only way that Panix managed to contact them was via the CEO's mobile number.
If these accusations are true, then this shows serious problems within Melbourne IT.
Evidently ICANN made a policy change in November 2004 that was intended to make it easier to transfer domains between registrars, but it turns out to also make it easier to hijack domains. Apparently multiple domains have been hijacked from Dotster.com, (the registrar for panix.com), so I would guess that they have some holes in their procedure for confirming transfers with their customers.
How do you prevent this? Well, when reading the various articles about this, (I know, I'm new here), I ran across the phrase 'locking your domain'. I had never heard of this before, but I checked with my registrar, and sure enough they now have settings for 'normal' and 'high' transfer security. Basically they will not allow any domains that have 'high transfer security' set on to be transferred. Period. Whether they can get in contact with me or not. If I want the domain transferred, I have to log in and reset transfer security to normal, and then a transfer can go ahead. Otherwise it stays with me until it expires. Unfortunately the default setting was normal, but once I knew about it, it only took 30 seconds to set my domains to 'high'.
In theory anyway; panix.com says that their domain was set to 'locked' with dotster, so your mileage may vary. Maybe tucows or someone can randomly test transfer attempts of 'locked' domains and certify registrars that appropriately deny the transfers?
So, check your domains now, set them to locked, or high security, or whatever your registrar calls it. If they don't have such a setting, hey, it ought to be easy to transfer your domain to one that does!
And as you tread the halls of sanity, You feel so glad to be, Unable to go beyond. I have a message, From another time..
Clearly, MIT has it's priorities.
"Who are in control, they are not in control of anything - they don't even control themselves!" - Glen Beck
But..you didn't check your facts. MelbourneIT had the domain transfered to them, even though Panix's registrar, Dotster, was not notified. A transfer lock was also in place for the domain.
I have no idea how you came to the conclusion that this is Panix fault, or the domain expired. Even with this incredible lack of evidence, you proceed to go out on a rant against Panix.
Check your facts before posting.
I've used Enetica quite happily.
The recomendation in the linked discussion is that by using both restrar-lock and auth_info the system provides a reasonable comprimise between security and the incentive for registrars to make the domain transfer process as difficult as possible.
Now, I agree that there is certainly a worry that losing registrars could make sending a domain name very difficult if they initiated a transfer. However, a system which provides registrar-lock which many registrars initiate by default and require user action to remove is just as abuseable. So long as the registrar may put on registrar-lock by default they may incorporate any difficulty they want into the process of removing registrar lock. In fact this is even worse than just requiring the losing registrar to initiate a transfer. After all many domain holders like myself until today have no idea that registrar lock even exists and may attempt to do the transfer before we know we have to undo the registrar lock, adding additional difficulty on top of any difficulty for removing registrar-lock.
As it is we get the worst of both worlds. Since registrar-lock is not always turned on many domain names are left vulnerable but those registrars who want to make it difficult to leave have just as much incentive to turn on registrar-lock by default and make it hard to turn off as they would to initiate a transfer. At this point it would be strictly better to go to a loser-initiated system.
I think a good fix would be to require that registrar-lock be off by default. Those domains that wanted it could turn it on easily, after all the registrar has every incentive to make this as easy to do as possible. This is also a good match for the threat/benefit model. Big name domains are must liable to be attacked, but they have departments that can deal with a difficult transfer process, while private users can leave registrar-lock off knowing that they are unlikely to be targeted and being more likely to change registrars anyway.
If you liked this thought maybe you would find my blog nice too:
"Aside from the obvious chicken-and-egg problem of claiming to have been an ISP before the "I" was even invented - 1989 may pre-date the web but it's a long way short of pre-dating the Internet."
"Advent" is commonly used to describe when something catches on and takes hold. "before the advent of the Internet" has a subtle yet distinctly different meaning than "before the Internet was invented" and that's why I think they chose to write it the way they did.
You're 100% correct, of course, that had they tried to claim that they were around before the Internet was invented, then it would be laughable.
Sitting in my day care, the art is decopainted.
Bollocks. Advent means, and always has meant, the very beginning. Check any dictionary. 'Advent', for Christians, is the month before Christ was born - not the month when Christianity 'caught on'. You can't just just go around redefining words because you've made an arse of yourself in public.
I'm old enough to remember when discussions on Slashdot were well informed.
They probably mean the public internet, hence the p in panix. IIRC there was a political decision made at some point which let the public get access to the internet (not just universities). This makes the world.std.com the first to provide public (dialup) internet service in 1990. Before then, the public had to make do with BBSs.
Aside from the obvious chicken-and-egg problem of claiming to have been an ISP before the "I" was even invented - 1989 may pre-date the web but it's a long way short of pre-dating the Internet.
Disclaimer: I am a Panix user, and I have always been very satisfied of their service.
A Panix old-timer once explained that the first connection between Panix and the outside world was a UUCP link. So they did predate the Internet in a way, since that connection was not TCP/IP.
This being said, they probably meant before the Internet was mainstream...
The right to offend is far more important than the right not to be offended. (Rowan Atkinson)
From the article: "I finally located their CEO's cellphone in an investor-relations web page."
That would be why the CEO was involved, so his involvement illustrates nothing about the company's laziness or otherwise
As a Panix subscriber (and submitter of this topic), I have seen informal update posts made to internal (Panix-only) newsgroups by Panix staff during and since the crisis.
Not only did Panix get MelbourneIT's CEO's cellphone number from a web page, but when they contacted him, he was most unhelpful and even directed MelbourneIT's corporate counsel to contact Panix and set them straight.
If this is the kind of leadership MelbourneIT shows in times of crisis, I pity anyone who has to depend on them--whether by their own choice or through someone else's--to do the right thing in a pinch.
www.icann.org/transfers/policy-12jul04.htm
Instances when the requested change of Registrar may not be denied include, but are not limited to:
* Nonpayment for a pending or future registration period
* No response from the Registered Name Holder or Administrative Contact.
* Domain name in Registrar Lock Status, unless the Registered Name Holder is provided with the reasonable opportunity and ability to unlock the domain name prior to the Transfer Request.
* Domain name registration period time constraints, other than during the first 60 days of initial registration or during the first 60 days after a registrar transfer.
* General payment defaults between Registrar and business partners / affiliates in cases where the Registered Name Holder for the domain in question has paid for the registration.
The bottom line to all of this is to provide accurate information with your domain registrations, and, lock the domain so that if your Registrar gets a notice that another Registrar wants to transfer your domain, it can't be transfered, even if you are not contactable (say, on a cruise or something).