Alle Bedrohungen

Viren

Hacker

Spam

Alle Seiten    Viren
  
Virus Enzyklopädie
Alarme
Analysen
Nachrichten
Glossar
Weblog

 
Kalender

<< 2014  
Jan Feb Mär
Apr Mai Jun
Jul    
     
Most Popular Analysis



Spam im Juni 2014



Betrüger in Sozialen Netzwerken



Entwicklung der IT-Bedrohungen im 1. Quartal 2014



Spam im Mai 2014



Kaspersky Security Bulletin 2013/2014 – Statistik für das Jahr 2013
 
Für potentielle Autoren

Möchten Sie einer unserer Autoren werden und Ihre Texte auf der Viruslist.com lesen? Setzen Sie sich mit uns in Verbindung!

 

  Home / Analysen

Keylogger: Verschiedene technische Umsetzungen von Tastaturspionen in Windows (Teil 2)

6.06.2007   |   Kommentare (1)

Nikolay Grebennikov

Der vorliegende Artikel ist die Fortsetzung einer Übersicht zu dem Thema Keylogger. Der zweite Teil enthält eine detaillierte Analyse der technischen Aspekte der Entwicklung von Keyloggern. Wie schon in Teil 1 erläutert, besteht das Prinzip von Keyloggern darin, zwischen zwei beliebigen Gliedern der Signalübertragungskette einzudringen - vom Drücken der Taste durch den Anwender bis zum Erscheinen des Symbols auf dem Bildschirm. Im vorliegenden Artikel wird analysiert, welche Glieder in dieser Kette enthalten sind und verschiedene Varianten von Soft- und Hardware-Keyloggern werden genauer untersucht.

Der Artikel wendet sich an IT-Experten und an fortgeschrittene Anwender. Für alle anderen Leser sei lediglich an die Tatsache erinnert, dass das Betriebssystem Windows eine Vielzahl von Möglichkeiten bietet, die über die Tastatur eingegebenen Daten abzufangen, wobei die Mehrheit der tatsächlich existierenden Keylogger nur zwei dieser Optionen nutzt (siehe „Grundsätzlicher Aufbau von Keyloggern“ im ersten Teil der Analyse).

An dieser Stelle sei darauf hingewiesen, dass in der vorliegenden Analyse keine Beispiele von Keylogger—Ausgangsvarianten enthalten sind. Im Gegensatz zu einigen Fachleuten auf dem Gebiet IT-Sicherheit sind wir nicht der Meinung, derartigen Code veröffentlichen zu können.

Bearbeitung der Tastatureingaben in Windows

Es existieren verschiedene grundlegende Technologien zum Abfangen der Tastatureingaben oder mit der Maus ausgeführter Aktionen, auf die sich die meisten Keylogger gründen. Bevor die konkreten Keylogger-Typen näher untersucht werden, ist es allerdings unumgänglich, sich zunächst einmal mit dem Bearbeitungsschema der Tastatureingaben im Betriebssystem Windows vertraut zu machen. Zur Beschreibung des gesamten Schemas – von der Betätigung einer Taste auf dem Keyboard bis hin zur Auslösung des Systeminterrupts des Tastaturkontrollers und der Darstellung der Mitteilung WM_KEYDOWN in einem aktiven Fenster – wurden drei Quellen hinzugezogen:

  1. Das Buch „Apparatnoe obespečenie IBM PC“. Alexander Frolov, Grigorij Frolov, Bd. 2, Buch 1, M.: Dialog-MIFI, 1992. Kapitel 2 „Tastatur“ beschreibt die Funktionsprinzipien der Tastatur, die verwendeten Ports und den Hardware-Interrupt der Tastatur;
  2. Der Abschnitt Human Input Devices der Bibliothek MSDN Library, in dem der Teil der unteren Ebene (Treiber) des Bearbeitungsschemas von Tastatureingaben beschrieben wird;
  3. Das Buch von Jeffrey Richter „Entwicklung effektiver WIN32-Anwendungen unter Berücksichtigung der Besonderheiten der 64-Bit Windows-Versionen“. In Kapitel 27 „Das Hardware-Eingabemodell und der lokale Eingabezustand“ wird die obere Ebene des Bearbeitungsschemas der Tastatureingaben (im User-Mode) beschrieben.

Funktionsprinzipien der Tastatur als physisches Gerät

Heutzutage sind die meisten Tastaturen eigenständige Geräte, die über Schnittstellen – zumeist PS/2 oder USB – mit dem Computer verbunden werden. Es gibt zwei Mikrokontroller, die den Bearbeitungsprozess der Tastatureingaben gewährleisten: einer befindet sich auf dem Motherboard, der andere in der Tastatur selbst. Daher stellt die PC-Tastatur an sich schon ein selbstständiges Computersystem dar. Dieses basiert auf dem Mikrocontroller 8042, der die Tastatureingaben fortwährend scannt - unabhängig von der Aktivität auf dem zentralen Prozessor x86.

Für jede Taste des Keyboards ist eine bestimmte Nummer festgelegt, die eindeutig der Aufteilung der Tastaturmatrix zugeordnet und nicht direkt von dem auf der Oberfläche der Taste dargestellten Zeichen abhängig ist. Diese Nummer wird als Scan-Code bezeichnet (diese Benennung verdeutlicht, dass der Computer die Tastatur auf der Suche nach Tasten-Betätigung scannt). Der Scan-Code ist ein zufälliger Wert, der von IBM bestimmt wurde, als das Unternehmen die erste Tastatur für einen PC herstellte. Der Scan-Code entspricht nicht dem ASCII-Code der Tastatur; ein und derselben Tastatur können verschiedene Werte des ASCII-Codes entsprechen. Eine Übersicht aller Scan-Codes kann unter anderem unter dem folgenden Link abgerufen werden.

Die Tastatur generiert zwei Scan-Codes für jede Taste - einen beim Drücken, den anderen beim Lösen der Taste. Das Vorhandensein von zwei Scan-Codes ist wichtig, weil einige Tasten nur dann sinnvoll sind, wenn sie gedrückt werden (Shift, Control, Alt).


Abb. 1. Vereinfachtes Tastaturschema

Betätigt der Anwender eine Taste auf dem Keyboard, löst er einen elektrischen Kontakt aus. Als Folge registriert der Mikrokontroller beim nächsten Scanvorgang die Betätigung einer bestimmten Taste und schickt den Scan-Code der gedrückten Taste und eine Interrupt-Anfrage an den Zentralcomputer. Analoge Aktionen werden durchgeführt, wenn der Anwender die vorher gedrückte Taste löst.

Der zweite Mikrokontroller empfängt den Scan-Code, wandelt ihn um und macht ihn am Eingabe-Ausgabe-Port 60h verfügbar, woraufhin er einen Hardware-Interrupt des zentralen Prozessors generiert. Danach kann die Interrupt-Behandlungsroutine (ISR = Interrupt Service Routine) den Scan-Code aus dem genannten Eingabe-Ausgabe-Port empfangen.

Die Tastatur verfügt über einen internen16-Byte-Puffer, über den der Datenaustausch mit dem Computer realisiert wird.

