Alex' blog (Artikel mit Tag buffer-overflow)

V2V bzw. Car2Car

nospam@example.com (Alex) — Thu, 10 May 2007 03:31:00 +0200

Auf V2V oder eine auf einen anderen Namen hörende, aber gleichwertige Technik freue ich mich schon genauso, wie auf Kühlschränke mit Ethernet- oder WLAN-Unterstützung.
Mehr zu V2V oder Car2Car hier und da.

Das hat alles unglaubliches Potenzial für Cracker / Hacker. Habe ich allerdings auch schon ein paar Monate früher prophezeit.

Auch Spielereien mit Bluetooth mit zentralen Kombi-Steuergeräten (Radio, Bordcomputer, Navigation, etc.) werden in Zukunft sicherlich nett werden. Und dem CAN-Bus sollte man auch mal genauer auf den Zahn füllen. Vielleicht sind ja doch einige elektrisch betriebene Außenspiegel am Auto bi- statt unidirektional ausgelegt.

Hat eigentlich schon jemand die neuen Ventile der Reifendrucksysteme ausprobiert ? Soll heißen: Wie sieht es denn da so mit Buffer-Overflows aus ? Schließlich lässt sich so ein Ventil manipulieren bzw. auch gut simulieren ...

Lösung Hakin9 Wargame I

nospam@example.com (Alex) — Fri, 30 Mar 2007 23:48:09 +0200

Seit einigen Tagen ist der Einsendeschluss für das Hakin9 Wargame I erreicht. Ab jetzt sollte man getrost eine Lösung veröffentlichen können ohne unfair anderen gegenüber zu sein.

Mein Ausgangspunkt war ein Buffer-Overflow, aber über dieses schon x Mal durchgekautes und daher schon super langweilig gewordenes Thema zu schreiben, liegt mir heute fern. Der Overflow ist zwar toll, aber es geht eleganter, einfacher und wesentlich (!) schneller auf eine andere Art, die ich hier ausführlich vorstellen möchte.
(Wahrscheinlich findet man in der (über)nächsten Print-Ausgabe oder online sowieso sämtliche eingebauten Möglichkeiten, um den Root-Zugang erobern zu können.)

Die Lorbeeren gehen hierfür allerdings nicht an mich, sondern an "Rootuser", welcher mir in Erinnerung gerufen hat, dass man nicht alles gleich mit den ultimativen Methoden, sozusagen, "überfahren" muss.

Wer sich das Dateisystem anschaut dürfte in Rekordzeit über die ungewohnte Datei namens "execute" stolpern, welche das SUID-Bit gesetzt hat.

Wer diese Datei direkt aufruft bekommt nur eine Meldung, dass das Programm nicht weiss, was es auszugeben hat und beendet sich wieder. Wenn man ein Argument angibt, dann wird dieses Argument auf dem Monitor in einer neuen Zeilen ausgegeben. Bei Angabe von mehreren Argumenten tut das Programm wieder nichts als die bekannte Meldung auszugeben. Wenn man diese Argumente aber dann wieder als ein Argument über (einfache / doppelte) Anführungszeichen angibt und das Programm startet, so schreibt das Programm auch ganze Sätze auf den Monitor.

Wer den Befehl "echo" kennt, dem dürfte diese Art der Ausgabe bekannt vorkommen. Warum sollte aber ein Programm, was wie "echo" funktioniert, aber "execute" heißen, wenn da nicht noch mehr versteckt wäre ?! Entweder man analysiert es in gdb oder man probiert seine Vermutung direkt aus. Dazu gleich mehr.

Wenn man eine Verbindung zwischen Dateiname und Funktionsweise des Programmes herstellen will, muss das Programm das übergebene Argument über irgendeine Funktion ans OS übergeben. Wenn man allerdings davon ausgeht, dass der Dateiname und die Funktionsweise nicht zueinander irgendwie passen sollten, so könnte es schlichtweg nur eine printf-ähnliche Funktion sein, wo der Buffer-Overflow ansetzen könnte.

Mit genug Spieltrieb geht man aber direkt zur erst möglichen Vermutung über und probiert sie auch sofort aus, anstatt einen Debugger zu benutzen. Es sollte sich herausstellen, dass das Anhängen von gdb an "execute" tatsächlich unnötig ist und nur Zeit verbraucht - auch wenn es sich nur um wenige Tastenanschläge handelt.

Wer sich mit der Shell auskennt, der weiß, dass man mehrere Kommandos getrennt durch ein Semikolon in einem Rutsch angeben kann. Wenn "execute" nun den angegebenen String tatsächlich nur als ein Argument für "echo" benutzt und ans OS übergibt und dabei nicht filtert, dann sollte sich hier dank gesetztem SUID-Bit der Root-Zugang erobern lassen.

Ein

execute ";id"

sollte also so etwas wie:

uid=0(root) gid=0(root) ...

anzeigen, da der Befehl "id" mit Root-Rechten ausgeführt wird. Die Anführungszeichen sind hier nötig, da sonst das Semikolon als Trenner für mehrere Befehle in einer Zeile verarbeitet wird, anstatt ihn als Argument zu belassen.
Nachdem die Ausgabe von "id" von Root spricht, ist unser Ziel erreicht: Wir sind nun Root.

