Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

twitter.com

Post reply on HN
Print view View original

171–180 of 289 posts

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

#171

Post by sixothree »

frogfuzion wrote: post #2

I think its naive to believe that even the most tech savvy are immune to phishing. People get tired, hurried, stressed - and during those moments anyone's guard can be let down.

This describes my experience many years ago. I woke up early and groggily read my through my emails. One of which was an angry message from an ebay buyer about a package not having arrived on time. I clicked and logged in and got an error message. Examining the email it was certainly phishing. Changed password immediately.

I believe this may have been before ebay took phishing seriously by included your real name in the emails etc.

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

#172

Post by thomasahle »

mike_hearn wrote: post #155
thomasahle wrote: post #54

Earlier quoted context omitted.

> 1. Reform the browser address bar. Safari does this right. Chrome, IMHO shamefully, does not. ... The address bar should show the domain name only, or the EV identity when that's present, Chrome on Android does this. And it's extremely annoying. Since mobile browsers (and desktop browsers with tabs) usually don't show the title of pages, the address bar is the only place to tell e.g. what Wikipedia page you're curr…

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.

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

#173

Post by fsavard »

dschep wrote: post #144
timruffles wrote: post #32

I reported this a back in March 2016, and Google said it was not an issue. Analysed whole attack here: https://gist.github.com/timruffles/5c76d2b61c88188e77f6 This was the response I got: > The address bar remains one of the few trusted UI components of the browsers and is the only one that can be relied upon as to what origin are the users currently visiting. If the users pay no attention to the address bar, phishin…

A minor change that would help (a little) is to replace all spaces in the address bar with %20.

Or some clearly visible icon at the end of the URL bar saying "2832 more characters ->".

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

#174

Post by Dangeranger »

chinathrow wrote: post #152
Dangeranger wrote: post #140

Use 2-Factor Auth. If you are a sysadmin make it required. Block image downloads by default. Turn on log in notifications for unknown devices. If you are a sysadmin in a controlled network and serve content via proxy block bit.ly. This is a clever and dangerous attack, but can still be avoided by following the above.

The 2FA token is valid for up to 1 minute and the attacker could easily ask for it as well... There were no image downloads, it was embedded within the message itself.

Ok that's valid. Other than blocking bit.ly and other commercial link sharing services this seems to be a human hacking problem. It's hard to get people to be careful about checking the URL on a login page.

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

#175

Post by voidlogic »

jonoberheide wrote: post #160
Jarwain wrote: post #73

Earlier quoted context omitted.

My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used…

Sorry to hear about your experience, Jarwain! Duo offers a choice of authentication methods, depending on the usability and security requirements of your application or organization. Duo Push is actually one of the easiest (and most secure) authentication methods, as one of the commenters pointed out: https://www.youtube.com/watch?v=tPLxe9HUDjY It might be worth pinging your IT/security dept to ask about enabling Duo…

Can Duo be used to Google Authenticator or do you have to use "Duo Push"?

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

#176

Post by pasta »

slazaro wrote: 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.

This is the reason why I convert all incoming to plain text. It saved me from trackers and fishers so many times.

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

#178

Post by kibwen »

Jarwain wrote: post #73
colinbartlett wrote: post #64

Earlier quoted context omitted.

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.

My school is actually rolling out optional 2-factor auth. I'm not a fan of the system they use^, but it's neat that a University is taking advantage of some security best practices. ^Instead of using "standard" 2-factor that generates a code on-the-fly within an app like GAuth or Authy, users receive a text message with 10 codes. The first digit of every code increases sequentially (0972,1042,2512,etc), must be used…

My university uses the same system as yours, and what's worse is that in order to install their custom 2FA app on Android you have to configure your phone to allow apps from unknown sources. So I have to choose between using SMS codes that can be intercepted or letting an entirely unvetted app run amok on my phone.

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

#179

Post by pavel_lishin »

laumars wrote: post #142
das_keyboard wrote: post #87

Earlier quoted context omitted.

Why don't just put a little frame around embedded elements like pictures, etc? Maybe with a little icon indicating the type.

That would break more legitimate HTML e-mails than the phishing it's aiming to catch. You might argue that it's worth the breakage but that would be a harder argument to sell to businesses. Pragmatically I think Browsers disabling the rendering of data:text/html is a better approach. The breakage is minimal and it would catch more phishing attacks than just ones that originated from emails with images embedded.

According to our numbers, plain emails actually perform better than HTML emails when it comes to business mailings.

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

#180

Post by soundwave106 »

Jarwain wrote: post #112
contravariant wrote: post #109

Earlier quoted context omitted.

>I can't even imagine what legitimate use there is to placing an entire HTML document into the URL. Just seems like a hack someone came up with as a solution to a problem, not the right solution, but a solution nonetheless. It allows you to embed data in an URL, meaning you can link to documents that aren't necessarily stored anywhere, such as generated images/text. I suppose you could make an argument that it should…

Why even render the content of data:text/html in the first place?

To give an example, I've seen some multiplayer games with dynamic content, that use Websockets for communication with the server and update various information via data URIs. I've never seen a text/html data URI yet (mostly image transmission to be honest) but for a multi-client Websockets type application I definitely wouldn't rule out that sort of thing.

I agree that blocking the rendering of data:text/html (and any other MIME type that could be used maliciously) from the address bar is a good idea. I can't think of a valid use case for that scenario. It seems like similar attack vectors have been known for some time (https://nakedsecurity.sophos.com/2012/08/31/phishing-without...).

Post reply on HN