#10: ThirdWeb Olayı: Güvenilir Modüller Arasındaki Uyumsuzluk Güvenlik Açığını Ortaya Çıkardı

5 Aralık 2023'te, önde gelen Web3 geliştirme platformu Thirdweb, önceden oluşturulmuş sözleşmelerini etkileyen önemli akıllı sözleşme güvenlik açıklarını ifşa etti. Bu kritik kusur, söz konusu savunmasız sözleşmeler kullanılarak dağıtılan tüm ERC-20, ERC-721 ve ERC-1155 token'larını etkiledi. İfşaatın ardından geçen günlerde, savunmasız sözleşmelerle dağıtılan token'lar bir dizi saldırıda aşamalı olarak istismar edildi; bu durum, temel uyumsuzluğun ciddiyetini gözler önüne serdi.

ThirdWeb Akıllı Sözleşme Güvenlik Açığını Anlamak

ThirdWeb olayının temel nedeni, akıllı sözleşme geliştirmenin iki temel bileşeni arasındaki beklenmedik etkileşimde yatmaktadır: ERC-2771 ve OpenZeppelin'in Multicall uygulaması. Güvenlik açığını tam olarak kavramak için her bir bileşeni ayrı ayrı ve ardından etkileşimlerinin nasıl istismar edilebilir bir yol oluşturduğunu anlamak gerekmektedir.

ERC-2771: Meta-İşlemler ve Güvenilir Yönlendiriciler

EIP-2771, Alıcı sözleşmelerin güvenilir Yönlendirici sözleşmeleri aracılığıyla meta-işlemleri kabul etmesini sağlayan sözleşme düzeyinde bir protokol tanımlar. Bu standart, üçüncü tarafların (yönlendiriciler) kullanıcılar adına gaz ücretlerini ödemesine izin vererek kullanıcıların yerel blokzincir token'larına sahip olma zorunluluğunu ortadan kaldırmak ve böylece kullanıcı deneyimini iyileştirmek açısından kritik öneme sahiptir.

Pratikte, OpenZeppelin'in ERC2771Context'i yaygın olarak benimsenen bir uygulamadır. Temel işlevi, güvenilir bir yönlendiriciden gelen calldata'nın son 20 baytını etkin _msgSender() olarak değerlendirmektir. Bu kütüphaneyi kullanan geliştiriciler için yaygın uygulama, meta-işlemlerle uyumluluğu sağlamak amacıyla msg.sender'ın tüm doğrudan kullanımlarını _msgSender() ile değiştirmektir. Benzer şekilde, _msgData() eklenen gönderici bilgisini hariç tutarak orijinal işlem verilerini almak için kullanılır.

function _msgSender() internal view virtual override returns (address) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return address(bytes20(msg.data[calldataLength - contextSuffixLength:]));
    } else {
        return super._msgSender();
    }
}

function _msgData() internal view virtual override returns (bytes calldata) {
    uint256 calldataLength = msg.data.length;
    uint256 contextSuffixLength = _contextSuffixLength();
    if (isTrustedForwarder(msg.sender) && calldataLength >= contextSuffixLength) {
        return msg.data[:calldataLength - contextSuffixLength];
    } else {
        return super._msgData();
    }
}

Multicall: Verimlilik İçin İşlemleri Toplu Hâle Getirme

Multicall işlevi, kullanıcıların birden fazla fonksiyon çağrısını tek bir işlemde bir araya getirmesine olanak tanır; bu sayede gaz maliyetleri önemli ölçüde azalır ve işlem verimliliği artar. OpenZeppelin'in MulticallUpgradeable'ı bu amaçla kullanılan popüler bir uygulamadır. Bir calldata bayt dizisi alır ve her giriş için çağıran sözleşmenin bağlamında yürütülen bir delegatecall gerçekleştirir.

function multicall(bytes[] calldata data) external virtual returns (bytes[] memory results) {
    results = new bytes[](data.length);
    for (uint256 i = 0; i < data.length; i++) {
        results[i] = _functionDelegateCall(address(this), data[i]);
    }
    return results;
}

(Not: Burada ele alınan hata, OpenZeppelin'in Multicall'ının sonraki sürümlerinde düzeltilmiştir.)

Uyumsuzluk: ERC-2771 ve Multicall Çakışması

ThirdWeb olayındaki akıllı sözleşme güvenlik açığının özü, calldata'nın ERC-2771 ve Multicall tarafından işlenme biçimindeki kritik tutarsızlıktan kaynaklanmaktadır. ERC-2771, güvenilir yönlendiricinin mesaj verilerini ve gönderici bilgisini bir arada paketlemesini bekler. Alıcı sözleşme daha sonra bu bilgileri doğru şekilde açmak için _msgData() ve _msgSender() kullanır.

