The Fake News as Cybersecurity Threat
powers-do-not-use! 270000NC1K Visits (736)
A group of malicious activists attacked pbs.org over Memorial Day weekend. Displeased by the tone of a recently aired documentary on the Wikileaks scandal, they posted Login IDs and passwords from the pbs.org infrastructure including some of the SQL database passwords many of the logins used by staff. The real attention grabber was that the activists posted a fake news story that claimed Tupac Shakur had not actually been killed 15 years ago but was secretly living in New Zealand. Jon Stuart of The Daily Show would have been proud. The story had just enough whiff of plausibility that it went viral and it was several hours before the fake story was removed. You can read more of the details about how it played out over the weekend at eWeek Security Watch's article, "PBS.org Hacked With Fake Tupac News Story."
According to statements made by the activists on pastebin.com, the exploited a vulnerability in Moveable Type to compromise the underlying Linux Servers. They also noted that the administrative user accounts used the same passwords on multiple systems which gave them further access to the internal network. At one point the activists were able to post a fair amount if detailed information about the internal infrastructure at pbs.org.
I don't personally have any more details about the attack than has been reported in public media. But just taking these statements at face-value, we can easily identify all the standard issue controls that could have prevented these attacks. I like the ISO 27001 standard so let's go with that one:
Control 12.6.1 - Control of Technical Vulnerabilities:ISO 27001 notes the importance of having a process in place to keep critical systems up to date with security patches. The activists claimed to have exploited a "zero day" vulnerability, which is to say that no fix was yet available from the software vendor. In this case, the vendor was Moveable Type, version 4. Their most recent security update was released on May 24, about 5 days before the pbs.org attacks. Maybe having the latest patches from Moveabe Type would not have prevented the attacks. But you can't help but wonder, did PBS install the latest round of security patches within 5 days? I haven't seen any statements from them indicating that they were completely up to date on their patches so it's unclear to me that it really was a zero day exploit or not. In any case, the point is that IT shops need to be brutally diligent about their patching processes and turn around times.
Control 11.2.3 - User Password Management - Easy to say, hard to do. The discipline needed by administrators to force themselves to practice good password management is tough and hindsight is always 20/20. But anyone thinking about a security policy would be able to predict that using the same login and password for administrative accounts across multiple systems tremendously improves security. But of course it makes other administrative tasks that much harder. There are identity management tools and single sign on tools that can help with these issues, including some sophisticated signon management tools from Tivoli that can help with these issues.
OK, I think that covers the obligatory IT control analysis of the incident. What I really wanted to say about the pbs.org attack was this:
Good thing the attackers had a sense of humor.
With no disrespect to Tupac Shakur, if it turned out that he'd actually been alive and in hiding the past 15 years, it would cause only a minor stir in the world. Might make headlines on Entertainment Tonight. he might even make the cover of Entertainment Weekly. But that's about it.
The attackers could just have easily posted a fake news story on pbs.org to cause much more trouble. Fake news is a tricky business. It can't be so outlandish that people immediately dismiss it. But there's no doubt in my mind that a carefully crafted fake story planted on pbs.org could move markets, create civil panic, and possibly even raise security alerts. Again, thank goodness the attackers tempered their response to cause embarrassment to pbs.org.
Here's a questions for ya. Who's gets held responsible for publishing lies? Especially lies that could cause serious damage to a person, cause civil panic. or a major incident? I'm not at all a lawyer and I am not trying to delve into libel law here. But I can't help but wonder if the attackers had posted a fake news story, could pbs.org be accused of libel? I doubt it, especially considering that pbs.org employees did everything they could to correct the story and get the word out as fast as possible. Even if the incident doesn't raise legal issues for PBS, the attack has certainly embarrassed them as an organization and caused harm to their brand reputation.
I wonder if it's time for us to start talking about digital signature controls on published content. I can imagine a system by which each post to a blog stream has metadata attached to it containing a digital signature for the story so that it can be verified as originating from the organization/author we think it's coming from. Certainly there are mature standards around signatures around XML documents. So signing items in an RSS feed for example wouldn't be too hard. I expect it would require a little more standardization work to surface such signatures on a typical news site in a way that they can be easily verified. But it doesn't require significant invention, just establishment of well published conventions that everyone can follow.
Given all the recent focus on cybersecurity and critical infrastructure protection. This might be an area to put on the list of concerns. To borrow a phrase from Jon Stewart, "the fake news is all I need" (to cause panic).
If you are aware of sign