Background
Around 2000 in Frankfurt, Germany I was member of a local computer club. We were approached by the Hesse TV. Supported and sponsored by a major bank they wanted us to show how to hack the newly developed online banking system with PC and card readers.
The security of this new card reader based system was considered superior to the old manual TAN based system.
System Layout
The online banking clients were Windows PCs with smart/banking card readers attached to the serial COM port. On a PC a bespoke banking application was run that connected to the card reader and performed the (web based) on-line banking transactions. Each transaction was individually approved though the card reader with the smart/banking card.
There was a great discussion of what kind of cryptographic protocol was used and how secure such an encrypted connection was. From the sponsoring bank’s point of view we were expected to admit that the whole set up was feasible, security-wise.
A Flaw In The Transaction Logic
Make no mistake. The banking client system was controlled by Windows PC software. The attached card reader was slave of the PC in a way that a transaction data was sent to the card reader so it could be digitally signed and then received back by the PC and forwarded to the bank.
It was sort of clear that the client system could not work securely because the transaction sent to the card reader could be anything and tampered with while the PC was owned (aka hacked) by somebody else.
We also wanted to show that there is limited coding skills needed for hijacking the banking system. So we used freely available Trojan horse software and some publicly available remote serial COM port administration tool for controlling a PC with an attached smart card reader.
While the smart/bank card was physically in the reader device, transactions could be successfully made on behalf of the user of the owned/hacked PC. In our case we even called the sponsoring bank’s help desk (which were unaware of the test situation) in the name of the user when something did not work out as expected. The help desk verified our identity by having us performed a particular card reader transaction remotely through the owned/hacked PC.
When setting up the software needed for the hacking proof-of-concept we spend most of the time patching a system tray icon of the COM port remote administration software so it could run unnoticed. This was the main part where coding skills came in handy. Most of the other software components (e.g. Trojan) could be used nearly as-is.
How To Secure That Scenario
The security problem described here was arose from the fact that a (human) PC user was not able to acknowledge the very transactions presented to the card reader. Instead the user was left to believe that the transaction displayed on the PC was also the one presented to the card reader.
A solution would have been to endow the card reader with a display for main transaction data (e.g. amount + destination) and a confirm button so that a transaction would not be approved before the button was pressed after a visual check of the transaction on the display.
There was a demonstration of the hack scenario on German TV (press report in German).