WinFuture-Forum.de: Win Sicher Durch Eingeschränkte Benutzer? - WinFuture-Forum.de

Zum Inhalt wechseln

Beiträge in diesem Forum erhöhen euren Beitragszähler nicht.
Seite 1 von 1

Win Sicher Durch Eingeschränkte Benutzer? der Traum ist ausgeträumt!


#1 Mitglied ist offline   funny__bunny 

  • Gruppe: aktive Mitglieder
  • Beiträge: 60
  • Beigetreten: 08. August 05
  • Reputation: 0

geschrieben 25. August 2005 - 18:19

Diesen sehr interessanten Artikel habe ich bei http://www.network-secure.de gefunden. Eines noch vorweg: wirklich neu ist diese Sache nicht. Es wurde unter anderem auch schon vom CCC im Video über Desktop Firewalls gezeigt. Viel Spaß beim Lesen (und Ausprobieren)!

Der Traum von den sicheren, eingeschränkten Benutzerkonten ist ausgeträumt

Bisher war es so, dass durch die Nutzung eines eingeschränkten Benutzer-Kontos ab Windows2000 eine relative Sicherheit für das System hergestellt werden konnte, da die Rechte für eingeschränkte Konten nicht ausreichten für größere Schäden. So weit die Theorie. Mit Hilfe spezieller Exploits und gezieltem Missbrauch genereller Mängel in der Windows System-Architektur wird dieser Schutzmechanismus allerdings dramatisch ausgehebelt.

Ein zufällig im Netz aufgefundenes Dokument bestätigt praktisch unseren seit Jahren bereits angewandten Leitsatz, ein System kann nur so weit geschützt werden, wie es selbst einen Schutz zulässt und eingeschlagene Wege zum Aufbau von Schutzlösungen nicht mit fehlerhaft implementierten Systemfunktionen konterkariert. Mit einfachen Worten ausgedrückt, hindert oftmals die verkorkste Windows System-Architektur den Aufbau eines wirksameren Schutzes, weil das System selbst seine eigene Manipulation weitgehend ohne Gegenwehr zulässt.

Das Dokument bezieht sich zwar primär auf das Betriebssystem Windows2000, Versionen unterhalb sind aber ohnehin aufgrund fehlender, vernünftiger Benutzerverwaltung ebenso betroffen wie das aktuelle System XP, da sich an der grundlegenden Systemkommunikation nichts wesentlich verändert hat und auch heute noch zahlreiche Codes enthalten sind, die lediglich aus Gründen der Kompatibilität zu früheren Systemen und Anwendungen als Ballast von Systemversion zu Systemversion mitgeschleppt wurden.

Shatter Attacks oder, wie kann Windows durchbrochen werden

Das Paper stellt ein neuartiges Angriffsszenario gegen Microsofts Windows vor. Die in dem Dokument vorgestellten Angriffsmethoden betreffen Systemfehler, die zum Zeitpunkt der Dokument-Erstellung noch nicht beseitigt waren. Die einzig zuverlässige Lösung zur Beseitigung der missbrauchbaren Fehler erfordert Funktionen, die in Windows nicht enthalten sind, sowie die Bemühungen von Software-Herstellern, die Anwendungen für Windows entwickeln.

Microsoft hat die Schwächen zwar generell anerkannt, sie jedoch nicht als schwerwiegende Fehler deklariert sondern als Designproblem, obwohl Microsoft Mitarbeiter unter Eid angab, dass die Fehler erheblich genug seien, um die Staatssicherheit zu gefährden, wenn der Windows Sourcecode freigegeben werden würde. Das Dokument lässt allerdings vermuten, Allchins wurde unter Druck gesetzt, denn kurz nach der Bekanntgabe seiner Informationen bedauerte er die Veröffentlichung bereits wieder.

Die beweisende Email ist verfügbar unter: Response
Das vom Autor erstellte und hier jetzt deutsch übersetzte Paper zeigt ein schrittweites Vorgehen zur Ausnutzung dieser Fehler-Kategorie. Einige andere Angriffsmethoden werden zwar besprochen, jedoch werden keine Beispiele aufgezeigt. Generell gibt es aber viele Möglichkeiten, diese Fehler-Kategorie zu missbrauchen. Dies hier ist lediglich also ein Beispiel.

