6 ms·

Making unphishable 2FA phishable

194 points by tony101 4y ago

pgn674 4y ago
> "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 think this is what the AWS Client VPN client for Ubuntu does. So AWS does have the method in their tool set somewhere, though I imagine it's owned by an entirely different team than their CLI.
_8j50 4y ago
This attack like OP says is not new. For a corporate environment you simply prevent all users except one or two admins/approvers from allowing 3rd party authorizations. For consumers, my suggestion is for federation providers (auth0,github, google,etc...) review and human-approve applications that ask users authorizations.
mdeeks 4y ago
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 tools on a remote machine (like say for vscode remote over ssh ). The browser redirect to localhost won’t work because the CLI tool isn’t on localhost.
- jadedtuna 4y ago
  If SSH is already being used, can't one just create an SSH tunnel to forward the login?
  - minitoar 4y ago
    ssh -D ftw
    - chupasaurus 4y ago
      AllowTcpForwarding no ftl
      - minitoar 4y ago
        eh if you have shell access anyway this is easy to circumvent.
        chupasaurus 4y ago
        "If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.
        minitoar 4y ago
        The thread we are in is talking specifically about using cli tools on a remote machine, so that’s why I mentioned it. If you have that you don’t need a hole in the firewall.
  - est 4y ago
    Some login requires Identity and access management (IAM) with a web interface only, if such gateway exists, a CLI tool would have to give user a link to open oneself I guess?
  - theamk 4y ago
    My SSH usage has multiple servers (staging, dev, etc..) and multiple clients (laptop, desktop). Some of those connections are going through jumphosts. Setting up SSH tunnel would be possible, but a major pain, as every source/dest combination will need to have its own port, and every signin should specify the port number. Compared to the current system, which prints a URL in terminal which I just need to click, it would be a major usability regression.
  - GreyStache 4y ago
    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.
    - dgoldstein0 4y ago
      Possibly redirect to localhost:<port> where the port is one forwarded over ssh could do the trick?
    - _flux 4y ago
      Curl can connect over unix domain sockets and ssh can forward them, I feel this would be a decent way to forward authentication as access control rules would apply to the sockets.
- dinosaurdynasty 4y ago
  I wonder if having the user copy-paste the token could work?
  - seanhunter 4y ago
    As long as noone compromised their clipboard using malware etc. Which is a vector that seems quite common in spearphishing at least anecdotally.
    - dinosaurdynasty 4y ago
      Wouldn't they already be pwned in that case?
      - seanhunter 4y ago
        Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into. That's the point of TFA - unphishable second factors and ways to make them phishable. I'm saying that using the clipboard would be a bad idea in this case.
        dinosaurdynasty 4y ago
        If the machine is pwned, it seems like it wouldn't be super hard to get the user to touch the yubikey.
  - Thorrez 4y ago
    Copy and paste means a user can be phished. The user can copy and paste it to an attacker.
    - dinosaurdynasty 4y ago
- tomjen3 4y ago
  Doesn't VSCode forward connections made in its terminal? I worked remote on some webstuff and I could use my local browser just fine.
zacharyvoase 4y ago
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 then in the browser you could prove that you have access to that same key. For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). Of course, this depends on services choosing to implement such flows, and when you introduce a requirement for a TPM or similar, plus multiple cryptographic steps, implementors are likely to get lazy and just do something that works but is insecure (or they implement the flows badly with home-rolled crypto).
- remram 4y ago
  > 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.
  - mjg59 4y ago
    I think the only MacBook Pros with real TPMs were the 1, and 2, series from 2006/2007. Right now Apple don't allow you to do device identity attestation with the secure element. But in the world where you take this approach you don't just tie issuance to "I have a hardware keystore", you tie it to "This hardware keystore has an identity that I know belongs to a computer I own"
    - remram 4y ago
      But the entire thread is about delegating the authentication, granting access to another machine or process. You want to give access to one device (e.g. TV) from the trusted one (e.g. iPhone). Both devices might be very pricey, real, up-to-date machines with TPM and keys and everything you want. The problem is that you can't tell whether the TV is the one TV that the iPhone's owner means to sign in.
kibwen 4y ago
> 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)?
- bobbylarrybobby 4y ago
  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.
  - mjg59 4y ago
    This is correct.
  - quickthrower2 4y ago
    Yes, the RFC is quite readable and this is mentioned in the intro. https://www.rfc-editor.org/rfc/rfc8628 https://www.rfc-editor.org/rfc/rfc8628
ValtteriL 4y ago
Well explained. A PoC video would make it even better.
deleted 4y ago
[deleted]
withinboredom 4y ago
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)
stavros 4y ago
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?
- mjg59 4y ago
  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.
  - stavros 4y ago
    Right, but who gives me the URL? I don't tend to authenticate random URLs I find lying around.
    - pimterry 4y ago
      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.
      - stavros 4y ago
arianvanp 4y ago
https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/ 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.
kerng 4y ago
Here an example with Microsoft login flow: https://embracethered.com/blog/posts/2022/device-code-phishing/ https://embracethered.com/blog/posts/2022/device-code-phishi...

194 points by tony101 4y ago

> "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 think this is what the AWS Client VPN client for Ubuntu does. So AWS does have the method in their tool set somewhere, though I imagine it's owned by an entirely different team than their CLI.

_8j50 4y ago

