This is a follow-up post to “Rolling your own crypto gone wrong: A look at a .NET Branca implementation”. In short, it went over several critical issues of a NuGet that offers authentication token formats, specifically Branca. The NuGet has since fixed the issues in its 1.3.0 release. The issues are tracked under CVE-2020-36255.
If you want to read the original issues on GitHub, describing the attack, you’ll have to find them on the Wayback Machine here, as they seem to have been deleted from the issue tracker after a CVE was assigned and before NVD finished analyzing it.
I criticized the library for not running tests with basic test vectors. This remains table stakes for implementing protocols used to process security credentials. Though, back then, Branca didn’t have an “official” set of test vectors, but rather a link to the tests used by the reference PHP and JavaScript implementations. In collaboration with Mika Tuupola (author of the Branca spec), I went ahead and finalized the test vectors. These include the existing ones of course, but also new ones for extended coverage. I’d like to thank Mika Tuupola for his patience and help working on this.
Further, the specification has been updated with a few small changes to define correct behavior a little more clearly: An expiration check must happen after the authenticity check (link) and that implementing libraries must have overflow checks for operations on TTL values (link).
Hopefully, this makes it easier to implement the Branca format correctly in the future.
Other libraries possibly affected
According to the author of the NuGet mentioned above, the version affected by CVE-2020-36255 was a port from a Java implementation.
Back then, I had a look at 1, 2, and 3 (this seems to have been deleted since then). These are the two Java and one Kotlin implementation. They all had the same patterns when attempting to implement Branca, but I haven’t verified (as in, executing a test with the code) if they’re actually affected. It does seem highly likely. I contacted the authors of all three over email about 5 months ago, but have not received any response.
Additional issues in other implementations
A security issue (CVE-2020-35918) was also fixed in the Rust implementation of Branca that could lead to unexpected panics when parsing tokens with invalid base62 encoding.
Another .NET implementation is also not in compliance with the specification, because it uses ChaCah20-Poly1305 and not the eXtended variant XChaCha20-Poly1305. This is also a security issue because it’s not safe to randomly generate 12 bytes nonces, as mentioned in the previous post.
It also doesn’t authenticate the header, which means the timestamp, or the version (which isn’t validated otherwise in this case), can be modified by an attacker. Another example where the inclusion of test vectors would have prevented security issues.
Found a mistake?
Please reach out.