Wechselwirkung auf der unteren Ebene mit der Tastatur über Eingabe-Ausgabe-Ports

Das Zusammenwirken mit dem Systemkontroller der Tastatur erfolgt über den Eingabe-Ausgabe-Port 64h. Mit dem Lesen von Bytes aus diesem Port kann der Status des Tastaturkontrollers bestimmt werden, mit dem Schreiben von Bytes wird dem Kontroller ein Befehl übermittelt.

Das Zusammenwirken mit dem Mikrokontroller in der Tastatur selbst wird mittels der Eingabe-Ausgabe-Ports 60h und 64h umgesetzt. Die Bits 0 und 1 im Statusbyte (Port 64 im Lesemodus) ermöglichen die Steuerung der Wechselwirkungs-Routine: Vor dem Schreiben von Daten in diese Ports muss Bit 0 des Ports 64 auf 0 stehen. Wenn die Daten aus Port 60h zum Lesen verfügbar sind, ist Bit 1 des Ports 64h gleich 1. Die On/Off-Bits der Tastatur im Befehlsbyte (Port 64h im Schreibemodus) bestimmen, ob die Tastatur aktiviert ist und ob der Tastaturkontroller einen Interrupt im System auslöst, wenn der Anwender eine Taste drückt.

In den Port 60h geschriebene Bytes werden an den Tastaturkontroller gesendet, wogegen in den Port 64h geschriebene Bytes an den Systemkontroller der Tastatur geschickt werden. Aufstellungen erlaubter Befehle, die an den Tastaturkontroller geschickt werden können, sind beispielsweise in dem Dokument «8042 Keyboard Controller IBM Technical Reference Manual» oder hier.

Aus Port 60h gelesene Bytes kommen von der Tastatur. Während des Lesens enthält Port 60h den Scan-Code der als letztes gedrückten Taste und im Schreibemodus wird er zur erweiterten Steuerung der Tastatur verwendet. Bei Verwendung des Ports zum Schreiben stehen dem Programm die zusätzlichen Optionen zur Verfügung:

  • Einstellung des Zeitraumes vor Übergang der Tastatur in den Modus Autowiederholung;
  • Einstellung des Generierungsrhythmus des Scan-Codes im Modus Autowiederholung;
  • Steuerung der auf der Außenabdeckung der Tastatur gelegenen Lichtdioden – Scroll Lock, Num Lock, Caps Lock.

Zusammenfassend lässt sich also feststellen, dass es ausreichend ist, die Werte der Eingabe-Ausgabe-Ports 60h und 64h ablesen zu können, um die über die Tastatur eingegebenen Daten zu lesen. Im Betriebssystem Windows ist es den Anwendungen im Benutzermodus allerdings nicht erlaubt mit Ports zu arbeiten, daher übernehmen die Treiber des Betriebssystems diese Aufgabe.

Die Architektur „interaktiver Eingabegeräte“

Wodurch werden nun die Hardware-Interrupts bearbeitet, die erzeugt werden, sobald in Port 60h Daten von der Tastatur empfangen werden? Offensichtlich durch dasselbe Programm, das die Behandlungsroutine des Hardware-Interrupts der Tastatur registriert hat. Unter Windows wird die Bearbeitung von dem Treiber i8042.sys durchgeführt. Im Unterschied zu MS DOS-Zeiten, zu denen jede Systemkomponente praktisch eigenständig war, folgt der Aufbau der Komponenten unter Windows einer genauen Architektur, sie funktionieren nach strikten Regeln, die in den Programmschnittstellen verankert sind. Bevor wir uns also genauer mit dem Treiber i8042pr beschäftigen, betrachten wir die Architektur von interaktiven Eingabegeräten, im Rahmen derer alle Programmkomponenten funktionieren, die mit der Bearbeitung von Eingaben über die Tastatur (oder der Maus) in Zusammenhang stehen.

Geräte, die zur direkten Steuerung von Operationen auf dem Computer verwendet werden, heißen im Betriebssystem Windows interaktive Eingabegeräte (interactive input device). Neben Maus, Joystick, Trackball, Cyberhelm usw. gehört die Tastatur zu dieser Gerätekategorie.

Die Steuerungsarchitektur für interaktive Eingabegeräte basiert auf dem Standard USB Human Interface Device (HID), vorgeschlagen von der Organisation USB Implementers Forum. Allerdings ist die Architektur nicht allein auf USB-Geräte beschränkt, sondern unterstützt auch andere Typen von Eingabegeräten, wie etwa die Bluetooth-Tastatur, über den PS/2-Port angeschlossene Tastaturen und „Mäuse“ sowie über den Spiele-Port (I/O port 201) verbundene Geräte).

Im Folgenden werden unter anderem die Aufbauprinzipien des Treiber-Stacks und des Geräte-Stacks für PS/2-Tastaturen näher betrachtet, da diese historisch gesehen die ersten Gerätetypen sind. USB-Tastaturen verwenden eine Reihe von Elementen, die mit der Entwicklung der Programmunterstützung von PS/2-Tastaturen eingeführt wurden.

Kernel-Mode-Treiber für PS/2-Tastaturen

Treiber-Stack für System-Eingabegeräte

Tastaturtreiber verwenden unabhängig von der Art des physischen Anschlusses Systemtreiber der Tastaturklasse zur Bearbeitung von Operationen, die nicht vom Hardwareteil abhängig sind. Solche Treiber werden Klassentreiber genannt, weil sie die vom System geforderten, von der Hardwareumsetzung unabhängigen Anforderungen an die konkrete Geräte-Klasse erfüllen.

Der entsprechende Funktionstreiber (Porttreiber) realisiert die vom konkreten Gerät abhängige Durchführung der Eingabe-Ausgabe-Operation. In Windows x86-Plattformen ist nur ein einziger Treiber der Tastatur (i8042) und der Maus umgesetzt.


Abb. 2. Driver-Stacks für die Systemeingabegeräte Tastatur und Maus

Treiber-Stack für Plug and Play von PS/2-Tastaturen


Abb. 3. Treiber-Stack für PS/2-Tastaturen

Der Treiber-Stack enthält die folgenden Elemente (von oben nach unten):

  1. Kbdclass – einen Filter-Tastaturklassentreiber der oberen Ebene;
  2. einen optionalen Filter-Tastaturklassentreiber der oberen Ebene;
  3. i8042 – einen Funktionstreiber der Tastatur;
  4. einen Kerneltreiber des Busses.

Im Betriebssystem Windows 2000 und niedriger ist Kbdclass der Tastaturklassentreiber, dessen wichtigste Aufgaben im Folgenden aufgelistet sind:

  • Durchführung allgemeiner und Hardware-unabhängiger Operationen der Geräteklasse;
  • Unterstützung von Plug and Play, Unterstützung der Einspeisungssteuerung und von Windows Management Instrumentation (WMI);
  • Unterstützung von Operationen für Legacy-Geräte;
  • Gleichzeitige Durchführung von Operationen auf mehr als einem Gerät;
  • Realisierung der class service callback routine, die vom Funktionstreiber zur Übermittlung der Daten aus dem Eingangspuffer des Gerätes in den Datenpuffer des Geräteklassentreibers ausgelöst wird.

