hacktricks/binary-exploitation/heap/unlink-attack.md

Unlink Saldırısı

AWS hacklemeyi sıfırdan kahraman seviyesine öğrenin htARTE (HackTricks AWS Kırmızı Takım Uzmanı) ile!

HackTricks'ı desteklemenin diğer yolları:

• Şirketinizi HackTricks'te reklamını görmek istiyorsanız veya HackTricks'i PDF olarak indirmek istiyorsanız [ABONELİK PLANLARI]'na(https://github.com/sponsors/carlospolop) göz atın!
• Resmi PEASS & HackTricks ürünlerini edinin
• The PEASS Ailesi'ni keşfedin, özel NFT'lerimiz koleksiyonumuzu
• Katılın 💬 Discord grubuna veya telegram grubuna veya bizi Twitter 🐦 @hacktricks_live** takip edin.**
• Hacking püf noktalarınızı paylaşarak PR'lar göndererek HackTricks ve HackTricks Cloud github depolarına katkıda bulunun.

Temel Bilgiler

Bu saldırı keşfedildiğinde genellikle bir WWW (Write What Where) izin veriyordu, ancak bazı kontroller eklenmiş ve saldırının yeni sürümü daha ilginç, daha karmaşık ve anlamsız hale getirilmiştir.

Kod Örneği:

Kod