Hintergrund - Das Win32 Messaging-System

Anwendungen innerhalb von Windows sind durch den Gebrauch von Nachrichten (technisch Messages genannt) völlig kontrolliert. Wird eine Taste gedrückt, geht damit auch direkt eine solche Nachricht an das aktive Fenster, die den Druck auf eine Taste angibt. Wenn Windows daraufhin entscheidet, dass die für dieses aktive Fenster verantwortliche Anwendung das Fenster neu aufbauen muss, sendet Windows ebenso eine "ReDraw" Nachricht an diese Anwendung. Solche Nachrichten werden immer dann und bei jedem Ereignis verschickt, wenn eine Anwendung oder ein Systemmodul Informationen über die Veränderung von Daten benötigt. Diese Nachrichten werden in eine Warteschlange gesetzt und von der Anwendung im Auftrag verarbeitet.

Diese Methode ist ein sehr zuverlässiger Mechanismus für kontrollierte, steuernde Anwendungen. Aufgrund eines grundliegenden Architekturmangels ist diese Einheit für die Steuerung von Nachrichten in Win32 aber defekt. Jede mögliche Anwendung kann eine solche Systemnachricht an ein beliebiges Fenster schicken, auch wenn das Fenster nicht zur sendenden Anwendung gehört und unabhängig davon, ob die empfangene Anwendung diese Nachricht überhaupt empfangen und verarbeiten möchte. Dazwischen existiert keine Einheit, die eine Überprüfung oder Beglaubigung der Quelle durchführt. Eine Systemnachricht, die von einem bösartigen Programm gesendet wird, ist nicht von einer Systemnachricht des Windows Kerns zu unterscheiden.

Es ist dieser Mangel an Authentisierung, der dazu führt, dass diese Nachrichten benutzt werden können, um Fenster zu manipulieren, sowie auch die zugrundeliegenden Prozesse.

Überblick

Im folgenden Beispiel wird gezeigt, wie ein auf einem Windows 2000 Professional laufendes Programm Network Associates VirusScan v4.5.1 manipuliert werden kann. Die VirusScan Konsole arbeitet auf dem Rechner als lokales System und der Beispiel-Angreifer loggt sich als Gast im System ein. Zielsetzung ist dabei, VirusScan zu hintergehen und durch die Ausführung von Code die Privilegien zu erhöhen.

Das Ziel wird in wenigen Schritten erreicht sein:

1. Lokalisierung eines verwendbaren Fensters innerhalb VirusScan (eine Eingabe-Box ist nahezu perfekt)
2. Entfernung aller möglichen Längenbeschränkungen zur Eingabe einer willkürlichen Datenmenge
3. Einfügen eines beliebigen binären Codes
4. Anweisung an VirusScan zur Ausführung des Codes (als LocalSystem)

Die Ausführung der Schritte ist wirklich sehr einfach, da Windows alle notwendigen Funktionen bereitstellt. Der Autor des Dokuments hat eine kleine Anwendung geschrieben, die er

Shatter

genannt hat und die alle für das Beispiel notwendigen Funktionen enthält. Ebenso wird ein Hex-Editor benötigt wie etwa

UltraEdit

sowie ein Debugger wie

WinDbg

Wichtig!
Einige Virenscanner erkennen in Shatter einen Schädling namens "Win32/Beavuh" mit der Datei sploit.bin in der Shatter Archivdatei. Shatter ist kein Virus! Die mögliche Aktion des Scanners ist aber korrekt, da sich in Shatter Funktionen befinden, mit denen eine Shell geöffnet und diese an ein Netzwerk Socket gebunden wird. Natürlich wäre eine solche Aktion normalerweise gefährlich und daher darf der Scanner auch reagieren. Shatter ist aber ungefährlich und dient nur der Ausführung des beispielhaften Angriffs. Es wäre entsprechend besser, den bevorzugten Virenscanner für die Zeit des Tests zu deaktivieren, falls ein Echtzeitmonitor aktiv ist.

