How the Syrian Electronic Army Hacked The Onion(theonion.github.io) |
How the Syrian Electronic Army Hacked The Onion(theonion.github.io) |
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.
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
tldr: you have a lower number of leads but a higher conversion rate from those that do respond.
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.
- 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).
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.
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.
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.
If a Syrian hacker phished my password, he wouldn't be able to login on his system, would he?
http://jimromenesko.com/2013/04/23/ap-warned-staffers-just-b...
> 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?
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).
(What I would have given for a physical, printed list of social media accounts, associated emails, and passwords hidden in a file drawer somewhere.)
>... 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 will forward this post to my grandfather with "Don’t let this happen to you" in bold.
/onion
"hey, check this out: http://blah.com "
and has their name at the bottom, it becomes very easy to make a mistake.
No wonder! I was wondering what the problem was, and it appears to be PEBKAC.
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.
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.
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.
What are the false positives?
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.
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?
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.
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...