```c #include #include #include #include

// Altered from d778318b6a/assets/files/unlink_exploit.c to make it work

struct chunk_structure { size_t prev_size; size_t size; struct chunk_structure *fd; struct chunk_structure *bk; char buf[10]; // padding };

int main() { unsigned long long *chunk1, *chunk2; struct chunk_structure *fake_chunk, *chunk2_hdr; char data[20];

// First grab two chunks (non fast) chunk1 = malloc(0x8000); chunk2 = malloc(0x8000); printf("Stack pointer to chunk1: %p\n", &chunk1); printf("Chunk1: %p\n", chunk1); printf("Chunk2: %p\n", chunk2);

// Assuming attacker has control over chunk1's contents // Overflow the heap, override chunk2's header

// First forge a fake chunk starting at chunk1 // Need to setup fd and bk pointers to pass the unlink security check fake_chunk = (struct chunk_structure *)chunk1; fake_chunk->size = 0x8000; fake_chunk->fd = (struct chunk_structure *)(&chunk1 - 3); // Ensures P->fd->bk == P fake_chunk->bk = (struct chunk_structure *)(&chunk1 - 2); // Ensures P->bk->fd == P

// Next modify the header of chunk2 to pass all security checks chunk2_hdr = (struct chunk_structure *)(chunk2 - 2); chunk2_hdr->prev_size = 0x8000; // chunk1's data region size chunk2_hdr->size &= ~1; // Unsetting prev_in_use bit

// Now, when chunk2 is freed, attacker's fake chunk is 'unlinked' // This results in chunk1 pointer pointing to chunk1 - 3 // i.e. chunk1[3] now contains chunk1 itself. // We then make chunk1 point to some victim's data free(chunk2); printf("Chunk1: %p\n", chunk1); printf("Chunk1[3]: %x\n", chunk1[3]);

chunk1[3] = (unsigned long long)data;

strcpy(data, "Victim's data");

// Overwrite victim's data using chunk1 chunk1[0] = 0x002164656b636168LL;

printf("%s\n", data);

return 0; }

</details>

* Saldırı, tcaches kullanılıyorsa çalışmaz (2.26 sonrası)

### Amaç

Bu saldırı, **bir parçanın işaretçisini kendisinden 3 adres öncesine işaret etmek** için izin verir. Eğer bu yeni konum (işaretçinin bulunduğu yerin çevresi) ilginç şeyler içeriyorsa, diğer kontrol edilebilir tahsisler / yığın gibi..., bunları okuyup/üzerine yazarak daha büyük zarara neden olmak mümkündür.

* Eğer bu işaretçi yığında bulunuyorsa, çünkü şimdi kendisinden 3 adres önce işaret ediyor ve kullanıcı potansiyel olarak bunu okuyup değiştirebiliyorsa, yığından hassas bilgiler sızdırmak veya hatta geri dönüş adresini (belki) canary'ye dokunmadan değiştirmek mümkün olacaktır.
* CTF örneklerinde, bu işaretçi diğer tahsislere işaret eden bir işaretçi dizisinde bulunmaktadır, bu nedenle 3 adres önce işaret etmesi ve okuyup yazabilmesi sayesinde diğer işaretçileri başka adreslere işaret etmesi mümkün olacaktır. Potansiyel olarak kullanıcı diğer tahsisleri de okuyup/yazabildiği için bilgi sızdırabilir veya rastgele konumlarda yeni adresler üzerine yazabilir (örneğin GOT'ta).

### Gereksinimler

* Bir bellekte (örneğin yığın) bazı kontrol sahibi olmak, bazı özniteliklere değerler vererek birkaç parça oluşturmak için.
* Sahte parçanın işaretçilerini ayarlamak için yığın sızıntısı.

### Saldırı

* Birkaç parça bulunmaktadır (parça1 ve parça2)
* Saldırgan parça1'in içeriğini ve parça2'nin başlıklarını kontrol eder.
* Parça1'de saldırgan sahte bir parça yapısını oluşturur:
* Korumaları atlatmak için `boyut` alanının doğru olduğundan emin olur, böylece `corrupted size vs. prev_size while consolidating` hatası oluşmaz
* ve sahte parçanın `fd` ve `bk` alanları, sahte parçanın depolandığı yerin -3 ve -2 ofsetlerinde işaret eder, böylece `fake_chunk->fd->bk` ve `fake_chunk->bk->fd` gerçek parça1 adresinin bulunduğu bellek (yığın) konumuna işaret eder:

<figure><img src="../../.gitbook/assets/image (1245).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>

* Parça2'nin başlıkları değiştirilir ve önceki parçanın kullanılmadığını ve sahte parçanın içerdiği boyutun boyutunu gösterir.
* İkinci parça serbest bırakıldığında, bu sahte parça bağlantısı kesilir:
* `fake_chunk->fd->bk` = `fake_chunk->bk`
* `fake_chunk->bk->fd` = `fake_chunk->fd`
* Daha önce `fake_chunk->fd->bk` ve `fake_chunk->fd->bk`'nin aynı yere işaret ettiği sağlandı (parça1'in depolandığı yığın konumu, bu nedenle geçerli bir bağlı liste idi). Çünkü **her ikisi de aynı yere işaret ediyor**, sadece sonuncu olan (`fake_chunk->bk->fd = fake_chunk->fd`) **etkili** olacaktır.
* Bu, yığında parça1 işaretçisini yığında kendisinden 3 adres önce depolanan adrese (veya baytlara) **üzerine yazacaktır**.
* Dolayısıyla, bir saldırgan parça1'in içeriğini kontrol edebilirse, yığının içine **yazabilecektir**, potansiyel olarak canary'yi atlayarak geri dönüş adresini değiştirebilir ve yerel değişkenlerin değerlerini ve işaretçilerini değiştirebilir. Hatta tekrar parça1'in yığında depolanan adresini farklı bir konuma değiştirerek, eğer saldırgan tekrar parça1'in içeriğini kontrol edebilirse herhangi bir yere yazabilir.
* Bu, **adreslerin yığında depolandığı için** mümkün oldu. Risk ve sömürü, sahte parça adreslerinin **nerede depolandığına bağlı olabilir**.

<figure><img src="../../.gitbook/assets/image (1246).png" alt=""><figcaption><p><a href="https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit">https://heap-exploitation.dhavalkapil.com/attacks/unlink_exploit</a></p></figcaption></figure>

## Referanslar

* [https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit](https://heap-exploitation.dhavalkapil.com/attacks/unlink\_exploit)
* Bir CTF'de bile unlink saldırısı bulmak garip olabilir ancak bu saldırının kullanıldığı bazı yazılara buradan ulaşabilirsiniz:
* CTF örneği: [https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html](https://guyinatuxedo.github.io/30-unlink/hitcon14\_stkof/index.html)
* Bu örnekte, yığın yerine malloc edilmiş adreslerin bir dizisi bulunmaktadır. Unlink saldırısı, buraya bir parça tahsis edebilmek için gerçekleştirilir, bu nedenle malloc edilmiş adreslerin dizisinin işaretçilerini kontrol etmek mümkün olur. Ardından, bu adreslerdeki parçaların içeriğini değiştirmeyi sağlayan başka bir işlevsellik vardır, bu da adresleri GOT'a işaret etmeye, işlev adreslerini değiştirmeye ve sızıntılar ve RCE elde etmeye olanak tanır.
* Başka bir CTF örneği: [https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html](https://guyinatuxedo.github.io/30-unlink/zctf16\_note2/index.html)
* Önceki örnekte olduğu gibi, tahsis edilen adreslerin bir dizisi bulunmaktadır. Bir unlink saldırısı gerçekleştirerek, ilk tahsis edilen adresin dizinin başlangıcından birkaç konum öncesine işaret etmesi sağlanabilir ve ardından bu tahsis edilen adres yeni konumda üzerine yazılabilir. Bu nedenle, diğer tahsislerin işaretçileri GOT'a işaret etmesi, bir libc sızıntısı almak için yazdırılması ve ardından atoi GOT'unu bir gadget adresine değiştirmek mümkün olacaktır.