Im Betriebssystem Windows 2000 und niedriger ist i8042prt der Funktionstreiber für Eingabegeräte, die den PS/2-Port benutzen (Tastatur und Maus). Seine wichtigsten Funktionen sind:

  • Durchführung von Hardware-abhängigen, gleichzeitigen Operationen von PS/2-Eingabegeräten (Tastatur und Maus nutzen gemeinsame Ein- und Ausgabeports, verwenden aber verschiedene Interrupts, Interrupt-Behandlungsroutinen (ISR) und verschiedene Routinen zur Vollendung der Interruptbehandlung);
  • Unterstützung von Plug and Play, Unterstützung der Einspeisungssteuerung und von Windows Management Instrumentation (WMI);
  • Unterstützung von Operationen für Legacy-Geräte;
  • Auslösung der class service callback routine für die Tastatur- und Mausklassen zur Übermittlung von Daten aus dem Eingangsdatenpuffer i8042prt in den Datenpuffer des Klassentreibers;
  • Auslösung verschiedener Rückruf-Funktionen, die von den Treiberfiltern der oberen Ebene zur flexiblen Steuerung der Geräte realisiert werden können.

Abb. 4. Liste der vom Treiber i8042prt verwendeten Hardware-Ressourcen

Die Abbildung zeigt eine Liste der Hardware-Ressourcen, die vom Treiber i8042prt verwendet werden, die unter anderem mit dem Tool Device Tree der Firma Open Systems Resources. Wer die Abschnitte 2.1 und 2.2 gelesen hat, den werden die Werte der Eingabe-Ausgabe-Ports (IO) 60h und 64h und des Hardware-Interrupts (IRQ) 1 nicht überraschen.

Der im dargestellten Treiber-Stack neue Treiberfilter kann z.B. zur spezifischen Bearbeitung der Tastatureingabe oberhalb der Tastaturklassentreiber ergänzt werden. Dieser Treiber muss dieselbe Bearbeitung aller Typen von Ein- und Ausgabe-Aufträgen (IRP) und von IOCTL-Befehlen unterstützen wie ein Tastaturklassentreiber. Im vorliegenden Fall werden die Daten vor der Übermittlung in das Subsystem des User-Mode zur Bearbeitung an den Treiberfilter geleitet.

Geräte-Stack für Plug and Play von PS/2-Tastaturen

Im Folgenden werden die Stacks der Geräte, die die oben beschriebenen Treiber im Treiber-Stack der Tastatur erzeugen, genauer betrachtet. Auf der folgenden Abbildung sind links die in der MSDN Library für PS/2-Tastaturen aufgeführten Geräte-Stacks dargestellt. Rechts sieht man einen Screenshot des Programms Device Tree, der die reale Situation auf dem Computer des Autors dieses Artikels zeigt.


Abb. 5. Konfiguration der Geräteobjekte für Plug and Play von PS/2-Tastaturen

Der Geräte-Stack (richtiger wäre es, vom Stack der Geräteobjekte zu sprechen) besteht insgesamt aus den folgenden Komponenten:

  1. dem Physical Device Object der Tastatur (PDO), das von dem Bustreiber erzeugt wird (in diesem Fall Bus PCI) - \Device\00000066;
  2. dem Functional Device Object der Tastatur (FDO), das von dem Treiber i8042prt erzeugt und dem PDO hinzugefügt wird – unbenanntes Objekt (unnamed);
  3. optionalen Filter-Objekten der Tastatur, die durch von Programmieren entwickelten Filtertreibern der Tastatur erzeugt werden;
  4. einem Filter-Objekt der Geräteklasse Tastatur der oberen Ebene, der vom Klassentreiber Kbdclass erzeugt wird - \Device\KeyboardClass0.

Bearbeitung der Tastatureingaben durch die Anwendungen

Raw Input Thread (Datenempfang vom Treiber)

Der vorhergehende Abschnitt beschäftigte sich mit Beispielen zum Aufbau von Tastatur-Stacks im Kernel-Mode des Betriebssystems. Nun soll der Daten-Transfer vom Tastendruck zu den Anwendungen des User-Mode genauer betrachtet werden. Das Subsystem Microsoft Win32 erhält mit Hilfe des Raw Input Threads (RIT) Zugriff auf die Tastatur. Der RIT ist Teil des Systemprozesses csrss.exe (User-Mode des Win32-Subsystems). Beim Start erzeugt das Betriebssystem den RIT und die System-Hardware-Eingabe-Queue (System Hardware Input Queue, SHIQ).

Der RIT öffnet das Objekt „Gerät“ im Tastaturklassentreiber zur exklusiven Nutzung und sendet diesem mit Hilfe der Funktion ZwReadFile eine Eingabe-Ausgabe-Anforderung (IRP = Input/Output Request Packets) wie zum Beispiel IRP_MJ_READ. Der Treiber Kbdclass registriert die Anfrage als unerledigt (pending), reiht sie in die Warteschleife ein und sendet den Rückkehrcode STATUS_PENDING zurück. Der RIT muss nun auf die Erledigung der IRP warten, was durch einen asynchronen Prozeduraufruf umgesetzt wird (Asynchronous Procedure Call, APC).

Drückt oder löst der Anwender eine Taste, so erzeugt der System-Tastaturkontroller einen Hardware-Interrupt. Sein Editor löst die vom Driver i8042prt im System registrierte spezielle Interrupt-Behandlungsroutine IRQ 1 aus (Interrupt Service Routine, ISR). Diese Routine liest die erscheinenden Daten aus der internen Queue des Tastaturkontrollers. Die Verarbeitung des Hardware-Interrupts muss so schnell wie möglich erfolgen, daher speichert die ISR den Deferred Procedure Call (DPC) I8042KeyboardIsrDpc in einer Queue und beendet ihre Arbeit. Sobald es möglich ist (IRQL sinkt auf DISPATCH_LEVEL ab), wird ein DPC vom System ausgelöst. In diesem Moment wird die Rückruf-Routine KeyboardClassServiceCallback, ausgelöst, die vom Treiber Kbdclass des Treibers i8042prt bereitgestellt wird. Die Routine KeyboardClassServiceCallback zieht aus ihrer Queue den unerledigten IRP-Aufruf, füllt die maximale Menge der KEYBOARD_INPUT_DATA-Strukturen aus, die alle notwendigen Informationen über das Drücken und Lösen von Tasten enthalten und erledigt die IRP. Der Raw Input Thread wird nun aktiviert, bearbeitet die empfangenen Informationen und sendet dem Klassentreiber erneut eine IRP des Typs IRP_MJ_READ, welche bis zum nächsten Drücken/Lösen einer Taste wiederum in einer Queue gespeichert wird. Daher ist im Tastatur-Stack immer mindestens eine unerledigte IRP vorhanden, die sich in der Queue des Treibers Kdbclass befindet.


Abb. 6. Reihenfolge der RIT-Anfragen an den Tastaturtreiber

Mit Hilfe des Tools IrpTracker des bereits erwähnten Unternehmens Open Systems Resources kann man die Reihenfolge der während der Bearbeitung der Tastatureingaben erfolgenden Aufrufe einsehen.


