Simulierte
Hackerangriffe
Die Durchführung
kontrollierter Hackerangriffe auf das eigene Computernetz wird auch als
Penetrationstest bezeichnet. Es werden dabei die selben Mittel eingesetzt,
die auch ein fremder Angreifer benutzen würde, um sich unberechtigten
Zugriff auf ein Computernetzwerk zu verschaffen.
Ziel
Ein Penetrationstest soll Aufschluss über die Widerstandsfähigkeit
eines Systems gegenüber Hackerangriffen geben. Wie bei einfachen Sicherheitsscans
wird dabei gleichzeitig die Funktionsfähigkeit der vorhandenen Absicherungsmaßnahmen
wie Firewall, System Logging und Intrusion Detection getestet.
Durchführung
Um die gestellten Aufgaben erfüllen zu können, ist der alleinige
Einsatz von Standard-Security-Scannern nicht ausreichend. Im Rahmen eines
kontrollierten Hackerangriffs erfolgt daher zusätzlich eine vorsichtige
Aufklärung des Zieles, wobei möglichst unauffällig potentielle
Einbruchspunkte identifiziert werden. Daran anschließend erfolgt ein
gezielter Testangriff gegen die gefundenen Schwachstellen.
Vor der Durchführung eines kontrollierten Hackerangriffs
wird in Absprache mit dem Kunden festgelegt, welche Arten von Angriffen
durchgeführt werden sollen und welche Teile der IT Infrastruktur nicht
angegriffen werden dürfen.
Sicherheitsmanagement
Kontinuität
Um die Sicherheit einer IT Infrastruktur auf Dauer zu gewährleisten,
ist es notwendig, ihre sicherheitsrelevanten Komponenten kontinuierlich
zu betreuen.
Sicherheit von Grund auf
Das Sicherheitsmanagement von Computernetzwerken setzt sich aus aufeinander
aufbauenden Komponenten zusammen: Sicherheitsbewusster Betrieb von Servern,
Administration von Firewalls und Intrusion Detection Systemen (IDS/NIDS),
Logfileverwaltung sowie Analyse von Veränderungen des Netzwerkes.
Sicherer Serverbetrieb
Die kontinuierliche Wartung und Aktualisierung der verwendeten Serversoftware
bilden die Grundlage der Netzwerksicherheit. Dies verhindert ein Eindringen
über bekannte Sicherheitslücken älterer oder fehlkonfigurierter
Versionen der angebotenen Dienste.
Firewall
und IDS
Der Betrieb einer Firewall und eines IDS zur frühzeitigen Erkennung
und Abwehr von Angriffsversuchen ist ein weiterer zentraler Bestandteil
der Gesamtsicherheit eines Computernetzwerkes. Auch hierbei ist die Verwendung
der jeweils aktuellen Softwareversionen von entscheidender Bedeutung.
Logfile Management
Durch die regelmäßige Analyse der anfallenden Protokolldateien
von Servern, Firewalls und IDS wird das gesamte Netzwerk auf Anzeichen einer
erfolgten Kompromittierung überprüft.
Analyse
von Veränderungen
Da Veränderungen einer IT Infrastruktur immer auch sicherheitsrelevant
sein können, gehört auch die regelmäßige Analyse und
Protokollierung dieser Veränderungen zu einem umfassenden Sicherheitsmanagement.
Windows XP aufllig gegen Hackerangriffe
Auch die neueste Windows-Version der Softwareschmiede Microsoft, Windows
XP, ist gegen Hackerangriffe nicht gefeit. So kann es Hackern gelingen,
in einen PC einzudringen, Daten zu "stehlen" und den Computer
fernzusteuern. Das Unternehmen hat bereits mehrere Updates zur Verfügung
gestellt, um die Lücken notdürftig zu stopfen. Windows XP war
als das bisher sicherste Windows angeboten worden. Ein Microsoft-Sprecher
gestand unterdessen ein, dass das Risiko für die User nicht zu untersch?tzen
sei.
Hacker, denen es gelingt in den Computer der das XP-Betriebssystem
nutzt einzudringen, k?nnen den Computer auch vollst?ndig blockieren, so
dass der User sich nur noch ins Internet verbinden kann.
Auf der Microsoft-Website gibt es unterdessen bereits Sicherheits-Sets,
die die Home- und die Professional-Editions von Windows XP flicken. Bisher
wurden weltweit bereits rund sieben Millionen XPs verkauft. Das neue Betriebssystem
gibt es seit dem vergangenen 25. Oktober im Handel. Die Sicherheitslücken
waren von den Spezialisten der eEye Digital Security Inc im us-amerikanischen
Bundesstaat Kalifornien entdeckt worden. Der Chef eEyes, der ehemalige Hacker
Marc Maiffret, hatte zuvor bereits das FBI und das Weisse Haus in Washington
in Internetsicherheits-Angelegenheiten beraten.
Ein Sicherheitsloch in XP findet sich in der Anwendung
mit dem Namen "universal plug and play". Dieses Feature wird jedoch
in jeder Windows-XP-Kopie aktiviert und kann auch in Windows-Vorg?ngerversionen
integriert werden.
Scott Culp, Manager in Microsofts Security Response Centre,
erkl?rte: "Dies ist das erste Mal, dass in ein Windows Desktop-System
unerlaubt über das Netz zugegriffen werden kann. Jeder Windows-XP-User
sollte unverzüglich Sicherheitsma?nahmen zu seinem eigenen Schutz einleiten."
Ein neues Feature mit dem Namen "drizzle", so Microsoft, solle
in der Lage sein, automatisch die bereitgestellte Sicherheitssoftware herunterzuladen
und zu installieren. Microsoft arbeitet unterdessen, gemeinsam mit weiteren
Softwareunternehmen, an einem neuen Schutz ihrer, von ihnen selbst entwickelten
Software.
Computer-Viren:
Kurzbeschreibungen zu Hoaxes
Virus-Meldungen
(Hoaxes, elektronische "Enten")
Mittels E-Mail werden seit ca. 5 Jahren häufig "Virus-Meldungen"
verschickt, die vor einem "ganz neuen, gefährlichen" Virus
warnen, der schon beim bloßen Lesen einer E-Mail aktiviert wird und
sofort Daten löscht oder die Festplatte formatiert.
Die Meldungen stimmen jedoch nicht, sie sollen nur ungeschulte
Computernutzer bei ihrer Hilfsbereitschaft und Gutmütigkeit ansprechen
und zu schädlichen Aktionen veranlassen.
Eine solche Meldung wird deshalb als Hoax (englisch für
Zeitungsente) bezeichnet. Man muß dazu wissen, daß jeden Monat
ca. 300 neue Viren und ähnliche Schadsoftware bekannt werden, die nicht
gefunden werden, solange sie "ganz neu" sind. Nach ca. 2 Tagen haben
die Hersteller von Anti-Virus-Software die Erkennung in Ihre Programme eingebaut.
Würde für jeden neuen Virus eine Warnung verbreitet...
Der Anwender kann Hoaxes an vier charakteristischen Merkmalen
erkennen:
- Es wird dazu aufgefordert, die Meldung an möglichst viele andere
Nutzer zu verteilen.
- Es handelt sich um einen Virus der so neu ist, daß kein Anti-Viren-Programm
in momentan findet, und er löscht schon beim Lesen der E-Mail sofort
Daten.
- Die Information stammt von einer Autorität. (Beispiele: Microsoft,
AOL, Polizei, Rundfunk)
- Die originale E-Mail-Adresse des ursprünglichen Absender oder eine
konkrete WWW-Adresse ist nicht vorhanden.
Der Name der gefährlichen Datei ist das Einzige, was ständig verändert
wird. Die Meldung darf
nicht
sofort weiter geleitet werden. Wenn jeder Anwender (oder auch nur viele)
dies tun, wird das E-Mail-System überlastet und blockiert. Das ist die
Schadensfunktion, die der anonyme Urheber der Meldung bezweckt.
Im Normalfall ist der behauptete Sachverhalt frei erfunden,
jedoch technisch nicht völlig unmöglich, wenn in der E-Mail aktive
Inhalte verwendet werden.
Maßnahmen:
a) Anwender
Alle Virus-Meldungen zur Kenntnis nehmen und anschließend sofort löschen.
Nicht weiterleiten, nicht den Systemadministrator oder Benutzerdienst anrufen
und nachfragen!
b) Systemadministrator
Die Meldung auf die obigen Merkmale prüfen. Treffen auch nur einige davon
zu, so handelt es sich um einen Hoax. Andernfalls sollte auf den Internetseiten
des Herstellers oder Lieferanten der benutzten Viren-Schutz-Software geprüft
werden, ob dort schon Gegenmittel oder weitere Informationen bereit stehen.
Die sogenannten News-Ticker der Computer-Zeitschriften im Internet veröffentlichen
solche Informationen ebenfalls frühzeitig. Auf den unten angegebenen
Internetseiten kann man auch prüfen, ob dieser Hoax schon bekannt ist.
Hier finden Sie ein Beispiel eines Hoax
Namen
einiger bekannter Hoaxes
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z $ 0 1
2 3 4 5 6 7 8 9
Ziel dieses Abschnittes ist es,
-
allgemeine Informationen zum Thema Buffer Overflow
zu vermitteln, und
-
an einem konkreten Beispiel nachzuvollziehen, wie
schwer/leicht es ist, solch einen Fehler zu nutzen. Dazu wird der Weg
eines Angreifers vom Finden des Buffer Overflows bis zum fertigen Exploit
nachvollzogen.
Ein Buffer Overflow entsteht immer dann, wenn eine Datenstruktur
zu klein ist für die Menge an Daten, die sie aufnehmen soll und weder
vom Programmierer, noch von der Programmiersprache, noch vom Betriebssystem
Vorkehrungen getroffen werden, die verhindern, daß die überschüssigen
Daten existierende Daten überschreiben.
Ein häufiges Beispiel sind Strings, die den für sie mit einer bestimmten
Länge angelegten buffer sprengen.
Ein Beispiel (in C):
void func() {
int i;
char buffer[256];
for (i = 0; i < 512; i++) {
buffer[i] = 'a';
}
}
Hier wird zunächst für den character buffer eine Länge von
256 bytes festgelet, dann werden aber in der Schleife 512 'a's in den buffer
geschrieben. C besitzt keine automatische Kontrolle für die Zugriffe
auf ein Array (Wie sie zum Beispiel Java besitzt, das immer wenn ein falscher
Index für ein Array angegeben wird, eine ArrayIndexOutOfBoundsException
aufwirft - bzw. eine StringIndexOutOfBoundsException bei Strings).
Wohin kommen die überschüssigen 'a's?
Sehen wir uns einen "normalen" Windows-32bit Stack nach dem Aufrunf
der Funktion func() und dem Deklarieren der Variablen an:
Würde kein Überlauf stattfinden, würde (auf
Assembler-Ebene) Folgendes passieren, wenn die Funktion beendet ist:
Der alte Wert des Basepointers (EBP) wird wiederhergestellt.
Eine POP-Operation holt die Rücksprungadresse vom Stack.
Schließlich wird an diese Stelle gesprungen und die Ausführung
des Programms läuft an der Rücksprungadresse weiter.
Was passiert nun beim Buffer Overflow? Da vom Stackpointer (ESP) aus gesehen
nach unten in den Buffer geschrieben wird, überschreiben die zusätzlichen
'a's zunächst den alten Wert von EBP und dann die Return-Adresse. Die
Folge davon ist, dass je nachdem was in den überschüssigen Bytes
steht, die Adresse an der die Programmausführung nach beenden der Funktion
weitergeht, (fast) beliebig beeinflusst werden kann.
Stellt man sich nun vor, daß keine 'a's in den Buffer geschrieben werden,
sondern ein manipulierbarer String (etwa die Eingabe aus einem Textfeld, oder
es wird aus einer Datei eingelesen), sieht man, daß dies eine optimale
Angriffsmöglichkeit bietet.
Hier haben wir also ein typisches Beispiel für einen Stack Overflow.
Es gibt noch andere Arten von Buffer Overflows, z.B. den Heap Overflow, die
aber wesentlich schwerer auszunutzen sind (da keine direkte Manipulation des
Befehlszeigers möglich ist).
Allgemeine Voraussetzungen
Für das Finden und nutzen eines Buffer Overflows braucht ein Angreifer
also:
gute Programmierkenntnisse (C & Assembler)
Wissen über die Vorgänge im betreffenden Betriebssystem (z.B. Aufbau
des Stacks, Realisierung von Funktionsaufrufen, Laden von Bibliotheken, ...)
Glück im Auffinden von Buffer Overflows
und natürlich genügend kriminelle Energie, um das ganze dann auch
einzusetzen
Folgende Hilfsmittel sind dafür wichtig:
Hex-editor, zum Durchsuchen und Erstellen der Strings
Ein realtime debugger, zur Untersuchung des Zustandes des Computers, z.B.
nach einem Programmabsturz (den ein Buffer Overflow ja meist verursacht)
dumpbin(Teil von MS Visual C++) o.ä., zur Untersuchung von Binärdateien
Das konkrete Beispiel: Microsoft NetMeeting
Microsoft Netmeeting ist ein Online-Conferencing System mit
erweiterten Funktionen, z.B. Chat oder Whiteboard.
Wichtig für diesen Fehler: Informationen über die eigene Erreichbarkeit
können in einer .cnf Datei, z.B. auf einer Webseite oder als Anhang einer
email weitergegeben werden. Dazu erstellt der Benutzer einen sog. Kurzwahleintrag.
In dieser Textdatei befinden sich alle Informationen, die man braucht, um
diesen Benutzer mit Netmeeting zu erreichen.
Eine normale Kurzwahldatei sieht z.B. so aus:
[ConferenceShortcut]
ConfName=uls.microsoft.com/email
Address=uls.microsoft.com/email
CallFlags=65539
Transport=5
Wie findet man einen Buffer Overflow?:
Die meisten dieser Fehler treten, wie bereits gesagt, im Zusammenhang mit
Strings auf. Ein Angreifer auf der Suche nach einem Buffer Overflow wird
also zunächst einmal Stellen im Programmablauf suchen, an denen der
Benutzer einen String eingeben oder auf andere Art vorgeben kann und dort
einen möglichst langen String unterbringen, in der Hoffnung, den zugrundeliegenden
Buffer zum Überlauf zu bringen.
Wie erkennt der Angreifer nun, ob ein String zum Überlauf geführt
hat? Meistens bewirkt ein Buffer Overflow etwa folgendes:
Nicht jedes Auftreten dieses ja doch relativ häufigen Dialogs bedeutet,
dass man auf einen Buffer Overflow gestossen ist, aber sehen wir genauer
hin:
Der Fehler tritt an der Adresse 0000:61616161 auf, der Befehlszähler
(EIP) zeigt also auf 0x61616161. Da der Dialog ansonsten relativ wenig nutzbare
Informationen liefert (der Fehler trat in RUNDLL32.exe im Modul unbekannt
auf), ist diese Anomalität genau das, wonach ein Angreifer sucht.
Dieser spezielle Fehler wurde verursacht, indem in einem Kurzwahleintrag
für Netmeeting ein langer String für das Feld "Address"
angegeben wurde:
[ConferenceShortcut]
ConfName=uls.microsoft.com/email
Address=aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa......
........aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
CallFlags=65539
Transport=5
Das 'a' hat in ASCII den Wert 0x61, also lässt sich annehmen, daß
vier der 'a's irgendwie in den Befehlszähler gelangt sind.
Ein weiterer Versuch mit 'b's statt 'a's liefert die Bestätigung:
Hier passiert also dasselbe mit dem Wert 0x62, dem ASCII-Wert für
'b'. Es wurde also ein Buffer Overflow gefunden.
Die Reaktion von Netmeeting (außer der Fehlerdialogbox) sieht so aus:
Ziel des Angreifers wird es also sein, eine geeignete .cnf/Kurzwahleintrag-datei
in emails oder auf Webseiten unterzubringen. Dazu noch ein verlockender
Text, der Benutzer/Besucher dazu auffordert, diesen Kurzwahleintrag zu verwenden
(Bei der heutigen Masse an Spam sollten die Möglichkeiten und Wege
dafür bekannt sein).
Weiteres Vorgehen:
Um den eben gefundenen Fehler dazu nutzen zu können, eigenen Code
auf dem Computer des Benutzers, der den Kurzwahleintrag angeklickt hat,
auszuführen, muß der Angreifer nun Schritt für Schritt weitere
Informationen sammeln. Es stellt sich auch heraus, daß er mit Schwierigkeiten
zu kämpfen hat, denen sich ein "normaler" Programmierer eher
selten gegenübersieht.
Zunächst muss die genaue Länge des Buffers für die Adresse
gefunden werden. Durch Ausprobieren ermittelt man, daß es 256 bytes
sein müssen, da ab einem byte mehr bereits ein Programmabsturz auftritt,
ab fünf bytes mehr sich die bytes direkt in den Befehlszähler
schreiben - man erinnere sich, daß auf dem Windows-Stack zwischen
dem Buffer und der Rücksprungadresse noch der alte wert von EBP liegt
(4 bytes).
Der Angreifer weiss, daß der Fehler in RUNDLL32.exe liegen muß,
das stand in der Fehlermeldung.
Was weiter passiert, kann man aus der in der Registry gespeicherten Aufrufsyntax
für .cnf-files ablesen:
rundll32.exe msconf.dll,OpenConfLink %1
Es wird also mittles RUNDLL32 die Bibliothek MSCONF.DLL geladen und dort
die Funktion OpenConfLink mit dem Namen der Kurzwahleintragdatei als Parameter
aufgerufen.
Sieht sich der Angreifer nun mittels dumpbin MSCONF.DLL genauer an, sieht
er, daß auch KERNEL32.DLL geladen ist.
Warum? Hier ein kleiner Exkurs zum Thema "import tables von .exe und
.dll Dateien":
Jede Datei, die ausführbahren Code enthält, der Funktionen verwendet,
die außerhalb dieser Datei definiert sind, enthält eine Tabelle
die diese Funktionen und die Adressen, an denen die Funktionen aufzufinden
sind, auflistet. Diese Tabelle kann mit einem Programm wie dumpbin extrahiert
und in menschenlesbare Form gebracht werden. Da die import table von MSCONF.DLL
Funktionen aus KERNEL32.DLL auflistet, kann der Angreifer davon ausgehen,
daß KERNEL32.DLL geladen ist.
Da Netmeeting selbst nach dem Auftreten des Fehlers nicht abstürzt,
kann der Angreifer ableiten, daß der Vorgang mit dem Buffer Overflow
in einem eigenen Prozess ausgeführt wird.
Das führt bereits zum ersten Problem: es bedeutet nämlich, dass
vermutlich kaum andere DLLs mit interessanten Funktionen geladen sind. Möchte
der Angreifer also weitere Betriebssystemfunktionen, zum Beispiel Internet-
oder Grafik-Funktionen, nutzen, muss er eine Möglichkeit finden, die
entsprechenden Bibliotheken zu laden.
Ein weiteres Problem stellt die Unterbringung des gewünschten Codes
im Adressstring dar.
Das ganze muß, auch wenn es versteckten Code enthält, immer noch
ein String sein, der vom Programm richtig gelesen wird. Solche Strings sind
"null-terminiert", d.h. ein byte mit dem Inhalt 0x00 (oder '\0'
in C) beendet den String und der Rest der Zeile wird ignoriert. Ebenso problematisch
können bytes sein, die Sonderzeichen darstellen ('\n', '\t').
Der Adressstring darf also keine solchen Zeichen enthalten. Dies stellt
ein großes Problem dar, da vor allem Adressen im Speicher häufig
null-bytes enthalten. RUNDLL32.exe hat in diesem Fall z.B. die Basisadresse
0x00400000.
Zunächst jedoch muß der Angreifer die Kontrolle über den
Befehlszeiger erlangen.
Dazu ist es wichtig zu wissen, dass es für ihn prinzipiell zwei Möglichkeiten
gibt, den eigenen Code im betreffenden String (also in diesem Fall im Adress-String)
unterzubringen.
Die erste Möglichkeit besteht darin, den Code vor den bytes, die die
Rücksprungadresse überschreiben, also in den "regulären"
256 bytes unterzubringen. Dies limitiert zwar den Platz für den Code
auf 256 bytes, erlaubt es aber, in der Adresse, die die Rückkehradresse
überschreiben soll, das höchste byte (little-endian!) auf 0x00
zu setzen, was häufig nötig ist (man erinnere sich an die Basis-Adresse
von RUNDLL32.exe). Dieses Vorgehen ist oft, so auch in diesem Fall, nicht
möglich. Der Grund ist, dass bevor die fehlerhafte Funktion beendet
ist, mit dem Adessstring noch String-Operationen vorgenommen werden, d.h.
es wird versucht, den String zu decodieren, dabei wird der String aber verändert.
Also muß der Code nach den die Rücksprungadresse überschreibenden
bytes platziert werden. Die Anzahl bytes die man hier unterbringen kann,
hängt davon ab, wie weit hinter dieser Stelle für den weiteren
Verlauf wichtige Daten überschrieben werden. In diesem Fall stellt
sich heraus, dass der Angreifer ca. 500 bytes unterbringen kann, bevor er
einen weiteren (und diesmal ungewollten) Absturz produziert. Hier stellt
sich allerdings das Problem, dass die Adresse, mit der die Rücksprungadresse
überschrieben wird, natürlich keine null-bytes enthalten darf
(da der String ja sonst abgeschnitten würde und den Stack nicht mehr
überschreibt). Ein Platzieren des Befehlszählers in den gewünschten
Bereich (irgendwo knapp über 0x00400000) ist also direkt nicht möglich.
Die Lösung des Problems für den Angreifer besteht nun darin, einen
realtime debugger zu verwenden, den Fehler auftreten zu lassen (den Adressstring
also so zu wählen, daß die Rücksprungadresse mit beliebigem
(und damit wahrscheinlich ins Leere zeigenden) Müll überschrieben
wird. Mittels des Debuggers untersucht der Angreifer nun den Zustand des
Prozessors zum Zeitpunkt des Absturzes und sucht nach einem Register (EAX,
EBX, ECX, EDX, ESI, EDI, ESP, EBP, ...), das in den Bereich zeigt, den er
manipulieren kann (also im überschriebenen Stack zwischen der neuen
Rücksprungadresse und dem Ende des überschriebenen Bereichs).
In diesem Fall ist dies der Stackpointer ESP. Nun muß der Angreifer
noch eine Code-Adresse suchen, die einerseits keine null-character enthält,
an der aber ein Sprung zum Stackpointer (JUMP ESP o.ä.) ausgeführt
wird. Er durchsucht mittles dumpbin die Dateien, von denen er weiß,
daß sie zum entsprechenden Zeitpunkt geladen sind, und findet den
entsprechenden Code in MSCONF.DLL an der Adresse 0x6A602A76. Die Adresse
enthält keine "gefährlichen" bytes, kann also verwendet
werden.
Nun kann der Angreifer den Adressstring seiner .cnf-Datei so bauen, dass
die Rücksprungadresse mit 0x6A602A76 überscrieben wird und dass
der Code, den er auf dem Computer ausführen möchte, an der Stelle
beginnt, auf die der Stackpointer zeigt.
Die Folge des ganzen ist also nun, daß der Angreifer ca. 500 bytes
(fast - es bleibt noch das Problem mit den null-bytes) beliebigen Code auf
dem Computer ausführen kann.
Der Angreifer kann nun seinen Exploit erstellen. Da 500 bytes relativ wenig
sind, wird er wohl ein Programmstück schreiben, daß eine Verbindung
ins Internet aufbaut, dann von einer bestimmten Adresse ein (nun beliebig
großes) Programm herunterlädt und dies dann ausführt.
Betrachten wir nun noch einige weitere Probleme für den Angreifer,
die ein "normaler" Programmierer selten vorfindet:
Zunächst kennt er die Adressen von vielen interessanten Funktionen,
die er gerne verwenden möchte, nicht, selbst wenn er weiss, dass die
DLL, die diese Funktionen definiert, geladen ist. Andererseits muß
er wahrscheinlich neue DLLs laden, z.B. für den Aufbau einer Internetverbindung.
Für beide Probleme gibt es API-Funktionen, die sich verwenden lassen:
Um die Adresse einer bestimmten Funktion herauszubekommen, gibt es die Funktion
GetProcAddress; zum Laden neuer DLLs gibt es LoadLibraryA. Nur: An welcher
Adresse befindet sich GetProcAdress? Man müßte GetProcAddress
aufrufen, um das "legal" herauszufinden.
Der Angreifer durchsucht nun abermals MSCONF.DLL mittels dumpbin, und findet
heraus, dass beide Funktionen in der import table gelistet sind, sogar an
Adressen ohne null-bytes.
Er kann jetzt also neben dem Code den er ausführen möchte auch
die Namen der DLLs, die er laden will und der Funktionen, die er aufrufen
will, in dem Adressstring unterbringen und diese dann als Parameter für
GetProcAddress bzw. LoadLibraryA verwenden. Ebenso die URL, zu der er sein
Programm eine Verbindung ausführen lassen will.
Problem: auch diese Namen sind natürlich null-terminierte Strings.
Wie bringt man diese Strings im Adressstring unter, ohne ihn abzuschneiden?
Kein ASCII-Wert eines Buchstabens eines Funktionsmanens, Bibliotheksnamens
oder der URL hat einen Wert grösser als 0x80. Daher speichert der Angreifer
seine Strings nicht direkt, sondern nimmt jedes byte zunächst XOR 0x80,
sodass alle null-character nun einen "ungefährlichen" Wert
von 0x80 haben. Nachteil dieser Lösung ist, dass das Exploit-Programm
die Strings natürlich erst decodieren muss, bevor es sie verwendet.
In diesem speziellen Fall sah der entsprechende Teil des Adressstrings (hexadekadisch)
so aus:
nach dem XOR dagegen sah das ganze dann so aus:
Es sind also keine null-character mehr vorhanden.
Für ausführlichere Informationen, z.B. zum decodieren der Strings
und zum tatsächlichen Exploit siehe Quellverweis.
Die Kurzwahldatei, die dann zum Fehler und zum ausführen des Exploits
führt, sieht dann so aus:
[ConferenceShortcut]
ConfName=explode
Address=>...........................................................................................................................................................
........................................................................................................1234v*`j3ɸ€Sÿc,€ÁÀ
±´H€0€âú¾|`jPPÿ‹ð[‹ûfïKÿü3É€éúC2ÀׄÀuøCQSVÿx`j«YâêC2ÀׄÀuøCSSÿ|`j‹ð
3ɃéüC2ÀׄÀuøCQSVÿx`j«Yâê3ÀfHÑà3ÒPRÿWì‹ð3ÒRRRRWÿWð3ÒRRRR‹×ƒêP
RPÿWøW3ÒfJÑâRVPÿWü3ÒR‹×ƒê0BRÿWØÿ7VP‹ØÿWÜSÿWà3ÒBR‹×ƒê0BRÿWä
ÿWèÌÌÌ---------------------------------------------------------------------ËÅÒÎÅ̳²€ßìãòåáô€ßì÷òéôå€ßìãìïóå€×éîÅøåã€ÅøéôÐòïãåóó€ÇìïâáìÁììïã€×ÉÎÉÎÅÔ€ÉîôåòîåôÏðåîÁ€Éîô
åòîåôÃìïóåÈáîäìå€ÉîôåòîåôÏðåîÕòìÁ€ÉîôåòîåôÒåáäÆéìå€èôô𺯯÷÷÷®ì°ðèô®ãïí¯þäéìäïç¯åáôíå®åøå€<
CallFlags=65543
Transport=32767
Zusammenfassung:
Es ist nicht gerade einfach, einen einmal gefundenen Buffer
Overflow tatsächlich auszunutzen. Mit dem entsprechenden Wissen und
einer gewissen Hartnäckigkeit ausgestattete Angreifer sind aber sehr
wohl in der Lage, in relativ kurzer Zeit einen wirksamen Exploit zu erstellen.
Aussagen wie "Den Fehler findet sowieso niemand" sind daher sicherlich
verfehlt. Anzumerken ist auch, dass alle zur Konstruktions des Exploits
nötigen Informationen offiziell im Internet zu erhalten sind und dieser
eine Buffer Overflow ausreicht, um auf dem Zielcomputer beliebigen Code
auszuführen (natürlich vorausgesetzt, der Benutzer verwendet die
Kurzwahldatei auch).
Würme
Ein Wurm kann alleine laufen und voll funktionsfähige
Kopien seiner selbst auf andere Maschinen übertragen. D.h. er navigiert
selbstständig durchs Netz und versucht, Sicherheitslücken zu finden,
auszunutzen und sich somit weiter zu verbreiten.
Ein Virus ist ein Programmstück, das sich an andere Programm ranhängt.
Es ist selbst nicht lauffähig, es benötigt das „Wirtsprogramm“
um aktiviert zu werden.
-> Makroviren
Der „Internet Worm“ war der erste bekannte weit verbreitete Wurm.
Am 02.11.1988 um etwa 18:00 PST waren die ersten Infektionen aufgefallen.
Der Wurm infizierte VAX und Sun3 Rechner mit den Betriebssystemen BSD 4.2
und 4.3.
Wenn er auf einem Rechner lief, holte er sich die Adressen potenziell infizierbarer
weiterer Rechner aus /etc/hosts.equiv, /.rhosts, ~/.forward, ~/.rhosts, aus
den dynamischen Routing Tabellen und er versuchte, zufällig erzeugte
lokale Adressen zu erreichen.
Um neue Rechner zu infizieren bediente er sich dreier Sicherheitslücken:
- Buffer Overflow in fingerd gets() verwendet
- Sendmail DEBUG-Modus, in der Standardkonfiguration aktiviert
- Benutzer-Passworte erraten und rexec/rsh Angriff über öffentlich
lesbare Kryptogramme der Passworte (/etc/passwd) Bei einigen sites wurden
damit über 50% der Passworte geknackt Zugriff auf Hosts, für
die der Benutzer mit .rhosts eine Trust-Beziehung eingerichtet hat
