RE: Defeating Citibank Virtual Keyboard protection using screenshot method
Hugo van der Kooij wrote:
> >> Sure, they're a lot more expensive and a lot more "high-tech" but
> >> unless they are doing end-to-end client and server authentication and
> >> strong crypto _AND_ have their own input and output devices that cannot
> >> be interfaced from the host OS _AND_ are required for verifying
> >> (virtually) every step of every transaction (in other words -- if you
> >> have any of the real-world implementations of banking OTP cards used
> >> anywhere in the world, the answer is "no"), they are effectively no
> >> better than the Citi OSK's as they are trivially MiTM'ed via on-client
> >> malware.
>
> In fact the system used by the major Dutch banks is audited rather
> extensively. The OTP system is based on an external smartcard reader and a
> smartcard application on the bank card. They have no physical connection
> so the web interfcae will present you with a challenge and you must use
> that challeng, your card and your pin to generate the proper response.
> Then you have to type in this response.
>
> It is a combination of:
> - What you have (the card with the smartcard application)
> - What you get (the challenge from the server)
> - What you know (your pincode)
>
> To the best of my knowldge the transaction value is also part of the
> calculations. So you can not fix the actual amount and let the other
> parts just pass by.
>
> I would welcome you to explain us how one can do a MITM attack on that.
Unless the "challenge" which the user must feed into the secure device
includes both the amount and the recipient, the MitM can present false
information to the user alongside the correct challenge, then use the
response to authenticate the fraudulent transaction.
IOW, the user thinks that they are paying $20 to amazon.com, but
they're actually paying $1000 to fraudster.com.
> It
> is many times harder to break into this sort of system then many of the
> soft targets relying on fixed username+password prompts.
Certainly, OTP prevents a keylogger from grabbing a password which can
be used subsequently to authenticate an arbitrary number of fraudulent
transactions. You at least have to intercept a legitimate transaction
for each fraudulent transaction, preferably in such a way that the
user doesn't realise that they've been intercepted.
[The last part requires the legitimate recipient to design their
payment interface such that it will only accept the exact transaction
they initiated, and not an alternative payment from a third party
(i.e. the fraudster paying the $20 out of the $1000 they just took).]
> Dutch law requires extensive external audits on these systems.
So long as the system places any trust in the user's PC, auditing the
other components is of limited value.
A really secure system would need to ensure that the user specifically
authorises the transfer of amount X to recipient Y, and not merely
some unspecified transaction.
Eliminating trust in the user's PC would require that the significant
details of the transaction are passed to the secure device, which
realistically requires a better communication channel than a keypad.
--
Glynn Clements <glynn@xxxxxxxxxxxxxxxxxx>