How the Syrian Electronic Army Hacked The Onion | Hacker News Reader

How the Syrian Electronic Army Hacked The Onion

theonion.github.io

154 pointssrbloom64 comments

Google requiring you to enter your password at random times for random things (e.g. to read a Google Groups message) seems like one contributing factor, since people treat those prompts as routine noise, and are less likely to investigate such a common occurrence too deeply.

I agree with this point. I retype my user information, even while logged in, at least a few times a week.

That's odd because I never do. I'm using two-factor and I only have to retype login information when that expires (approximately 30 days I believe.) Also, someone did phish my Google cookies and Google immediately shutdown my account and made me type in something from a text to reactivate my account. Overall I'm pretty happy with both of those circumstances.

Good point; I wonder how many people take that approach. I personally tend to log out of Gmail after I read my email, which signs me out of my Google Account fairly regularly. But maybe that's an unusual use pattern.

I always log out of my Gmail account when I am done reading my e-mail, as well. Until recently, when I've come across several people who stay logged in all the time, I thought that was the 'normal' use pattern. Then again, I'm old and "back in the day" you always logged out of an application/system when you were done.

This happens to me weekly. One problem in my case is I have three Google accounts (1 work, 1 Personal Gmail, 1 Youtube).

Some of the accounts don't work in every context, i.e. the pre-Google YouTube account doesn't seem to work for displaying public Google docs embedded PDFs. Sadly the accounts can be linked but not merged[1] which means I'm stuck.

[1]http://support.google.com/accounts/bin/answer.py?hl=en&a...

I never re-type my user information. I don't even know what it is.

Whenever I create a new password for a website, I make sure it's random, and I make sure I can't remember it. I leave that job up to Firefox's password save mechanism.

Whenever I REALLY need a password, I go to the text file I pasted it in when I created it. Or extract it from within the firefox preferences.

Case in point. If a certain login URL I am familiar with doesn't know my password I am suspicious already.

That's a really good point. It happened with me a few times, especially while clicking on some search results pointing to Google Groups. Now I'm wondering if any of those were actually phishing attempts, because it's sometimes really easily to overlook what the real domain of the search result is.

> "Please read the following article for its importance"

This immediately hit my brain's bayesian classifier like a ton of bricks. Or as the saying goes, "If spammers ever learn proper English, god help us all."

* the English is actually proper, but the wording is unusual

A few minutes of searching and I couldn't immediately find it but, if I recall correctly, it's actually intentionally incorrect as poor grammar comes off as folksy and more trustworthy and leads to more clicks.

+1, this phrasing immediately triggers my brain's spam alert. It's not simply a "familiar" kind of phrasing friends or teenagers would use to make communication shorter - it's just that kind of mistake scam emails tend to be full of, for some reason.

That "some reason" is, as other comments have said, to only get responses from the most gullible marks. If you're gullible enough to respond to a typo-ridden email from someone claiming to be a Nigerian prince who just needs you to pay him a small fortune now in return for a huge fortune later, you're worth pursuing. However, that logic doesn't apply here since the phishing attack was targeted. That's why the email did not have deliberate typos. However, unlike Nigeria, Syria isn't an English speaking country, which explains the awkward phrasing in the email's one line.

Interesting. I never considered that shady language is a purposeful thing, always assuming it's genuine mistakes by non-native speakers.

Yeah, unusual (oddly formal, non-colloquial, weird syntax) English is usually the best giveaway.

That said, spammers and phishers are getting better and better. I've seen some "Apple" emails that looked almost quasi-legit to my weary eyes at 2am, say, but which revealed themselves as laughably bad upon closer inspection of the writing and the email addresses.

We should assume that phishing attempts will continue to improve in writing quality, use of plausible email addresses, and mimicry of email templates from legitimate sources. But some things will never change, because they are fundamental to the phishing playbook: seeking credentials, linking, etc.

