Lately I've been inspecting a key generator program in IDA Pro. I believe the thread here discusses a similar key generator. Therefore, it may be referred to for certain details. The key generator takes a device serial number as input and generates a 32 byte (character) master key along with a OTPAUTH URI of the form in the link aforementioned.
- The master key is only a function of the current time (in seconds from epoch). Therefore changes every second regardless of different serial numbers.
Since the key changes every second, so does the OTPAUTH URI. I wonder how is the server supposed to verify a TOTP once a client enters it under this situation?
Edit: So now there are some new questions:
- How do I authenticate to a server with this keygen knowing that the keygen is using
srand(time(NULL))for the seed while calling
rand()8 consecutive times to generate a 32-byte random sequence.
- Is it logical to say the time step for the OTP codes is still 30 seconds while we know that the key and consequently secret are changing every second? Does this translate to the fact that the OTP validity is 1 seconds now?
Vulnerability: Isn't the server susceptible to creating TOTPs of the future and saving them in a repository by an adversary? While I'm writing this section 1476946414 seconds have passed since epoch. Assume creating a TOTP for the time equivalent to 1476947000 seconds passed from epoch. The keygen may be modified such that 1476947000 is passed to
srand() instead of
time(NULL). Presumably there will also be enough time to derive the TOTP from the OTPAUTH URI.
Patching using IDA Pro 6.8:
So I thought its better to continue in a hands on fashion. Scrolling through the disassembly, I changed the call to
time(NULL) to a mov instruction, assigning my favorite time to eax. In order to check my patch I ran the original keygen on the favorite time. The results were equivalent. Three things still bother me:
- May the validation process the server carries out be concealed in the keygen or the keygen is what its only expected to be, a keygen?!
- The disassembly has a bunch of strings resembling openssl subroutines I presume. For instance digest.c, pmeth_gn.c, pmeth_lib.c, etc. The codes are available on the web. However, I found no lucid documentation for a layman. I suspect if the server's validation parameters are defined here. I've also been able to detect SHA256 and SHA512 cryptographic constants in the disassembly using findcrypt2.
- I've been cautioned that the keys are generated using Linux. What effect may this have? I'm still on the Windows track!
Switching to Linux:
So I installed Ubuntu 16.04 and ran the patched linux binary keygen. The key file and the secret were completely different from the ones generated by Windows for the same time. Before reaching the specified time, I created the HMAC and derived the TOTP codes for that specific time and entered them exactly on the specific time. However, I was not able to authenticate. It may seem that the server is not expecting TOTPs for the current time. I have no idea TOTPs for what time should I feed to the server!
While findcrypt2 did not find any sign of AES in Windows keygen binary, it did notice multiple Rijndael 's in the Linux keygen binary (just adding as additional info).
I have been able to receive the server binary. I think the authentication procedure must be outlined there. But where should I look?
Here is the Final Problem: The key generator program is used to produce device specific keys. There is a weakness in how these keys are generated which should be exploited to generate valid one-time codes for any device.