mirror of
https://github.com/carlospolop/hacktricks
synced 2024-11-26 14:40:37 +00:00
95 lines
11 KiB
Markdown
95 lines
11 KiB
Markdown
|
# Libc Beskerming
|
||
|
|
||
|
<details>
|
||
|
|
||
|
<summary><strong>Leer AWS hakwerk vanaf nul tot held met</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
|
||
|
|
||
|
Ander maniere om HackTricks te ondersteun:
|
||
|
|
||
|
* As jy wil sien dat jou **maatskappy geadverteer word in HackTricks** of **HackTricks aflaai in PDF-formaat** Kontroleer die [**INSKRYWINGSPLANNE**](https://github.com/sponsors/carlospolop)!
|
||
|
* Kry die [**amptelike PEASS & HackTricks swag**](https://peass.creator-spring.com)
|
||
|
* Ontdek [**Die PEASS Familie**](https://opensea.io/collection/the-peass-family), ons versameling van eksklusiewe [**NFTs**](https://opensea.io/collection/the-peass-family)
|
||
|
* **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 jou haktruuks deur PRs in te dien by die** [**HackTricks**](https://github.com/carlospolop/hacktricks) en [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) github repos.
|
||
|
|
||
|
</details>
|
||
|
|
||
|
## Stuk Uitlynhandhawing
|
||
|
|
||
|
**Malloc** ken geheue toe in **8-byte (32-bit) of 16-byte (64-bit) groeperings**. Dit beteken die einde van stukke in 32-bit stelsels moet belyn met **0x8**, en in 64-bit stelsels met **0x0**. Die sekuriteitsfunksie kontroleer dat elke stuk **korrek belyn** is by hierdie spesifieke plekke voordat 'n aanwyser van 'n bak gebruik word.
|
||
|
|
||
|
### Sekuriteitsvoordele
|
||
|
|
||
|
Die handhawing van stuk uitlyn in 64-bit stelsels verbeter Malloc se sekuriteit aansienlik deur die **plaas van valse stukke te beperk tot slegs 1 uit elke 16 adresse**. Dit bemoeilik uitbuitingspogings aansienlik, veral in scenario's waar die gebruiker beperkte beheer oor insetwaardes het, wat aanvalle meer kompleks en moeiliker maak om suksesvol uit te voer.
|
||
|
|
||
|
* **Fastbin Aanval op \_\_malloc\_hook**
|
||
|
|
||
|
Die nuwe uitlynreëls in Malloc keer ook 'n klassieke aanval met betrekking tot die `__malloc_hook`. Voorheen kon aanvallers stukgroottes manipuleer om hierdie funksieaanwyser te **oorheers** en **kode-uitvoering** te verkry. Nou verseker die streng uitlynvereiste dat sulke manipulasies nie meer lewensvatbaar is nie, wat 'n algemene uitbuitingsroete sluit en die algehele sekuriteit verbeter.
|
||
|
|
||
|
## Aanwyserverminking op fastbins en tcache
|
||
|
|
||
|
**Aanwyserverminking** is 'n sekuriteitsverbetering wat gebruik word om **fastbin en tcache Fd aanwysers** in geheuebestuurhandelinge te beskerm. Hierdie tegniek help om sekere tipes geheue-uitbuitingstaktieke te voorkom, spesifiek dié wat nie gelekte geheue-inligting vereis nie of wat geheueposisies direk relatief tot bekende posisies manipuleer (relatiewe **oorheersing**).
|
||
|
|
||
|
Die kern van hierdie tegniek is 'n verduisteringsformule:
|
||
|
|
||
|
**`Nuwe_Aanwyser = (L >> 12) XOR P`**
|
||
|
|
||
|
* **L** is die **Stoorplek** van die aanwyser.
|
||
|
* **P** is die werklike **fastbin/tcache Fd Aanwyser**.
|
||
|
|
||
|
Die rede vir die bietjieverskuiwing van die stoorplek (L) met 12 bietjies na regs voor die XOR-operasie is krities. Hierdie manipulasie spreek 'n kwesbaarheid aan wat inherent is aan die bepaalde aard van die minst betekenisvolle 12 bietjies van geheueadresse, wat tipies voorspelbaar is as gevolg van stelselargitektuurbeperkings. Deur die bietjies te skuif, word die voorspelbare gedeelte uit die vergelyking verwyder, wat die willekeurigheid van die nuwe, verminkte aanwyser verbeter en sodoende teen uitbuitings beskerm wat op die voorspelbaarheid van hierdie bietjies staatmaak.
|
||
|
|
||
|
Hierdie verminkte aanwyser maak gebruik van die bestaande willekeurigheid wat deur **Adresruimte-uitlegverandering (ASLR)** voorsien word, wat adresse wat deur programme gebruik word, willekeurig maak om dit moeilik vir aanvallers te maak om die geheuelêer van 'n proses te voorspel.
|
||
|
|
||
|
**Aanwyserontverminking** om die oorspronklike adres te herwin behels die gebruik van dieselfde XOR-operasie. Hier word die verminkte aanwyser as P in die formule behandel, en wanneer dit met die onveranderde stoorplek (L) XOR is, lei dit daartoe dat die oorspronklike aanwyser onthul word. Hierdie simmetrie in verminking en ontverminking verseker dat die stelsel aanwysers doeltreffend kan kodeer en ontkodeer sonder beduidende oorhoofse, terwyl dit die sekuriteit teen aanvalle wat geheueaanwysers manipuleer, aansienlik verhoog.
|
||
|
|
||
|
### Sekuriteitsvoordele
|
||
|
|
||
|
Aanwyserverminking beoog om **gedeeltelike en volledige aanwyseroorheersing in die hoop** bestuur, 'n beduidende verbetering in sekuriteit. Hierdie kenmerk beïnvloed uitbuitingstegnieke op verskeie maniere:
|
||
|
|
||
|
1. **Voorkoming van Bye Byte Relatiewe Oorheersing**: Voorheen kon aanvallers 'n deel van 'n aanwyser verander om **geheuestukke na verskillende plekke om te lei sonder om die presiese adresse te ken**, 'n tegniek wat duidelik is in die leklose **House of Roman**-uitbuiting. Met aanwyserverminking vereis sulke relatiewe oorheersing **sonder 'n geheuelek nou brute force**, wat hul suksesmoontlikheid drasties verminder.
|
||
|
2. **Verhoogde Moeilikheid van Tcache Bin/Fastbin Aanvalle**: Gewone aanvalle wat funksieaanwysers oorskryf (soos `__malloc_hook`) deur fastbin of tcache inskrywings te manipuleer, word gehinder. Byvoorbeeld, 'n aanval kan 'n LibC-adres lek, 'n stuk in die tcache-bin vrymaak, en dan die Fd-aanwyser oorskryf om dit na `__malloc_hook` te stuur vir willekeurige kode-uitvoering. Met aanwyserverminking moet hierdie aanwysers korrek vermink word, **wat 'n geheuelek vir akkurate manipulasie noodsaak**, en verhoog dus die uitbuitingsdrempel.
|
||
|
3. **Vereiste vir Geheuelekke in Nie-Geheuelposisies**: Die skep van 'n valse stuk in nie-geheue-areas (soos die stok, .bss-afdeling, of PLT/GOT) vereis nou ook 'n geheuelek weens die behoefte aan aanwyserverminking. Dit verleng die kompleksiteit van die uitbuiting van hierdie areas, soortgelyk aan die vereiste vir die manipulasie van LibC-adresse.
|
||
|
4. **Die lek van Geheueadresse word meer uitdagend**: Aanwyserverminking beperk die bruikbaarheid van Fd-aanwysers in fastbin en tcache-bakke as bronne vir geheueadreslekkasies. Tog bly aanwysers in ongesorteerde, klein, en groot bakke onvermink, dus steeds bruikbaar vir die lek van adresse. Hierdie skuif dwing aanvallers om hierdie bakke te ondersoek vir uitbuitbare inligting, alhoewel sommige tegnieke steeds mag toelaat om aanwysers te ontvermink voordat 'n lek plaasvind, alhoewel met beperkings.
|
||
|
|
||
|
### **Ontverminking van Aanwysers met 'n Geheuelek**
|
||
|
|
||
|
{% hint style="danger" %}
|
||
|
Vir 'n beter verduideliking van die proses [**kyk na die oorspronklike pos vanaf hier**](https://maxwelldulin.com/BlogPost?post=5445977088).
|
||
|
{% endhint %}
|
||
|
|
||
|
### Algoritme-oorsig
|
||
|
|
||
|
Die formule wat gebruik word vir die verminking en ontverminking van aanwysers is: 
|
||
|
|
||
|
**`Nuwe_Aanwyser = (L >> 12) XOR P`**
|
||
|
|
||
|
Waar **L** die stoorplek is en **P** die Fd-aanwyser is. Wanneer **L** regs verskuif word met 12 bietjies, kry jy effektief die boonste 12 bietjies van **P** omdat die verskuifde gedeelte van **L** nul sal wees, wat **P** se ooreenstemmende bietjies onveranderd laat.
|
||
|
|
||
|
**Belangrike Stappe in die Algoritme:**
|
||
|
|
||
|
1. **Aanvanklike Lek van die Mees Betekenisvolle Bietjies**: Deur die verskuifde **L** met **P** te XOR, kry jy effektief die boonste 12 bietjies van **P** omdat die verskuifde gedeelte van **L** nul sal wees, wat **P** se ooreenstemmende bietjies onveranderd laat.
|
||
|
2. **Herwinning van Aanwyserbietjies**: Aangesien XOR omkeerbaar is, laat die kennis van die resultaat en een van die operandes jou toe om die ander operand te bereken. Hierdie eienskap word gebruik om die hele stel bietjies vir **P** af te lei deur bekende stelle bietjies suksesvol met dele van die verminkte aanwyser te XOR.
|
||
|
3. **Iteratiewe Ontverminking**: Die proses word herhaal, elke keer met die nuut ontdekte bietjies van **P** van die vorige stap om die volgende segment van die verminkte aanwyser te ontsluit, totdat alle bietjies herwin is.
|
||
|
4. **Hantering van Bepaalde Bietjies**: Die finale 12 bietjies van **L** gaan verlore weens die verskuif, maar hulle is bepaal en kan na die proses herkonstrueer word.
|
||
|
|
||
|
Jy kan 'n implementering van hierdie algoritme hier vind: [https://github.com/mdulin2/mangle](https://github.com/mdulin2/mangle)
|
||
|
## Pointer Wagtwoord
|
||
|
|
||
|
Pointer wagtwoord is 'n uitbuitingstegniek wat gebruik word in glibc om gestoorde funksie-aanwysers te beskerm, veral dié wat geregistreer is deur biblioteekoproepe soos `atexit()`. Hierdie beskerming behels die deurmekaarklits van die aanwysers deur hulle met 'n geheim wat gestoor word in die draaddata (`fs:0x30`) te XOR en 'n bitwyses rotasie toe te pas. Hierdie meganisme is daarop gemik om aanvallers te verhoed om beheervloei te kap nie deur funksie-aanwysers te oorskryf nie.
|
||
|
|
||
|
### **Bypassing Pointer Wagtwoord met 'n lek**
|
||
|
|
||
|
1. **Begrip van Pointer Wagtwoord Operasies:** Die deurmekaarklits (mangling) van aanwysers word gedoen met behulp van die `PTR_MANGLE` makro wat die aanwyser met 'n 64-bis geheim XOR en dan 'n linkse rotasie van 0x11-bits uitvoer. Die omgekeerde operasie om die oorspronklike aanwyser te herwin, word hanteer deur `PTR_DEMANGLE`.
|
||
|
2. **Aanvalstrategie:** Die aanval is gebaseer op 'n bekende-teksbenadering, waar die aanvaller beide die oorspronklike en die deurmekaargemaakte weergawes van 'n aanwyser moet ken om die geheim wat gebruik word vir deurmekaarklitting af te lei.
|
||
|
3. **Uitbuiting van Bekende Teks:**
|
||
|
* **Identifisering van Vaste Funksie-Aanwysers:** Deur glibc-bronkode te ondersoek of geïnisialiseerde funksie-aanwyser-tabelle (soos `__libc_pthread_functions`) te ondersoek, kan 'n aanvaller voorspelbare funksie-aanwysers vind.
|
||
|
* **Berekening van die Geheim:** Deur 'n bekende funksie-aanwyser soos `__pthread_attr_destroy` te gebruik en sy deurmekaargemaakte weergawe van die funksie-aanwyser-tabel, kan die geheim bereken word deur die deurmekaargemaakte aanwyser omgekeerd te roteer (regs rotasie) en dit dan met die adres van die funksie te XOR.
|
||
|
4. **Alternatiewe Teks:** Die aanvaller kan ook eksperimenteer met die deurmekaarklitting van aanwysers met bekende waardes soos 0 of -1 om te sien of hierdie identifiseerbare patrone in geheue produseer, wat moontlik die geheim kan onthul wanneer hierdie patrone in geheue-afleidings gevind word.
|
||
|
5. **Praktiese Toepassing:** Na die berekening van die geheim kan 'n aanvaller aanwysers op 'n beheerde wyse manipuleer, wat in wese die Pointer Wagtwoordbeskerming in 'n multidraadtoepassing kan omseil met kennis van die libc-basisadres en die vermoë om willekeurige geheue-plekke te lees.
|
||
|
|
||
|
## Verwysings
|
||
|
|
||
|
* [https://maxwelldulin.com/BlogPost?post=5445977088](https://maxwelldulin.com/BlogPost?post=5445977088)
|
||
|
* [https://blog.infosectcbr.com.au/2020/04/bypassing-pointer-guard-in-linuxs-glibc.html?m=1](https://blog.infosectcbr.com.au/2020/04/bypassing-pointer-guard-in-linuxs-glibc.html?m=1)
|