Leer & oefen AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Leer & oefen GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* **Sluit aan by die** 💬 [**Discord-groep**](https://discord.gg/hRep4RUj7f) of die [**telegram-groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
Om te sien dat die stelsels oproepe korrek uitgevoer word, moet die vorige program gekompileer word en die stelsels oproepe moet verskyn in **strace ./PROGRAMA\_COMPILADO**
Wanneer shellcodes geskep word, kan 'n truuk gedoen word. Die eerste instruksie is 'n jump na 'n call. Die call roep die oorspronklike kode aan en plaas ook die EIP op die stack. Na die call instruksie het ons die string wat ons benodig, ingevoeg, sodat ons met daardie EIP na die string kan verwys en ook die kode kan voortgaan uitvoer.
Bestaan uit 'n klein kode wat die geheuebladsye wat aan 'n proses gekoppel is, deursoek op soek na die shellcode wat daar gestoor is (soek 'n handtekening wat in die shellcode geplaas is). Nuttig in gevalle waar daar slegs 'n klein ruimte is om kode in te spuit.
Bestaan uit gesleutelde shells wat 'n klein kode het wat hulle ontsleutel en na hulle spring, met die Call-Pop truuk, dit sou 'n **cesar gesleutelde voorbeeld** wees:
Deur te kyk hoe die stapel van 'n nuwe proses in linux gebou word, kan 'n exploit ontwikkel word sodat die program in 'n omgewing begin word waarvan die enigste veranderlike die shellcode is. Die adres hiervan kan dan bereken word as: addr = 0xbfffffff - 4 - strlen(NAME\_complete\_executable) - strlen(shellcode)
Die **sprintf beweeg** 'n geformateerde string **na** 'n **veranderlike.** Daarom kan jy die **formatering** van 'n string misbruik om 'n **buffer oorloop in die veranderlike** waar die inhoud na gekopieer word, te veroorsaak.\
Byvoorbeeld, die payload `%.44xAAAA` sal **44B+"AAAA" in die veranderlike skryf**, wat 'n buffer oorloop kan veroorsaak.
**`atexit()`** is 'n funksie waaraan **ander funksies as parameters oorgedra word.** Hierdie **funksies** sal **uitgevoer** word wanneer 'n **`exit()`** of die **terugkeer** van die **hoof** uitgevoer word.\
As jy die **adres** van enige van hierdie **funksies** kan **wysig** om na 'n shellcode te verwys, sal jy **beheer** oor die **proses** verkry, maar dit is tans meer ingewikkeld.\
Tans is die **adresse na die funksies** wat uitgevoer moet word, **versteek** agter verskeie strukture en uiteindelik is die adres waarnatoe dit verwys nie die adresse van die funksies nie, maar is **geënkripteer met XOR** en verskuiwings met 'n **willekeurige sleutel**. So tans is hierdie aanvalsvector **nie baie nuttig nie, ten minste op x86** en **x64\_86**.\
Die **enkripsiefunksie** is **`PTR_MANGLE`**. **Ander argitekture** soos m68k, mips32, mips64, aarch64, arm, hppa... **implementeer nie die enkripsie** funksie nie omdat dit **die selfde** teruggee as wat dit as invoer ontvang. So hierdie argitekture kan deur hierdie vektor aangeval word.
Wat gebeur is dat EIP en ESP deur die **`PTR_MANGLE`** funksie oorgedra word, so die **argitekture wat kwesbaar is vir hierdie aanval is dieselfde as hierbo**.\
E however, volgens wat ek gelees het, is die ander registers nie beskerm nie, **so as daar 'n `call ebx`, `call esi` of `call edi`** binne die funksie wat aangeroep word, kan beheer oorgeneem word. Of jy kan ook EBP wysig om die ESP te wysig.
Elke objek van 'n **klas** het 'n **VPtr** wat 'n **pointer** na die array van sy klas is. Die VPtr is deel van die kop van elke objek, so as 'n **oorskrywing** van die **VPtr** bereik word, kan dit **gewysig** word om na 'n dummy metode te **wys** sodat die uitvoering van 'n funksie na die shellcode sal gaan.
Dit onderskep oproepe na sommige onveilige funksies deur ander veilige. Dit is nie gestandaardiseer nie. (slegs vir x86, nie vir kompilasies met -fomit-frame-pointer, nie statiese kompilasies nie, nie alle kwesbare funksies word veilig nie en LD\_PRELOAD werk nie in binêre met suid).
Dit bestaan uit die laai van die gedeelde biblioteke van 0x00000000 tot 0x00ffffff sodat daar altyd 'n byte 0x00 is. Dit stop egter regtig min aanvalle, en nog minder in little endian.
Dit bestaan uit die uitvoering van 'n ROP sodat die funksie strcpy@plt (van die plt) aangeroep word en na die ingang van die GOT gewys word en die eerste byte van die funksie wat aangeroep moet word (system()). Daarna word dieselfde gedoen deur na GOT+1 te wys en die 2de byte van system() te kopieer… Uiteindelik word die adres wat in GOT gestoor is, aangeroep wat system() sal wees.
In “size” is daar bits om aan te dui: Of die vorige stuk in gebruik is, of die stuk deur mmap() toegeken is en of die stuk aan die primêre arena behoort.
As 'n stuk vrygestel word en enige van die aangrensende vry is, word hulle saamgevoeg deur die makro unlink() en die nuwe groter stuk word aan frontlink() oorgedra sodat dit die toepaslike bin kan invoeg.
Daarom, as ons daarin slaag om die P->bk met die adres van 'n shellcode en die P->fd met die adres na 'n ingang in die GOT of DTORS minus 12 te wysig, word dit bereik:
BK->fd = FD -> \*(\&shellcode + 8) = (&\_\_dtor\_end\_\_ - 12) —> Dit veroorsaak die skrywe van 4 bytes vanaf die 8ste byte van die shellcode, so die eerste instruksie van die shellcode moet 'n jmp wees om dit te spring en in 'n paar nops te val wat na die res van die shellcode lei.
Na die shellcode plaas ons opvulling totdat ons by die prev\_size en size veld van die volgende stuk kom. In hierdie plekke plaas ons 0xfffffff0 (sodat die prev\_size oorgeskryf word om die bit wat sê dat dit vry is, te hê) en “-4“(0xfffffffc) in die size (sodat wanneer dit in die 3de stuk nagaan of die 2de werklik vry was, dit na die gewysigde prev\_size gaan wat sal sê dat dit vry is) -> So wanneer free() ondersoek, sal dit na die size van die 3de gaan, maar werklik na die 2de - 4 en sal dink dat die 2de stuk vry is. En dan sal dit **unlink()** aanroep.
Wanneer unlink() aangeroep word, sal dit as P->fd die eerste data van die 2de stuk gebruik, sodat daar die adres wat oorgeskryf moet word - 12 (want in FD->bk sal dit 12 by die adres wat in FD gestoor is, optel). En in daardie adres sal dit die tweede adres wat in die 2de stuk gevind word, invoeg, wat ons sal belangrik wees dat dit die adres na die shellcode is (P->bk vals).
**fake\_size = pack("\<I”, 0xfffffffc) #-4, sodat dit dink dat die “size” van die 3de stuk 4bytes agter is (wys na prev\_size) want dit is daar waar dit kyk of die 2de stuk vry is**
**got\_free = pack("\<I", 0x08048300 - 12) #Adres van free() in die plt-12 (sal die adres wees wat oorgeskryf word sodat die shellcode die 2de keer wat free aangeroep word, gelanseer word)**
**payload += prev\_size + fake\_size + got\_free + addr\_sc #Die 2de stuk word gewysig, die got\_free wys na waar ons die adres addr\_sc + 12 gaan stoor**
Dan sal die program dink dat “a” vry is en in 'n bin, sodat dit unlink() sal aanroep om dit te ontkoppel. Maar, aangesien die kop PREV\_SIZE -4 is, sal dit dink dat die stuk van “a” werklik begin in b+4. Dit wil sê, dit sal 'n unlink() na 'n stuk wat begin in b+4, so in b+12 sal die pointer “fd” wees en in b+16 sal die pointer “bk” wees.
Dit word frontlink genoem wanneer iets vrygestel word en geen van sy aangrensende stukke vry is nie, word unlink() nie aangeroep nie, maar word direk frontlink() aangeroep.
'n buffer wat aan hierdie buffer grens wat vrygestel moet word en waarvan die fd veld van sy kop gewysig sal word danksy die oorloop van die vorige buffer
Op hierdie manier, deur in twee mallocs ongekontroleerd te oorskry en in een op 'n beheerde manier, maar slegs daardie een vry te stel, kan ons 'n exploit maak.
In die geval dat een weer gebruik moet word, sal dit sonder probleme toegeken word. In die geval dat 'n ander gebruik moet word, sal dit dieselfde ruimte toegeken word, sodat ons die pointers “fd” en “bk” vals sal hê met die data wat die vorige reservasie sal skryf.
Slegs een oproep na free() is nodig om die uitvoering van arbitrêre kode te veroorsaak. Dit is belangrik om 'n tweede stuk te soek wat deur 'n vorige oorloop vrygestel kan word.
In \[1] kyk dit na die size veld die bit NON\_MAIN\_ARENA, wat verander kan word sodat die kontrole terugkeer waar dit waar is en heap\_for\_ptr() aanroep wat 'n and op “mem” doen wat die 2.5 minder belangrike bytes op 0 laat (in ons geval van 0x0804a000 laat dit 0x08000000) en toegang tot 0x08000000->ar\_ptr verkry (soos 'n struct heap\_info).
Op hierdie manier, as ons 'n stuk kan beheer byvoorbeeld in 0x0804a000 en daar gaan 'n stuk vrygestel word in **0x081002a0**, kan ons by die adres 0x08100000 kom en skryf wat ons wil, byvoorbeeld **0x0804a000**. Wanneer hierdie tweede stuk vrygestel word, sal dit vind dat heap\_for\_ptr(ptr)->ar\_ptr die waarde teruggee wat ons in 0x08100000 geskryf het (want die and wat ons vroeër gesien het, word op 0x081002a0 toegepas en daaruit word die waarde van die eerste 4 bytes, die ar\_ptr, geneem).
Daarom, as ons in av->bins\[2] die waarde van \_\_DTOR\_END\_\_-12 skryf, sal die laaste instruksie in \_\_DTOR\_END\_\_ die adres van die tweede stuk skryf.
Dit wil sê, in die eerste stuk moet ons aan die begin baie keer die adres van \_\_DTOR\_END\_\_-12 plaas, want daaruit sal av->bins\[2] dit neem.
In die adres waar die adres van die tweede stuk met die laaste 5 nulles val, moet ons die adres na hierdie eerste stuk skryf sodat heap\_for\_ptr() dink dat die ar\_ptr aan die begin van die eerste stuk is en daaruit die av->bins\[2] sal neem.
Op hierdie manier sal \_int\_free(TROZO1, TROZO2) aangeroep word en die instruksies volg om in \_\_DTOR\_END\_\_ die adres van die prev\_size van TROZO2 te skryf wat na die shellcode sal spring.
Hierdie tegniek is nie meer toepaslik nie, aangesien 'n soortgelyke herstel toegepas is soos vir unlink. Dit word vergelyk of die nuwe plek waarnatoe gewys word, ook na homself wys.
Op hierdie manier, as ons in “fb” die adres van 'n funksie in die GOT plaas, sal daar in hierdie adres die adres na die oorgeskrywe stuk geplaas word. Hiervoor sal dit nodig wees dat die arena naby die adresse van dtors is. Meer presies dat av->max\_fast in die adres is wat ons gaan oorskryf.
As ons dan in die size veld 'n grootte van 8 + NON\_MAIN\_ARENA + PREV\_INUSE plaas —> fastbin\_index() sal ons fastbins\[-1] teruggee, wat na av->max\_fast sal wys.
Boonop moet daar aan voldoen dat die stuk wat aan die vrygestelde groter as 8 moet wees -> Aangesien ons gesê het dat die size van die vrygestelde stuk 8 is, moet ons in hierdie vals stuk net 'n size groter as 8 plaas (soos die shellcode in die vrygestelde stuk sal wees, sal daar aan die begin 'n jmp wees wat in nops val).
As gevolg van die nulles van \_DTOR\_END\_ en die min adresse in die GOT, is geen adres van hierdie afdelings geskik om oorgeskryf te word nie, so kom ons kyk hoe om fastbin toe te pas om die stapel aan te val.
Boonop, in **av->system\_mem** (1484bytes bo die posisie in die stapel) sal daar genoeg rommel wees wat ons sal toelaat om die kontrole wat gedoen word, te oorkom.
Boonop moet daar aan voldoen dat die stuk wat aan die vrygestelde groter as 8 moet wees -> Aangesien ons gesê het dat die size van die vrygestelde stuk 16 is, moet ons in hierdie vals stuk net 'n size groter as 8 plaas (soos die shellcode in die vrygestelde stuk sal wees, sal daar aan die begin 'n jmp wees wat in nops val wat na die size veld van die nuwe vals stuk gaan).
In hierdie geval soek ons 'n pointer na 'n malloc wat deur die aanvaller gewysig kan word (byvoorbeeld, dat die pointer onder 'n moontlike oorloop na 'n veranderlike op die stapel is).
So kan ons maak dat hierdie pointer na enige plek wys. Maar nie enige plek is geldig nie, die grootte van die vals stuk moet kleiner wees as av->max\_fast en meer spesifiek gelyk aan die grootte wat in 'n toekomstige oproep na malloc()+8 aangevra word. Daarom, as ons weet dat na hierdie kwesbare pointer malloc(40) aangeroep word, moet die grootte van die vals stuk gelyk wees aan 48.
As die program byvoorbeeld die gebruiker om 'n nommer vra, kan ons 48 invoer en die veranderlike pointer na die volgende 4bytes (wat dalk aan die EBP behoort, met geluk, so die 48 agterbly, soos die kop grootte). Boonop moet die adres ptr-4+48 aan verskeie voorwaardes voldoen (in hierdie geval ptr=EBP), dit wil sê, 8 <ptr-4+48<av->system\_mem.
As dit nagekom word, wanneer die volgende malloc wat ons gesê het malloc(40) is, sal dit as adres die adres van die EBP toegeken word. As die aanvaller ook kan beheer wat in hierdie malloc geskryf word, kan hy sowel die EBP as die EIP met die adres wat hy wil, oorskryf.
Ek glo dit is omdat wanneer dit vrygestel word, free() sal onthou dat daar in die adres wat na die EBP van die stapel wys, 'n stuk van die perfekte grootte vir die nuwe malloc() wat gereserveer wil word, is, so dit ken daardie adres toe.
Die eerste stap is om die size van die wilderness stuk met 'n baie groot waarde (0xffffffff) te oorskryf, sodat enige aanvraag van genoegsame groot geheue in \_int\_malloc() behandel sal word sonder om die heap uit te brei.
Die tweede stap is om die av->top te verander sodat dit na 'n geheuegebied onder die beheer van die aanvaller wys, soos die stapel. In av->top sal \&EIP - 8 geplaas word.
Victim neem die waarde van die adres van die huidige wilderness stuk (die huidige av->top) en remainder is presies die som van daardie adres plus die hoeveelheid bytes wat deur malloc() aangevra is. So as \&EIP-8 in 0xbffff224 is en av->top 0x080c2788 bevat, sal die hoeveelheid wat ons in die beheerde malloc moet reserveer sodat av->top na $EIP-8 wys vir die volgende malloc() wees:
Dit is belangrik om te weet dat die size van die nuwe wilderness stuk groter moet wees as die aanvraag wat deur die laaste malloc gemaak is. Dit wil sê, as die wilderness na \&EIP-8 wys, sal die size presies in die EBP veld van die stapel wees.
Die vrygestelde stukke word in die bin ingevoer op grond van hul grootte. Maar voordat hulle ingevoer word, word hulle in onsorted bins gestoor. 'n Stuk wat vrygestel word, word nie onmiddellik in sy bin geplaas nie, maar bly in onsorted bins. Daarna, as 'n nuwe stuk gereserveer word en die vorige vrygestelde dit kan dien, word dit teruggegee, maar as 'n groter gereserveer word, word die vrygestelde stuk in onsorted bins in sy toepaslike bin geplaas.
Dat daar twee mallocs gereserveer word, sodat die eerste oorloop kan word nadat die tweede vrygestel is en in sy bin ingevoer is (dit wil sê, 'n groter malloc gereserveer is voordat die oorloop gemaak word).
Die doel is die volgende, as ons 'n oorloop na 'n heap kan maak wat onder 'n reeds vrygestelde stuk en in sy bin is, kan ons sy pointer bk verander. As ons sy pointer bk verander en hierdie stuk die eerste van die bin word en gereserveer word, sal bin mislei word en gesê word dat die laaste stuk van die lys (die volgende wat aangebied word) in die vals adres wat ons geplaas het (na die stapel of GOT byvoorbeeld) is. So as daar weer 'n ander stuk gereserveer word en die aanvaller toestemming het, sal 'n stuk in die gewenste posisie gegee word en kan daar in geskryf word.
Na die vrystelling van die gewysigde stuk is dit nodig om 'n stuk groter as die vrygestelde te reserveer, sodat die gewysigde stuk uit onsorted bins sal kom en in sy bin ingevoer sal word.
So sal die bin moet wag totdat daar genoeg malloc() aanroep is sodat die gewysigde bin weer gebruik word en bin mislei word om te glo dat die volgende stuk in die vals adres is. En dan sal die stuk wat ons belangstel, gegee word.
Om die kwesbaarheid so vroeg as moontlik uit te voer, is dit ideaal: Reservasie van die kwesbare stuk, reservasie van die stuk wat gewysig sal word, vrystelling van hierdie stuk, reservasie van 'n groter stuk wat gewysig sal word, wysiging van die stuk (kwesbaarheid), reservasie van 'n stuk van gelyke grootte as die gewysigde en 'n tweede stuk van gelyke grootte wat na die gekose adres sal wys.
Om hierdie aanval te beskerm, is die tipiese kontrole gebruik dat die stuk “nie” vals is nie: dit word nagegaan of bck->fd na victim wys. Dit wil sê, in ons geval of die pointer fd\* van die vals stuk wat in die stapel gewys is, na victim wys. Om hierdie beskerming te oorkom, moet die aanvaller in staat wees om op een of ander manier (waarskynlik deur die stapel) in die toepaslike adres die adres van victim te skryf. Sodat dit soos 'n werklike stuk lyk.
Die aanval is soos die vorige, dit wil sê, die pointer bk moet gewysig word en al daardie aanroepe na malloc() is nodig, maar boonop moet die size van die gewysigde stuk so gewysig word dat daardie size - nb <MINSIZE.
Basies bestaan dit uit die reservasie van soveel moontlik geheue vir heaps en om dit met 'n matras van nops wat met 'n shellcode eindig, te vul. Boonop word 0x0c as matras gebruik. Dit sal probeer om na die adres 0x0c0c0c0c te spring, en so as daar enige adres oorgeskryf word waarnatoe daar na geroep gaan word met hierdie matras, sal dit daarheen spring. Basies is die taktiek om soveel as moontlik te reserveer om te sien of 'n pointer oorgeskryf word en na 0x0c0c0c0c te spring in die verwagting dat daar nops is.
Dit bestaan uit die reservasie en vrystelling van geheue sodat daar stukke gereserveer word tussen vrye stukke. Die buffer wat oorloop sal in een van die eiers geleë wees.
Leer & oefen AWS Hacking:<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">[**HackTricks Training AWS Red Team Expert (ARTE)**](https://training.hacktricks.xyz/courses/arte)<imgsrc="/.gitbook/assets/arte.png"alt=""data-size="line">\
Leer & oefen GCP Hacking: <imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">[**HackTricks Training GCP Red Team Expert (GRTE)**<imgsrc="/.gitbook/assets/grte.png"alt=""data-size="line">](https://training.hacktricks.xyz/courses/grte)
* Kyk na die [**subskripsie planne**](https://github.com/sponsors/carlospolop)!
* **Sluit aan by die** 💬 [**Discord groep**](https://discord.gg/hRep4RUj7f) of die [**telegram groep**](https://t.me/peass) of **volg** ons op **Twitter** 🐦 [**@hacktricks\_live**](https://twitter.com/hacktricks\_live)**.**
* **Deel hacking truuks deur PRs in te dien na die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
