nicht angemeldet
Root-Rechte mit Buffer Overflows erlangen
Hallo,
in meinem neu erworbenen Buch wird anhand diverser Beispiele erklärt, wie es gelingen kann, mithilfe von schlampigen Programmen und Buffer Overflows Root-Rechte zu erlangen.
Das Beispiel bezieht sich auf ein einfaches Programm, dass die Länge des einzugebenen Strings nicht überprüft:
#include <string.h>
int main(int argc, char **argv) {
char buffer[500];
strcpy(buffer, argv[1]);
return 0;
}
Mithilfe des Exploits wird dieses obige Programm ausgeführt und versucht, Code einzuschleusen. Der einzuschleusende Shellcode, den ich zur besseren Übersicht aus dem Exploit in einen Hex-Editor übertragen habe, sieht so aus:
Dazu hätte ich zwei Fragen:
Das Erlangen der Root-Rechte gelingt nur zu relativ selten. Ich muss das Exploit dafür sehr oft ausführen. Ohne jetzt mal den Code zu posten würde ich gerne wissen, ob jemand Ahnung hat, warum das so ist? Ein Programmfehler scheint nicht vorzuliegen, da es doch ab und zu funktioniert.
Meine zweite Frage wäre die Erklärung des HEX-Codes vor /bin/sh. Ich würde gerne wissen, welche Anweisungen für den PC die paar Hex-Zahlen vor /bin/sh beinhalten. Das wird nämlich leider nicht erklärt, und dass die letzte Anweisung /bin/sh ist, habe ich natürlich auch erst im Hex-Editor gesehen.
Markus.
-
Hallo *Markus.
Das Erlangen der Root-Rechte gelingt nur zu relativ selten. Ich muss das Exploit dafür sehr oft ausführen. Ohne jetzt mal den Code zu posten würde ich gerne wissen, ob jemand Ahnung hat, warum das so ist?
Das kann alles moegliche sein -- ohne konkretes Zielprogramm, Plattform, verwendete Methode usw. schwer zu sagen. Du kannst (und solltest) das am laufenden Programm aber ganz einfach selber nachvollziehen. Falls du tatsaechlich etwas tiefer in die Materie eintauchen und sie verstehen moechtest, empfehle ich dir noch etwas mehr dazu zu lesen, z.B. Aleph Ones "Smashing the stack for fun and profit" (_der_ Klassiker) und fuer weitere Methoden "Buffer overflows demystified" von Murat Balaban.
Meine zweite Frage wäre die Erklärung des HEX-Codes vor /bin/sh. Ich würde gerne wissen, welche Anweisungen für den PC die paar Hex-Zahlen vor /bin/sh beinhalten.
Da du das Binary ja hast: Fuer so etwas eignen sich Disassembler hervorragend. ;-)
-
Ich nochmal.
[...] ohne konkretes Zielprogramm, Plattform, verwendete Methode usw. schwer zu sagen. [...]
Ich nehme das Zielprogramm zurueck, da du es ja angegeben hast. Mein Fehler. Aendert aber am Rest meines Postings nichts. ;-)
-
Hallo,
Das kann alles moegliche sein -- ohne konkretes Zielprogramm, Plattform, verwendete Methode usw. schwer zu sagen.
Ich verwende Gentoo Linux, und das Zielprogramm war eigentlich das von mir gepostete. Darüberhinaus bin ich jetzt fast sicher, dass dieses sporadische Funktionieren normal ist. Der Autor schreibt nämlich folgendes:
"[...] um das Programm hoffentlich dazu zu verleiten, den injizierten Shellcode beim Absturz auszuführen."Meine zweite Frage wäre die Erklärung des HEX-Codes vor /bin/sh. Ich würde gerne wissen, welche Anweisungen für den PC die paar Hex-Zahlen vor /bin/sh beinhalten.
Da du das Binary ja hast: Fuer so etwas eignen sich Disassembler hervorragend.
Nein, so habe ich das nicht gemeint. Diese 46 Hexzahlen werden tatsächlich so in ein Array in dem C-Programm, also dem Exploit, eingetragen, und dem anderen von mir geposteten C-Programm untergejubelt. Ich habe den offenen Quellcode vor mir, nur wollte ich diese Anweisungen verstehen.
Markus.
-
Hallo *Markus.
Ich verwende Gentoo Linux, und das Zielprogramm war eigentlich das von mir gepostete. Darüberhinaus bin ich jetzt fast sicher, dass dieses sporadische Funktionieren normal ist. Der Autor schreibt nämlich folgendes:
"[...] um das Programm hoffentlich dazu zu verleiten, den injizierten Shellcode beim Absturz auszuführen."Wie gesagt, das haengt massgeblich von der Methode ab, mit der du den Shellcode zu injizieren versuchst. Die beiden Artikel, die ich im ersten Posting erwaehnte beschreiben z.B. zwei gaenzlich unterschiedliche Moeglichkeiten.
Egal welche Methode du nun verwendest, es lohnt sich auf alle Faelle, sich mit GNU Debug (gdb) zu beschaeftigen, um dem Programm beim Abarbeiten der Befehle "ueber die Schulter schauen" zu koennen. So findest du sicher auch selber heraus, was das Problem ist.
Meine zweite Frage wäre die Erklärung des HEX-Codes vor /bin/sh. Ich würde gerne wissen, welche Anweisungen für den PC die paar Hex-Zahlen vor /bin/sh beinhalten.
Da du das Binary ja hast: Fuer so etwas eignen sich Disassembler hervorragend.
Nein, so habe ich das nicht gemeint. Diese 46 Hexzahlen werden tatsächlich so in ein Array in dem C-Programm, also dem Exploit, eingetragen, und dem anderen von mir geposteten C-Programm untergejubelt. Ich habe den offenen Quellcode vor mir, nur wollte ich diese Anweisungen verstehen.
Ist schon klar. Diese "Hexzahlen" sind Maschinencode, der nachher (vermutlich) auf dem Stack landet. Du kannst diese Opcodes mit einem Disassembler als besser lesbare Mnemonics darstellen lassen, falls du sie nicht "von Hand" uebersetzen willst. Auswendig kennen die fuer moderne Prozessoren vermutlich nur die absoluten Freaks. ;-)
Oder meintest du mit "offener Quellcode" das Assembler-Listing des Shellcodes und willst nun lediglich wissen, was dieser die ganzen "push eax" usw. machen?
-
Hi,
Egal welche Methode du nun verwendest, es lohnt sich auf alle Faelle, sich mit GNU Debug (gdb) zu beschaeftigen, um dem Programm beim Abarbeiten der Befehle "ueber die Schulter schauen" zu koennen. So findest du sicher auch selber heraus, was das Problem ist.
An den Debugger dachte ich schon. Jedoch ist es doch eigentlich so, dass ich das Programm auf "unkonventionelle Weise" benutze, und es eigentlich klar ist, dass das Programm beim Pufferüberlauf abstürzt. Ich dachte, gerade deswegen ist die Wahrscheinlichkeit nicht so groß, dass dieser Trick gleich beim ersten Mal das gewünschte Ergebnis liefert, da das Programm doch nicht auf die vorgesehene Weise ausgeführt wird.
Wahrscheinlich habe ich noch zu wenig Kenntnisse über den inneren Hokuspokus, um die genaue Ursache erahnen zu können.Ist schon klar. Diese "Hexzahlen" sind Maschinencode, der nachher (vermutlich) auf dem Stack landet. Du kannst diese Opcodes mit einem Disassembler als besser lesbare Mnemonics darstellen lassen, falls du sie nicht "von Hand" uebersetzen willst. Auswendig kennen die fuer moderne Prozessoren vermutlich nur die absoluten Freaks. ;-)
Das mit dem Stack ist mir schon klar. Genau diese "Übersetzung" habe ich eigentlich gemeint. Ich dachte, dass ein geübter Programmierer diese Anweisungen "so einfach" aus den Hex-Anweisungen ablesen kann.
Markus.
-
Hallo *Markus.
Jedoch ist es doch eigentlich so, dass ich das Programm auf "unkonventionelle Weise" benutze, und es eigentlich klar ist, dass das Programm beim Pufferüberlauf abstürzt.
Nein, es stürzt nicht ab... Genau das willst du ja verhindern. Das Programm soll statt dessen an anderer Stelle mit der Codeabarbeitung fortfahren, als wäre nichts passiert. Wenn es abstürzt (z.B. mit einem SEGFAULT), hast du was falsch gemacht. ;-)
Ich dachte, gerade deswegen ist die Wahrscheinlichkeit nicht so groß, dass dieser Trick gleich beim ersten Mal das gewünschte Ergebnis liefert, da das Programm doch nicht auf die vorgesehene Weise ausgeführt wird.
Wenn du einmal die entsprechende Stelle gefunden hast (und die injizierten Daten richtig "aligned" hast oder was sonst noch nötig ist für deine spezielle Methode), funktioniert eine solche Aktion immer. Nur das Finden kann u.U. ein langwieriges Glücksspiel sein...
Wie gesagt, die beiden angegebenen Artikel vermitteln schon mal eine sehr solide Basis.
Ich dachte, dass ein geübter Programmierer diese Anweisungen "so einfach" aus den Hex-Anweisungen ablesen kann.
Möglich. _Ich_ brauche dazu -- um nicht stundenlang zu puzzeln -- i.d.R. allerdings etwas Computerhilfe. Falls es dir ganz wichtig ist, schau ich es mir später nochmal an. Oder einer der "geübten Programmierer" schaut mal kurz drauf. ;-)
-
Hi,
Nein, es stürzt nicht ab... Genau das willst du ja verhindern. Das Programm soll statt dessen an anderer Stelle mit der Codeabarbeitung fortfahren, als wäre nichts passiert. Wenn es abstürzt (z.B. mit einem SEGFAULT), hast du was falsch gemacht. ;-)
Hmmm, es stürzt tatsächlich immer mit Segemntation Fault ab, aber ich habe es genauso gemacht, wie es im Buch beschrieben ist und den Code 3x kontrolliert, eigenartig.
Möglich. _Ich_ brauche dazu -- um nicht stundenlang zu puzzeln -- i.d.R. allerdings etwas Computerhilfe. Falls es dir ganz wichtig ist, schau ich es mir später nochmal an. Oder einer der "geübten Programmierer" schaut mal kurz drauf. ;-)
Ach, schon ok. Vielleicht ergibt es sich inden nächsten Kapiteln ganz von selbst. :)
Markus.
-
Hallo,
um sowas als Newbie grundlegend zu üben, ist die Verwendung eines im Protected Mode arbeitenden Prozessors auch nicht gerade der richtige Einstieg. Das sollte man erstmal mit einer Museumsmaschine im Real Mode testen.
Leider gibt es heutzutage dazu kaum noch Literatur.
LG
Chris
-
-
-
-
-
-
-
Meine zweite Frage
...ist geklärt. Ist doch nur gewöhnlicher kompilierter Assemblercode :)
Markus.