• Hey!

    Hat jemand einen Tipp zu vuln2.c? :wein:

    Bin ich auf dem richtigen Weg, wenn ich es schaffe system() aufzurufen? Das Problem dabei ist nur, dass er dann zwar eine Shell öffnet (Standardverhalten bei Aufruf von system()), aber mit dieser Shell kann ich nichts anfangen, weil sie gleich wieder weg ist bzw. kommt der Output " : command not found". Die Frage ist nur, nach welchem command sie überhaupt sucht, weil dann könnte man ja leicht etwas unterjubeln.

    Komischerweise funktioniert der obige Exploit überhaupt nicht (also system() wird nicht mal aufgerufen), wenn ich die Adresse von exit zum "ersetzen" übergebe.

    Thanks a lot

  • Läst sich einstellen, dass eine Shell bei ihrem Aufruf einen bstimmten Befehl/Datei automatisch ausführt? Mir gelingt es zwar eine Shell aufzurufen, aber diese beendet sich dann wieder selbstständig ohne etwas zu tun.

  • Also bei mir geht das mit exit(0) allerdings ist die Ausgabe der Shell unverständlich zb:

    sh: ì
    : command not found

    Eine Datei mit Namen ì anzulegen nützt aber nichts. Kann mir jemand einen Tipp geben oder zumindest sagen, ob ich auf der richtigen Spur bin. Ich möcht halt nicht 2 Tage lang nach einen richtigen Dateinamen suchen wenn es so vielleicht ohnedies nicht funktioniert.

  • same Problem here:


    sh: �: command not found


    ----------------------------------


    hab eine Datei � zwar angelegt kann diese auch ausführen aber das verwundbare Programm kann es nicht aufrufen (Path ist gesetzt).


    Kann eventuell jemand einen Tipp geben ob fprint eh die methode die es zu überschreiben gilt und zwar mit system oder braucht man eine andere Methode ?


    thx für jeden Tipp...

  • Hallo,


    ich kann euch zu eurem Problem nicht helfen, sondern stelle zwei weitere Fragen:


    1. Überschreiben der Return-Adresse
    Mittlerweile ist es mir möglich die Return-Adresse der Funktion "echo" (0x0804...) zu überschreiben. Die Adresse ändere ich auf eine, die auf den oberen Teil des Buffers (auf eine NOP-Anweisung vor dem Shellcode) zeigt (0xbffff8a0). Dadurch bekomme ich die folgende Fehlermeldung:

    Code
    1. (gdb) n
    2. 0xbffff8a0 in ?? ()
    3. (gdb) c
    4. Continuing.
    5. Program received signal SIGSEGV, Segmentation fault.
    6. 0x08049a58 in _GLOBAL_OFFSET_TABLE_ ()

    2. Hinweis zur Angabe

    Quote


    Note that you cannot debug the vulnerable programs directly, so you might want to compile your version of the vulnerable program and try to exploit it first.

    Warum sollte ich das nicht können? Das Debuggen der Programme ist grundsätzlich möglich.


    Ich hoffe es kann mir jemand weiterhelfen.
    danke


    PS: Ich sitze mittlerweile seit Tagen an dieser Challenge ohne wirklich zählbare Erfolge. Es würde mich daher interessieren ob es anderen ähnlich geht?

  • Hallo,


    @everyone but andi_:
    ich nehm mal an ihr habt ein bestimmtes tutorial gefunden. das ist gut, aber nicht schwierig. ihr seid dem tutorial gefolgt - von anfang bis ende. auch das ist gut, aber ebenfalls nicht schwierig. sorry wenn ich diese gerne von lehrpersonal verwendete floskel verwende aber: versucht, zu verstehen, was da passiert! was genau wird in der got gespeichert? genau, ein ______. und dieser ______ _____ auf eine beliebige speicherstelle. hat das jeder verstanden? auf eine beliebige speicherstelle.


    der schlüsssel zu vuln2 liegt schon in besagtem tutorial, nur muss man am schluss doch etwas "kreativ" werden und sich selbst was einfallen lassen. nur stur (hey, das reimt sich) dem tutorial folgen reicht nicht.
    ich versuch mal anzudeuten, was meiner meinung nach bei euch nicht funktioniert: ihr macht aus dem exit() (oder dem fprintf(), wie jemand gemeint hat - wo ich auch angesetzt hab; aber rein theoretisch sollte es auch bei exit() möglich sein) ein system(). ja? all diese funktionen lassen sich ihre parameter über den stack geben. und jetzt seht euch mal an, welche parameter system() braucht, und welche fprintf() und exit() haben. dann überlegt euch, was passiert, wenn ihr zwar das aufrufziel für eine funktion ändert, aber die parameter nicht. übrigens: stdout ist ein zeiger. (ich kann natürlich nicht für die richtigkeit all dieser information garantieren, es ist nur eine vermutung. und es tut mir leid, dass ich so klinge wie der irrsinig nervige mathelehrer in der 6. klasse, aber ich will nicht zuviel verraten...:rolleyes: schließlich soll man doch was lernen :p)



    so und nun andi_:
    bezgl. überschreiben der return-adresse: das klingt interessant; bist du dir sicher, dass die adresse, mit der du die return-adresse überschreibst, in deine nop-sledge zeigt? versuch mal, nicht mit "c"(ontinue) zu arbeiten, sondern mit stepi schritt für schritt weiterzugehen und dir mit "x/10i $eip" ausgeben zu lassen, was gleich passiert; dann siehst du, wo und warum der seg fault passiert. kann natürlich auch sein, dass dein shellcode nicht so funktioniert wie geplant.
    bzgl. hinweis zu angabe: vielleicht war gemeint, dass man mit einer selbstkompilierten version auf sourcecode-ebene debuggen kann (von wegen debug-informationen und so)? nur eine vermutung meinerseits.



    viel spaß & erfolg,


    onkel_keks

    [chaas4747]: What the hell is a defence?
    [dermalin3k]:
    It's that wall in deyard between dehouses.

    Edited 2 times, last by onkel_keks: ergänzungen ().

  • HI - thx für dein Reply und keine Angst empfinde es nicht als störrend wenn du vielleicht ein wenig belehrend wirkst *G*


    Bin für jeden Tip dankbar und will nun auch keinen fertigen Code oder Addressen. *Der Lerneffekt steht für mich sicherlich im Vordergrund*


    per objdump hab ich auch gesehendas man stdout verändern könnte dachte aber noch nicht an diese Möglichkeit da was zu verändern ;)


    ich hab gedacht das man eventuell das exit verändert weil soweit ich weiß ein system(0) -> eine Bash aufmacht (bitte um Berichtigung) *g*

  • Ich hab vuln2.c gelöst, aber nicht dadurch, dass der Shellcode im eingeschleusten Argument lag. Das hat einfach nicht geklappt bei mir. Sollte das grundsätzlich gehen, oder hat es einen bestimmten Grund warum ich es auf diese Art und Weise nicht lösen konnte?

  • Hi hätte eine generelle Frage ob die Methode für vul2 eventuell funktionieren könnte:


    ich erstelle ein C - Programm mit 2 buffern


    char buffer1[133]
    char buffer2[5]


    die ersten 128 Zeichen für buffer 1 geb ich Nops rein dann geb ich 128-strlen(shellcode)-1 den shellcode rein und ein terminierendes '\0'
    hinten dran sprich ab Zeichen 128 geb ich die Addresse von fprint oder exit rein und lass es wieder mit einen '\0' enden


    im Buffer2 geb ich die Addresse des Buffers rein + '\0'


    ist das möglich weil entweder ist es nicht möglich und ich bräuchte dringends einen Tipp ;) oder es ist möglich und ich hab mich verechnet - dann wäre ich auch dankbar für jeden Tipp ;)


    thx auf alle Fälle ;)

  • ich habe nun folgendes problem:
    ich habe es geschafft dem prog meinen shellcode unterzujubeln und ausfuehren zu lassen. das funktioniert einwandfrei mit meinem eigenen objectfile von vuln2.
    wenn ich meinen exploit jedoch auf das original objectfile von vuln2 loslasse, bekomme ich immer einen fehler und schaffe es nicht eine shell zu oeffnen. (ja ich habe die adressen angepasst ;-))


    das kuriose an der ganzen sache ist, dass ich mir dann /usr/local/bin/prog6 in mein verzeichnis kopiert habe und den exploit auf diesem objectfile getestet habe - und siehe da, eine shell hat sich geoeffnet!!! allerdings natuerlich mit der falschen guid.


    aber wie kann es sein, dass der exploit auf dem selben objectfile einmal funktioniert und einmal nicht?? was habe ich uebersehen??

    Es gibt nur einen Gott:
    Farin - Bela - Rod
    ---------------------------------------
    There are 10 types of people:
    those that understand binary,
    and those that don´t!!!

  • ich habe nun folgendes problem:
    ich habe es geschafft dem prog meinen shellcode unterzujubeln und ausfuehren zu lassen. das funktioniert einwandfrei mit meinem eigenen objectfile von vuln2.
    wenn ich meinen exploit jedoch auf das original objectfile von vuln2 loslasse, bekomme ich immer einen fehler und schaffe es nicht eine shell zu oeffnen. (ja ich habe die adressen angepasst ;-))


    das kuriose an der ganzen sache ist, dass ich mir dann /usr/local/bin/prog6 in mein verzeichnis kopiert habe und den exploit auf diesem objectfile getestet habe - und siehe da, eine shell hat sich geoeffnet!!! allerdings natuerlich mit der falschen guid.


    aber wie kann es sein, dass der exploit auf dem selben objectfile einmal funktioniert und einmal nicht?? was habe ich uebersehen??


    ich habe das beispiel nun geloest. war logischerweise ein adressproblem, obwohl ich nicht genau weiss wo der unterschied ist (adressmaessig gesehen), ob ich prog6 in meinem verzeichnis aufrufe oder in /usr/local/bin/prog6?

    Es gibt nur einen Gott:
    Farin - Bela - Rod
    ---------------------------------------
    There are 10 types of people:
    those that understand binary,
    and those that don´t!!!

  • Servus,


    Prog6 hab ich schon geschafft - bei prog5 häng ich grad komplett.
    Hat jemand einen kleinen Tipp für mich?


    Andere Frage, Deadline ist der 17.11 ist damit gemeint das ich den 17. auch noch Zeit habe oder "nur" noch heute bis 23:59 ?

  • Prog6 hab ich schon geschafft - bei prog5 häng ich grad komplett.

    bei mir ists genau umgekehrt :) wobei sich die shell schon kurz öffnet (genau wie Uter schon geschrieben hat)
    fürs vuln1 ist aleph one eine gute referenz, wobei du bei diesem stop-character noch etwas kreativ werden musst. wo haperts denn genau?


    Andere Frage, Deadline ist der 17.11 ist damit gemeint das ich den 17. auch noch Zeit habe oder "nur" noch heute bis 23:59 ?

    in der angabe steht doch "you need to submit your solution until november the 19th" morgen kommt nur das ch3, eventuell hast du da was verwechselt. oder hast du andere infos?

  • Naja, wo haengst du denn? Aleph One's exploit3.c schon angeschaut?


    Und ich kann dich beruhigen, die deadline ist am 19.11. ;)

  • das mit dem 17 hab ich dann wohl irgendwo anders her... :/


    Danke, ging doch viel leichter als ich gedacht hab...



    habs damit geschafft :D



    kroni leg dir Breakpoints für system() an und schau was dann genau im speicher liegt.

  • Quote from bandit


    gcc: vfork: Resource temporarily unavailable


    Nachdem bandit mich leider seit Mitternacht nicht mehr kompilieren lässt, frage ich halt hier in der Zwischenzeit mal nach, ob ich auf dem richtigen Weg bin.


    vuln1.c: Dafür sollte exploit3.c eh fast unverändert ausreichen, mit dem passenden Offset sollte ich in den Adressbereich der NOP-Sledge hüpfen können. Was hat es mit diesem mysteriösem Stop-Zeichen auf sich? Soweit ich sehe kommt dieses Zeichen im Inhalt meines Buffers samt Shellcode nicht vor, also brauche ich ja eigentlich nur das terminierende '\0' damit zu ersetzen? Oder was habt ihr mit Kreativität gemeint?


    vuln2.c: Plan: Sprung auf exit() durch Sprung auf system() ersetzen. Habe mir mal objdump -R angesehen und versucht durch den angegebenen Offset Rückschlüsse zu ziehen, an welcher Speicherstelle denn dieser Sprung liegt (ohne Erfolg, muss erst herausfinden zu welcher Basisadresse der Offset dazugezählt wird). Dann muss ich auch noch die Speicherstellen der Argumente finden (bzw. die Zeiger auf die Argumente) ... Kann ich da mit GDB irgendwie arbeiten, um auf die Speicherstellen zu kommen?

  • vuln1.c:


    In den Shellcodes vom Aleph One-Tutorial kommen entweder \x00 oder \x31 vor, beide Zeichen führen dazu, dass der Buffer nicht komplett kopiert wird. Diese Zeichen musst du durch andere ersetzen, indem du andere Assembler-Befehle verwendest und die Addressen entsprechend anpasst. Wenn du einen Shellcode ohne diesen Zeichen hast, der in einem Testprogramm auch wirklich eine Shell öffnet, bist du eh schon so gut wie fertig. Aber Achtung, nicht gleich aufgeben, wenn's nicht beim ersten Aufruf klappt, ich hab bei mir auch erst ein wenig mit den Parametern von exploit3 spielen müssen.


    vuln2.c:


    Da gibts ein schönes pdf-Tutorial im Netz (google mal nach Global Offset Table Stack Overflow), das man anwenden kann. Die Grundidee ist, dass man die GOT überschreibt (in 2 Schritten über die beiden strcpy-Befehle) und damit dafür sorgt, dass statt printf (oder exit) ein system-Befehl ausgeführt wird.
    objDump -R sollte dir eigentlich anzeigen, wo die GOT liegt, die Addresse von system kriegst du z.B. über gdb und die lokalen Variablen liegen sowieso alle am Stack, da musst du dir nur die Reihenfolge überlegen, ansonsten brauchst du glaub ich keine Addressen herausfinden. Von wo die GOT aufgerufen wird und was da genau an Adressauflösung passiert, ist da nicht so entscheidend.

    "Sausen Sie mit mir ins Laplace-Land" - KAISER 4ever :D

    Edited 2 times, last by templar ().

  • Was hat es mit diesem mysteriösem Stop-Zeichen auf sich? Soweit ich sehe kommt dieses Zeichen im Inhalt meines Buffers samt Shellcode nicht vor, also brauche ich ja eigentlich nur das terminierende '\0' damit zu ersetzen? Oder was habt ihr mit Kreativität gemeint?


    OK, falsch gedacht - natürlich kommt das Stopzeichen im Shellcode vor, habe jetzt meinen Buffer so umstrukturiert, dass zuerst die Sprungadresse sehr oft wiederholt wird, dann knapp über der echten Buffergröße die NOP-Sledge anfängt und schließlich der Shellcode kommt.


    Problem: Wenn ich dann "prog5 `echo $EGG`" ausführe, erhalte ich eine Illegal instruction. Wenn ich aber prog5 im gdb mit "run `echo $EGG`" laufen lasse, dann öffnet sich eine Shell. Leider habe ich in dieser Shell aber wieder nur meine GID, auch wenn ich versuche in einem Programm die GID auf 205 setzen und danach /bin/grade aufrufe passt die GID nicht. Hat da jemand Vorschläge?

  • vuln1.c:


    In den Shellcodes vom Aleph One-Tutorial kommen entweder \x00 oder \x31 vor, beide Zeichen führen dazu, dass der Buffer nicht komplett kopiert wird. Diese Zeichen musst du durch andere ersetzen, indem du andere Assembler-Befehle verwendest und die Addressen entsprechend anpasst. Wenn du einen Shellcode ohne diesen Zeichen hast, der in einem Testprogramm auch wirklich eine Shell öffnet, bist du eh schon so gut wie fertig.


    Danke, das hat geholfen. 0x31 ist der Befehl xorl, der in unseren Fällen nichts anderes macht als ein Register auf 0 zu setzen (in dem das Register mit sich selbst XOR-verknüpft wird). Das kann man aber auch mit einem anderen Assemblerbefehl erreichen, der angewendet auf dasselbe Register den gleichen Effekt erzielt.


    Leider musste ich auf diesen Ansatz umsteigen, weil meine Shell, die ich zwar in GDB öffnen konnte, nicht die richtige effektive GID besaß. Immerhin ist prog5 jetzt mal gelöst.


    BTW: Ich stehe heute wohl permanent auf der Leitung, das Abgabeskript ist /bin/grade2 und nicht /bin/grade! :sudern: