| Yubico Forum https://forum.yubico.com/ |
|
| Question about trojan intercepting & replaying OTP https://forum.yubico.com/viewtopic.php?f=4&t=361 |
Page 1 of 1 |
| Author: | Didier Stevens [ Tue Jul 28, 2009 9:01 pm ] |
| Post subject: | Question about trojan intercepting & replaying OTP |
I got a Yubikey last year at RSA Europe (thanks Stina), obtained the AES key and have done some Python programming with it. But I'm stuck with this: Assume a website which uses the Yubikey OTP to 1) authenticate users and 2) validate transactions. Classic example of such a site is an online banking site. User generates an OTP to logon, and then has to generate an OTP for each financial transaction. A web browser trojan could insert it's own transaction like this: - I generate an OTP (OTP1) with my Yubikey - The trojan intercepts and stores OTP1 together with a timestamp, doesn't send OTP1 to the website, but makes the browser display a fake error message (404, server load to high, Yubikey error, ...) prompting me to generate a second OTP - I'm fooled by the fake error, and generate a second OTP (OTP2) with my Yubikey - The trojan intercepts and stores OTP2 together with a timestamp, and sends OTP1 to the web site - Web site grants me access. - After an amount of time equal to the delta between the 2 stored timestamps, the trojan starts a transaction (invisible to the user) and uses OTP2 to validate the transaction. - When the user starts his own transactions, the trojan pases the OTPs on to the website, but delays them with the same timestamp delta to avoid post-exploitation detection. I cannot device an algorithm to detect this fraud on the website, if the Yubikey is the only authentication and validation mechanism used. Any ideas? Asking the user to reinsert his Yubikey to force each OTP to have a session counter equal to 0 (and thus prevent above scenario) is not a good idea, because then the user is accustomed to have to reinsert his Yubikey. The trojan could just do the same and ask the user to reinsert his Yubikey. Didier ----- Didier Stevens http://blog.DidierStevens.com |
|
| Author: | dain [ Wed Jul 29, 2009 9:29 am ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
Sure, but once you have a trojan on your system pretty much all bets are off anyway. It could just as easily intercept my communication with my online bank, changing the amount and receiver of any transaction I perform without me knowing it (except for my original transaction not being made, but the damage is already done and the trojan could make it look like it went through), regardless of authentication device. At least, I am unaware of anything that is able to fully protect you when using a compromised system. Still, it is an interesting problem. One way to solve it would have a more advanced trusted device which itself is capable of displaying the transaction to sign, so that the user cannot be tricked into signing something else than what was intended. |
|
| Author: | fortean [ Wed Jul 29, 2009 6:51 pm ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
Didier Stevens wrote: I cannot device an algorithm to detect this fraud on the website, if the Yubikey is the only authentication and validation mechanism used. .I guess you can't do it unless you add some crude mechanism to verify if he transaction is executed in real time. What about something like this: 1 - upon login the server shows a graphic that depicts 4 random digits. 2 - the user types over these digits and presses the key. 3 - the server verifies the correctness of the number (it is only valid for let's say 15 seconds) 4 - if correct, the server registers the wall clock time and Yubikey timestamp. 5 - if not correct, go to step 1 again. 6 - upon verification of he transaction the server shows a graphic that depicts 4 random digits 7 - the user types over these digits and presses the key. 8 - the server verifies if this is still the same session (key has not been unplugged). If not: go to step B 9 - the server verifies the correctness of the number (it is only valid for let's say 15 seconds) A - if correct, the server uses the wall clock time to determine if the timestamp on the key is within acceptable range B - if not correct, refuse transaction and go to step 1. C - allow transaktion D - goto step 6 |
|
| Author: | Didier Stevens [ Wed Jul 29, 2009 7:41 pm ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
dain wrote: Still, it is an interesting problem. One way to solve it would have a more advanced trusted device which itself is capable of displaying the transaction to sign, so that the user cannot be tricked into signing something else than what was intended. Yes, this exists and is one way to deal with trojans. Example: there are security tokens that use a different protocol to logon and to validate a transaction. logon: user types his PIN, security token generates digits, user types digits transaction signing: user types his PIN, user types in transaction challenge (a unique number for the transaction generated by the bank server), security token generates digits, user types digits So already in this simple case, a trojan can't use 2 logon digits to logon & sign a transaction Other banks go further and include data of the transaction in the challenge, for example the number the user has to type in the security token includes the amount of the transaction and/or the account number. |
|
| Author: | Didier Stevens [ Wed Jul 29, 2009 8:19 pm ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
fortean wrote: Didier Stevens wrote: I cannot device an algorithm to detect this fraud on the website, if the Yubikey is the only authentication and validation mechanism used. .I guess you can't do it unless you add some crude mechanism to verify if he transaction is executed in real time. What about something like this: This makes sense. If I understand you correctly: You associate the OTP the server gets with an action that only the user can perform, and not the trojan? And this assures you that the OTP comes in real time from the Yubikey? In your example, this action is reading digits from a graphic and typing these digits? Did I understand that correctly? So the key is to find an operation that a user can perform, and not a program. A CAPTCHA? |
|
| Author: | fortean [ Thu Jul 30, 2009 10:23 am ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
Didier Stevens wrote: fortean wrote: Didier Stevens wrote: I cannot device an algorithm to detect this fraud on the website, if the Yubikey is the only authentication and validation mechanism used. .I guess you can't do it unless you add some crude mechanism to verify if he transaction is executed in real time. What about something like this: This makes sense. If I understand you correctly: You associate the OTP the server gets with an action that only the user can perform, and not the trojan? And this assures you that the OTP comes in real time from the Yubikey? Yes. The 'in real time' is a bit fuzzy, as the Internet was not really designed for realtime actions. I'm not sure (haven't looked at it yet) how precise the 8Hz clock in the Yubikey actually is, it will probably drift, so your algorithm needs to take care of that too. But it should be do-able. Quote: In your example, this action is reading digits from a graphic and typing these digits? Did I understand that correctly? So the key is to find an operation that a user can perform, and not a program. A CAPTCHA? Yes, that's what I meant. |
|
| Author: | Didier Stevens [ Thu Jul 30, 2009 6:26 pm ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
fortean wrote: ... how precise the 8Hz clock in the Yubikey actually is, it will probably drift, so your algorithm needs to take care of that too. But it should be do-able. ... Mine is 30% ! |
|
| Author: | fortean [ Fri Jul 31, 2009 11:05 am ] |
| Post subject: | Re: Question about trojan intercepting & replaying OTP |
Didier Stevens wrote: fortean wrote: ... how precise the 8Hz clock in the Yubikey actually is, it will probably drift, so your algorithm needs to take care of that too. But it should be do-able. ... Mine is 30% ! Well, as long as it is constant, you could calculate the drift and take that into account. Worst case the timer depends on the voltage provided by the system it happens to be plugged in to.. the key probably does not contain a crystal or something like that. Might even be that the clock is implemented in software, so pressing the button will actually stall updating the timer.. Perhaps some of our Yubico friends here can provide additional information? |
|
| Page 1 of 1 | All times are UTC + 1 hour |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|