Google.com.pk and 284 Other .PK Domains Hacked
35
ryzvonusef writes with news that hackers have taken down the local Pakistan versions of many popular websites, including google.com.pk, apple.pk, microsoft.pk and yahoo.pk. 284 sites were affected in total. Many of the sites were defaced, and a group called Eboz is taking credit for the hack. According to TechCrunch, "The root of today’s attack, it seems, came via a breach of Pakistan’s TLD operator, PKNIC, which administers and registers all .pk domains. Looking at affected organizations via PKNIC’s look up, it appears that all the sites are now redirecting to two nameservers, dns1.freehostia.com and dns2.freehostia.com."
Difference? (Score:3)
Its the TLD that was hacked (Score:5, Insightful)
Blame the TLD operators, dont name google,etc who had no role in the hack
Re: (Score:1)
Blame the TLD operators, dont name google,etc who had no role in the hack
Sounds like an inside job to me. How many of the 284 sites belonged to non-Pakistani companies? Probably all of them.
Re: (Score:2)
Re:Its the TLD that was hacked (Score:5, Interesting)
I was sitting here scratching my head, wondering why all those sites were hosted by the same servers.
Re: (Score:2, Informative)
Taken down and defaced? (Score:5, Insightful)
I'm not great at networking knowledge, but if you simply redirect to a new IP, is the site really defaced?
Re:Taken down and defaced? (Score:4, Informative)
I'm not great at networking knowledge, but if you simply redirect to a new IP, is the site really defaced?
From the end user perspective, site may appear as defaced but the actual web page at {Google, MS,....} is not defaced.
PKNIC unable to respond, PR team in picknick. (Score:1)
PKNIC unable to respond, PR team in picknick.
Re: (Score:1)
Well, if the support is via some .pk email address, any mails to support might also not reach their intended destination ...
Re:PKNIC unable to respond, PR team in picknick. (Score:5, Funny)
One might say... (Score:3)
One might say the entire TLD is PhuKed. The teachable moment here is that security rolls downhill, and depending on any single layer of public infrastructure, at least for authentication of who you're talking to without giving serious consideration to cryptographic concerns, is asking for trouble. This is still something that the world is failing at on, well, a global scale.
Well, that and taking perimeter security seriously in terms of access to critical components, and having short order failover to components with completely different codebases ready to roll into production for select services in the event of something nasty happening. These days, virtualization on multiple platforms running in parallel makes that easier, although it does have the effect of acting as a cost multiplier (sliding scale factor-wise) depending on what you're trying to make as bulletproof as possible.
TLDR = Security is hard. Be prepared to be compromised. Have alternate plans in place that assume at least one $major_thing is already silently compromised. Yeah, it's tough. Life is tough.
Re:One might say... (Score:5, Interesting)
I'd imagine the NIC could simply revert to a backup of their TLD zone and undo the changes -- the zone itself isn't infected and in need of purging, though the systems that can write to it may well be. I would hope that a NIC managing a national-level TLD has backups.
That said, how could any entity that relies on DNS have alternate plans to deal with this sort of thing? Its one thing to have off-site nameservers on a different network to provide some degree of fault tolerance for your own domain, but it's another thing if the TLD itself gets hosed and bad guys modify the zone to point at different nameservers. As far as I can tell there's no reasonable way for the holder of a domain name to prepare for the TLD getting compromised.
I hope this incident serves as a wakeup call for TLD owners everywhere so they can review their security policies.
Re: (Score:2)
As far as I can tell there's no reasonable way for the holder of a domain name to prepare for the TLD getting compromised.
You will need additional names under other TLDs, and to advertise them to your users ahead of time. One common way to accomplish this to do it how google does it; no, not to have massive clusters everywhere, but to have multiple international domain names. If your site is translated, they can default to various languages, but all should permit selecting all languages without redirection to another domain.
Re: (Score:2)
Sure, one could have different TLD variants (e.g. example.com/net/org/us/co.uk/etc.), but that isn't terribly useful in terms of continuing to offer service in the event of a TLD compromise: if the registry for your main domain gets borked some users may try a different TLD but most will simply give up -- how many people would try accessing Google under a different ccTLD? Same thing with email: if you have email at your domain and the TLD is hosed then emails can't automatically pick another TLD and try aga
DNSSec (Score:2)
Re: (Score:1)
Re: (Score:1)
Re: (Score:2)
Whether or not the process exists to remove DS records quickly from the root zone, however, I'm not sure--I don't manage TLDs...
In other news sensationalism at an all time high (Score:1)
"Oh we don't really have a story if we say the .pk TLD had a compromise of sorts that affected 284 domains. What big names were affected so we can put them in the headline?"
Took them long enough (Score:1)
hack Pakistan’s TLD operator, PKNIC... (Score:1)
In Ireland Google.ie and yahoo.ie were also hacked (Score:3, Interesting)
Freehostia (Score:2)
Would blocking port 53 by default on free subdomains prevent such hijacking?
I cannot think of a legitimate reason one would need a free DNS server beyond those that already exist with stated goals of minimizing/preventing DNS-based censorship.
Re: (Score:2)
Are you saying people like me that have always hosted their own DNS, since the Internet became available to us (~1992 here), should now have to stop doing so?
Rgds
Damon
Re: (Score:2)
Let's pretend for the sake of argument you are one of the good guys - I believe you, but how can an even-less-technical user be sure?
Could something be done during routing traffic in the internet at large to block port 53 for an IP address or a range of IP addresses when there is reason to believe malicious redirection is occurring?
Is protecting a mostly-non-technical majority from falling for DNS-based bait-and-switch tricks worth having to appeal an occasional false positive?
Outside of the scope of TFS:
Wh
Re: (Score:2)
My DNS is often colocated with my Web sites and other services that it supports: forcing me to separate them would add nothing to end-user security in reaching me, and would likely lower reliability and increase costs.
Specialised and high-volume sites will also want to do things such as geo- and load- sensitive DNS and constraining innovation in that area by constraining DNS providers is unlikely to be helpful for the end user (ie would result in slower and less reliable service).
Entire IP addresses can be
Hmm. (Score:2)