Jetzt kann man natürlich den Befehl "id" gegen den Dateinamen einer vorhandenen Shell auf dem System (sh, bash, etc.) austauschen. So kommt man also zu seiner Bash-Root-Shell: execute ";bash"

Jetzt dauert es nicht mehr lange bis zum Hakin9 Wargame II - hoffentlich schwerer.

Hakin9 Wargame - die Zweite

nospam@example.com (Alex) — Sat, 03 Mar 2007 04:25:26 +0100

Es gibt Leute, die ihre Exploits ausschließlich in C schreiben. Wer seine Exploits für die Wargame Linux-CD (Hakin9 Ausgabe 03/2007) also nun in C schreiben will, der muss wissen, dass hier nicht die glibc verwendet wird, sondern die uClibc.

Auf der offiziellen Homepage von uClibc gibt es unter der Rubrik Toolchains ein fertiges uClibc Development System zum Download. Für die Kompilierung von Exploits reicht dies vollkommen aus. Nach dem Download muss das Archiv (i386) nur noch entpackt werden und z.B. so mittels dem Loop-Device ins System eingehangen werden:

sudo mount -o loop root_fs_i386.ext2 /mnt/mountpoint

Gefolgt von:

sudo chroot /mnt/mountpoint /bin/su -

... chrootet man in die Entwicklungsumgebung und kann den gcc benutzen.

Damit man sich nicht mit den uClibc-Gegebenheiten herumschlagen muss, sollte man der Einfachheit her seine Exploits statisch bauen. Also in etwa so:

gcc -o exploit exploit.c -static

Aber eigentlich reichen Bash, Perl und Python zum Exploiten soweit aus.

Browser Fuzzing

nospam@example.com (Alex) — Fri, 02 Feb 2007 13:59:00 +0100

Ich habe mich gestern Abend hingesetzt und die erste, kümmerliche Version eines Fuzzers für Webbrowser geschrieben. Momentan fehlt noch viel Funktionalität, Einstellmöglichkeiten, etc., aber das Grundgerüst steht bereits stabil.

An einer Anbindung an FileFuzz arbeite ich parallel. Okay, eigentlich bin ich damit theoretisch schon fertig, nur ein Test steht bislang noch aus. Ich bin mir aber sicher, dass es einwandfrei funktionieren wird.

Und mein Fuzzer verspricht auch schon erste Erfolge wie z.B. eine gecrashte JVM (Auszug):

Current thread (0x0716e098):  JavaThread "Java2D Disposer" daemon [_thread_in_vm, id=4024]

siginfo: ExceptionCode=0xc0000005, reading address 0xffffffff

oder auch den IE selbst betreffend - siehe Bild.

Einen Fuzzer für Browser gibt es in Form von MangleMe ja eigentlich schon, aber dieses Programm erfordert entweder einen Webserver oder man lenkt die Ausgabe in HTML-Dateien um, was wiederum aber etwas Handarbeit erfordert um wieder eine Automatisierung zu bekommen um MangleMe wie sonst normal im Browser ablaufen lassen zu können.

Man könnte natürlich sagen, dass ich einfach hätte MangleMe umschreiben können, aber da ich recht viel anders machen möchte und mein Fuzzer aus gewissen Gründen erst einmal stark auf die Eigenheiten des Internet Explorers >= 6.0 abzielen soll, kam das für mich nicht in Frage.

Vielleicht sollte man dies noch der Vollständigkeit halber erwähnen: ein weiteres Fuzzing-Tool namens AxMan gibt es auch noch, welches aber ein Programm speziell für ActiveX Fuzzing ist.

Wer mir noch andere Fuzzer-Tools für Webbrowser nennen kann, der darf sich gerne bei mir melden.

Update: Nun hat es auch den IE 7.0 erwischt.

Update 2: Anbindung an FileFuzz klappt nach meinem Test eben auch ganz problemlos. Jetzt geht das auch mit den CPU-Registern etwas einfacher.

Bug in Internet Explorer 7 Beta

nospam@example.com (Alex) — Thu, 20 Jul 2006 15:52:32 +0200

Wer MS-Windows Vista Ultimate Edition Build 5384 testet und alle verfügbaren Updates installiert hat, der ist auch mit dem neuen Internet Explorer 7.0 (immer noch eine Beta-Version), vor den neuen Bugs nicht sicher.

H.D. Moore hat in seinem Browserfun-Blog bis jetzt 17 Bugs für den Internet Explorer 6.0 veröffentlicht, die auf einem voll gepatchten Windows XP SP2 zum Absturz des Browsers führen. Desweiteren befindet sich unter den aktuell ingesamt 20 Bugs jeweils noch einer für den Konqueror, Firefox und Safari.

Ich habe kurzer Hand sämtliche Sicherheitsfeatures des Browsers deaktiviert und alle IE-Bugs schnell durchgetestet. Nur die Demo für MoBB ("Month of Browser Bugs") #10 bringt den neuen IE zum Abstürzen.

