Posts by onkel_keks

    Maybe try generating packets with different ip addresses, different ports etc. and see if the checksum is always valid. how do you use those wireshark functions? are you linking some module or did you rip the code, i.e. copy/paste the source? (btw: its really not that difficult to code the algo but hey - interesting approach :p)

    Quote


    I was wondering if
    1) i have to support hostnames as well
    2) i have to do sanity checks for the arguments (now i just check argument number
    3) i have to suppress all output

    1) - no
    2) and 3) maybe. my working program did not produce any output to stdout (except in case of an error). and i checked for the proper formatting of the arguments.



    Quote


    - Wird hier immer nach der IP Addresse von inetsec.seclab.tuwien.ac.at gefragt?

    es scheint auf master.inetsec.edu eine firewall o.ä. zu geben, angeblich (da von mir ungetestet) werden auf der website nur pakete angezeigt, deren source-ip im selben netz liegen wie master.
    edit: ach so, jetzt verstehe ich was du meinst. also rein prinzipiell ist es egal, nach welcher adresse gefragt wurde. du sollst nur - unabhängig von einem dns request - ein dns reply paket generieren. mit einer durch kommandozeilenparameter festgelegten antwort-ip.


    Quote


    - Erhalten wir das zu verändernde Paket (immer) von dns.dump oder geht es hier (nur) um Antworten zu diesem spezifischen dns.dump?

    du sollst kein paket verändern sondern eines erstellen/generieren - nämlich ein DNS reply. ich hab als dns id die id von dns.dump genommen (hardcoded); falls die frage noch auftaucht.


    viel erfolg
    onkel_keks

    so does master.inetsec.edu accept your packets now?
    as for the grading robot problem: try to clone the answer packet from the dump files provided on the course website (spoof.dump and dns.dump). you should be able to create identical packets with your code except for the ethernet header, obviously. diff is your friend here. or fc, for that matter). if there is anything different in the packets generated by your program, this might be the error.

    Quote


    Hat jemand eine Erklärung dafür warum das mit den Segmentation-Faults sobald man Breakpints einfügt passiert?

    Ich nehm mal an, das wird ein anti-debug-mechanismus sein. Ich muss sagen, dass ich von anti-debugging-techniken unter linux nicht wirklich ahnung hab und ich auch gdb nicht wirklich sooo gut kenn, aber es wäre möglich, dass folgendes passiert:
    - wenn du in gdb einen breakpoint setzt, schreibt dir gdb an die angegebene stelle ein 0xcc (int 03). sobald im programmfluss dieses int 03 erreicht wird, wird die kontrolle an den debugger übergeben, der überschreibt das 0xcc wieder mit dem original-byte an der adresse und du kannst fröhlich befehl für befehl tracen.
    - im programm befindet sich eine kleine routine, die das eigene image nach 0xcc absucht und wenn die routine fündig wird, bringt sie das programm zum absturz, weil dann klar ist, dass das programm debuggt wird (oder es wird einfach eine checksum berechnet und verglichen).


    wie gesagt bin ich aber zu wenig linux/gdb-guru um mehr als vermutungen anzustellen. ich hab kurz nach einer solchen check-routine gesucht, wurde aber nicht fündig. allerdings ist der serial-check von prog8 glücklicherweise relativ simpel gehalten, sodass statische code-analyse eigentlich ausreicht (zugegebenermaßen habe ich für die statische analyse aber nicht mit objdump sondern mit ida gearbeitet - das macht die sache irgendwie angenehmer :p).


    EDIT: ich weiß nicht ob die sache mit prog7 und nicht vollständiger lösung noch aktuell ist. anyway: wenn man einen CALL auf eine funktion ausNOPt, wird die funktion nicht aufgerufen. klingt banal, ist es auch. allerdings sollte man, bevor man dies tut, genau wissen was die funktion macht. und damit meine ich nicht, dass den serialcheck-algorithmus verstehen sollte. es ist viel einfacher. man muss sich nur die funktion genau ansehen - von anfang bis ende.

    Quote


    Was bringt eigentlich: movzx eax, al
    passiert da nicht im Wesentlichen folgendes: eax=eax?

    im wesentlichen ja; allerdings "move with zero extension". auf deutsch (oder besser in zahlen :)): wenn in eax 0x11223344 steht und du machst movzx eax, al dann hast du nachher in eax 0x00000044 stehen. klar?


    Quote


    mul ecx --> was genau bedeutet dieser Befehl (abgesehen vom Überlauf): EAX= EAX*EXC???? Und warum landet der Überlauf dann in EDX?

    deine eigene beantwortung der frage stimmt :thumb:
    und der überlauf landet in edx weil...das eben so ist. wenn man zwei 32-bit zahlen multipliziert ist die wahrscheinlichkeit groß, dass das ergebnis größer als 32 bit ist. ergo verwendet man das registerpaar edx:eax um das ergebnis als 64-bit-zahl darzustellen. warum gerade edx verwendet wurde...wahrscheinlich weil das hardwaretechnisch günstig ist.


    Quote


    mov [ebp+var_30], eax
    mov eax, [ebp+var_30]


    ist doch eax=eax, oder?

    wieder richtig, allerdings solltest du bemerkt haben, dass außerdem der wert von eax in einer lokalen variable gespeichert wird.
    der compiler erzeugt imho hässlichen code. aber gut. kann man nichts machen.


    Quote


    Also mir ist nicht klar, was "lookup" und "handle" bedeutet.

    lookup ist doch eigentlich recht offensichtlich (imho). stichwort indexed addressing mode... und rat mal woher der index kommt.
    bei handle allerdings kann ich auch nicht helfen; ich dachte erst, das wäre ein zusätzlicher constraint für die serial oder den user aber das wars dann irgendwie doch nicht (oder schon? nachdem ich die ch. gelöst hatte wars mir ehrlich gesagt nicht mehr so wichtig).


    viel erfolg,
    onkel_keks

    ich kann beruhigen; /bin/nc ist auch auf gangsta vorhanden. wobei ich sagen muss, mein versuch, nc auf gangsta aufzurufen war ebenfalls nicht erfolgreich. das warum habe ich da nicht weiter verfolgt, da ich auf anderem weg erfolgreich war.

    Quote

    Kann sich am Server im Vergleich zur lokalen Version auch das Allignement der 4 Adressbytes verschieben?


    Du meinst, sodass er nicht an 0x00112233 springt, sondern zB an 0x22330011? Nein, das kann nicht passieren, wenn auf gangsta die gleiche Methode respond() verwendet wird, da ja der Frame auf gangsta genau gleich aufgebaut ist wie bei dir lokal. Außer du hast in deiner lokalen Version in dieser Methode noch irgend welche Variablen eingebaut, dann verschiebt sich das ganze natürlich.

    schwierig zu erraten...eigentlich nicht. sagen wir, 3 bis 4 "educated guesses". ich nehme mal an, du arbeitest mit einer nop-sledge...
    bei mir war die richtige adresse (soweit ich mich erinnern kann) größenordnungsmäßig etwa 0x100 bytes entfernt. ich würde sagen, wenn du so einen großen bereich (mit entsprechender schrittweite) ohne erfolg durchläufst, passt was anderes nicht. hast du die login-daten für gangsta mitgeschickt? ich war so begeistert von meinem lokal funktionierendem overflow, dass ich auf den login völlig vergessen hab und dann wie ein irrer ohne erfolg tausende von adressen versucht hab...:rolleyes:

    Quote

    You will have successfuly exploited the vulnerability in the server when you are able to call /bin/grade on gangsta with the effective group-id of the group that owns the server.


    nachdem du den server exploitest, arbeitet dein shellcode schon mit der richtigen gid. wenn du im shellcode den execve-syscall ausführst, führst du das angegebene programm ebenfalls mit dieser gid aus (zumindest war bei mir kein wie auch immer gearteter set[r][e][g][u]id call erforderlich ;))

    In der Angabe steht was von einer Reverse Shell um z.B. Firewalls zu umgehen...evtl. ist auf gangsta eine Firewall eingerichtet, die das Shell binding verhindert (nachdem ich mich damit aber nicht näher beschäftigt habe, ist das nur eine Vermutung). Bei mir hat Reverse Shell funktioniert.

    ein recht praktisches programm hierbei ist netcat...(siehe auch der tip auf der challenge3-website)

    Quote


    Also ich versuche /bin/sh auszuführen und an einen Port zu binden.


    und konntest du dich in deinem lokalem testszenario mit dieser shell verbinden?

    Quote

    Die Frage ist nur, wie finde ich heraus, welche Zeile im Executable der verwundbaren Zeile im .c entspricht.


    wenn man gcc gaaanz lieb mit einem '-g' darum bittet, sieht man im gdb mit 'l' (oder 'list') den sourcecode inkl. zeilennummer und kann breakpoints auf zeilennummern setzen.


    Quote

    Aber wozu ist das fork eigentlich?


    damit der serverprozess schneller neue requests beantworten kann - indem ein eigener prozess für das handeln von eingegangenen requests geforkt wird, kann der ursprüngliche server gleich wieder zum lauschen übergehen.

    mal abgesehen davon - es ist ja sehr unterstützenswert, den shellcode verstehen zu wollen, aber so kurz vor der deadline...kopier doch einfach den shellcode vom tutorial, mach die notwendigen modifikationen daran (siehe stop-zeichen) und schau dass du fertig wirst...
    ich weiß nicht, wie du das mit dem jmp getestet/ausprobiert hast, aber irgendwas in deinem procedere passt nicht. denn der jmp war eigtl. kein problem. wie gesagt - ich würde mich jetzt nicht unbedingt darauf konzentrieren.
    oder hängst du dabei fest? dann versuch, dein problem genauer zu beschreiben.


    viel erfolg,
    onkel_keks

    was meinst du mit abfragen? wenn du einen buffer overflow zustande bringst, wirst du das ziemlich sicher bemerken - normalerweise bekommt man dann einen segmentation fault weil die adresse (noch) nicht passt. wenn dein server einfach weiter macht, läuft der buffer wahrscheinlich nicht über.
    setz doch einfach im gdb einen breakpoint auf die verwundbare codezeile im server, lass ihn laufen, verbinde dich (zb über eine parallele ssh-session) mit dem lauschenden server und versuch, den puffer zum überlaufen zu bringen.
    btw: hast du das fork-zeug in deiner lokalen server.c - version disabled?

    Hallo,


    Quote

    \x90 zählt er als 4 Zeichen statt als 1 Byte.


    du lässt server im gdb rennen, connectest (o gott was für ein wort) dich mit telnet localhost <port> und gibst \x90 ein? dann empfängt der server '\', 'x', '9', '0'. also 4 zeichen. (wie du richtig schreibst...)
    es ist aber sowieso wenig praktikabel, shellcode mit telnet zu füttern. die naheliegende lösung dafür wäre, ein clientprogramm zu schreiben, das idealerweise auch gleichzeitig den shellcode generiert und dann dem server schickt...;)


    frank99: du deaktivierst die while-schleife im server? warum?



    viel erfolg,
    onkel_keks

    hallo tno,


    jetzt verstehe ich was du meinst. ich dachte mit "buffer array" meinst du eine lokale variable.
    also zu deinem beispiel folgendes: dein buffer array ist keine lokale variable, sondern eine mittels malloc() alloziierte speicherregion. die tatsache, dass der zeiger auf diese speicherregion (buffer) eine lokale variable ist, hat hier keine bedeutung. wie man sieht, alloziiert malloc() den speicher in der "gegend" von 0x804aXXX. so.
    lokale variablen werden anders behandelt, denn sie werden am stack angelegt (wie das aleph one - tutorial erklärt). wenn man in einer funktion ein array deklariert, dann liegt dieses array auf dem stack. der stack liegt in einer eigenen "speicherregion", so um 0xbffffXXX. daher haben lokale variablen adressen in der region 0xbffffXXX und mittels malloc alloziierte speicherbereiche adressen in der region 0x804aXXX. das warum und die genauen umstände kann ich für linux leider nicht erklären; ich komm da eher von windows. auf jeden fall liegen stack-adressen aber eher weiter oben im speicher (eben bei 0xbffffXXX; eigtl. ja logisich, da der stack von oben nach unten wächst).
    malloc hat mit buffer overflows (oder zumindest mit diesem beispiel) aber wenig zu tun. wenn wir hier von "buffer overflow" reden, dann ist damit ein buffer gemeint, der am stack liegt (also eine lokale variable ist).

    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