- From: micolous via GitHub <sysbot+gh@w3.org>
- Date: Tue, 26 Sep 2023 01:07:05 +0000
- To: public-webauthn@w3.org
> Now it is clear that the webauthn.dll driver in windows already knows which application is making the webauthn call. This is not _always_ true. The Windows Webauthn API _also_ works over RDP[^1] – so when you connect to a terminal server (or other RDP host), it can [tunnel the Webauthn API calls over a RDP virtual channel][0]. When this happens, Windows' Webauthn consent prompts are still presented on the client, because this has the USB, smartcard and/or BLE interface(s) physically adjacent to the user's authenticator, and [Windows still restricts direct hardware interface with authenticators][2]. Because the _client_ has no way to know/trust which binary on the server called the Webauthn API (it could be a malicious RDP server), it instead the consent dialog shows the properties of `mstsc.exe`, which is signed by Microsoft. `webauthn.dll` exposes this functionality to `mstsc` via [the `IWTSPlugin` COM interface][3]; which other Windows applications (ie: remote desktop clients) could _also_ use. If an attacker has a way to convince a signed application to call the Webauthn API on its behalf (such as connecting to a malicious RDP server), then the consent UI will show requests as being "from" legitimate applications. In your screenshot, you made a request from Python: and _every_ Python application/script would be presented as being made by a binary signed by the Python Software Foundation in the same way. > I would suggest passing the same onto the authenticator by adding it to the publicKeyCredentials object. The authenticator might reflect the same on the ClientDataJSON, whose hash is signed by the authenticator. Hence, in this way, the RP can know what application was used to perform the WebAuthn call. Then, the RP server can decide whether to allow the user or not. What you're proposing is similar to [Web Environment Integrity API][1]. This would have privacy implications, as this is browser fingerprinting. I don't understand how "knowing which application performed the request" prevents any sort of attack: on Windows, it's also possible for a program running as Administrator to directly communicate with authenticators on outside this API, and construct whatever Client Data JSON you like and have the authenticator sign it (by design). Running as a non-Administrator, you could also bring your own caBLE implementation, because Windows 11 only recently got platform support for that, and browsers still need to ship a caBLE implementation on Windows 10. Microsoft might start filtering the BLE advertisements on Windows 11 needed to make caBLE work in future, but again... Windows 11 only. These are all very Windows-specific things anyhow, and _only_ Windows locks down authenticator communication. But otherwise, that attack scenario isn't particularly new – Webauthn relies on the client's platform not being compromised to mitigate many security issues. [0]: https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-rdpewa/68f2df2e-7c40-4a93-9bb0-517e4283a991 [1]: https://en.wikipedia.org/wiki/Web_Environment_Integrity [2]: https://learn.microsoft.com/en-us/windows/security/identity-protection/hello-for-business/webauthn-apis#what-does-this-mean [3]: https://learn.microsoft.com/en-us/windows/win32/api/tsvirtualchannels/nn-tsvirtualchannels-iwtsplugin [^1]: This is only available in Microsoft's Remote Desktop Client on Windows 10 and later, connecting to systems with Windows 10 and later. It is not available in the macOS version of Microsoft's RDP client, and I'm not aware of any third-party clients implementing it. -- GitHub Notification of comment by micolous Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1965#issuecomment-1734678105 using your GitHub account -- Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config
Received on Tuesday, 26 September 2023 01:07:07 UTC