ActiveX: cornucopia for pickpockets

If Microsoft's ActiveX technology is implemented as has been planned then a real barn door is opened up for technically minded white collar criminals. That at least is the opinion of the Chaos Computer Club after completion of an experiment which can cost a lot of Windows users dearly.

At the yearly Chaos Communication Congress in Hamburg, Germany, they talk about a lot of nonsense. That was also the case on the Friday evening. The subject that the people around the table were discussing was: "(In)security of online banking and Internet banking".

As well as the well known methods of "man in the middle attacks" - in which, for example, some piece of software that isn't known to the communicating partners sits between the service provider and customer - and other known weaknesses within bank protocols, it was point attacks - that is attacks on the customer and his system - that were of particular interest.

ActiveX was known to Unix users at the latest after a NASA-Cert announcement on 6 September 1996, which highlighted the fact that Microsoft Internet Explorer contains security loopholes with respect to macro programming.

That's why on this evening someone suggested leaving everything to do with ActiveX alone and not to develop any of their own activities. An ActiveX applet written and then set it loose…: a task for Steffen Peter, the only willing Windows programmer at the table.

Programming the devil's tools

A quick visit to http://www.microsoft.com/download/ then gave the possibility of writing ActiveX controls in the form of an 8 Mbyte beta version of Visual Basic 5.0. Microsoft has also extended the well known "visual" programming style to ActiveX components within Visual Basic. Quicken was chosen as suitable software to be manipulated by ActiveX. In Germany Quicken is the most widely used program for account administration and online banking by individuals and self-employed people.

With Visual Basic's various functions it was possible to quickly write a control that started Quicken commands and controled them remotely via SendKeys. However, in doing so the problem arose that in some circumstances Quicken hadn't finished processing an input when SendKeys had already carried out its work. To overcome this, wait loops were inserted at various points in the program in order to give Quicken the chance to process the inputs in sequence.

At this point however, the transaction was still presented to the user on the full screen in the foreground. The first attempt to solve this problem, whereby Quicken was made to run in the background as an icon, failed because the SendKeys rountine in Visual Basic obviously can't send keyboard inputs to a minimised program. To make Quicken run in the background, unseen by the user, it's necessary to use the Windows API, which makes this possible with SetWindowPos.

SetWindowPos sets the position of a window in the Windows internal window administration and in doing so makes instruction HWND_TOPMOST possible, in which a window remains in the foreground irrespective of activity or inactivity. The Windows help function uses this method, for example. Now setting the handle of the active window can take place. If you bring a current window - with an Internet connection generally that of the Microsoft Explorer - to the foreground, then any action can be carried out unbeknown to the user in the background.