CVE-2022-24584: CVE-2022-24584: Incorrect access control in Yubico OTP functionality of the Yu b - Pastebin.com

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.

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]