Windows Nachrichten bestehen aus drei Teilen, einem "Message Identifier" und zwei Parametern. Die Parameter werden unterschiedlich benutzt, je nachdem, wozu die Nachricht gedacht ist. Genau das macht uns das Leben einfach, denn es sind nur ungefähr vier zu berücksichtigende Dinge zu beachten:

* Ein Window Handle zum Empfang der Nachricht
* die Nachricht selbst
* die zwei Parameter der Nachricht

Lassen Sie uns herausfinden, wie einfach das ist.

Schritt 1: Lokalisierung des Fensters

Zunächst müssen wir irgendein "Edit Control" lokalisieren, also etwas, wo hinein Material eingegeben werden kann. Kümmern Sie sich dabei nicht um Einschränkungen, die können wir korrigieren:

* Starten Sie die VirusScan Konsole
* klicken auf die erste Schaltfläche "Neuer Task" oder "New Task"

Oberhalb ist nun eine Eingabe-Box zu sehen, für die noch ein "Handle" benötigt wird, um interaktiv mit der Box zu arbeiten. Windows wird glücklich sein, Ihnen ein solches "Handle" für ein beliebiges Fenster zu geben, wir müssen nur darum bitten und damit ist der Zeitpunkt gekommen, die heruntergeladene und entpackte Shatter Datei auszuführen.

Danach gehen Sie dann wie folgt vor:

* Positionieren Sie Shatter so, dass das VirusScan Eingabefeld sichtbar ist.
* Klicken Sie auf "Get Cursor Window" (es sollte dann in der Liste etwas zu sehen sein wie "102f2 - Get cursor window"). Dieser String wird angezeigt, weil Windows darum gebeten wurde, ein Handle auf ein Fenster direkt unterhalb des Cursors zu übergeben.
* Verschieben Sie nun den Cursor über das VirusScan Eingabefeld, um Shatter erneut zu aktivieren.
* Shatter sollte das Listenfeld nun leeren und das Handle für das gewünschte Fenster übergeben.

Was nun folgt, ist ein programmierbares Fenster, das mit höheren Privilegien läuft als der Gast Zugriff zulässt. Lassen Sie uns also jetzt etwas Shellcode verarbeiten.

Schritt 2: Entfernen von Einschränkungen

Nun, wo wir ein "Window Handle" besitzen, können wir alle möglichen Nachrichten senden, die wir zur Steuerung von gewünschten Funktionen benötigen und sie werden blind ausgeführt. Also schauen wir jetzt und prüfen, ob wir genügend Raum für unseren Shellcode bekommen:

* Nehmen Sie das Shatter Fenster
* Geben Sie das "Window Handle" in die Shatter "Handle Box" ein (Der Nachrichtentyp zur Festlegung der maximalen Textlänge ist EM_SETLIMITTEXT. Der erste Parameter ist die neue maximale Textlänge, der zweite Parameter kann hier ignoriert werden)
* Geben Sie nun eine 4 in das WPARAM Eingabefeld ein sowie eine 0 in das Feld LPARAM.
* Klicken Sie auf EM_SETLIMITTEXT zur Sendung der Nachricht und geben etwas in das VirusScan Eingabefeld ein. Sie sollten nicht in der Lage sein, mehr als 4 Zeichen einzugeben.
* Ändern Sie die 4 im Shatter Eingabefeld hin zu FFFFFFFF und senden die Nachricht erneut. Sie haben jetzt zumindest theoretisch 4 GB Platz für Ihre Eingaben in das VirusScan Eingabefeld. Genug also, um ein bisschen schädlichen Shellcode zu starten.

Schritt 3: Shellcode injizieren

Im nächsten Schritt lassen Sie uns etwas in das VirusScan Eingabefeld einfügen. Rechtsklick also mit der Maustaste und Auswahl von "Einfügen" aus dem Kontextmenü. Das hat zwar geklappt aber um des Beispiels wegen lassen Sie uns so tun, als könnten wir noch keinen Text eingeben.

Gehen Sie dann wie folgt vor:

* Leeren Sie das VirusScan Eingabefeld und starten Notepad
* Geben Sie etwas in Notepad ein und kopieren den Inhalt
* Zurück zu Shatter senden wir also jetzt eine neue Nachricht hin zu VirusScan mit der Anweisung "Einfügen aus der Zwischenablage". Hierfür wird WM_PASTE benötigt.
* Beide Parameter für diese Nachrichten müssen 0 sein. Falls noch nicht geschehen, geben Sie also für die Parameter WPARAM und LPARAM jeweils eine 0 ein und belassen das "Window Handle" wie es ist.
* Klicken Sie nun auf "WM_PASTE" und passen auf, was mit dem VirusScan Eingabefeld geschieht. Klicken Sie nochmals auf "WM_PASTE" und sehen, der kopierte Text erscheint doppelt. Spaßig, nicht wahr.

Gut, wir haben nun genug gespielt. Leeren Sie das VirusScan Eingabefeld erneut, starten den Hex-Editor und laden damit die Datei sploit.bin aus dem Shatter Archiv. Das jetzt ist ein bisschen Shellcode von Jill (Hey, Dark Spyrit!), mit dem eine Remote-Command Shell geöffnet wird. Um mit dem Beispiel keinen Schaden anzurichten oder eine Gefahr heraufzubeschwören, ist die Shell fest verdrahtet mit der Loopback Adresse an Port 123.

So, nun ist eine gute Zeit, um ein Netcat Listener zu starten, bevor Sie es vergessen. Dazu benötigen Sie Hobbits kleines Programm

NetCat

und kopieren die Datei nc.exe in Ihr Windows Hauptverzeichnis. Anschließend öffnen Sie eine CMD Box und geben dort in der CMD-Line folgenden Befehl ein:

nc -lp 123

und bestätigen ihn mit der Enter-Taste.

Nun beschäftigen Sie sich wieder mit dem Hex-Editor, kopieren den Shellcode in die Zwischenablage und versichern sich, den gesamten Shellcode kopiert zu haben (einschließlich FOON zu Beginn, weil das noch benötigt wird). Zurück zu Shatter klicken Sie wieder auf WM_PASTE und sehen im VirusScan Eingabefeld eine Anzahl verschiedener Zeichen. Das ist der gerade kopierte Shellcode, der nun schön sauber in das gewünschte Eingabefeld aus der Zwischenablage eingefügt ist.

Schritt 4: Ausführen des Codes

Dieser letzte Schritt ist nicht trivial und der einzige, der einige Fähigkeiten vom Anwender abfordert.

Gehen Sie also wie folgt vor:

* Starten Sie den zuvor geladenen Debugger
* Gehen Sie zum Prozess avconsol.exe (Taste F6 und einfach den Prozess suchen)
* Jetzt muss der Speicher nach dem String FOON durchsucht werden. Der hierfür notwendige Befehl ist:

s -a 00000001 10000000 "FOON"
* Merken oder notieren Sie sich die Speicherstelle, an der FOON erscheint. In diesem Fall war es der Speicherplatz 0x00148c28. Wenn Sie den selben Debugger benutzen, wird FOON also nicht weit davon entfernt sein.
* Nun beenden Sie den Debugger, loggen sich als Gast ins System ein und bereiten sich auf den Erhalt von Systemprivilegien vor, indem Sie die Schritte 1 bis 3 wiederholen. Denken Sie dabei daran, Sie sind immer noch Gast des Systems und vergessen auch nicht den NetCat Listener, um die Shell zu empfangen.

An diesem Punkt sollten Sie eigentlich denken, dass die Ausführung eines Debuggers eine privilegierte Operation ist, die nicht als Gast ausgeführt werden kann. Es ist jedoch das selbe, als wenn ein Puffer-Überlauf Exploit seine Arbeit verrichtet. Die Aktion kann auf jedem möglichen System ausgeführt werden. Alles was Sie benötigen ist die Adresse einer Maschine, auf der die gleiche Software in der selben Version läuft. Die meisten Anwendungen haben ihre eigenen, speziellen Handler zur Ausführung (VirusScan zweifellos). Wenn Sie also so einen Zugriffsfehler (Access Violation) erzeugen, verhandeln Sie einen Deal mit ihm und statt die Anwendung wirklich abbrechen zu lassen, führen Sie zwischenzeitlich die Shellcode Kommandos aus und niemand kann Sie stoppen. Die Zeit reicht, um einige hundert Kilobyte zu übertragen, um anschließend den Shellcode auszuführen. Nicht gerade elegant aber sehr effektiv.