Abb. 7. Bearbeitung der Tastatureingabe im User-Mode

Wie bearbeitet der RIT nun die eingehenden Informationen? Alle Tastaturereignisse werden in die SHIQ eingereiht, woraufhin sie nacheinander in Windows-Meldungen umgewandelt werden (wie etwa WM_KEY*, WM_?BUTTON* oder WM_MOUSEMOVE) und sich ans Ende der virtualisierten Eingabe-Queue (VIQ – virtualized input queue) des Vordergrund-Threads einreihen. In den Windows-Meldungen werden die Tasten-Scan-Codes durch virtuelle Tastencodes ersetzt, die nicht der Anordnung der Tasten auf der Tastatur, sondern der Aktion, die die jeweilige Taste ausführt, entsprechen. Der Mechanismus der Codeumwandlung hängt vom jeweils aktiven Tastaturlayout, von der gleichzeitigen Betätigung anderer Tasten (wie etwa SHIFT) und anderen Faktoren ab.

Geht der Anwender ins System, generiert der Window Explorer einen Thread, der eine Aufgabenliste und einen Arbeitstisch (WinSta0_RIT) erzeugt. Dieser Thread wird an den RIT gekoppelt. Startet der Anwender MS Word, so fügt sich der Thread dieser Anwendung, der das Fenster erzeugt, sofort zu dem RIT hinzu. Daraufhin löst sich der zum Explorer gehörende Thread vom RIT, da immer nur ein Thread zurzeit an den RIT gekoppelt sein kann. Bei der Betätigung von Tasten erscheint in der SHIQ ein entsprechendes Element, das dafür sorgt, dass der RIT aktiviert wird, dass er die Ereignisse der Hardware-Eingabe in Mitteilungen der Tastatur umwandelt und sie in der VIQ des Threads der Anwendung MS Word anlegt.

Bearbeitung der Meldungen durch ein konkretes Fenster

Es stellt sich nun die Frage, wie der Thread die Meldungen verarbeitet, die in seiner Message-Queue einlaufen.

Der Standard-Verarbeitungs-Zyklus von Meldungen sieht für gewöhnlich folgendermaßen aus:

while(GetMessage(&msg, 0, 0, 0))
{
  TranslateMessage(&msg);
  DispatchMessage(&msg);
}

Mit Hilfe der Funktion GetMessage werden die Tastaturereignisse aus der Queue gezogen und mittels der Funktion DispatchMessage in eine Fensterroutine weitergeleitet, die die Meldungen für das Fenster bearbeitet, wo im gegebenen Augenblick der Input-Fokus konzentriert ist. Der Input-Fokus ist ein von der Anwendung oder von Windows erzeugtes Attribut, das dem Fenster hinzugefügt werden kann. Verfügt ein Fenster über einen Input-Fokus, empfängt die entsprechende Funktion dieses Fensters alle Tastaturmeldungen aus der System-Queue. Anwendungen können den Input-Fokus von einem Fenster zu einem anderen weiterreichen, wie etwa beim Wechsel von einer Anwendung zur anderen mit Hilfe der Tastenkombination Alt+Tab.

Noch vor der Funktion DispatchMessage wird für gewöhnlich die Funktion TranslateMessage ausgelöst, die auf der Grundlage der Meldungen WM_KEYDOWN, WM_KEYUP, WM_SYSKEYDOWN, WM_SYSKEYUP die „symbolischen“ Meldungen WM_CHAR, WM_SYSCHAR, WM_DEADCHAR und WM_SYSDEADCHAR generiert. Diese symbolischen Meldungen reihen sich in die Message-Queue der Anwendung ein, wobei die originalen Tastatur-Meldungen nicht aus der Queue gelöscht werden.

Datenfelder des Tastenzustands der Tastatur

Bei der Entwicklung des Hardware-Eingabemodells in Windows war die Gewährleistung der Ausfallunempfindlichkeit ein wichtiger Punkt. Die Ausfallunempfindlichkeit wird durch eine unabhängige Verarbeitung der Eingabe durch die Threads gewährleistet, wodurch ungünstige Wechselwirkungen der Threads miteinander verhindert werden. Eine zuverlässige Isolation der Threads voneinander ist dadurch allerdings noch nicht gegeben, daher unterstützt das System noch eine zusätzliche Konzeption, den lokalen Eingabezustand. Jeder Thread verfügt über einen eigenen Eingabezustand, der in der Struktur THREADINFO dokumentiert ist. Die Informationen über den Zustand enthalten Daten über die virtualisierte Eingabe-Queue des Threads sowie eine Gruppe von Variablen. Letztere enthalten steuernde Informationen über den Eingabe-Zustand. Bezüglich der Tastatur werden die folgenden Angaben unterstützt: welches Fenster befindet sich im Fokus der Tastatur, welches Fenster ist gegenwärtig aktiv, welche Tasten sind gedrückt, in welchem Zustand befindet sich der Eingabecursor.

Angaben dazu, welche Tasten gedrückt sind, werden im Datenfeld des synchronen Tastenzustandes gespeichert. Alle Variablen des lokalen Eingabezustands des Threads enthalten einen Synchronous Key State Array, während sich alle Threads nur ein Datenfeld des asynchronen Eingabezustands teilen, welches analoge Informationen enthält. Diese Datenfelder geben Auskunft über den Zustand aller Tasten zu jedem beliebigen Zeitpunkt und mit der Funktion GetAsyncKeyState lässt sich bestimmen, ob eine einzelne Taste gegenwärtig gedrückt ist. Die Funktion GetAsyncKeyState sendet stets 0 (nicht gedrückt) zurück, wenn der Thread, der die Funktion aufruft, nicht derjenige ist, der das Fenster erzeugt hat, das derzeit den Input-Fokus hat.

Die folgende Funktion GetKeyState unterscheidet sich dadurch von der Funktion GetAsyncKeyState, dass sie den Tastaturzustand in dem Moment zurücksendet, in dem die letzte Tastaturmeldung aus der Thread-Queue entfernt wird. Diese Funktion kann jederzeit aufgerufen werden, unabhängig davon, welches Fenster sich gerade im Fokus befindet.

Tastaturhooks

Als Hook wird im Betriebssystem Microsoft® Windows ein Mechanismus bezeichnet, der Ereignisse unter Verwendung einer bestimmten Funktion (wie etwa der Übermittlung von Windows-Meldungen, der Eingabe über die Maus oder die Tastatur) abfängt, bis diese zu den Anwendungen gelangen. Diese Funktion kann daraufhin auf die Ereignisse reagieren und sie unter Umständen verändern oder außer Kraft setzen.

Funktionen, denen die Ereignisse gemeldet werden, heißen Filterfunktionen und werden nach Typen entsprechend der von ihnen abzufangenden Ereignisse unterschieden. Damit Windows eine Filterfunktion aufrufen kann, muss diese Funktion an einen Hook gekoppelt sein (zum Beispiel an einen Tastatur-Hook). Die Anbindung eines oder mehrerer Filterfunktionen an einen beliebigen Hook nennt man Hook-Installation. Zum Installieren und Löschen von Funktionsfiltern einer Anwendung werden die Funktionen Win32 API SetWindowsHookEx und UnhookWindowsHookEx verwendet. Einige Hooks können sowohl für das gesamte System als auch für einen konkreten Thread installiert werden.

