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

We Got Phished

exploratorium.edu

Post reply on HN
Print view View original

151–156 of 156 posts

Re: We Got Phished

#151

Post by acdha »

oarsinsync wrote: post #148
acdha wrote: post #131

Earlier quoted context omitted.

Your browser connects to Google and tells the U2F token to auth using the www.google.com key: works Your browser connects to www.google.com@phish.me but no matter whether you believe that site to be Google, the U2F process means that it can only use a key for phish.me, which won't work on the Google.com servers even if they relay it. The only attack which still works is if they control DNS and can forge an SSL certif…

> The only attack which still works is if they control DNS and can forge an SSL certificate Or if they're able to get some malware onto your system permitting them to change your dns servers or alter your hosts file, and add certificates to your OS/browser trust store.

Both of those fall into “control of DNS” or “forging an SSL certificate”. Besides, if they can do either of those things they don't need to phish you because they can just hijaack your existing browser when you login to the real site.

Re: We Got Phished

#152

Post by Kadin »

oarsinsync wrote: post #148
acdha wrote: post #131

Earlier quoted context omitted.

Your browser connects to Google and tells the U2F token to auth using the www.google.com key: works Your browser connects to www.google.com@phish.me but no matter whether you believe that site to be Google, the U2F process means that it can only use a key for phish.me, which won't work on the Google.com servers even if they relay it. The only attack which still works is if they control DNS and can forge an SSL certif…

> The only attack which still works is if they control DNS and can forge an SSL certificate Or if they're able to get some malware onto your system permitting them to change your dns servers or alter your hosts file, and add certificates to your OS/browser trust store.

Sure, but that's raising the bar a hell of a lot higher than where it is currently, where all you need is a HTML email message that happens to superficially resemble something a random person might expect Google to send.

And in the long run I have more faith in making systems more secure via technological means than to try and convince users not to click on links in shady email messages. So by moving the problem into the technology domain and out of the social domain, I'd say it's a big win.

Re: We Got Phished

#153

Post by emodendroket »

lucb1e wrote: post #150
emodendroket wrote: post #121

Earlier quoted context omitted.

Unless you connect from a different IP every time, Google can recognize your computer.

Well there's NAT and dynamic addresses.

Yes, and I suppose you change your IP so frequently that you never visit the same page from the same IP twice.

Re: We Got Phished

#154

Post by andrewla »

jjnoakes wrote: post #135
andrewla wrote: post #98

Earlier quoted context omitted.

Adding 2fa does not completely close the exploit window, but it does reduce it considerably. Even if the phishing page prompted for 2fa, those credentials would only be valid for the next ~60-120 seconds, so any attack would have to be staged very quickly. In this example, they waited three days before trying to utilize the broken account; with 2fa they would not have that luxury. And this (asking for 2fa in the phis…

Why couldn't the attacker page pass on the 2fa token immediately to Google and log in as the victim? Then the attacker would have a month or so, not 30 seconds, with which to abuse their account

That's why I said that it narrowed the exploit and what I meant by "[staging] very quickly". It's a more narrow window, and the other objections (like prompting non-2fa users for 2fa) still apply.

If a human has to be involved on the attacker side, then this gets tricky, since they only have a short window where the 2fa is valid. If an automated process is trying to log on, then it is possible that CAPTCHAs would either prevent getting a full interactive session (i.e. just a "read email" level of access, as for an app) or block the attack entirely.

Re: We Got Phished

#155

Post by jjnoakes »

andrewla wrote: post #154
jjnoakes wrote: post #135

Earlier quoted context omitted.

Why couldn't the attacker page pass on the 2fa token immediately to Google and log in as the victim? Then the attacker would have a month or so, not 30 seconds, with which to abuse their account

That's why I said that it narrowed the exploit and what I meant by "[staging] very quickly". It's a more narrow window, and the other objections (like prompting non-2fa users for 2fa) still apply. If a human has to be involved on the attacker side, then this gets tricky, since they only have a short window where the 2fa is valid. If an automated process is trying to log on, then it is possible that CAPTCHAs would eit…

If you are a MITM you don't have to prompt non-2fa users for 2fa. You just replay their credentials, live, on the real site, and if the real site is asking you for 2fa, then you ask the real user for their 2fa.

Re: We Got Phished

#156

Post by fredericmartin »

closeparen wrote: post #104
laurencei wrote: post #97

Earlier quoted context omitted.

Does 2 factor prevent phishing though? If I was going to do a Google Phishing page - I would take the username + password that the user supplied into MY fake page, and POST/CURL that to the Google login. If Google returns asking for a 2factor to MY fake, I would display the 2 factor prompt to the user, and get them to type the 2-factor into my page, which I would pass back to Google. Basically you can use a phishing…

Under FIDO U2F, the token and website authenticate each other. You're right, though, TOTP is not enough.

To be clear, there is no real mutual authentication between the server and the token. The server can authenticate tokens (after first registrations) but not the other way. (You have to get outside FIDO U2F specifications if you want to do so.) With standard FIDO U2F USB tokens, the server authentication is done through SSL on the client application level (most of the time : a web browser).
Post reply on HN