No, the Times episode was clearly the result of an ill-considered and ill-timed system update that went south. Not that the Times isn't sometimes hacked, but yesterday's episode had a pedestrian explanation.
So what are best guesses here? Weeks of surveillance and social engineering or a 0-day/unpatched software?
I just feel like these sites should be getting scanned daily by all kinds of frameworks like metasploit so unpatched known vuln seems unlikely.
More likely is exploiting the employees with spear phishing or social engineering, or 0day. And of those three I'd have to lean towards 0day, if it truly was Syrians that did it.
And if they got socialflow at almost the same time I'm betting they were using something in common.
Though considering the post claims an employee account was hacked through phishing, maybe they had shared accounts for columnists or something.
Not that I was leaning towards that because they were Syrian, more like I was leaning away from the other options because they were Syrian. Social engineering and phishing is much easier for people with a good knowledge of the culture and language they're attacking.
They effectively didn't hack WaPo at all- they hacked Outbrain, and ad provider network, which embeds ads on the WaPo site. Which is a kind of fascinating way to side-step a lot of work I'm sure WaPo have done up until now.
You need insight into how these kind of sites are run to understand how attacks typically work on them.
Backend: lots of technology feeding them content and sending their content out other places. App servers, content sinks, message buses, databases, FTP'd stories, etc etc. Nobody ever attacks these because you have to have some kind of basic reconnaissance on what they do and how they do it. And they're not very secure because of the low visibility. But if you do know how most news sites get their content, there's some fun holes to play with.
Frontend: SQL injection, misconfigured services, bad firewalls, shared or easily-guessed accounts. You don't need anything fancy most of the time. There is no Security Czar making sure everything is secure on the frontend. There's supposed to be, but their lack of authority or motivation prevents them from really trying to secure everything in a big-picture way.
Development: The site is constantly being developed, and not always by the same staff. Sometimes a new guy who writes really shitty code will push something to production which is clearly hazardous to security. It gets through code review and policies and procedures because everyone's busy trying to get real work done. Often these holes go unnoticed for years.
Third-party content: There is nothing ensuring content you're getting from a 3rd party is what you expect it to be. If it's not being served by your servers, it's subject to attack. Often sites get taken down not because of attack, but because an ad network is timing out, causing the page to stop being loaded, effectively DoSing the page. SLAs mitigate this to a small extent by encouraging the 3rd party not to lose money to their customers by being hacked.
Phishing: This will work 90% of the time. Professional pen-testers have agreements not to phish or social engineer their targets more than a certain amount, because it almost always works; there's not much need to test it. But keep in mind that if this were Syrians, their lack of mastery of English could present a problem. Maybe it'd only work 60% of the time in this case.
"I just feel like these sites should be getting scanned daily": Nope. The vast majority of sites don't get constantly hammered by attackers looking for a way in, because 99% of the attacks seen on large-traffic sites are trivial automated things like botnets, which try one or two common holes across millions of sites. Even the most basic security measures prevent these.
Real, targeted attacks are rare, and often get lost in the noise of constant botnet barrage. There just aren't a whole lot of SEA's out there trying to take over every single website. Usually when they do try, they succeed, in some fashion or another; if they were to do this to every popular website on the internet, it would take them months or years to get around to it all. And they probably have day jobs.
The very last attack that works is a 0-day. It's called a 0-day because (typically) it is patched a day or two after it's announced, and they are rare. If you have one, you don't use it just to attack one news site.
> The vast majority of sites don't get constantly hammered by attackers looking for a way in
I find that hard to believe really.
Even just my residential connections honeypot is stuffed with people trying to do obscenely stupid things. There's people installing botnet clients, trying to find databases, you name it. I get a connect every couple of hours, and there's absolutely nothing else interesting about the IP address other than the single open port. Funnily enough, most of them fall into the "Chinese hacker" stereotype, about 90% of the connections I've logged geolocate there.
I can't imagine what a large companies SSH logs must look like.
Your expectations are based on a completely different scenario. A honeypot is designed to attract attackers, and is designed with bad security in mind. No corporate network runs SSH in the open. There's no need.
What a corporate network needs is to provide remote access to specific services based on who is authorized. A VPN is the way to accomplish this. It would be stupid to allow SSH access to everyone (including hackers) when only a handful of authorized administrators would even have SSH accounts, much less do anything on the box. You keep it behind the VPN and only allow specific users access. It reduces the attack surface, creates audit trails, simplifies revoking network access, etc. This is security 101.
> A honeypot is designed to attract attackers, and is designed with bad security in mind.
I wouldn't say that. You'd be very hard pressed to find a production server without SSH, if not on the default port. I'm doing absolutely nothing to draw attention to myself, so it stands to reason that somebody who is (say, running a large website) would draw a lot more probes and "hacked" logins.
> amongst them not running SSH in the open
Moving SSH to a different port is the usual "fix" I see, which does next to nothing really. There's very little in terms of attacks against sshd, and none when you disable password based authentication. Having an open port is not an issue unto itself, unless you used an older Debian to generate your keys.
Moving SSH to a different port does nothing if your system is being specifically targeted, but it stops 99% of drive-by bots. Not that they do much anyway but it at least stops them from showing up in your logs.
Just out of interest I tried running on 22 and a very high random port, as you said significantly less, though not no attempts. I think it's a false sense of security more than anything.
This happened at the FT a few weeks ago with "Syrian Electronic Army" posts and that was a successful phishing attack so "their lack of mastery of English" clearly isn't an issue.
Otherwise an excellent analysis of the likely vectors by the way.
"It's called a 0-day because (typically) it is patched a day or two after it's announced, and they are rare. If you have one, you don't use it just to attack one news site."
It's called a zero day, because there's no patch for it. And if you think most 0days are patched in a day or two after announced, I have a bridge to sell you.
Alright, you got me there. General security holes stay open for months at a time, and remote holes in the production site that are actually vulnerable to a PoC get workarounds installed a day or two after. But still, nobody's going to use an unannounced 0day for a defacement.
In an ironic twist, the Syrian Electronic Army's website wins a Pulitzer for investigative reporting; Jeff Bezos replaces entire editorial staff with six hackers and a shell script.
So many media sites have a ton of javascript widgets: ad networks serving third-party ads serving third-party tracking scripts, recommendation tools, analytics, etc. It really increases the attack surface.
How do publishers know that the scripts that go on their pages are safe?
That is the risk you take with ads, and to answer your question: they don't know if it's safe.
Frankly it would be nice to not run third-party scripts completely outside of your control, but ad networks would never comply with such a one-sided relationship.
It's a constant battle between so many internal groups about what should be on a news site.
Editorial wants the new cool startup storytelling platform , marketing and advertising are using various ad networks and platforms, countless social networking platforms and apis, 3rd party software to manage live streaming, publishing, or what have you.
And behind that is a usually under resourced development team trying desperately to grow the network while re-working old code projects rushed together because of some breaking news story.
In my experience, working for a news agency is a careful balance between trying to establish solid software engineering practices, rushed prototype code, and sysadmin with large amounts of social thrown in just to keep it interesting.
Publishers should use AdSafe[1], which is a system for sandboxing widgets. AdSafe provides widget authors an API for access object properties and the DOM, as well as a static check to ensure that widgets are using this API properly. Given that the static check passes, and the library implementing the API is correct, then your widget is properly sandboxed and attacks like that can't happen. Check out the AdSafety paper[2] for more details about the extent to which AdSafe has been verified.
AFAIK, there was nothing vulnerable in the widget itself: the hackers accessed Outbrain's admin panel, and changed the content of their recommended links to point to their website instead.
What was reported[1] was that certain stories were redirecting users to the SEA's site. This implies that they weren't just rewriting recommended links, but were changing the code of the widgets, which resulted in that behavior.
Are there projects like this that let me embed a third-party URL instead of direct code?
So if a publisher provides me with a link to widget.js, I could just run some sort of Adsafe.executeInWrapper(http://example.com/widget.js)
Most providers in my experience don't want you to embed their actual JS code, because then they lose the ability to do updates and fix bugs without contacting every single customer to upgrade.
Recently, security researchers say the group has also started to engage in more sophisticated attacks,
including using Trojans and and targeting Voice over IP (VOIP) services. Those attacks and this week’s Socialflow and Outbrain compromises suggest the SEA may just be getting started.
Fear mongering at its finest. These people aren't doing anything that isn't already being done by others.
I'm expecting a lot more "cyber warfare" and terrorism-related fear mongering in the following months.
We already saw an increase in politicians complaining about Chinese cyber attacks, but the leaks put an end to that. Let's see who they'll focus on next.
So if the most common way these hacker "groups" actually "hack" websites are through phishing attacks. How do protect against phishing attacks in a way that will stop them. Obviously educating Martha the secretary to not click links in emails from people she doesn't know isnt working.
How can we make phishing attacks less successful or remove these attack style altogether. 9 times out of 10 when I hear about some major hack its because of phishing.
Right now, I'm trying to think of jobs for a news provider that wouldn't require tech savvy. "Secretary" is the only one that comes to mind. Secretaries are stereotypically women.
I only picked the first name that came to mind that sounded older. I didnt choose a womens name on purpose. Albert in accounting, etc... would have done just fine.
That's a _really_ tough thing to solve. If your opponent has rooted the box of someone with credentials, they're going to get those credentials. If you want any kind of remote work productivity though, you're going to have to let them access your system from networks you don't control and can't lock down.
It's one thing to lock everyone out if you're Booz Allen, but another if you've got journalists on the ground in Cairo competing with Twitter to break news.
The easiest way is to IP limit any services with user privileges.
IP's can be spoofed though, and then you're severely limiting your ability to work flexibly, which doesn't go well for journalists.
Two Factor Auth is another technique that's really coming into it's own now among web systems, but again not super great if someone loses their smartphone or RSA dongle while running from a gunfight and needs to access the system NOW.
I work on the assumption that any password can be compromised at any time, so the system should be able to lock out and roll back a user's edits ASAP, and content-creating users shouldn't be able to get any code executing on the server. Easier said than done with most CMS's though...
We've been on the receiving end of these attacks lately. Strict SPF policies, DKIM, and a restrictive DMARC policy can help ward them off.
As a matter of policy, our team uses LastPass, too, which makes phishing easy to detect; if LastPass doesn't offer to fill your login info, you're not on a legit site. Using LastPass-generated passwords that users can't remember on their own is a marvelous anti-phishing weapon. We also enforce 2FA.
The "Syrian Electronic Army" is just rented Iranian hackers. They also have a large propaganda chorus you'll see in newspaper article comments just like Gaddafi did to give the illusion of popular support. They also steal citizen journalist videos of atrocities in Syria and then make up fake translations for them to paint the regime in the best light possible. Since most people never fact check anything they see on youtube largely this strategy works. It's too late when the Guardian or Al Jazeera reveal the true translation weeks later damage has already been done.
Shouldn't the Washington Post and other news agencies be running honeypots to catch these guys?
45 comments
[ 3.2 ms ] story [ 103 ms ] threadI just feel like these sites should be getting scanned daily by all kinds of frameworks like metasploit so unpatched known vuln seems unlikely.
More likely is exploiting the employees with spear phishing or social engineering, or 0day. And of those three I'd have to lean towards 0day, if it truly was Syrians that did it.
And if they got socialflow at almost the same time I'm betting they were using something in common.
Though considering the post claims an employee account was hacked through phishing, maybe they had shared accounts for columnists or something.
https://twitter.com/Official_SEA16/status/368038668709019648
They effectively didn't hack WaPo at all- they hacked Outbrain, and ad provider network, which embeds ads on the WaPo site. Which is a kind of fascinating way to side-step a lot of work I'm sure WaPo have done up until now.
Backend: lots of technology feeding them content and sending their content out other places. App servers, content sinks, message buses, databases, FTP'd stories, etc etc. Nobody ever attacks these because you have to have some kind of basic reconnaissance on what they do and how they do it. And they're not very secure because of the low visibility. But if you do know how most news sites get their content, there's some fun holes to play with.
Frontend: SQL injection, misconfigured services, bad firewalls, shared or easily-guessed accounts. You don't need anything fancy most of the time. There is no Security Czar making sure everything is secure on the frontend. There's supposed to be, but their lack of authority or motivation prevents them from really trying to secure everything in a big-picture way.
Development: The site is constantly being developed, and not always by the same staff. Sometimes a new guy who writes really shitty code will push something to production which is clearly hazardous to security. It gets through code review and policies and procedures because everyone's busy trying to get real work done. Often these holes go unnoticed for years.
Third-party content: There is nothing ensuring content you're getting from a 3rd party is what you expect it to be. If it's not being served by your servers, it's subject to attack. Often sites get taken down not because of attack, but because an ad network is timing out, causing the page to stop being loaded, effectively DoSing the page. SLAs mitigate this to a small extent by encouraging the 3rd party not to lose money to their customers by being hacked.
Phishing: This will work 90% of the time. Professional pen-testers have agreements not to phish or social engineer their targets more than a certain amount, because it almost always works; there's not much need to test it. But keep in mind that if this were Syrians, their lack of mastery of English could present a problem. Maybe it'd only work 60% of the time in this case.
"I just feel like these sites should be getting scanned daily": Nope. The vast majority of sites don't get constantly hammered by attackers looking for a way in, because 99% of the attacks seen on large-traffic sites are trivial automated things like botnets, which try one or two common holes across millions of sites. Even the most basic security measures prevent these.
Real, targeted attacks are rare, and often get lost in the noise of constant botnet barrage. There just aren't a whole lot of SEA's out there trying to take over every single website. Usually when they do try, they succeed, in some fashion or another; if they were to do this to every popular website on the internet, it would take them months or years to get around to it all. And they probably have day jobs.
The very last attack that works is a 0-day. It's called a 0-day because (typically) it is patched a day or two after it's announced, and they are rare. If you have one, you don't use it just to attack one news site.
I find that hard to believe really.
Even just my residential connections honeypot is stuffed with people trying to do obscenely stupid things. There's people installing botnet clients, trying to find databases, you name it. I get a connect every couple of hours, and there's absolutely nothing else interesting about the IP address other than the single open port. Funnily enough, most of them fall into the "Chinese hacker" stereotype, about 90% of the connections I've logged geolocate there.
I can't imagine what a large companies SSH logs must look like.
What a corporate network needs is to provide remote access to specific services based on who is authorized. A VPN is the way to accomplish this. It would be stupid to allow SSH access to everyone (including hackers) when only a handful of authorized administrators would even have SSH accounts, much less do anything on the box. You keep it behind the VPN and only allow specific users access. It reduces the attack surface, creates audit trails, simplifies revoking network access, etc. This is security 101.
I wouldn't say that. You'd be very hard pressed to find a production server without SSH, if not on the default port. I'm doing absolutely nothing to draw attention to myself, so it stands to reason that somebody who is (say, running a large website) would draw a lot more probes and "hacked" logins.
> amongst them not running SSH in the open
Moving SSH to a different port is the usual "fix" I see, which does next to nothing really. There's very little in terms of attacks against sshd, and none when you disable password based authentication. Having an open port is not an issue unto itself, unless you used an older Debian to generate your keys.
Otherwise an excellent analysis of the likely vectors by the way.
It's called a zero day, because there's no patch for it. And if you think most 0days are patched in a day or two after announced, I have a bridge to sell you.
How do publishers know that the scripts that go on their pages are safe?
Frankly it would be nice to not run third-party scripts completely outside of your control, but ad networks would never comply with such a one-sided relationship.
On at least one site I frequent, the served advertising images are gifs.
Editorial wants the new cool startup storytelling platform , marketing and advertising are using various ad networks and platforms, countless social networking platforms and apis, 3rd party software to manage live streaming, publishing, or what have you.
And behind that is a usually under resourced development team trying desperately to grow the network while re-working old code projects rushed together because of some breaking news story.
In my experience, working for a news agency is a careful balance between trying to establish solid software engineering practices, rushed prototype code, and sysadmin with large amounts of social thrown in just to keep it interesting.
They use technologies such as Google Caja to control access to the global object.
Disclosure: I'm an author on the paper.
EDIT: Here's a great talk by Arjun on AdSafety: https://www.usenix.org/conference/usenix-security-11/adsafet...
[1]: http://www.adsafe.org/
[2]: http://cs.brown.edu/research/plt/dl/adsafety/v1
The hackers posted screenshots of accessing the admin panel: http://mashable.com/2013/08/15/outbrain-hacked/
[1]: http://www.politico.com/blogs/media/2013/08/washington-post-...
So if a publisher provides me with a link to widget.js, I could just run some sort of Adsafe.executeInWrapper(http://example.com/widget.js)
Most providers in my experience don't want you to embed their actual JS code, because then they lose the ability to do updates and fix bugs without contacting every single customer to upgrade.
"The Post just got hacked by the Syrian Electronic Army. Here’s who they are."
http://www.washingtonpost.com/blogs/the-switch/wp/2013/08/15...
Fear mongering at its finest. These people aren't doing anything that isn't already being done by others.
I'm expecting a lot more "cyber warfare" and terrorism-related fear mongering in the following months. We already saw an increase in politicians complaining about Chinese cyber attacks, but the leaks put an end to that. Let's see who they'll focus on next.
How can we make phishing attacks less successful or remove these attack style altogether. 9 times out of 10 when I hear about some major hack its because of phishing.
the undercurrents of misogyny is depressing.
Right now, I'm trying to think of jobs for a news provider that wouldn't require tech savvy. "Secretary" is the only one that comes to mind. Secretaries are stereotypically women.
It's one thing to lock everyone out if you're Booz Allen, but another if you've got journalists on the ground in Cairo competing with Twitter to break news.
The easiest way is to IP limit any services with user privileges.
IP's can be spoofed though, and then you're severely limiting your ability to work flexibly, which doesn't go well for journalists.
Two Factor Auth is another technique that's really coming into it's own now among web systems, but again not super great if someone loses their smartphone or RSA dongle while running from a gunfight and needs to access the system NOW.
I work on the assumption that any password can be compromised at any time, so the system should be able to lock out and roll back a user's edits ASAP, and content-creating users shouldn't be able to get any code executing on the server. Easier said than done with most CMS's though...
As a matter of policy, our team uses LastPass, too, which makes phishing easy to detect; if LastPass doesn't offer to fill your login info, you're not on a legit site. Using LastPass-generated passwords that users can't remember on their own is a marvelous anti-phishing weapon. We also enforce 2FA.
That said, there is no substitute for education.
Shouldn't the Washington Post and other news agencies be running honeypots to catch these guys?