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

Making unphishable 2FA phishable

mjg59.dreamwidth.org

Post reply on HN
Print view View original

21–30 of 56 posts

Re: Making unphishable 2FA phishable

#21

Post by GreyStache »

jadedtuna wrote: post #5
mdeeks wrote: post #4

The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. Unfortunately this doesn’t work for CLI to…

If SSH is already being used, can't one just create an SSH tunnel to forward the login?

Something akin to ssh agent-forwarding ("oauth-forwarding"?) is really needed. And it needs to be integrated similarly well like support for jumphosts.

Haven't seen anything like this, I'll try to bring this up with the openssh folks.

Re: Making unphishable 2FA phishable

#23

Post by Thorrez »

dinosaurdynasty wrote: post #8
mdeeks wrote: post #4

The infuriating thing is that this isn't necessary for CLI tooling. The reason this approach is taken is that you need a way to get the token to a local process even if the user is doing authentication in a browser. This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. Unfortunately this doesn’t work for CLI to…

I wonder if having the user copy-paste the token could work?

Copy and paste means a user can be phished. The user can copy and paste it to an attacker.

Re: Making unphishable 2FA phishable

#24

Post by cryptonector »

remram wrote: post #12
zacharyvoase wrote: post #10

It would be great if OAuth could include some form of cryptographic attestation—similar to what is already present in WebAuthn—to ensure that only trusted devices can get authorization tokens. In the case of CLI app authorization (where you are proving that the refresh + access tokens are being retrieved on the same device that issued the request), the CLI could generate a local key, store it in the TPM/keychain, and…

> For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). The attacker may well be using a MacBook Pro, a real one. With a TPM.

Yes, but the idea is that you'd enroll the device (and its TPM), and thence wouldn't be phishable like this. Granted, there might still be a problem at device enrollment time.

Re: Making unphishable 2FA phishable

#25

Post by hirsin »

zacharyvoase wrote: post #16
hirsin wrote: post #14

Earlier quoted context omitted.

This is what Intune and similar provide, but you need some existing, secure registry of devices before this works. Cross device webauthn is the better solution here but it's still vulnerable to the oauth phishing called out here.

WebAuthn uses such a directory already. Most implementations validate the attestation against a public database of ‘trusted’ device types (and DAA enables this to be done without compromising anonymity, up to the uniqueness of a device type)

That's not a trust statement, and it's not reliable as a proof. You can reliably tell you've seen this authenticator before, but that doesn't solve the problem being described here

Re: Making unphishable 2FA phishable

#26

Post by zxcvgm »

zacharyvoase wrote: post #10

It would be great if OAuth could include some form of cryptographic attestation—similar to what is already present in WebAuthn—to ensure that only trusted devices can get authorization tokens. In the case of CLI app authorization (where you are proving that the refresh + access tokens are being retrieved on the same device that issued the request), the CLI could generate a local key, store it in the TPM/keychain, and…

I guess this is what Heroku was pushing for [1] when client tokens were leaked. They wanted GitHub to adopt RFC 8075 [2], that combines mutual TLS auth with the tokens, so that the tokens can only be used by authorized clients, not just anyone that had possession of the tokens.

[1] https://blog.heroku.com/april-2022-incident-review

[2] https://datatracker.ietf.org/doc/html/rfc8705

Re: Making unphishable 2FA phishable

#28

Post by withinboredom »

What's worse is if you can get rudimentary access to the target. If you can force a deauth (usually by just DOSing the domain), you can force them through the flow again. But as the domain is DOSed, you can do authentication at the same time from a non-DOSed route. Thus they authenticate the attacker instead of themselves.

In my experience, tools don't see a difference between a 409/disconnect. They just see "error, need to reauth" (Docker, cough)

Re: Making unphishable 2FA phishable

#29

Post by dgoldstein0 »

GreyStache wrote: post #21
jadedtuna wrote: post #5

Earlier quoted context omitted.

If SSH is already being used, can't one just create an SSH tunnel to forward the login?

Something akin to ssh agent-forwarding ("oauth-forwarding"?) is really needed. And it needs to be integrated similarly well like support for jumphosts. Haven't seen anything like this, I'll try to bring this up with the openssh folks.

Possibly redirect to localhost: where the port is one forwarded over ssh could do the trick?

Re: Making unphishable 2FA phishable

#30

Post by quickthrower2 »

bobbylarrybobby wrote: post #17
kibwen wrote: post #11

> This can be avoided by having the process listen on localhost, and then have the login flow redirect to localhost (including the token) on successful completion. I'm confused, isn't having the device listen on localhost necessary for the device authorization grant flow? What's the alternative (that, apparently, people are doing but shouldn't be)?

My impression was that the device was repeatedly fetching site.com/auth/userid/session_id and waiting for a response with a token in it.

Yes, the RFC is quite readable and this is mentioned in the intro.

https://www.rfc-editor.org/rfc/rfc8628

Post reply on HN