It doesn't work for spear phishing, but for wide-ranging hits the broken english is often on purpose: http://research.microsoft.com/pubs/167719/whyfromnigeria.pdf :: http://www.onthemedia.org/2012/aug/31/why-nigerian-email-sca...

tldr: you have a lower number of leads but a higher conversion rate from those that do respond.

I can see the logic here, but for something that's a one-and-done "click this link and type in your credentials," I honestly think good spelling would add to the legitimacy. So in The Onion's case I think it's just a matter of the attackers not being good at English; if they were, I feel their success would increase a bit.

I suspect folks at The Onion get completely legitimate lead emails with worse English than that on a regular basis.

I often think about creating a browser and email plugin/extension to help with this:

- Look at all link tags.

- If it looks like a URL (has a scheme at the beginning, or something which resembles a hostname, or a bunch of path or query parameters), inspect the actual link.

- If they have different hosts, warn the user, and perhaps give them the option of just visiting what the contents of the link tag say (rather than the href attribute).

- Maybe do some magic with onclick events too.

I don't care that it wont be right 100% of the time. I don't care that some times I'll be warned when in fact it is perfectly fine. What I do care about is that when I click a link, I go to that link.

It would be quite helpful for attacks like this, but I'm also interested from a privacy perspective.

Google, Facebook and others go to great lengths so that when you mouse over a link, it looks like it will take you directly to the webpage it says it will, but actually redirects via themselves first. I often find myself copying a url from Facebook and pasting into the address bar, because I don't want them to know which articles I read (yes, I know, if I'm that paranoid, I probably shouldn't use Facebook, blah, blah).

My brain is a bit fried, but what about a rule that "if the text contained in the <a> tag is a FQDN, it should match the FQDN in the href exactly"?

What are the false positives?

Things like Google results that go through a redirector for click tracking.

So, another practice that should be highlighted and made to stop.

The easiest way to recognise the link text as a FQDN would be to check for http:// or www., but even without them (i.e. google.com/foo) users will still assume it's a URL. If attackers get creative with unicode (e.g. google۔com using U+06D4), it could be pretty difficult to identify text that looks like a link.

This is where my appliaction of a "privacy" idea to a "security" problem falls down.

With privacy, I try to be pretty vigilant, but I don't do everything in my power to prevent tracking. I am more worried with companies collecting large swathes of data on my behaviour rather than the odd tidbit. I'm quietly hopeful that analytics, advertising et al. companies will not go to such ingeniously dodgey methods for tracking peoples behaviour (though being hopeful is very different than expecting them not to be dodgey).

But who knows, as a filter that might catch a portion of phishing links, it may have some use.

One word: mutt.

<a href="http://google.com/ onclick="document.location.href='http://www.hackersite.com/>http://google.com/</a>;

Oh, so you check that? How about I just position an invisible element overtop of the valid looking link? Or use the click handler to do a preventDefault/setTimeout?

The only way I can think of to even remotely feasibly try and catch this is to just track the last URL clicked if it looks like a FQDN, then compare that against the browser's URL on the next document.onready.

Of course, if the site has any sort of open redirection, then that's useless.

However, after all of this... The attackers can just switch to using links which don't have the FQDN in their label.

No sane e-mail client executes Javascript from mails.

People who fall for attacks like this don't install protective extensions, or if they do, they become complacent assuming that those extensions will always protect them.

I would just be happy if clicking any link in an email just popped up dialog first with "Do you want to go to the following URL" with the real URL. I always copy URLs from emails and paste into the browser to be sure I'm getting the URL I think I am, and this is basically just giving me the same preview. For less qualified users, maybe it could bold/highlight the domain name (stripping the subdomains where all the phishing magic happens) and ask "are you sure you want to go to phishingdomain.com".

I believe Thunderbird's phishing detection does something along the lines of matching link text with link destinations. Mostly noticed it because mail from Mozilla tend to trip it...

It also (by default) disables scripts in mail anyway, so onclick events aren't a problem. In fact, I would be surprised if any mail client enables script by default; that just seems like a horribly bad idea.

