Making unphishable 2FA phishable • Hacker News Board

Re: Making unphishable 2FA phishable

#31

Post by stavros » Thu, Dec 01, 2022, 10:13 AM UTC

I don't quite understand the flow here, can someone explain?

It seems to me that you're on evilsite.com and you get a screen to authorize your AWS account, which evilsite.com then gets and can log in to your AWS account. In that case, however, I'm aware that I'm browsing evilsite.com, so what's the issue?

It's like evilsite.com requesting OAuth permissions to my Twitter account, no? We don't need the RFC for that, it's just what OAuth normally does, and you're supposed to be careful who you give permission to, no?

Re: Making unphishable 2FA phishable

#32

Post by mjg59 » Thu, Dec 01, 2022, 10:17 AM UTC

stavros wrote: post #31

I don't quite understand the flow here, can someone explain? It seems to me that you're on evilsite.com and you get a screen to authorize your AWS account, which evilsite.com then gets and can log in to your AWS account. In that case, however, I'm aware that I'm browsing evilsite.com, so what's the issue? It's like evilsite.com requesting OAuth permissions to my Twitter account, no? We don't need the RFC for that, it…

No. You're given a URL that redirects to your ID Provider, and you're not given any indication who you're granting permission to.

Re: Making unphishable 2FA phishable

#33

Post by stavros » Thu, Dec 01, 2022, 10:22 AM UTC

mjg59 wrote: post #32

stavros wrote: post #31

I don't quite understand the flow here, can someone explain? It seems to me that you're on evilsite.com and you get a screen to authorize your AWS account, which evilsite.com then gets and can log in to your AWS account. In that case, however, I'm aware that I'm browsing evilsite.com, so what's the issue? It's like evilsite.com requesting OAuth permissions to my Twitter account, no? We don't need the RFC for that, it…

No. You're given a URL that redirects to your ID Provider, and you're not given any indication who you're granting permission to.

Right, but who gives me the URL? I don't tend to authenticate random URLs I find lying around.

Re: Making unphishable 2FA phishable

#34

Post by pimterry » Thu, Dec 01, 2022, 11:31 AM UTC

stavros wrote: post #33

mjg59 wrote: post #32

Earlier quoted context omitted.

No. You're given a URL that redirects to your ID Provider, and you're not given any indication who you're granting permission to.

Right, but who gives me the URL? I don't tend to authenticate random URLs I find lying around.

You could receive a spearphishing email from an AWS lookalike address, which includes a link to the real AWS login page, which you auth to legitimately but which then sends your credentials to somebody else.

This has a link expiry problem, as described in the article, but you can do similar things with e.g. a background tab that swaps itself out, starting the flow on demand when you go back to the tab.

That might catch quite a few people: a web page, which after X minutes in the background changes its favicon to AWS, and then next time you open it it immediately starts a device code flow and redirects to the real AWS login page. Looks just like you've gone back to an AWS tab that's just been logged out, and it's the real bone fide login so you can't tell the difference unless you remember where the tab came from. I imagine if you're working in AWS all day, it wouldn't be so unusual, and you'd just log in again.

Re: Making unphishable 2FA phishable

#35

Post by minitoar » Thu, Dec 01, 2022, 1:24 PM UTC

chupasaurus wrote: post #27

minitoar wrote: post #6

Earlier quoted context omitted.

ssh -D ftw

AllowTcpForwarding no ftl

eh if you have shell access anyway this is easy to circumvent.

Re: Making unphishable 2FA phishable

#36

Post by stavros » Thu, Dec 01, 2022, 1:37 PM UTC

pimterry wrote: post #34

stavros wrote: post #33

Earlier quoted context omitted.

Right, but who gives me the URL? I don't tend to authenticate random URLs I find lying around.

You could receive a spearphishing email from an AWS lookalike address, which includes a link to the real AWS login page, which you auth to legitimately but which then sends your credentials to somebody else. This has a link expiry problem, as described in the article, but you can do similar things with e.g. a background tab that swaps itself out, starting the flow on demand when you go back to the tab. That might cat…

Couldn't they do exactly the same thing with OAuth? I don't understand what the increased risk here is.

Re: Making unphishable 2FA phishable

#37

Post by arianvanp » Thu, Dec 01, 2022, 2:19 PM UTC

https://datatracker.ietf.org/doc/draft-kasselman-cross-devic... explains this attack vector in great detail and suggests some mitigationz.

Their most interesting suggestion is to use the Hybrid transport of CTAP2.2 (not published yet) to perform cross device authorization in a secure way.

This involved proving proximity over Bluetooth Low Energy and a key exchange. Then the Webauthn flow happens over an encrypted channel through a TURN server.

Problem is that your cli tool now needs access to BLE. We're not there yet.

Re: Making unphishable 2FA phishable

#38

Post by dinosaurdynasty » Thu, Dec 01, 2022, 2:59 PM UTC

seanhunter wrote: post #20

dinosaurdynasty wrote: post #8

Earlier quoted context omitted.

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

As long as noone compromised their clipboard using malware etc. Which is a vector that seems quite common in spearphishing at least anecdotally.

Wouldn't they already be pwned in that case?

Re: Making unphishable 2FA phishable

#39

Post by dinosaurdynasty » Thu, Dec 01, 2022, 3:02 PM UTC

Thorrez wrote: post #23

dinosaurdynasty wrote: post #8

Earlier quoted context omitted.

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.

The token could be made only usable by the cli process that asked for it (should be really).

Re: Making unphishable 2FA phishable

#40

Post by infotogivenm » Thu, Dec 01, 2022, 3:32 PM UTC

stavros wrote: post #36

pimterry wrote: post #34

Earlier quoted context omitted.

You could receive a spearphishing email from an AWS lookalike address, which includes a link to the real AWS login page, which you auth to legitimately but which then sends your credentials to somebody else. This has a link expiry problem, as described in the article, but you can do similar things with e.g. a background tab that swaps itself out, starting the flow on demand when you go back to the tab. That might cat…

Couldn't they do exactly the same thing with OAuth? I don't understand what the increased risk here is.

Normally iirc oauth will just transport the token in a browser redirect to the allowed domain that linked to the login page. evil.com will not be allowed, or if it is the token will end up scoped to evil.com.