If you find a good tactic and it works you stick with it, right? That certainly seems to be the case for the Syrian Electronic Army (SEA).
Early in 2013 we watched them phish major media organizations in succession.
More recently they have moved on to more sophisticated techniques, mixing together social engineering, phishing, email hijacking and domain hijacking.
Today, it was Facebook’s turn. It appears the SEA were able to gain access to an administrative panel at DNS provider MarkMonitor.
MarkMonitor prides itself in providing brand protection services, including DNS hosting.
Despite the blemish from today’s SEA shenanigans, it can still stand reasonably tall because it was able to stop the attack while it was still in progress.
They weren’t able to totally prevent the incident, however.
The SEA began by altering the contact details in Facebook’s WHOIS records to allow them to authorize a transfer to an account that would allow them to make further changes.
You can see the records were altered at 2014-02-05T23:33:44 UTC. Here in Vancouver that was on Wednesday at around 3:30 pm.
More important to note is that the name servers still point at the legitimate nameservers for Facebook.com.
I was watching this in real-time and there appeared to be a struggle for control around 23:49 UTC, with MarkMonitor winning the war at 23:56 UTC.
The SEA Twitter account also claimed to have been able to potentially alter domain records belonging to Yahoo!, Google and Amazon.
All of these companies appear to use MarkMonitor for their DNS services.
According to The Next Web, MarkMonitor would neither confirm nor deny whether Facebook is in fact a customer of its services.
Pro tip to the PR people at MarkMonitor: Don’t refuse to confirm things that are obviously true if you don’t wish to make a statement.
Say something like, “We can’t comment on things that involve an ongoing investigation by law enforcement.” Far classier.
The real challenge in these situations is that the design and protocols of the Internet were not designed to defend against malfeasance.
To a degree we are like the little Dutch boy in Hans Brinker attempting to save ourselves by plugging holes in the dike.
We must bootstrap the Internet into modern times by taking things like DNSSEC seriously.
Stealing someone’s password or convincing an innocent customer service representative you are someone else should not be sufficient to take over someone’s online identity.
Stay vigilant, folks, and look into what your organization’s DNS provider offers in the way of protection.
Note: Folks seem to think that I am suggesting DNSSEC would have prevented this. Not in this case, but it is another piece of the puzzle that needs to fall in place to shore up the integrity of our name resolution system.
The whois info for facebook.com wasn’t upated since Updated Date: 2013-06-06T04:00:37-0700 according to the whois info. The database update isn’t = the whois record change.
Wait, DNSSEC would have solved this problem? What?
While DNSSEC can augment the security of host/domain queries, it does nothing to stop attacks similar to the one described. DNSSEC relies on a chain of trust which begins at the registrar. Corrupt the record at the registrar (which SEA has done in each of the attacks described) and DNSSEC provides no value.
The proper fix is to use a registrar that provides strong authentication prior to permitting zone changes. For example decent two factor authentication for their management interface, required verification to a fixed call back number, etc. will do far more to prevent these attacks than DNSSEC.
In addition, the DNSSEC spec still needs work so that hosts supporting it do not automatically become DDoS amplifiers. This needs to be fixed before the spec can be widely deployed.
Starting today, I have seen a rash of what appears to be posts from hacked accounts on facebook. The text is always the same, “check your last profil visitor”, (with profile misspelled). Then the link which starts with adf(period deleted by me)ly. I have already seen these posts on six different group pages. What is this, and will Sophos’s “cleaner” fix it?