... and thousands of HN readers get infected by a zero-day exploit. Maybe. If you're thinking of submitting a known compromised site to HN, consider instead submitting a third-party site which explains/documents the compromise. Ideally from a respected security research company. This has several benefits:
1. You're not subjecting HN readers to a site under the control of a malicious party who may have done more than just deface it. Even if you verify that you only receive plain boring text with no scripts, iframes, plugins, etc. it's impossible to verify that someone else won't get served different content. For example, malware that only gets served to people in Israel.
2. Once the compromised site is restored, people visiting the link won't see what happened. When you link to a third-party article, that article will persist even after the hack is long since gone.
3. Linking to a security research company will probably give better insight into the technical details how the attack happened, gratifying our intellectual curiosity, instead of just being a dumbed-down piece from some mass-market tech blog.
> 0-day exploits aren't tossed around like candy corn
They are if the zero-day isn't what you're after.
Something like this is like candy corn to a site like HN. You need an exploit and a reason to get your targets to visit your hacked site. When something like this hits HN's front page, if your target is in the tech world, odds are very good that you'll catch someone in the company/companies you're after. This is not theoretical. See, for instance, the Java exploits employed in those hacked iOS dev forums that successfully compromised computers at Facebook, Twitter, Apple, and Microsoft[1].
While DNS-hijacking Google.ps as a watering hole for HN seems like a bit of a long shot of a vector to get access to HN users, it would be a pretty logical vector for Palestinian Authority systems. And is likely a lot of other users would get unintentionally caught in the net.
Flash/Java vulnerabilities are also quite a bit cheaper (100k range), and well within the price range of most criminal APTs, let alone nation-states. But I imagine most, if not all, HN users have those extensions disabled by default.
So the only way to compromise the systems of most users here would be a 0-day javascript vulnerability in Chrome/Firefox. These are the 0-days to which I was referring, which are massively expensive.
But overall the point is valid. The risk, even if not that large that anyone here would be targeted, makes it a good idea not to post directly to compromised websites. I'm not exactly wild about a random workstation at any US company being compromised, even though they weren't explicitly targeted, by random Israeli hackers or even Unit 8200.
There are tons of 0-days out there, maybe not in Chrome proper but in Java, in extensions, in flash... Multi-million is a huge exaggeration. I think market is 20k - 50k for many areas.
>1. You're not subjecting HN readers to a site under the control of a malicious party who may have done more than just deface it. Even if you verify that you only receive plain boring text with no scripts, iframes, plugins, etc. it's impossible to verify that someone else won't get served different content. For example, malware that only gets served to people in Israel.
I don't agree at all, the system which was hacked is not in Google's control at all, even though it does depend on it for DNS SOA.
Every site depends on root DNS servers to do their job right...the root for .ps was hacked...that's what happened here...google was affected, but not hacked.
You are using these words, but I don't think you know what they mean.
The SOA record is almost irrelevant in this case, unless you are seeing some trickery where they set high TTLs or something to keep the "hack" around longer after it has been corrected.
There is only one root (which is kinda what makes it a root) - and in this case the root servers are doing their job just fine. DNS is hardly even involved. As far as I can tell this was simply a compromise of the web UI that allows for the management of domains under the .ps ccTLD. Probably just another sloppy front end developer.
Forgive me, it has been several years since I dealt with DNS authority, however it still does not change the argument that it was not google who was 'hacked'...the title of this post is just blatantly wrong.
I wish OP would have done the same with a comment. In fact, this should probably be standard procedure when submitting a link to a compromised site if it's not to a blog/news post about it.
That is not what "hacked" means. If they had really hacked Google their servers and proxied all searches through a system of theirs without letting the users know it would not have been "apparent" yet Google was hacked in the correct sense of the definition.
They were defaced which was directly apparent to users - not hacked. At all.
Being hacked means a hacker has found and exploited a weakness in a computer system or network. Saying that Google Palestine was hacked is false because no exploit in a computer system or computer network OF Google Palestine was found nor exploited.
Out of six DNS servers, which are authoritative for zone .ps, only one gives out wrong NS records for google.ps . Is it pure luck for that answer to be cached at Google Public DNS, or it possibly had been done by some obscure trick?
EDIT: Ok, on the second thought it seems that the compromised server is just the closest to google. All that is left is to wonder, whether palestine guys did target that server because of it :)
Being the Google bar on the screenshot in French and the name servers on a Moroccan hosting provider I think it's clear where these script kiddies are from :)
Aren't we seeing a lot of DNS based attacks in the recent past? I remember .pk TLD was hacked not too long ago.
Considering that most of the big sites run local variants of their services using these TLDs is it fair to assume that one of these next ones could be of the phishing kind?
What's the best thing to do - always use the .com hoping that it is safer?
This isn't a DNS issue, it's a SQL injection attack.
ICANN needs to mandate stronger requirements for best practices with web based management UIs. Unfortunately they have little in the way of real control over ccTLDs.
You'd be best served registering ccTLDs and redirecting them to your gTLD of choice (say, .com) and not trying to serve localized content from them.
ICANN is not in a position to mandate such requirements for ccTLDs as they are not empowered to. ccTLD governance differs from gTLDs in that each country code is managed and overseen locally within the country. This is why there is such a diversity in ccTLD policies. For better or worse this model of subsidiarity is what we have today.
> Unfortunately they have little in the way of real control over ccTLDs.
Hopefully NTIA can empower ICANN (as the IANA operator) to better exercise security requirements against ccTLDs. Ultimately NTIA can pull the ccTLD from the root, which is a stick we could use increase the overall security of the internet, but I would prefer we find a carrot.
Semantics. If it was an SQL injection attack, it was an SQL injection account that caused a DNS issue. No one cares about a specific SQL injection vulnerability, what matters is that a domain stopped being secure. Nothing bad happened here, but they could have made the fake page look like Google and collected a bunch of logins.
I cannot confirm this from all locations. google.ps sometimes resolve to a legitimate Google and other times to the Moroccan server. Does anyone have an idea how could that be possible?
Congratulating someone by calling them "butthurt" and "losers" doesn't work. Your post is rather offending and your last name does indeed spoil your stance in the Israeli-Palestinian conflict but nevertheless your comment is inappropriate and was uncalled for.
1. You're not subjecting HN readers to a site under the control of a malicious party who may have done more than just deface it. Even if you verify that you only receive plain boring text with no scripts, iframes, plugins, etc. it's impossible to verify that someone else won't get served different content. For example, malware that only gets served to people in Israel.
2. Once the compromised site is restored, people visiting the link won't see what happened. When you link to a third-party article, that article will persist even after the hack is long since gone.
3. Linking to a security research company will probably give better insight into the technical details how the attack happened, gratifying our intellectual curiosity, instead of just being a dumbed-down piece from some mass-market tech blog.