Live data from Hacker News

How the Syrian Electronic Army Hacked The Onion

theonion.github.io

31–40 of 68 posts

Re: How the Syrian Electronic Army Hacked The Onion

#32

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…

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).

Re: How the Syrian Electronic Army Hacked The Onion

#33
post #2

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

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.

Re: How the Syrian Electronic Army Hacked The Onion

#34
post #5
post #3

> "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

+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.

Re: How the Syrian Electronic Army Hacked The Onion

#35
post #3

> "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

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

Re: How the Syrian Electronic Army Hacked The Onion

#36
post #9

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 tha…

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

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.

Re: How the Syrian Electronic Army Hacked The Onion

#37
post #9

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 tha…

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

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.

Re: How the Syrian Electronic Army Hacked The Onion

#38

Earlier quoted context omitted.

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

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.

Re: How the Syrian Electronic Army Hacked The Onion

#40
post #34
post #5

Earlier quoted context omitted.

+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 d…

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