> “Click here to read more details” the email said. The click opened the “Google” password dialog, and the unlucky team member entered the password for our developer account. This looked all legit to the team member, so we did not notice the pishing attack as such at this point. Pishing for Chrome extensions was simply not on our radar screen.
First, it is excellent that you disclosed the issue.
Second, based upon the quoted text you really aren't accepting responsibility for having been phished. The team member wasn't "unlucky." Your "radar" shouldn't trick you into thinking you won't be attacked.
While I normally agree, I think it's important that they referred to the specific person without using blaming language. The team failed and screwed up because they had bad policies with their account. The individual team member who was holding the keys when the screw-up happened? Unlucky.
Fix the process, not the people.
It's good that they're not throwing the poor person under the bus.
I agree with you. The email makes the situation appear as a process issue. Based upon the disclosure text, it seems quite possible the person wouldn't normally have clicked on an email text, but did so here based upon process.
The disclosure displayed the attitude that they shouldn't have expected to get phished. It's 2017. Lots of people get phished.
It's pretty straightforward to never click links that arrive in emails, to never enter passwords into webpages that open on their own.
Of course there are technical ways to mitigate this specific attack, but it is more important not to excuse poor Internet hygiene after the fact.
I don't think more policies will make a better place. One of the team member screw up and stuff like this happen. I am questioning his security education to have been phished so easily.
It's counter intuitive. I bet you $5 that if I target you, and you're not expecting it, I can phish you. I've seen this happen in the field, and it doesn't have much to do with education. Relax for an instant and I have you.
The only real defense is to glance at the url bar every time you're about to enter your password. And even I find myself not doing that 100% of the time. It's a numbers game.
A policy of popping up a popup "glance at url bar" every time you copy your password from your password manager (which you're using, right?) would go a long way.
>> The only real defense is to glance at the url bar every time you're about to enter your password
With Google specifically, the worst part is you really do have to look at the URL every single time you go to enter your password. And by that I mean that if you land on the login page, verify the URL, enter your password, submit, and get the error page saying you got the password wrong... you must check the URL again before re-entering your password.
Why? Because Google's login, by design - and repeatedly defended by them as being "acceptable" - allows redirecting off Google's properties after login. So hackers send you to the real Google login page, with a post-login redirect to a fake but perfect copy of the "wrong password, try again" page, where they then capture the passwords of people who mindlessly re-enter their password without double checking the URL a second time.
Most importantly, 2FA does not help you here. You'll enter a currently valid 2FA code on the hacker's site, and they will immediately use that code to actually log in to your account. Before you realize what is happening, you are already locked out of your account - new password, 2FA stripped or replaced, security questions changed, and all pre-existing sessions/devices wiped.
U2F is a second factor which can't be easily phished. If you are using a service which supports U2F and care a minimum about being secure, enabling it is the least you should do.
Physical keys would solve the problem of redirecting to a fake page (and maybe they would make 3-rd party auth protocols like OAuth or Github login unnecessary).
Most do not, and even Google doesn't. I just verified on my account. You only need to provide your password to access account settings. Completely stripping all two-factor authentication requires no additional 2FA code.
The phisher just shows you a "password incorrect" message on the first attempt. Assuming you made some typing mistake, you enter your password and 2FA again...
I activated it so it would display the punycode. Every major browser up to few months ago would show it as "apple", not sure now. But we know many people cannot just upgrade their browsers, so there must be still many vulnerable browsers out there.
Lastpass will tell you whether it recognizes the site when you go to fill in the password (yes, I use it despite the scary stuff, I know I probably should switch to OnePassword).
Do other password managers not do that?
Just curious, not trying to engage the bigger question of whether getting phished is the user's fault.
One password has similar behaviour as well as verifying the integrity of the browser[1]. It's not perfect, I'm sure a malicious extension would be unimpeded, but these little features all added up and eventually made me switch.
I use KeepassX, mostly because it's small and nearly impossible to attack. But I understand the desire for convenience, and as you say, there are some advantages to other managers.
I use iCloud keychain. Safari autofills passwords only if the URL matches. If the password doesn't autofill, I know something odd is going on. Makes it trivial to recognise phishing sites like the one from the linked blog post.
An email from Google with a bit.ly link? Hell no, I hope I won't fell from it in whatever situation.
I agree that any defense is far from being perfect, but IT professionals shouldn't fell for an unsofiscated attack like this even if you are no working in security. I am not even talking about a web developer.
Disabling HTML e-mails does not sound particularly unreasonable. There’s little additional benefit from them but a whole host of possible issues, least of all that suddenly your e-mail client has to deal with properly parsing HTML and you have to decide whether or not to load remote images and potentially execute JavaScript.
I've never read my email in HTML, mostly for security reasons such as this incident. For the rare occasion where an email doesn't render correctly, Thunderbird's "Show HTML" button works a charm.
Have I been able to convince a single customer (I run a computer services business) or friend to follow my lead? Nope, not a single one.
That too can be fooled. Much better to login to your relevant account by manually opening a new tab and navigating to it. In this case one they saw no link and call to action on their Google developer's website they should realize something was a foot.
Mmm, maybe. I'm certainly not immune to being fooled. I am careful, however. I roll over and check any link in an email before I click it, and I know when I am or am not authenticated into one of my google accounts. It's all too easy, though, to make a mistake like this when you're in a hurry or don't give something enough thought. The email was very good but after reading it a couple of times the language strikes me as not _quite_ right, especially the "unless you fix it" part at the end. Perhaps the key insight is that you have to assume going in that any email you get like this is fake, and then prove otherwise.
In this particular case, though, there were enough warning signs that I wouldn't want to run code by anyone who wouldn't notice them on my machine. The email was clearly not professionally written or machine-generated (note the comma inside the quotation marks around the app name; the oblique "fix the issue" doesn't seem like the right expression to match "did not comply with our program policies"), the ID is clearly non-random (a cluster of keys on the left-hand side of a QWERTY keyboard interspersed with a cluster of keys on the right-hand side, as you would get if you mashed keys randomly) and then there's of course the URL shortener link.
A simple policy to add would be 2-factor authentication, no single shared developer account, and (on Google's side), both another security challenge (2FA) and e-mail notification to both a primary and recovery e-mail address when an extension is moved. Pretty sure Google also raises a question when logging in from a new device, e.g. from Russia, or when certain information is changed. (I know Facebook did at least).
Incorrect. They literally declared "we were phished", in plain words, describing how they were phished and the resulting attack. To say this does not "accept responsibility" is bullshit. You don't get to light the torches and grab the pitchforks to go chase some stranger who exposed you to vulnerability. They are human, they failed, and they're dealing it with professionally.
I'm assuming from your tone of "I demand his head" that you were running the compromised extension, and wish to extract your pound of flesh from the person who compromised you. (EDIT: If not, what's your beef with them? Are you a competitor? Please explain!) This, too, is wrong. And here's why we don't play the blame game when it comes to human failures:
You chose to run a Chrome extension, from an untrusted source, with only machine automation vetting its contents and auto-update ensuring that you get the latest attack. Of course you got compromised. What else did you expect? How could you place ultimate trust for all content in your browser in the hands of an OCR extension?! What on earth could compel you to accept such a ridiculous risk in exchange for this?
Everyone's human, you included. They clearly stated and accepted responsibility for the incident. Now you need to stand up and accept responsibility for running unvetted code in your browser. (EDIT: Yes, it's machine-vetted. How's that working out for you?)
There's more than enough blame to ensure you get an equal portion. Being human is bad enough without people coming to destroy you because they'd rather not confront their own failures of judgement. Get over your immature desire to get your vengeance for being compromised and build a better approach to your own personal security.
I used to do that till lastpass had several vulns [1] in which passwords to all sites can be gotten by a malicious page or extension.
If you use a password manager that auto fills in the paswords, it is open to an attack by a site or program that can fool it into thinking you have visited the site.
Any malicious extension such as the one compromised her, has a good chance of being able to drain all your passwords.
You are probably safer, even with phishing threats, to paste it in from another program each time.
I am aware of that bug. However, Google wants to replace lastpass with Chrome sync, so no surprise that their employees are attacking it. Hopefully that made it better.
Given it's a team account might have made usage a bit more complicated, but this sounds like something 2FA would have prevented, as even with the passsword the hackers wouldn't have been able to login.
The password login system is seriously flawed. I think people and websites should switch to physical keys. They are also easier to use because you don't have to remember complicated passwords.
First, it is excellent that you disclosed the issue.
Second, based upon the quoted text you really aren't accepting responsibility for having been phished. The team member wasn't "unlucky." Your "radar" shouldn't trick you into thinking you won't be attacked.