You can imagine the tech team at the Onion feeling a race against time before their editorial team managed to so infuriate the attackers that the situation got out of control.

Accurate. On one hand, we didn't want to fuel the fire, but on the other, that inflammatory article forced the attacker to reveal their hand. So it was actually to our benefit, strangely enough.

Broadly speaking this is just what happened to us at The Guardian.

Our major takeaways have been a drive to 2FA-by-default for all users, and a move to managing social accounts through intermediaries like HootSuite.

One more reason to use 2FA on your Google Apps account.

2FA is great, but it wouldn't save you here if you ask it to remember you for 30 days.

It would have stopped someone from using a phished GApps credential from logging in to Google using it, though.

It sounds like one prong of the attack was to gain access to one employee's email, then use that account to send phishing emails to other employees. 2FA would have stopped that.

I wonder if it would be possible to phish 2factor while you're at it... Something like:

1- get target to enter google credentials

2- log into target's account using those credentials with a proxy/controlled IP that shows up nearby in geoip DBs

3- display a credible message, asking for 2factor code (something something DHCP something something more buzzwords - dummy mode on)

Any reason this wouldn't work?

Can you explain? I use 2FA and tell it to remember me on this device, right?

If a Syrian hacker phished my password, he wouldn't be able to login on his system, would he?

You're completely right. I was too focused on the fact that 2FA doesn't text you every time you log in, meaning a 2FA user wouldn't find a google login prompt without a text code requirement abnormal. They couldn't login from their own machines - that's the whole point! Silly me.

That feature is limited to the device you told it to 'remember' you on.

One problem I have with the current 2FA on Google Apps is that there is no way to enforce 2FA for all users before everyone sets up their mobile device. If you've set the requirement for all to have 2FA, then new users can never log in.

You're then left in this limbo of some with/some without 2FA, and unless you actively pursue those without it setup, you can never change that system wide setting in the control panel.

This is a serious problem, but they do have a workaround. You put new users in an "exception group" that doesn't require two factor auth. Then after they set them up you take them out of the group. It's better than nothing:

http://support.google.com/a/bin/answer.py?hl=en&answer=2...

Why not? If you think you're logging in you'll also need to enter the 2FA code and if you do that the attacker can get an active session.

The attacker (most likely) wouldn't know the phone number, so the user would have to recognize that the text prompt isn't displaying the last 4 digits of their phone number like it usually does. Then again, if you're already oblivious to the fact you're not on an official google login form, it's completely possible to miss that as well.

This is almost verbatim to the spear phishing email that allowed the AP twitter account to be compromised.

http://jimromenesko.com/2013/04/23/ap-warned-staffers-just-b...

An interesting story.

> The email addresses for your twitter accounts should be on a system that is isolated from your organization’s normal email. This will make your Twitter accounts virtually invulnerable to phishing (providing that you’re using unique, strong passwords for every account).

That doesn't make a lot of sense. Sure, now your twitter account is somewhat protected against phishing (I think 'invulernable' is a bit too confident, even with 'virtually' added as qualifier).

But what about any other possible account? So now you say every single other possible account related to your business should be associated with an email address isolated from normal email, to protect them from phishing. Right?

Okay, so what makes is the 'normal email' again? You've just decided to split all your email amongst as many disparate systems as possible, to protect against phishing... which I guess it sort of does, but at cost of so much confusion that you've probably opened yourself up to something else.

Unless twitter alone is so high value to protect in this way?

Or am I missing something?

Our point there was this: the type of phishing that caught us was pretty casual, and aimed at users who weren't very technically sophisticated, and those users shouldn't have had access to our twitter accounts.

The proposed solution is certainly pretty drastic, but when it comes to securing twitter accounts, there aren't a lot of options. The safest one I can see is to connect the accounts to an email address that isn't part of our google apps organization, as that is the common attack vector here.