Die abschließend benötigte Nachricht ist WM_TIMER. Sie ist nicht ungefährlich, weil sie als zweiten Parameter eine "Timer Callback" Funktion enthalten kann. Wenn dieser zweite Parameter ungleich 0 ist, springt die Ausführung zur spezifizierten Adresse zurück. Sie haben richtig gelesen, Sie können praktisch jedem Fenster eine WM_TIMER Nachricht mit einem Nicht 0 Wert als zweitem Parameter (der erste ist die Timer ID) und der ausführende Code springt zurück.

Der jetzt "leicht" sarkastisch wirkende Autor weist an der Stelle darauf hin, das seines Wissens nach diese Nachricht nicht einmal in die Nachrichten-Warteschlange eingefügt wird. Somit kann die empfangene Anwendung sie auch nicht eventuell ignorieren.... dumm, dumm, dumm.

Wir sparen uns hier an dieser Stelle die Übersetzung weiterer Beispiele, weil sie lediglich eine Wiederholung mit etwas schwierigeren Umsetzungsmöglichkeiten wären.

So aber kam seinerzeit auch die Hype rund um den Missbrauch der API Befehle "WM_DESTROY" oder "WM_CLOSE" zustande, die sehr viele Schlagzeilen erzeugte und die in ihren darunterliegenden Texten Vorwürfe gegen Entwickler und Hersteller von Firewallsystemen beinhalteten.

Wir berichteten darüber im Artikel: API Missbrauch
Bereits damals erheiterten uns die Vorwürfe, weil eine Anwendung nicht dafür verantwortlich gemacht werden kann, wenn das Betriebssystem selbst sich derart leicht manipulieren lässt. So wie ein Computer lediglich das macht, was ein beliebiger Anwender von ihm einfordert, so arbeitet ein Anwendungsprogramm auch lediglich nach den Vorgaben des Betriebssystems, mit dem es zusammenarbeiten muss. Solche Vorwürfe entstehen halt immer dann, wenn der Autor oder Redakteur nicht sehr wirklich weiß, worüber er schreibt und verunsichert dann Anwender, die eigentlich dringend auf vernünftige Hilfe angewiesen ist. Auf ähnliche Weise entstand auch die Demo des CCC, wo ein Video beweisen wollte, wie schnell Desktop-Firewallsysteme abgeschossen werden können.

Dennoch bleibt das eigentliche und gefährliche Problem bestehen.

Als Microsoft eine Kopie des Dokuments vom Autoren erhielt, wurde ihm bestätigt, die Angriffsmethoden werden berücksichtigt, letztlich wurden sie aber nicht klassifiziert als Verwundbarkeit. Microsoft wehrt heute die Forderung nach Anerkennung ab, weil zur Ausführung der Missbrauchsszenarien physikalischer Zugang zum Zielrechner bestehen muss. Das ist natürlich so und das bestätigt auch der Autor dieses Dokuments. Allerdings wurde in der Argumentation nicht berücksichtigt, dass bei aktiven Gast Kosten ein beliebiger Zugriff erfolgen kann und dann jegliche Benutzerkonten des Rechners manipuliert werden können.

Welcher normale Anwender weiß denn überhaupt, dass die zum Abschluß der Installation eines Windows XP angelegten Benutzerkonten dann sämtlich administrative Rechte besitzen, die systemweiten Zugriff ermöglichen. Nicht einmal ein Passwortschutz ist in dem Fall vorhanden, denn den verhindert die einfache Benutzeranmeldung, die dem Anwender sein Windows so schön einfach machen soll. Einfach für den Anwender oder einfach für denjenigen, der sich auf zahlreiche Art und Weise Zugriff in das System verschaffen kann.

Network-Secure News

Dieser Beitrag wurde von funny__bunny bearbeitet: 25. August 2005 - 18:30

0

Anzeige



Thema verteilen:


Seite 1 von 1

1 Besucher lesen dieses Thema
Mitglieder: 0, Gäste: 1, unsichtbare Mitglieder: 0