Werden an einen Hook mehrere Filterfunktionen gekoppelt, realisiert Windows eine Funktionen-Queue, wobei die als letzte angekoppelte Funktion an den Anfang und die allererste Funktion ans Ende der Queue gestellt wird. Die Queue der Filterfunktionen (s. Abb. 8) wird von Windows selbst unterstützt, wodurch das Schreiben von Filterfunktionen erleichtert und die Performance des Betriebssystems verbessert wird.

Windows unterstützt einzelne Ketten für jeden Hook-Typ. Unter einer Hook-Kette versteht man eine Liste von Verweisen auf Filterfunktionen (spezielle von der Anwendung definierbare Rückruf-Funktionen). Findet ein bestimmtes Ereignis statt, das mit einem konkreten Hook-Typ in Verbindung steht, so sendet das System nacheinander jeder Filterfunktion in der Hook-Kette eine Meldung. Welche Aktion von der jeweiligen Filterfunktion durchgeführt werden kann, hängt von dem Hook-Typ ab: Einige Funktionen können lediglich das Ereignis an sich verfolgen, andere sind in der Lage, die Parameter einer Meldung zu modifizieren oder gar die Verarbeitung einer Meldung zu stoppen, indem sie den Aufruf der nächsten Filterfunktion in der Hook-Kette oder die Verarbeitungsfunktionen der Fenster-Meldungen blockieren.


Abb. 8. Funktionsfilter-Kette in Windows

Wenn eine oder mehrere Filterfunktionen an einen Hook gekoppelt sind und ein Ereignis stattfindet, dass zur Aktivierung des Hooks führt, ruft das Betriebssystem Windows die erste Funktion aus der Funktionsfilter-Queue auf, womit dessen Verantwortlichkeit beendet ist. Im Folgenden ist die Funktion dafür verantwortlich, die nächste Funktion in der Kette aufzurufen, wofür die Funktion Win32 API CallNextHookEx verwendet wird.

Das Betriebssystem unterstützt verschiedene Hook-Typen, von denen jeder einzelne Zugriff auf einen der Aspekte des Bearbeitungsmechanismus von Windows-Meldungen ermöglicht.

Für einen Keylogger-Autoren sind fast alle Hook-Typen von Interesse: WH_KEYBOARD, WH_KEYBOARD_LL (Abfangen der Tastaturereignisse und deren Hinzufügen in die Ereignis-Queue des Threads), WH_JOURNALRECORD und WH_JOURNALPLAYBACK (Aufzeichnung und Wiedergabe der Maus- und Tastaturereignisse), WH_CBT (Abfangen einer Vielzahl von Ereignissen, einschließlich des Löschens der Tastaturereignisse aus der System-Hardware-Eingabe-Queue), WH_GETMESSAGE (Abfangen der aus der Ereignis-Queue des Threads empfangenen Ereignisse).

Allgemeines Bearbeitungsschema

Die bis hier dargestellten Abläufe der Tastatureingaberoutine lassen sich in einem einzigen Algorithmus der Signalübertragung zusammenfassen – von der Betätigung einer Taste durch den Anwender bis zum Erscheinen eines Zeichens auf dem Bildschirm:

  1. Beim Starten erzeugt das Betriebssystem im Systemprozess csrss.exe einen Raw Input Thread und eine System-Hardware-Eingabe-Queue.
  2. Der RIT sendet dem Tastaturklassentreiber Leseanfragen, die bis zum Eintreten eines Tastaturereignisses im Wartezustand verbleiben.
  3. Drückt oder löst der Anwender eine Taste auf der Tastatur, wird das Drücken/Lösen vom Mikrokontroller der Tastatur festgehalten und der Scan-Code der gedrückten Taste sowie eine Interruptanforderung werden an den Zentralcomputer gesendet.
  4. Der System-Tastaturkontroller empfängt den Scan-Code, wandelt ihn um, macht ihn am Eingabe-Ausgabe-Port 60h verfügbar und generiert einen Hardware-Interrupt des Zentralprozessors.
  5. Der Interrupt-Kontroller ruft die Interruptbehandlungs-Routine IRQ1 auf, eine IRS, die im System des Tastaturfunktionstreibers i8042prt registriert ist.
  6. Die IRS liest die aus der inneren Queue des Tastaturkontrollers erscheinenden Daten , übersetzt den Scan-Code in einen virtuellen Tastencode (unabhängige, vom System definierte Werte) und stellt den Aufruf des Deferred Procedure Calls I8042KeyboardIsrDpc in die Queue.
  7. Sobald wie möglich ruft das System den DPC auf, welcher wiederum die Rückruf-Routine KeyboardClassServiceCallback erzeugt, die im Tastaturklassentreiber Kbdclass registriert ist.
  8. Die Routine KeyboardClassServiceCallback zieht aus ihrer Queue die zu erledigende Anfrage des RIT und sendet in ihm die Informationen über die gedrückte Taste zurück.
  9. Der RIT speichert die empfangenen Informationen in der System-Queue der Hardware-Eingabe und erstellt auf deren Basis die grundlegenden Windows-Tastaturmeldungen WM_KEYDOWN, WM_KEYUP, die ans Ende der VIQ des aktiven Threads gestellt werden.
  10. Der Bearbeitungszyklus der Threadmeldungen löscht die Meldung aus der Queue und leitet sie an die entsprechende Fensterroutine zur Bearbeitung weiter. Dabei kann die Systemfunktion TranslateMessage ausgelöst werden, die auf der Basis der grundlegenden Tastaturmeldungen die zusätzlichen „symbolischen“ Meldungen WM_CHAR, WM_SYSCHAR, WM_DEADCHAR und WM_SYSDEADCHAR erzeugt.

Das Raw Input-Modell

Die oben beschriebenen Modelle der Tastatureingabe sind aus der Sicht von Anwendungs-Programmierern in mancherlei Hinsicht unzureichend. Zum Eingabe-Empfang von Nicht-Standardgeräten muss eine Anwendung nämlich eine ganze Reihe von Operationen durchführen: das Gerät öffnen, es periodisch abfragen, die Möglichkeit einer parallelen Nutzung des Gerätes durch eine andere Anwendung sicherstellen usw. Deshalb wurde in den letzten Windows-Versionen ein alternatives Eingabe-Modell – das Raw Input-Modell – angeboten, welches die Entwicklung von Anwendungen erleichtert, die Nicht-Standard-Eingabegeräte verwenden (s. Abb. 3, Anwendung DirectInput).

Das Raw Input-Modell unterscheidet sich von dem Original-Eingabemodell von Windows. Beim herkömmlichen Modell empfängt die Anwendung eine Geräte-unabhängige Eingabe in Form von Meldungen (wie etwa WM_CHAR), die an die Fenster der Anwendung gesendet werden. Das Raw Input-Modell sieht vor, dass die Anwendung die Geräte registriert, von denen sie Eingabe empfangen will. Weiterhin empfängt die Anwendung die User-Eingabe über die Meldung WM_INPUT.

Zwei Arten der Datenübertragung werden unterstützt, und zwar Standard und gepuffert; zur Interpretation der eingegebenen Daten muss die Anwendung Informationen über die Art des Eingabegerätes erhalten, was mit Hilfe der Funktion GetRawInputDeviceInfo ermöglicht wird.

Verschiedene Umsetzungen von Keyloggern

Ausgehend von den oben beschriebenen Bearbeitungsmodellen von Tastatureingabe im Betriebssystem Windows werden im Folgenden die grundlegenden Methoden zur Umsetzung von Keyloggern näher betrachtet. Ist der Aufbau des Modells klar, ist auch leichter zu verstehen, welche Mechanismen von Keyloggern ausgenutzt werden können.

Keylogger können an jeder beliebigen Stelle des Bearbeitungszyklus eindringen und Daten über gedrückte Tasten abfangen, die von einem Bearbeitungs-Subsystem zu dem nächsten Subsystem in der Editor-Chain übermittelt werden. Wir haben die zu untersuchenden Methoden der Umsetzung von Software-Keyloggern in solche des User-Mode und in solche des Kernel-Mode unterteilt. Auf Abbildung 9 sind alle Bearbeitungs-Subsysteme der Tastatureingabe und ihre Wechselbeziehungen miteinander dargestellt. An einigen Stellen der Abbildung befinden sich rot umkreiste Ziffern, die auf die Abschnitte der vorliegenden Analyse verweisen, in welchen die Umsetzungsmethode von Keyloggern beschrieben wird, die mit dem Austausch oder der Ausnutzung des jeweiligen Subsystems in Verbindung steht.


Abb. 9. Allgemeines Bearbeitungsschema von Tastatureingabe im Betriebssystem Windows

Dieser Abschnitt beschäftigt sich nicht mit Hardware-Methoden zur Umsetzung von Keyloggern. Es sei lediglich erwähnt, dass es drei grundlegende Spielarten von Hardware-Keyloggern gibt: Keylogger, die in die Tastatur selbst eingebaut werden, Keylogger, die in eine Unterbrechung des Kabels gebaut werden, das die Tastatur und den Systemblock miteinander verbindet und Keylogger, die in den Systemblock des Computers montiert werden. Am weitesten verbreitet ist der zweitgenannte Typ von Hardware-Keyloggern. Eines der bekanntesten Beipiele hierfür ist der KeyGhost USB Keylogger.

Leider sind derzeit nur wenige Antivirus-Lösungen auf dem Markt erhältlich, die das Sicherheitsniveau gewährleisten, das zum Schutz vor der potentiellen Gefahr, die Keylogger in sich bergen, dringend notwendig ist. Zu diesen Lösungen gehören die Produkte der Version 6.0 von Kaspersky Lab (genauere Informationen hierzu finden Sie in dem Bericht „Schutz vor Keyloggern mit Kaspersky Antivirus 6.0 und Kaspersky Internet Security 6.0“).

Keylogger des User-Mode

Die Keylogger des User-Mode sind sowohl in der Umsetzung als auch in der Entdeckung die simpelsten ihrer Art, da sie zum Abfangen Aufrufe bekannter und wohl dokumentierter Funktionen der Programmierschnittstelle Win32 API nutzen.

Installation des Hooks für Tastaturmeldungen

Hierbei handelt es sich um den wohl am weitesten verbreiteten Typ von Keyloggern. Durch den Aufruf der Funktion SetWindowsHookEx installiert der Keylogger einen globalen Hook auf die Tastaturereignisse für alle Threads im System (s. Abschnitt 2.6). Die Filterfunktion des Hooks positioniert sich in diesem Fall in einer einzelnen dynamischen Bibliothek, die in alle Prozesse eindringt, die an der Bearbeitung der Meldungen beteiligt sind. Bei der Auswahl aus der Meldungen-Queue eines beliebigen Threads der Tastaturmeldung ruft das System die installierte Filterfunktion auf.

Der Vorteil dieser Abfang-Methode liegt unter anderem in ihrer Einfachheit und der Garantie, dass sämtliche Tastenbetätigungen abgefangen werden. Die Nachteile bestehen darin, dass eine Datei der dynamischen Bibliothek vorhanden sein muss und dass die Entdeckung auf Grund des Eindringens in alle Systemprozesse recht einfach ist.

Zu Keyloggern dieser Machart gehören unter anderem: AdvancedKeyLogger, KeyGhost, Absolute Keylogger, Actual Keylogger, Actual Spy, Family Key Logger, GHOST SPY, Haxdoor, MyDoom.

Kaspersky Internet Security erkennt derartige Keylogger mit Hilfe des proaktiven Schutzmechanismus als invader (loader) (die Option „Eindringen von Hooks in Fenster“ des Subsystems „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz muss aktiviert sein).

Zyklische Abfrage des Tastaturzustands

Die im Folgenden beschriebene Methode zur Umsetzung von Keyloggern rangiert bezüglich ihrer Verbreitung auf Platz zwei. Der Zustand aller Tasten wird in kurzen Intervallen mit Hilfe der Funktionen GetAsyncKeyState oder GetKeyState abgefragt. Diese Funktionen senden die Datenfelder des asynchronen oder synchronen Tastaturzustands zurück (s. Abschnitt 2.5.3). Deren Analyse gibt Aufschluss darüber, welche Tasten nach der letzten Abfrage gedrückt oder gelöst wurden.

Von Vorteil ist, dass diese Methode einigermaßen einfach umzusetzen ist und kein zusätzliches Modul benötigt wird, wie im unter Punkt 3.1.1 beschriebenen Fall. Die Nachteile dieser Methode liegen darin, dass die Aufzeichnung aller Tastenbetätigungen nicht garantiert ist und es zu Lücken kommen kann. Überdies kann ein solcher Keylogger leicht entdeckt werden – durch die Überwachung der Prozesse, die die Tastatur mit hoher Frequenz abfragen.

Diese Methode wird unter anderem in den folgenden Keyloggern eingesetzt: Computer Monitor, Keyboard Guardian, PC Activity Monitor Pro, Power Spy, Powered Keylogger, Spytector, Stealth KeyLogger, Total Spy.

Kaspersky Internet Security erkennt derartige Keylogger proaktiv als Keylogger (die Option „Erkennen von Tastaturspionen“ des Subsystems „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz muss aktiviert sein).

Eindringen in den Prozess und Abfangen der Funktionen GetMessage/PeekMessage

Diese Methode zur Umsetzung von Keyloggern wird selten verwendet. Der Keylogger dringt in alle Prozesse ein und fängt in ihnen die Funktionen GetMessage oder PeekMessage aus der Bibliothek user32.dll ab (s. Abschnitt 2.5.2). Hierfür können verschiedene Methoden zum Einsatz kommen: Splicing, Modifikationen der Adress-Listen der in die IAT importierten Funktionen, Abfangen der Funktion GetProcAddress, die die Adresse der Funktion aus der geladenen Bibliothek zurücksendet. Der Keylogger kann als DLL realisiert werden oder durch das direkte Eindringen von Code in einen speziellen Prozess.