Ancak Multicall fonksiyonu, savunmasız uygulamasında ERC-2771'in meta-işlemler için verileri paketleme biçimiyle uyumlu olacak şekilde tasarlanmamıştı. Özellikle Multicall bir çağrı grubunu işlerken, ilk meta-işlemden _msgSender()'ı doğru şekilde çıkarması ve ardından her bir çağrıyı yürütmeden önce bu gönderici bilgisini her bir çağrının calldata'sına eklemesi gerekirdi. Bu kritik adım eksikti.

Gönderici bilgisinin Multicall tarafından işlenen her alt çağrı içindeki calldata'ya doğru şekilde eklenmemesi nedeniyle, hedef sözleşmedeki ERC-2771 bağlamı, gönderici bilgisini alt çağrının _msgData()'sının son 20 baytından çıkarmaya çalışacaktı. Kritik olan husus, bir saldırganın bu son 20 baytı kontrol edebilmesiydi. Bu durum, kötü niyetli bir kişinin Multicall tarafından işlendiğinde ve ardından ERC-2771 etkin bir sözleşme tarafından yorumlandığında, manipüle edilmiş bir _msgSender() değeriyle (örneğin, saldırgan tarafından kontrol edilen bir adres veya hatta bir protokolün kendi havuz adresi) keyfi mantığı yürütecek belirli calldata'lar oluşturmasına imkân tanıdı. Bu durum, amaçlanan güvenlik kontrollerini etkin biçimde atlattı, her iki spesifikasyonun beklentilerini ihlal etti ve yetkisiz işlemlere yol açtı.

ThirdWeb Olayı: Saldırı Analizi ve İstismar

BlockSec'in Phalcon platformu tarafından analiz edilen bir saldırı işlemini kullanarak ThirdWeb olayındaki akıllı sözleşme güvenlik açığı istismarının gerçek dünyadan bir örneğini inceleyelim.

Saldırganın stratejisi, bir Uniswap havuzunun kimliğine bürünmek ve token bakiyesini tüketmek için _msgSender()'ı manipüle etmeyi içeriyordu.

• Adım 1: İlk Token Edinimi. Saldırgan, merkezi olmayan bir borsada 5 WETH karşılığında 3.455.399.346 TIME token'ı takas ederek işe başladı. Bu, sonraki manipülasyon için gerekli token'ları sağladı.

• Adım 2: Kötü Amaçlı Multicall Yürütümü. Bu, istismarın özüdür. Saldırgan, ERC-2771/Multicall uyumsuzluğunu istismar etmek üzere tasarlanmış özenle hazırlanmış calldata ile güvenilir bir yönlendiriciyi çağırdı. Bu calldata Multicall fonksiyonu tarafından ayrıştırıldığında, TIME token sözleşmesinin burn fonksiyonunun çağrılmasıyla sonuçlandı. Kritik olarak, güvenlik açığı nedeniyle _msgSender() yanlışlıkla Uniswap Havuzu adresi olarak yorumlandı. Bu durum, saldırganın gerçek bir yetkilendirme olmaksızın Uniswap havuzu tarafından tutulan TIME token'larının önemli bir bölümünü etkin biçimde yakmasına olanak tanıdı. BlockSec Phalcon platformu, bu akışı görselleştirmek için ayrıntılı işlem izleme imkânı sunmaktadır.

  

  Yukarıdaki görsel, saldırganın Forwarder.execute çağrısının nasıl işlendiğini göstermektedir. multicall fonksiyonu bir bayt dizisi alır ve bu dizi, manipüle edilmiş _msgSender() ile burn fonksiyonunun çağrılmasına yol açar.

  

  Phalcon'dan alınan bu ayrıntılı görünüm, sözleşmeyi çağırmak için veri olarak uzunluğu 1 olan bytes[]'ın kullanıldığını ve bunun sahte _msgSender() altında burn fonksiyonunun yürütülmesine yol açtığını göstermektedir.

• Adım 3: Fiyat Manipülasyonu. Saldırgan, Uniswap havuzundan büyük miktarda TIME token'ı yakarak havuzun TIME likiditesini büyük ölçüde azalttı. Bu yapay kıtlık, havuz içinde TIME'ın WETH karşısındaki fiyatının fırlamasına neden oldu.

• Adım 4: Kârlı Arbitraj. TIME fiyatı yapay olarak şişirilmişken saldırgan, kalan 3.455.399.346 TIME token'ını 94 WETH karşılığında geri takas ederek manipüle edilmiş fiyattan kayda değer bir kâr elde etti.

Bu olaylar dizisi, modül uyumsuzluğundan kaynaklanan ince bir akıllı sözleşme güvenlik açığından yararlanan sofistike bir saldırıyı gözler önüne sermektedir.