You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The decrypt routine is used to decrypt the X-Zoom-App-Context header. The decrypted value contains important information for the application, such as the user's ID and action, which the application will act upon.
Unfortunately, the decryption process is insecure, as the Node crypto API does not enforce an expected length of the authentication tag (docs, a blog post I wrote about this issue), which allows the verification of the GCM authentication tag, even if it has been truncated to 32bits (as opposed to the desired 128bit). The unpack routine does allow an attacker to supply such a shortened authentication tag, leading to a tag value being checked that is in brute-force range (2^32).
For a minimal PoC of the behaviour of the Node crypto module, consider
Since GCM is built on the Counter mode, any bit flip to the ciphertext flips the corresponding bit in the plaintext. As such, an attacker with a valid token for user with ID 123 can forge a ciphertext that matches a user with ID 456. Then they can brute-force the authentication tag and create events that seem to originate from Zoom, which pertain to a different user.
According to the Zoom documentation applications are invited to store OAuth tokens for users to act on their behalf:
Optionally, you may store it in a database or cache for later use if your app will be making requests to Zoom Restful APIs on behalf of the user.
As such, if an application uses the X-Zoom-App-Context header to fetch the corresponding OAuth token and act on behalf of the user, the above allows an attacker to impersonate their victim toward the Zoom application and via the OAuth token stored by the application even toward Zoom.
Any application that uses the implementation of this repository or the offical documentation's example is vulnerable, with the impact depending on what the application does.
Fixing the vulnerability
The fix would be to explicitly specify the expected auth tag length using the options field of the Decipher class here
With {authTagLength: 16} specified, the Decipher object will reject authentication tags of shorter-than-expected lengths
TypeError: Invalid authentication tag length: 4
at Decipheriv.setAuthTag (node:internal/crypto/cipher:220:22)
...
at node:internal/main/run_main_module:28:49 {
code: 'ERR_CRYPTO_INVALID_AUTH_TAG'
}
A note on disclosure
I tried to disclose this issue to Zoom in a coordinated disclosure process. However, the issue was closed as "this submission relies on the fact that other users/customers build a vulnerable application making it, therefore, exploitable".
I hope raising this issue here prevents someone from implementing an insecure solution or makes Zoom reconsider their stance on fixing this (in all their reference implementation and their documentation).
The text was updated successfully, but these errors were encountered:
The decrypt routine is used to decrypt the X-Zoom-App-Context header. The decrypted value contains important information for the application, such as the user's ID and action, which the application will act upon.
Unfortunately, the decryption process is insecure, as the Node crypto API does not enforce an expected length of the authentication tag (docs, a blog post I wrote about this issue), which allows the verification of the GCM authentication tag, even if it has been truncated to 32bits (as opposed to the desired 128bit). The unpack routine does allow an attacker to supply such a shortened authentication tag, leading to a tag value being checked that is in brute-force range (2^32).
For a minimal PoC of the behaviour of the Node crypto module, consider
Since GCM is built on the Counter mode, any bit flip to the ciphertext flips the corresponding bit in the plaintext. As such, an attacker with a valid token for user with ID 123 can forge a ciphertext that matches a user with ID 456. Then they can brute-force the authentication tag and create events that seem to originate from Zoom, which pertain to a different user.
According to the Zoom documentation applications are invited to store OAuth tokens for users to act on their behalf:
As such, if an application uses the X-Zoom-App-Context header to fetch the corresponding OAuth token and act on behalf of the user, the above allows an attacker to impersonate their victim toward the Zoom application and via the OAuth token stored by the application even toward Zoom.
Any application that uses the implementation of this repository or the offical documentation's example is vulnerable, with the impact depending on what the application does.
Fixing the vulnerability
The fix would be to explicitly specify the expected auth tag length using the
options
field of the Decipher class hereWith
{authTagLength: 16}
specified, the Decipher object will reject authentication tags of shorter-than-expected lengthsA note on disclosure
I tried to disclose this issue to Zoom in a coordinated disclosure process. However, the issue was closed as "this submission relies on the fact that other users/customers build a vulnerable application making it, therefore, exploitable".
I hope raising this issue here prevents someone from implementing an insecure solution or makes Zoom reconsider their stance on fixing this (in all their reference implementation and their documentation).
The text was updated successfully, but these errors were encountered: