4 ms·

What prevents essentially the same attack from being done by making a (desktop / tablet or even wall-mounted-display) web page that shows a QR code that, when s

by amluto 2y ago

What prevents essentially the same attack from being done by making a (desktop / tablet or even wall-mounted-display) web page that shows a QR code that, when scanned by a victim device, triggers the authentication flow?

charcircuit 2y ago
The fix blocks fido links from anywhere, including QR code scans. https://chromium-review.googlesource.com/c/chromium/src/+/5906286 https://chromium-review.googlesource.com/c/chromium/src/+/59... Edit: QR code scans are actually allowed to open such links.
- amluto 2y ago
  Is there some handshake over BLE that allows a browser that speaks BLE and shows a QR code to trigger the FIDO flow but does not allow a QR code by itself to do so? If so, how? Remember, the attacker is presumed to control a BLE device in range of the victim’s authenticator.
  - charcircuit 2y ago
    I was mistaken. I'm not sure what would prevent a proxied QR code + proxied Bluetooth signal.
    - lxgr 2y ago
      Nothing, by definition. If an attacker can successfully proxy all channels designed to frustrate proxying attacks, it's game over, at least without a distance bounding protocol being used (and I don't think Bluetooth has one).
      - WorldMaker 2y ago
        Signal Power affects readable distance (signal to noise radius) and the specs for this do suggest the lowest power Bluetooth LTE packets for the shortest "personal area network" distance we can get for these FIDO requests. (It doesn't entirely solve it, you can be extremely unlucky with a radio bounce or a surprisingly quiet Bluetooth radio band at transmission time. Surprising because Bluetooth is somewhat intentionally in one of the noisiest radio bands we've allowed to be extremely noisy.)
        lxgr 2y ago
        GP mentioned Bluetooth proxying (i.e. using two devices forwarding protocol messages bidirectionally to create a "Bluetooth wormhole"), which doesn't have any obvious inherent distance bound in this protocol, as as far as I can tell.
        0x457 2y ago
        I guess it's possible to reduce radius where that attack is executable with signal level.
        lxgr 2y ago
        Unless there is an API to actively limit the broadcasting signal strength via BLE that authenticator implementations could leverage, I don't see how. And even then you'll quickly run into problems when the attacker's receiver has better antennas in better locations than e.g. the user's laptop.
rcxdude 2y ago
Indeed. That attack is a little more involved (requires having a BLE device in proximity and tricking the user into scanning a QR code outside of the normal browser flow), but it seems like the main issue is that there's no way for the authenticator to validate that the device that's actually being authenticated is the device that the user actually intends to authenticate.
- lxgr 2y ago
  The device being authenticated is the one that I scan the QR code off of, isn't it? The problem here seems to be that implementations don't check whether a QR code has, in fact, been legitimately scanned at all.
  - rcxdude 2y ago
    That's what the user intends, but there's no way for the authenticator to know whether the QR code it's scanning is actually from a webauth session on the device it's scanned it from, or simply proxied from another device: ultimately the QR code is just a bunch of pixels, and a web page can display arbitrary pixels. Basically, there would need to be some device-specific private key included in the QR code which the authenticator could check somehow, but that trust needs to be established first somehow One potential mitigation I could imagine is browsers actively trying to prevent FIDO QR codes from being rendered in web pages, but that's pretty difficult to stop This is, of course, something that an attentive user can likely detect, as the browser can prevent web pages from mimicking the QR code workflow exactly, but a) webauthn is supposed to prevent this from happening, as the 'line of death' has proven to be a poor barrier, and b) there's no good way for the authenticator scanning the QR code to identify this line of death reliably. https://textslashplain.com/2017/01/14/the-line-of-death/ https://textslashplain.com/2017/01/14/the-line-of-death/ (And, of course, the designers of this interface knew this could be an issue, which is why BLE is involved at all: so that this kind of attack can't just be done entirely remotely. But BLE is a bad way of identifying a particular device compared to, say, plugging in a USB port. Especially also imagine compromised IoT devices...)
    - 2y ago

