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:
- 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.
- 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ück