This attack like OP says is not new. For a corporate environment you simply prevent all users except one or two admins/approvers from allowing 3rd party authorizations. For consumers, my suggestion is for federation providers (auth0,github, google,etc...) review and human-approve applications that ask users authorizations.

mdeeks 4y ago

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 tools on a remote machine (like say for vscode remote over ssh ). The browser redirect to localhost won’t work because the CLI tool isn’t on localhost.

jadedtuna 4y ago
If SSH is already being used, can't one just create an SSH tunnel to forward the login?
- minitoar 4y ago
  ssh -D ftw
  - chupasaurus 4y ago
    AllowTcpForwarding no ftl
    - minitoar 4y ago
      eh if you have shell access anyway this is easy to circumvent.
      - chupasaurus 4y ago
        "If" is a good word. The setting above is usually being used in environments where network security is a bit paranoid, so shell access won't help against lack of a hole through the firewall somewhere in-between, unless there's a way to use avian carriers.
        minitoar 4y ago
        The thread we are in is talking specifically about using cli tools on a remote machine, so that’s why I mentioned it. If you have that you don’t need a hole in the firewall.
- est 4y ago
  Some login requires Identity and access management (IAM) with a web interface only, if such gateway exists, a CLI tool would have to give user a link to open oneself I guess?
- theamk 4y ago
  My SSH usage has multiple servers (staging, dev, etc..) and multiple clients (laptop, desktop). Some of those connections are going through jumphosts. Setting up SSH tunnel would be possible, but a major pain, as every source/dest combination will need to have its own port, and every signin should specify the port number. Compared to the current system, which prints a URL in terminal which I just need to click, it would be a major usability regression.
- GreyStache 4y ago
  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.
  - dgoldstein0 4y ago
    Possibly redirect to localhost:<port> where the port is one forwarded over ssh could do the trick?
  - _flux 4y ago
    Curl can connect over unix domain sockets and ssh can forward them, I feel this would be a decent way to forward authentication as access control rules would apply to the sockets.
dinosaurdynasty 4y ago
I wonder if having the user copy-paste the token could work?
- seanhunter 4y ago
  As long as noone compromised their clipboard using malware etc. Which is a vector that seems quite common in spearphishing at least anecdotally.
  - dinosaurdynasty 4y ago
    Wouldn't they already be pwned in that case?
    - seanhunter 4y ago
      Their machine would be pwned, but their 2nd factor would not be compromised if they used something like a yubikey, so the attacker couldn't use the compromised host to SSO to other systems and enlarge their compromise. That's why yubikey requires that you touch it - an attacker can't just remotely trigger it even if they totally own the host the yubikey is plugged into. That's the point of TFA - unphishable second factors and ways to make them phishable. I'm saying that using the clipboard would be a bad idea in this case.
      - dinosaurdynasty 4y ago
        If the machine is pwned, it seems like it wouldn't be super hard to get the user to touch the yubikey.
- Thorrez 4y ago
  Copy and paste means a user can be phished. The user can copy and paste it to an attacker.
  - dinosaurdynasty 4y ago
tomjen3 4y ago
Doesn't VSCode forward connections made in its terminal? I worked remote on some webstuff and I could use my local browser just fine.

zacharyvoase 4y ago

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 then in the browser you could prove that you have access to that same key. For devices, direct attestation could authenticate the device making the request (e.g. as a legitimate MacBook Pro, or something). Of course, this depends on services choosing to implement such flows, and when you introduce a requirement for a TPM or similar, plus multiple cryptographic steps, implementors are likely to get lazy and just do something that works but is insecure (or they implement the flows badly with home-rolled crypto).

remram 4y ago
> 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.
- mjg59 4y ago
  I think the only MacBook Pros with real TPMs were the 1, and 2, series from 2006/2007. Right now Apple don't allow you to do device identity attestation with the secure element. But in the world where you take this approach you don't just tie issuance to "I have a hardware keystore", you tie it to "This hardware keystore has an identity that I know belongs to a computer I own"
  - remram 4y ago
    But the entire thread is about delegating the authentication, granting access to another machine or process. You want to give access to one device (e.g. TV) from the trusted one (e.g. iPhone). Both devices might be very pricey, real, up-to-date machines with TPM and keys and everything you want. The problem is that you can't tell whether the TV is the one TV that the iPhone's owner means to sign in.

kibwen 4y ago

> 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)?

bobbylarrybobby 4y ago
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.
- mjg59 4y ago
  This is correct.
- quickthrower2 4y ago
  Yes, the RFC is quite readable and this is mentioned in the intro. https://www.rfc-editor.org/rfc/rfc8628 https://www.rfc-editor.org/rfc/rfc8628

ValtteriL 4y ago

Well explained. A PoC video would make it even better.

deleted 4y ago

[deleted]

withinboredom 4y ago

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)

stavros 4y ago

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?

mjg59 4y ago
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.
- stavros 4y ago
  Right, but who gives me the URL? I don't tend to authenticate random URLs I find lying around.
  - pimterry 4y ago
    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.
    - stavros 4y ago

arianvanp 4y ago

https://datatracker.ietf.org/doc/draft-kasselman-cross-device-security/ 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.

kerng 4y ago

Here an example with Microsoft login flow: https://embracethered.com/blog/posts/2022/device-code-phishing/ https://embracethered.com/blog/posts/2022/device-code-phishi...