Das Ergebnis bleibt dasselbe: Wenn eine Anwendung beispielsweise die Funktion GetMessage zum Empfang der nächsten Meldung aus der Meldungs-Queue aufruft, gelangt dieser Aufruf in den Code des Tastaturspions. Dieser ruft die Ausgangsfunktion GetMessage aus der user32.dll auf und analysiert die zurückgesendeten Resultate hinsichtlich der Meldungstypen. Sobald eine Tastaturmeldung empfangen wird, werden alle sie betreffenden Informationen aus den Parametern der Meldung herausgezogen und vom Keylogger protokolliert.

Zu den Vorteilen dieser Methode gehört zweifellos ihre Effektivität: da sie nur wenig verbreitet ist, ist nur eine geringe Anzahl von Programmen in der Lage, derartige Keylogger zu finden; hinzu kommt, dass auch herkömmliche Bildschirmtastaturen nichts gegen diesen Keylogger-Typ ausrichten können, da die von ihnen versendeten Meldungen ebenso von ihm abgefangen werden.

Nachteile: Modifikationen der IAT-Tabellen können das Abfangen nicht garantieren, da die Adressen der Funktionen der Bibliothek user32.dll so lange gespeichert werden könnten, bis der Keylogger eindringt; das Splicing ist ebenfalls mit Schwierigkeiten verbunden, etwa auf Grund der Notwendigkeit, den Funktionskörper „on-the-fly“ zu überschreiben.

Kaspersky Internet Security erkennt derartige Keylogger mit Hilfe des proaktiven Schutzmechanismus als invader (die Option „Eindringen in Prozess (invaders)“ des Subsystems „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz muss aktiviert sein).

*Splicing - eine Methode, die zum Abfangen des Aufrufs von API-Funktionen genutzt wird. Das Wesen der Methode besteht im Austausch der ersten (normalerweise der ersten 5) Bytes der Instruktionsfunktion JMP, die die Steuerung an den Keylogger-Code weiterleitet.

Ausnutzung des Raw Input-Modells

Zum gegenwärtigen Zeitpunkt ist lediglich ein Beispiel für die Realisierung dieser Methode bekannt, und zwar ein Tool zur Austestung der Schutzfunktionen vor Keyloggern im System. Das Wesen dieser Methode besteht in der Ausnutzung des neuen Raw Input-Modells (s. Abschnitt 2.8), wobei der Keylogger die Tastatur als ein Gerät registriert, von dem er Eingabe empfangen will. Daraufhin beginnt der Keylogger Daten über gedrückte und gelöste Tasten über die Meldung WM_INPUT zu empfangen.

Die Vorteile dieser Methode liegen in ihrer Einfachheit und Effektivität: Da die gegebene Methode erst vor kurzem allgemein bekannt geworden ist, ist bisher kaum eine Sicherheitslösung in der Lage, vor derartigen Keyloggern zu schützen.

Der Nachteil besteht darin, dass Keylogger dieser Machart sehr einfach aufzuspüren sind, da eine spezielle Registrierung zum Empfang des Raw Input durch die Anwendung unerlässlich ist (in der Standardeinstellung wird der Raw Input von keinem einzigen Prozess im System empfangen).

Kaspersky Internet Security 7.0 wird Keylogger dieser Art proaktiv als Keylogger erkennen (die Option „Erkennen von Tastaturspionen“ des Subsystems „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz muss aktiviert sein).

Keylogger des Kernel-Mode

Keylogger des Kernel-Mode sind weitaus komplexer und komplizierter als Keylogger des User-Mode – sowohl in der Umsetzung als auch bezüglich ihrer Entdeckung. Ihre Entwicklung erfordert spezielle Programmier-Kenntnisse, doch das Ergebnis sind Keylogger, die für alle Anwendungen des User-Mode absolut unbemerkt bleiben. Zum Abfangen können sowohl die im Microsoft Driver Development Kit dokumentierte als auch andere, nicht dokumentierte Methoden verwendet werden.

Verwendung eines Treiberfilters des Tastaturklassentreibers Kbdclass

Hierbei handelt es sich um den im DDK dokumentierten Ansatz zum Abfangen der Tastatureingabe (s. Abschnitt 2.4.2). Nach diesem Modell konstruierte Keylogger fangen die Anfragen an die Tastatur durch die Installation eines Filters oberhalb des Gerätes “\Device\KeyboardClass0” ab, der von dem Treiber Kbdclass erzeugt wird (s. Abschnitt 2.4.3). Es werden ausschließlich Anfragen des Typs IRP_MJ_READ gefiltert, da gerade diese den Empfang der Codes gedrückter und gelöster Tasten ermöglichen.

Die Vorteile dieses Ansatzes: Alle Tastenbetätigungen werden garantiert abgefangen und eine Entdeckung ist ohne den Einsatz eines Treibers nicht möglich, weshalb viele Anti-Keylogger derartige Tastaturspione nicht erkennen.

Der Nachteil liegt in der Notwendigkeit, einen eigenen Treiber zu installieren.

Die bekanntesten Keylogger dieser Art sind ELITE Keylogger und Invisible KeyLogger Stealth).

