2024.12.0 security issues
Hello everyone!
A few months ago, Lachlan Davidson from Carapace, made us aware of two security issues impacting CryptPad 2024.12.0 source code:
Both issues were fixed in version 2025.3.0 (now superseded by 2025.3.1). In this article we will share his findings, we will also explain the impact of such issues in CryptPad and how we fixed them.
Dom-Based Cross-Site Scripting (XSS) Vector
Cross-Site Scripting is a family of security vulnerabilities that allow the execution of remote code, allowing in some cases bypassing access control and policies. This may open a breach to the website and exfiltrate data without the user consent.
In our case, the XSS happens in a sand-boxed domain, thus not having access to the actual data storage of CryptPad and is prevented by our strong content-security policies (CSP). In the eventuality of an attacker bypassing our CSP rules, they still cannot access the decrypted data from CryptPad. However, it may allow attackers to execute code on your browser. This is part of our security measures against XSS attacks. More details about this can be found in our documentation.
The security vulnerability stemmed from our code, where the sanitization happened too little too late in some cases. This happens in some early allow in the code in the case of same domain links:
↳ See impacted source code here.
However, a maliciously crafted URI, such as javascript://main.cryptpad.internal/%250dalert(document.domain), will appear to have the same host name value as the instance's (in this case, main.cryptpad.internal), and follow this early allow.
As described in the security report, this has minimal impact, as it only give access to the sandbox domain and the default content security policy is quite strong. However it may create an entry point for further attacks down the road and had to be addressed.
To fix this, we moved the validation of same-domain redirection after XSS-sanitization.
2FA Bypass
Multifactor authentication is an important security feature for CryptPad. It protects users against their username/password leaking by providing a temporal factor into logging in.
In our case, the issue was from the way we were handling the 2FA detection. Indeed, 2FA is enforced by the server, and we cannot have it done on the client side as the server holds the TOTP secret. However, there was a case where it was possible to submit a valid authentication request that needs 2FA without having the server to trigger the 2FA validation. This loophole was fixed in 2025.3.0.
This detection issue takes root in the following code block:
↳ See impacted source code here.
For context, when you log in to CryptPad, your credentials are used to derive several cryptographic keys. Your browser then requests a file from the server, known as the “block”. The block is identified by one of your Base64-encoded public keys, and only you can decrypt it. We implement 2FA verification by requiring that you complete a 2FA challenge before the server lets you access your block.
It would completely skip the 2FA verification if the block length was different from 44 (which would normally won’t be valid and the rest of the code was supposed to fail). However, replacing the base64 padding symbol (=) with its URL-encoded equivalent (%3d) would lead to a valid block file name, but because it is longer than 44 characters, it would bypass the 2FA verification. This allows an attacker to log in knowing only the username and password.
We fixed that by raising an error whenever there is a request with invalid length.
Note that to mount such an attack, the username and password of the targeted user still needs to be compromised. However, it totally rendered moot the extra protection that 2FA was supposed to provide.
This is also a good reminder that having 2FA enabled does not mean that you can skip refreshing your passphrases regularly. If you are reading this blog post, we may assume that you are interested in security. Now would be as good as a time as any to regenerate your passphrases.
Cover photo by Cedric Fox on Unsplash.
Links