Sämtliche Versionsnummern und Registerwerte, etc. kann ich hier und jetzt leider nicht präsentieren, da ich sie mir nicht direkt notiert habe und ich sonst erst die Festplatte mit Windows Vista wieder einbauen muss.

Hacking Nintendo DS

nospam@example.com (Alex) — Tue, 16 May 2006 23:42:00 +0200

Nintendos Spielekonsole DS ist seit langer Zeit schon gehackt. Entweder per WifiMe oder PassMe. So kann man eigene Software (sog. Homebrew) über den GBA-Steckplatz laden.

PassMe liegt in zwei verschiedenen Versionen vor. WifiMe nur in einer.
Welche Technik wann funktioniert ist relativ schnell erzählt. Zunächst zu den verschiedenen Firmware-Versionen:

Version 1: DS friert ein
Version 2: Blau-graue LCDs
Version 3: Dunkelgrüne LCDs
Version 4: Goldgelbe LCDs
Version 5: Magentafarbene LCDs
Version 6: Blaue LCDs
iQue-Version: Dunkelgrüne LCDs
DS Lite Version: Violette LCDs

Die Firmware-Version kann man auf folgendem Weg ermitteln: DS-Spiel einschieben. DS starten und Pictochat auswählen und anschließend Raum A betreten. Danach das DS-Spiel entfernen. Daraufhin bleibt der DS entweder hängen oder die beiden LCDs nehmen die oben beschriebenen Farben an. (Die Liste ist u.U. nicht vollständig.)

(Die zwei bzw. drei dunkelgrünen DS-Firmware Versionen kann man auch noch auseinander halten, aber darum soll es hier nicht gehen. Dafür wirft man am besten einen Blick in das englischsprachige Wikipedia.)

WifiMe funktioniert nur bis einschließlich Version 3. PassMe 1 ebenfalls. WifiMe läßt sich mittels Software und einer passenden WLAN-Karte zum Abspielen eigener Software übereden. So läßt sich auch FlashMe aufspielen. PassMe 2 ist ab Version 3 gedacht und basiert auf einem Adapter, der in den DS-Steckplatz gesteckt wird.

Mittels FlashMe (eine neue Firmware-Version) läßt sich Software direkt vom GBA-Steckplatz starten ohne auf WLAN oder Hardware-Adapter in Zukunft angewiesen zu sein. (Ein FlashMe-behandelter DS meldet sich ebenfalls mit zwei dunkelgrünen LCDs.)

Wie gesagt, dies alles ist nicht wirklich neu, jedoch habe ich jetzt einen Nintendo DS zur Verfügung, der bereits Version 4 der Firmware besitzt, und ich möchte kein PassMe 2 benutzen. Daher begebe ich mich die nächsten Wochen auf die Suche nach weiteren, noch nicht gefundenen Bugs mittels der WifiMe-Technik, da dafür eine passende WLAN-Karte herumfährt, so dass prinzipiell bei einer Firmware-Version 1, 2 oder 3 es kein Problem wäre eigenen Code auf der Konsole auszuführen.
Zudem möchte ich auch untersuchen, ob ich Bugs in Mario Kart DS oder Animal Crossing finde, die per WLAN die Einschleusung von eigenem Code ermöglichen.

Immer noch ungefixte JavaScript-Bugs im Firefox

nospam@example.com (Alex) — Tue, 02 May 2006 22:44:15 +0200

Es gibt auch in der allerneusten Version von Mozilla Firefox 1.5.0.3 (erhältlich seit heute) noch immer ungefixte JavaScript-Bugs. Der hier am 25.04.2006 erwähnte Bug ist seit 1.5.0.1 bekannt und auch ca. 4 Monate danach noch immer nicht gefixt.

In der aktuellen Version wurde nur ein JavaScript-Problem gegenüber 1.5.0.2 gefixt. Sonst wurde gar nichts geändert. Das Problem iframe.contentWindow.focus() ist nun nicht mehr existent. Wieso wieder nur halbe Arbeit getan wurde, ist mir echt unverständlich ...

Ungefixte JavaScript-Bugs im Firefox

nospam@example.com (Alex) — Tue, 25 Apr 2006 18:30:25 +0200

Wie bereits schon zu Zeiten von Mozilla Firefox 1.5.0.1 bekannt wurde, dass folgender kurzer HTML-Code mit JavaScript ausreicht, um Firefox einen DoS zu verpassen, funktioniert dies ebenfalls noch in der neusten Firefox-Version 1.5.0.2 (dt. Sprachversion). Warum ? Sind die Entwickler bisher über diese Erkenntnis noch nicht gestolpert und warum hat es niemand in Bugzilla eingetragen ? Spätestens nach einem kurzen mehrmaligen Drücken von OK ist es dann um den Firefox geschehen:


<html>
<body onfocus="alert('Ja');">
</body>
</html>

Passend dazu wurde heute bekannt gegeben, dass sich Firefox (ebenfalls auch in der neusten Version) bei gewissen JavaScript-Konstrukten von iframe.contentWindow.focus() ebenfalls verhaspelt.