Our twitter accounts are a high value resource, and are pretty hard to protect. We have almost 5 million followers, and two factor authentication isn't even an option. Once hackers change the email address on the account, we lose all access until we can get in touch with someone at Twitter (which takes a while, even for us).

There's a potential non-technical problem with that solution, though - what happens when the person who controls that email address leaves the company, especially if they leave on bad terms? I've had to deal with figuring out the mystery email that was connected to a corporate social media account, and it was a hellish bureaucratic nightmare to find the social media intern from three summers ago who had the password for the throwaway email. If it had been an email from our corporate domain, it would have been a lot easier to gain control of it again.

(What I would have given for a physical, printed list of social media accounts, associated emails, and passwords hidden in a file drawer somewhere.)

Wait, did did The Onion actually get hacked? I just assumed that was a joke. Now I'm confused...

Notice that the Onion Tech Blog is an entirely new site with a single post. Presumably because if this was posted on theonion.com no one would've believed it.

That's wild. Yeah, I read both of the Syrian Electronic Army articles, but it never occurred to me they had actually been targeted. That makes a "SEA has some fun before their inevitable deaths" a bit cruel perhaps. Since that could very well happen.

I assume the email was in HTML where the link's href was pointing to something different than what the text is. Couldn't gmail easily detect this discrepancy and warn the user that this is potentially a phishing attempt?

I'm not sure what happened here:

>... which asked for Google Apps credentials before redirecting to the Gmail inbox.

followed by:

>Coming from a trusted address, many staff members clicked the link, but most refrained from entering their login credentials.

Does this mean "[asking] for Google Apps credentials" should be read as "put in their Google username and password", or should it be "gave the site OAuth access to their Google account"?

I'm a bit curious, because it sounds like they set up a Google Apps app that sent phishing emails from the first-round-phished accounts to others in the company, so it looked more legit, but this second-round email was not the same as the first. I haven't heard of that trick before, but it's clever, and probably hard to work around.

But if they actually entered their user/pass, there's an easy solution. USE A PASSWORD MANAGER. Kills phishing dead, since it won't auto-fill on the wrong domain.

This, of course, is an artefact of the well-known, old problem of your email being the single point of failure for your entire online identity.

Google might be able to do something to help here: Surely, they can detect with high reliability if a given email contains a password reset link, and trigger an extra challenge. I'm not sure what it should be, as obviously the account password isn't going to cut it. It could really just be a very short PIN-style code for opening "sensitive" email.

I thought it would be something interesting given the title..nope just something you see in your email everyday .. Maybe the Onion's next move should be to invest with a Nigerian prince.

I will forward this post to my grandfather with "Don’t let this happen to you" in bold.

/onion

When an email looks like it came from someone you know, and says something like:

"hey, check this out: http://blah.com "

and has their name at the bottom, it becomes very easy to make a mistake.

It's really cool to see The Onion hosting on github and using Octopress for blogging.

Yet another reason to use a password plugin like 1Password or Keepass or whatever: because they memorize password-per-domain, they do not attempt to fill in a password when the domain is merely similar to a known domain.

It's good to see that the Syrian regime has its priorities well thought through (assuming this has anything to do with Syria). First, hack the Onion. Then, fight off the rebels.

I got several paragraphs into this writeup before I realized it wasn't just an Onion spoof of the once-a-day "anatomy of a hack" articles that come through here. :P

The points in this blog post are good...but how about something more basic: Never log in after clicking through an email link

Why would you ever click on an e-mail link?

No wonder! I was wondering what the problem was, and it appears to be PEBKAC.

don't credit them and say this is a hack....it's just phishing.

I think it is hilarious that people still click on links in e-mails.

Just go to the website directly via a URL. Don't ever click on links in e-mails. Once you learn this, you're much safer.

People do what they're told. Or more accurately, they do the last thing they're told.

The IT department yells at them not to click any links in emails. But then, every legitimate web site also still routinely sends emails instructing their users to click links within.

Reply on news.ycombinator.com