Live data from Hacker News

The closest I've ever come to falling for a Gmail phishing attack

twitter.com

231–240 of 289 posts

Re: The closest I've ever come to falling for a Gmail phishing attack

#231
post #63

Earlier quoted context omitted.

It's a hard problem but the industry isn't doing as much as it could do. There's low hanging fruit that has gone unharvested for years at most big companies. 1. Reform the browser address bar. Safari does this right. Chrome, IMHO shamefully, does not. The address bar is completely ignored by a large fraction (I've read it's about 25%) of users because it's full of meaningless technobabble. These users navigate entire…

> The address bar should show the domain name only, or the EV identity when that's present, and the browser industry should adopt practices to push usage of EV SSL everywhere. Only EV SSL is a feasible approach to get the actual, legal, verified identity of a server operator on the users screen in a reliable and scalable way. EV certs have their place, but I'm not sure they're better than a URL that you're familiar w…

One problem with URLs you're familiar with is lookalike URLs that appear to be something you're familiar with. Would you notice that you're visiting natwеst.com instead of natwest.com?

Re: The closest I've ever come to falling for a Gmail phishing attack

#232
post #168

Earlier quoted context omitted.

Agreed - I think simply highlighting the data:... part of the URL with a vaguely scary colour would help.

Apple's approach in Safari is to only show the hostname in the address bar, unless the address bar has focus. This works pretty well in general (for non-power-users). Unfortunately, for a data URL, it just shows as much of the URL as fits. This may well include the phony “ https://account.google.com” part of the URL and thus still mislead naive users.

At the very least it'll still look different, which might hopefully make the user take a closer look. For example, for normal URLs, you never seen the https:// part (unless the address bar has focus). Even if you enable the advanced preference to show the full website address again, it still hides the https:// part.

Re: The closest I've ever come to falling for a Gmail phishing attack

#233
post #53

Had the same exact experience in August. Amazing thing was I KNEW the email was phishing. I was asked to look at it by someone internally who was suspicious. I forwarded it to a Gmail account I use for dodgy items. I fired up a VM and logged in to the Gmail account. I looked at the email. I briefly examined the raw message (too briefly). Then I clicked on what I still thought was a Google Drive attachment. My first t…

The scariest part is that you knew that there was something suspicious and still [almost] got phished. There's no reason to believe anyone (technical or not) that wasn't looking out for something suspicious would have possibly avoided the attack.

Pretty nasty phishing attempt, way more subtle than past attacks.

Re: The closest I've ever come to falling for a Gmail phishing attack

#234
post #19

The only two things that I think could have prevented me from falling for this is: I don't have images loaded by default for unknown senders, and LastPass wouldn't match the domain and therefore wouldn't show the button to autocomplete on the password box. Depending on how observant I'd be at the moment, I might check the URL bar and see something fishy. But I could fall for this, which is worrying.

"I don't have images loaded by default for unknown senders" Does this just prevent the display of images which require fetching from a remote URL, or does it also include images which are embedded in the email as attachments?

An even more common way of making it load without causing the email to look like it has an attachment is to embed the image as a data: URI in an tag. Since it's not remote, it will be loaded, but since it's not an attachment, your email client won't show it in the attachments list.

Re: The closest I've ever come to falling for a Gmail phishing attack

#235
post #163

Earlier quoted context omitted.

It's a hard problem but the industry isn't doing as much as it could do. There's low hanging fruit that has gone unharvested for years at most big companies. 1. Reform the browser address bar. Safari does this right. Chrome, IMHO shamefully, does not. The address bar is completely ignored by a large fraction (I've read it's about 25%) of users because it's full of meaningless technobabble. These users navigate entire…

> 3. Kill re-authentications dead. Then I would forget my password, like I always forget my github password and have to reset it every leap year when i log out for some reason, but i guess that's a small price to pay.

Password Safe is a (Bruce Schneier recommended) alternative. Free, runs locally. I'm a big fan.

https://pwsafe.org/

Re: The closest I've ever come to falling for a Gmail phishing attack

#236

Almost fell for another clever one today: https://medium.com/@scardine/clever-phishing-scam-of-the-day...

What's the point of that one? Just hoping that the user selects the same security questions and/or password as their google account?

Re: The closest I've ever come to falling for a Gmail phishing attack

#237

Earlier quoted context omitted.

Depends on the type of 2FA. If it's using U2F, then you'd be fine as that is tied to the domain name of the site you're on, but if it's using TOTP/HOTP (i.e. Google Authenticator), and the phishing site asked you for your 2FA code, and you gave it, then you would still be successfully phished.

Is the difference here that TOTP/HOTP is entered by the user, while U2F is entered automatically?

Not entirely. The important difference is that instead of generating a secret on the token and passing it to the server, U2F has the token answer a challenge issued by the server and encrypted to the token's (per-domain) public key, stored by the server at token registration time.

The corresponding private key is stored on the token indexed in part by the requesting domain, which is supplied by the browser during an auth request. It is because of browser participation that a MITM domain would not be able to ask the token to answer the challenge with the correct key handle.

The actual implementation can differ from what's described above, see Yubico's description of their key wrapping scheme if you want more detail:

https://www.yubico.com/2014/11/yubicos-u2f-key-wrapping/

Re: The closest I've ever come to falling for a Gmail phishing attack

#238

Earlier quoted context omitted.

Wikipedia pages have the title at the top of the page. In practice, the sort of users who complain about such things are in my experience the sort who also have dozens of tabs open, which smushes the title down to just a few characters. Heck even when there's space in the tab bar Chrome won't allocate more than a few cm of space on screen to showing the title. HTML titles are pretty much a dying thing anyway, so give…

On mobile, scrolling to the top of a Wikipedia page can be 20 screens or more. After that it's a lot of working going back to where you were. Many news sites are similar.

You could just pop open the tab view, so you can see the page title.

Re: The closest I've ever come to falling for a Gmail phishing attack

#239

Sysadmin at a school: we use GMail for our students and faculty, and we got hit by this hard right before the holiday break. Three employees and a handful of students all got hit by the attack within a two hour period. It's the most sophisticated attack I've seen. The attackers log in to your account immediately once they get the credentials, and they use one of your actual attachments, along with one of your actual…

Requiring 2-factor auth would prevent this from being exploitable, right? Probably impossible in a school environment but in an enterprise situation, more palatable perhaps.

2FA would make it harder to exploit, but phishing attacks are getting fancier. They capture the 2FA code you enter and immediately start a session elsewhere with your password and 2FA. Hardware 2FA, a security key, (such as a Yubikey) is the only likely way to prevent phishing (excluding targets of state actors) https://support.google.com/accounts/answer/6103523?hl=en

Re: The closest I've ever come to falling for a Gmail phishing attack

#240
post #225

Earlier quoted context omitted.

U2F would prevent this from being exploitable, but one-time password schemes like TOTP would not.

Why would TOTP not suffice to prevent this exploit ?

They can use the TOTP token to auth themselves where as U2F will not work if you are the middle-man.

U2F basically[0] signs the current URI and HTTPS key and sends it back. If there is a man-in-middle then the signatures will not match and the auth will fail.

[0]: https://developers.yubico.com/U2F/Protocol_details/Overview....

Post reply on HN