by amluto 2y ago

charcircuit 2y ago

The fix blocks fido links from anywhere, including QR code scans. https://chromium-review.googlesource.com/c/chromium/src/+/5906286 https://chromium-review.googlesource.com/c/chromium/src/+/59... Edit: QR code scans are actually allowed to open such links.

amluto 2y ago
Is there some handshake over BLE that allows a browser that speaks BLE and shows a QR code to trigger the FIDO flow but does not allow a QR code by itself to do so? If so, how? Remember, the attacker is presumed to control a BLE device in range of the victim’s authenticator.
- charcircuit 2y ago
  I was mistaken. I'm not sure what would prevent a proxied QR code + proxied Bluetooth signal.
  - lxgr 2y ago
    Nothing, by definition. If an attacker can successfully proxy all channels designed to frustrate proxying attacks, it's game over, at least without a distance bounding protocol being used (and I don't think Bluetooth has one).
    - WorldMaker 2y ago
      Signal Power affects readable distance (signal to noise radius) and the specs for this do suggest the lowest power Bluetooth LTE packets for the shortest "personal area network" distance we can get for these FIDO requests. (It doesn't entirely solve it, you can be extremely unlucky with a radio bounce or a surprisingly quiet Bluetooth radio band at transmission time. Surprising because Bluetooth is somewhat intentionally in one of the noisiest radio bands we've allowed to be extremely noisy.)
      - lxgr 2y ago
        GP mentioned Bluetooth proxying (i.e. using two devices forwarding protocol messages bidirectionally to create a "Bluetooth wormhole"), which doesn't have any obvious inherent distance bound in this protocol, as as far as I can tell.
        0x457 2y ago
        I guess it's possible to reduce radius where that attack is executable with signal level.
        lxgr 2y ago
        Unless there is an API to actively limit the broadcasting signal strength via BLE that authenticator implementations could leverage, I don't see how. And even then you'll quickly run into problems when the attacker's receiver has better antennas in better locations than e.g. the user's laptop.

rcxdude 2y ago

Indeed. That attack is a little more involved (requires having a BLE device in proximity and tricking the user into scanning a QR code outside of the normal browser flow), but it seems like the main issue is that there's no way for the authenticator to validate that the device that's actually being authenticated is the device that the user actually intends to authenticate.

lxgr 2y ago
The device being authenticated is the one that I scan the QR code off of, isn't it? The problem here seems to be that implementations don't check whether a QR code has, in fact, been legitimately scanned at all.
- rcxdude 2y ago
  That's what the user intends, but there's no way for the authenticator to know whether the QR code it's scanning is actually from a webauth session on the device it's scanned it from, or simply proxied from another device: ultimately the QR code is just a bunch of pixels, and a web page can display arbitrary pixels. Basically, there would need to be some device-specific private key included in the QR code which the authenticator could check somehow, but that trust needs to be established first somehow One potential mitigation I could imagine is browsers actively trying to prevent FIDO QR codes from being rendered in web pages, but that's pretty difficult to stop This is, of course, something that an attentive user can likely detect, as the browser can prevent web pages from mimicking the QR code workflow exactly, but a) webauthn is supposed to prevent this from happening, as the 'line of death' has proven to be a poor barrier, and b) there's no good way for the authenticator scanning the QR code to identify this line of death reliably. https://textslashplain.com/2017/01/14/the-line-of-death/ https://textslashplain.com/2017/01/14/the-line-of-death/ (And, of course, the designers of this interface knew this could be an issue, which is why BLE is involved at all: so that this kind of attack can't just be done entirely remotely. But BLE is a bad way of identifying a particular device compared to, say, plugging in a USB port. Especially also imagine compromised IoT devices...)
  - 2y ago