Token Phishing attack

[101Coder101]

The attack illustrated in the below message sequence chart shows the beginning of a normal flow between a victim and the credential issuer. During this flow, the adversary only becomes active when the authorization server, responsible for issuing access tokens, sends a response to the wallet with their token. This message cannot be read by the adversary but is stored for future reuse. The message is also blocked from reaching the wallet.

If the wallet initiates a second flow with the adversary holding such a token, for example, through phishing, the adversary can send back metadata containing the legitimate authorization server URL. When the wallet sends a token request to the same authorization endpoint as previously, given that it uses the same HTTPS session, the previously captured response from the prior flow can be forwarded to the wallet. The wallet accepts this response, since it indeed came from the endpoint it expected it from. The next step in the protocol flow is the credential request, which contains all the necessary information to request a credential. This request is sent to the adversary in this malicious flow. The adversary can use this information to send a request to the credential issuer and receive the credential meant for the victim.

This attack assumes that

• the TLS session used for the two token requests to the legitimate credential issuers (one in the legitimate and one in the malicious flow) use the same TLS session, and that
• TLS gives no protections other than a secure channel.

These assumptions are in place such that the protocol does not rely on other protocols to achieve security properties it is assumed to hold itself.

If the credential is not revoked despite the wallet's failure to retrieve the credential, the adversary can misuse the credential. Real-world examples include authentication for financial transactions or unauthorized access to restricted areas. This type of attack is considered to have potential for grave consequences.

Mitigations

In the attack, the adversary only learns the token for the credential on the wallet's credential request in a malicious flow. This holds since he cannot decrypt messages sent over the HTTPS channel between the wallet and the legitimate credential issuer. If, as a sanity check, the token response includes the credential endpoint at which the credential issuer awaits a credential request, then the victim's wallet can learn if the current communication flow is being tampered with and can reject sending the acquired token. The credential endpoint is also sent to wallets in the metadata request and is thus public information. These values must match.

Furthermore, this mitigation also requires the responses from the token endpoint and credential endpoint to be signed. This ensures that wallets are indeed communicating with the credential issuer they believe to be communicating with. The current specification only notes that the credential issuer must sign the metadata request. This measure ensures that adversaries cannot claim they own a domain or endpoint while only forwarding the responses or contents from the true owner (being the legitimate credential issuer).

These measures have been shown with the Tamarin prover to mitigate the risk of credential phishing attacks, drastically reducing the potential attack vectors of the OID4VCI protocol.

[Sakurann]

i think this attack is prevented using sender-constraint access tokens, which would prevent attacker being able to replay access token issued to the victim at the legitimate credential endpoint.

and on The wallet accepts this response, since it indeed came from the endpoint it expected it from.: Usually, there is state parameter that prevents mix matching request-response like this

[GarethCOliver]

Agree with @Sakurann, dpop will prevent this, as the Wallet will use different dpop keys for the first token request and the second one (so mixing the tokens will be detectable).

Worth noting that response encryption + message signing would also prevent an attack even if the attacker intercepted a credential request with a signed token, but I don't think as described that would be necessary to prevent this.