Kaspersky Internet Security erkennt derartige Keylogger proaktiv als Keylogger durch ein Monitoring des Tastatur-Stacks der Geräte (die Option „Erkennen von Tastaturspionen“ muss im Subsystem „Aktivitätsanalyse für Anwendungen“ des Moduls Proaktiver Schutz aktiviert sein.

Verwendung eines Treiberfilters des Funktionstreibers i8042prt

Auch dies ist eine im DDK dokumentierte Abfang-Methode. Nach diesem Modell konstruierte Keylogger fangen die Anfragen an die Tastatur durch die Installation eines Filters “\Device\KeyboardClass0” oberhalb eines namenlosen Gerätes ab, erzeugt vom Treiber i8042prt unter dem Gerät (s. Abschnitt 2.4.3). Der Treiber i8042prt ist eine Programmierschnittstelle zur Ergänzung einer zusätzlichen Funktion zur Bearbeitung des IRQ1 (IsrRoutine), in der eine Analyse der von der Tastatur empfangenen Daten möglich ist.

Die Vor- und Nachteile entsprechen denen unter Punkt 3.2.1. In diesem Fall gibt es allerdings noch ein zusätzliches Manko – die Abhängigkeit vom jeweiligen Tastatur-Typ: Der Treiber i8042prt bearbeitet ausschließlich Anfragen von PS/2-Tastaturen. Aus diesem Grund ist die dargestellte Methode nicht zum Abfangen von über USB- oder Funk-Tastaturen übermittelten Daten geeignet.

Kaspersky Internet Security erkennt derartige Keylogger proaktiv als Keylogger durch ein Monitoring des Tastatur-Stacks der Geräte (die Option „Erkennen von Tastaturspionen“ muss im Subsystem „Aktivitätsanalyse für Anwendungen“ des Moduls Proaktiver Schutz aktiviert sein).

Modifikation der Bearbeitungstabelle der Systemanfragen im Treiber Kbdclass

Nach dieser Methode konstruierte Keylogger fangen die Anfragen an die Tastatur ab, indem sie den Eingabepunkt IRP_MJ_READ in der Bearbeitungstabelle der Systemanfragen (dispatch table) des Treibers Kbdclass austauschen. Der Funktionalität nach ist dies dem Treiberfilter des Treibers Kdbclass sehr ähnlich (s. Abschnitt 3.2.1). Auch die Vor-und Nachteile sind dieselben. Eine andere Variante fängt die Funktion des Anfrage-Editors IRP_MJ_DEVICECONTROL.B ab. In diesem Fall ähnelt der Keylogger dem Treiberfilter des Treibers i8042 (s. Abschnitt 3.2.2).

Kaspersky Internet Security erkennt derartige Keylogger proaktiv als Keylogger (die Option „Erkennen von Tastaturspionen“ muss im Subsystem „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz aktiviert sein).

Modifikation der Tabelle der Systemdienste KeServiceDescriptorTableShadow

Hierbei handelt es sich um ein recht verbreitetes Keylogger-Modell, welches analog zu der unter Punkt 3.1.3 beschriebenen Umsetzungs-Methode des User-Mode funktioniert. Keylogger dieser Machart realisieren das Abfangen der Anfragen an die Tastatur durch ein Patching des Eingabepunktes NtUserGetMessage/PeekMessage in der zweiten Tabelle der Systemdienste (KeServiceDescriptorTableShadow) des Treibers win.32k.sys. Die Informationen über Tastenbetätigungen gelangen in den Keylogger, wenn in irgendeinem Thread die Funktionen GetMessage oder PeekMessage aufgerufen werden.

Die Methode hat den Vorteil, dass auf diese Weise realisierte Keylogger nur sehr schwer entdeckt werden, ihr Nachteile liegen in der relativ komplizierten Umsetzung (die Suche nach d Tabelle KeServiceDescriptorTableShadow selbst ist nicht einfach. Hinzu kommt das Problem, dass andere Treiber den Eingabepunkt in dieser Tabelle bereits gepatcht haben können) und in der Notwendigkeit, einen separaten Treiber zu installieren.

Kaspersky Internet Security erkennt derartige Keylogger proaktiv als Keylogger (die Option „Erkennen von Tastaturspionen“ muss im Subsystem „Aktivitätsanalyse für Anwendungen“ im Modul Proaktiver Schutz aktiviert sein).

Modifikation der Funktionen NtUserGetMessage / NtUserPeekMessage durch Splicing

Keylogger dieses Typs sind höchst selten anzutreffen. Nach dieser Methode realisierte Keylogger fangen die Anfragen an die Tastatur ab, indem sie den Code der Funktionen NtUserGetMessage oder NtUserPeekMessage mit Hilfe von Splicing modifizieren. Die genannten Funktionen sind im Systemkernel im Treiber win32k.sys realisiert und werden aus den entsprechenden Funktionen der Bibliothek user32.dll aufgerufen. Wie in Abschnitt 3.1.3 beschrieben, ermöglichen diese Funktionen das Filtern aller von den Anwendungen empfangenen Meldungen und den Empfang von Informationen über das Drücken und Lösen von Tasten aus den Tastaturmeldungen.

Der Vorteil dieser Art von Keylogger: Sie werden nur sehr schwer entdeckt. Die Nachteile liegen in der komplizierten Umsetzung (der Funktionskörper muss „on-the-fly“ überschrieben werden, Keylogger dieser Art sind abhängig von der Version des Betriebssystems und der installierten Software) und der Notwendigkeit einen Treiber zu installieren.

Austausch des Treibers im Tastatur-Stack der Treiber

Diese Methode basiert auf dem Austausch des Treibers Kbdclass oder eines Tastaturtreibers der unteren Ebene mit einem selbst entwickelten Treiber. Der eindeutige Nachteil dieser Methode besteht in der komplizierten Umsetzung, da im Vorwege nicht bekannt ist, welcher Tastatur-Typ vom User verwendet wird und der Austausch des Treibers daher recht einfach entdeckt wird. Aus diesem Grund wird diese Methode in der Praxis so gut wie nie umgesetzt.

Entwicklung eines Treibers zur Bearbeitung des Interrupts IRQ1

Zur Realisierung dieser Methode ist das Programmieren eines eigenen Kernel-Treibers notwendig, der den Tastaturinterrupt (IRQ1) abfängt und direkt an die Eingabe-Ausgabe-Ports (60h, 64h) geleitet wird. Auf Grund der komplizierten Umsetzung dieser Methode und der nicht ganz klaren Art von Wechselwirkungen mit dem im System integrierten „Bearbeiter“ des Interrupts (Treiber i8042prt.sys) ist diese Methode zum gegenwärtigen Zeitpunkt noch reine Theorie.

Fazit

In der vorliegenden Analyse wurde der Algorithmus der Datenübertragung vom Drücken einer Taste auf der Tastatur durch den Anwender bis zum Erscheinen eines Zeichens auf dem Bildschirm dargestellt, des weiteren wurden die einzelnen Glieder der Signal-Bearbeitungskette analysiert und die verschiedenen Umsetzungen von Keyloggern, die auf dem Abfangen von Tastatureingabe auf bestimmten Etappen des beschriebenen Algorithmus basieren, genauer beschrieben.

  1. Das hier untersuchte Schema der Tastatureingabe im Betriebssystem Windows ist hinreichend kompliziert und auf praktisch jedem Anschnitt dieses Ablaufs könnte ein Keylogger installiert werden. In einigen Anschnitten ist dies bereits der Fall, in anderen bisher noch nicht.
  2. Es besteht eindeutig ein Verhältnis zwischen dem Verbreitungsgrad von Keyloggern und der Komplexität ihrer Entwicklung. Daher gehören die am weitesten verbreiteten Realisierungs-Methoden von Keyloggern - nämlich die Installation von Hooks auf Eingabeereignisse und die zyklische Abfrage der Tastaturzustände – auch gleichzeitig zu den am einfachsten umsetzbaren Keylogger-Typen. Ein derartiger Tastaturspion kann selbst von jemandem geschrieben werden, der erst vor einer Woche mit dem Programmieren angefangen hat.
  3. Die breite Masse der derzeit existierenden Keylogger ist ein relativ einfach umzusetzendes Instrument, das problemlos zu unlauteren Zwecken eingesetzt werden kann – in erster Linie zum Diebstahl von über die Tastatur eingegebenen vertraulichen Informationen.
  4. Antivirushersteller müssen ihre Kunden unbedingt vor den Bedrohungen schützen, die von Keyloggern in den Händen von Kriminellen ausgehen können.

Da die Schutzmechanismen immer ausgereifter werden, sind die Keylogger-Autoren gezwungen, sich mit der Umsetzung immer komplizierterer Tastaturspione – unter anderem solcher, die die Kernel-Treiber des Betriebssystems Windows nutzen – auseinanderzusetzen. In diesem Bereich eröffnet sich ihnen noch eine Vielzahl von Möglichkeiten.

Quelle:
Kaspersky Lab
 

Copyright © 1996 - 2014
Kaspersky Lab
Industry Leading Antivirus Software
Alle Rechte vorbehalten
 

Email: webmaster@kaspersky.com
Datenschutzbestimmungen