CVE-2022-24584: Incorrect access control in Yubico OTP functionality of the Yu bi Key hardware tokens along with the Yubico OTP validation server

https://boards.4channel.org/g/thread/86801252
https://i.4cdn.org/g/1651680877341.jpg
https://anonfiles.com/Tav0bddby7/CVE-2022-24584_pdf
https://cdn-130.anonfiles.com/Tav0bddby7/3602e604-1651679466/CVE-2022-24584.pdf
https://anonfiles.com/Ddk0d4d7y7/yubico_zip
https://cdn-104.anonfiles.com/Ddk0d4d7y7/9f80ed64-1651685867/yubico.zip

All links are included in the Internet Archive/Wayback Machine
Screenshots for Proof of Vulnerability are included as attachments in the PDF.

Hello,

I am writing to you to report a security vulnerability in the Yubico OTP Validation Server. I assess the
severity NOT to be High, mostly because Yubico OTP isn't as widely used as the alternatives, such as U2f,
FIDO etc., but regardless I believe it must be published and an advisory issued.

The product claims made on the product page state that the Yubico OTPs are hardware bound and
unclonable. This might be correct AFTER the configuration has been written to the device. But, someone
could make a duplicate device using the same configuration. After reprogramming, the new
configuration will have to be uploaded to the Yubico servers. I have shown that the server will accept
any uploaded configuration and, even though the upload form asks for the serial number, it is not
utilized to make sure that the configuration is actually bound to a particular device.

The conclusion is that only OTPs starting with "cc" are hardware bound, since they are programmed at
the factory. In the case where the customer wants to program custom secrets, the new configuration
uploaded to the Yubico server (OTPs starting with "vv") are not hardware bound and the serial number
isn't checked.

I have already applied for a CVE ID (CVE-2022-24584) but haven't otherwise publicized these findings
and I leave it to you.

Thank you,
[REDACTED]