TOTP replay attack — Yubikey et al.

I have recently stumbled upon several articles with rather clickbait titles stating that some models of FIDO keys were compromised. If you are not aware, this was a successful attempt by Ninjalab engineers to clone the keys stored on NXP A700X, which is used as a component of popular U2F devices, such as the Yubico keys. Leaving the technical details aside, here are the preconditions for a successful attack:

• The attacker should know the victim’s primary authentication factor (username + password)
• The attacker should have access to the victim’s U2F key for an extended period (i.e. >5 hours)

As you can see, the preconditions are quite hard to meet, but if the media presents this as a serious vulnerability, this makes me think of a different attack type which does not use any of the published vulnerabilities, but exists for many years, can be easily exploited with the same preconditions and is very easy to perform.

I take Yubikey only as an example, but the same “vulnerability” applies to many other FIDO2 devices that have the possibility of using them as TOTP devices.

TOTP on YubiKeys

You can configure your YubiKey so that you can use two-factor authentication to sign in to any account that requires authenticator codes, i.e. classic HOTP and TOTP. Different from HOTP, where the counter is simply stored on the device itself and the generated OTP is simply sent via HID USB interface to the main system, TOTP requires the current time as its counter. Yubikey devices are passive and have no RTC chip nor a battery to power any system clock. However, it is still possible to use Yubikey as a TOTP token, but not as a standalone device.

“For TOTP you need an application that can read OATH codes from YubiKeys, since YubiKeys does not have an internal clock”

A requirement for this is a special app, Yubico Authenticator, that fills the gap: the app sends the timestamp information from the system it is installed on to the Yubikey, and reads back the OTP generated by its chip. So, the use case of Yubikey as a TOTP generator is different from standalone TOTP tokens — with TOTP tokens, users do not need any additional device or system to log in, with Yubikey this is to enhance security. A risk comparison is shown in the figure below:

Yubico Authenticator vs Google Authenticator

So, the main advantage of using Yubico Authenticator in combination with a physical Yubikey over a TOTP App, such as Google authenticator, is that the shared secret is stored on an external device, which is marketed as a more secure solution.

TOTP Replay attack

Remember the preconditions we listed for Ninjalab’s attack? Pasting it here again:

• The attacker should know the victim’s primary authentication factor (username + password)
• The attacker should have access to the victim’s U2F key for an extended period (i.e. >5 hours)

Now, finally to the vulnerability itself — here are the steps:

Example: Recorded results of YKOATH replay attack

• The attacker installs the Yubico Authenticator on a PC, and sets the time to the future, i.e. several weeks from now (for example, 3rd of March as shown on the example above) in the future and records the OTPs generated by the Yubikey stolen from the victim. This can be repeated for several hundreds/thousands of times as it can be easily automated using YKOATH Protocol and simple scripts (like this one, where the Clock argument of OATH struct can be replaced with a series of “future” timestamps )
• The attacker returns the Yubikey back to the victim, ideally without the victim even noticing it (this is much easier to implement than with Ninjalab’s attack where they have to physically open the case)

So, again, if the preconditions are met, the attacker gets access to the victim’s second factor and can exploit the vulnerability on the specific date and time (i.e. 3rd of March around 10:00 AM) by logging in using the previously generated OTPs. The second factor is hereby officially compromised.

Summary

This “vulnerability” exists since the first day the method was introduced and for some reason never researched nor mentioned. There are several articles about “replay attacks” with Yubikeys, but they are explaining the FIDO/FIDO2 components (U2F and WebAuthN) of the devices and not the TOTP subsystem, which is a completely different component implemented on the same hardware product. This attack uses the weakest link of not only the YKOATH implementation but any other devices without onboard real-time clock (including FIDO keys from Token2, the company I am involved with as a security consultant): the current time is sent by the host system which it has to blindly trust.

Trademarks, quoted texts, photos and other similar content used in this article are property of their respective owners, Google, NinjaLabs, Yubico etc.