Cakepie Sözleşmeleri için Güvenlik Denetim Raporu

Rapor Manifestosu

Sürüm Geçmişi

1. Giriş

1.1 Hedef Sözleşmeler Hakkında

Bu denetimin hedefi, Magpie XYZ'nin CakePie Sözleşmeleri^1 kod deposudur. CakePie Sözleşmeleri, kullanıcıların CAKE tokenlarını veya PancakeSwap'teki kilitli CAKE pozisyonlarını CakePie üzerinde dönüştürebildiği bir CakeRush kampanyası yürütmektedir. Yalnızca CakeRush.sol ve PancakeStakingBNBChain.sol'un denetim kapsamına dahil olduğunu, diğer dosyaların bu denetimin kapsam dışında olduğunu lütfen unutmayın.

Denetim süreci yinelemeli bir yapıdadır. Özellikle, keşfedilen sorunları gideren commit'leri denetleyeceğiz. Yeni sorunlar ortaya çıkarsa bu süreci sürdüreceğiz. Denetim sırasındaki commit SHA değerleri aşağıdaki tabloda gösterilmektedir. Denetim raporumuz, başlangıç sürümündeki (Sürüm1) koddan ve denetim raporundaki sorunları gidermek için yapılan yeni koddan (sonraki sürümlerde) sorumludur.

1.2 Güvenlik Modeli

Riski değerlendirmek için, OWASP Risk Derecelendirme Metodolojisi^2 ve Yaygın Zayıflık Sayımı^3 dahil olmak üzere hem sektör hem de akademi tarafından yaygın biçimde benimsenen standart veya önerileri takip ediyoruz. Riskin genel şiddeti, olasılık ve etki ile belirlenmektedir. Özellikle, olasılık; belirli bir güvenlik açığının bir saldırgan tarafından ne ölçüde keşfedilip istismar edilebileceğini tahmin etmek için kullanılırken, etki; başarılı bir istismarın sonuçlarını ölçmek için kullanılmaktadır.

Bu raporda, hem olasılık hem de etki iki derecelendirmeye ayrılmıştır; yani sırasıyla yüksek ve düşük olarak, ve bunların kombinasyonları Tablo 1.1'de gösterilmektedir.

Buna göre, bu raporda ölçülen şiddet üç kategoriye ayrılmıştır: Yüksek, Orta, Düşük. Bütünlük açısından, riskin yeterince belirlenemediği durumlara ilişkin Belirsiz kategorisi de kullanılmaktadır.

Ayrıca, keşfedilen bir öğenin durumu aşağıdaki dört kategoriden birine girmektedir:

• Belirsiz Henüz yanıt alınmadı.

• Onaylandı Öğe müşteri tarafından alınmış, ancak henüz teyit edilmemiştir.

• Teyit Edildi Öğe müşteri tarafından kabul edilmiş, ancak henüz düzeltilmemiştir.

• Düzeltildi Öğe müşteri tarafından teyit edilmiş ve düzeltilmiştir.

2. Bulgular

Toplamda iki potansiyel sorun tespit ettik. Bunun yanı sıra üç öneri ve bir not da bulunmaktadır.

• Yüksek Risk: 1

• Düşük Risk: 1

• Öneri: 3

• Not: 1

Ayrıntılar aşağıdaki bölümlerde verilmektedir.

2.1 Yazılım Güvenliği

2.1.1 Parametre sıfırlamasından sonra potansiyel tutarsız durum

Açıklama CakeRush sözleşmesi, ödülleri çeşitli parametrelere göre dağıtmaktadır. Aşağıdaki fonksiyonlar, proje yöneticisinin bazı parametreleri sıfırlamasına olanak tanır:

function resetMultiplier() external onlyOwner {
        uint256 len = rewardMultiplier.length;
        for (uint8 i = 0; i < len; ++i) {
            rewardMultiplier.pop();
            rewardTier.pop();
        }

        tierLength = 0;
    }

    function resetTimeWeighting() external onlyOwner {
        uint256 len = weightedTime.length;
        for (uint8 i = 0; i < len; ++i) {
            weightedTime.pop();
            weighting.pop();
        }

        weightLength = 0;
    }

Liste 2.1: CakeRush.sol

Ancak bu fonksiyonlar yalnızca parametreleri sıfırlar; userInfos durum değişkeninde saklanan kullanıcı bilgilerini sıfırlamaz. Sonuç olarak, CakeRush sözleşmesindeki hesaplamalar tutarsız durum nedeniyle başarısız olabilir. Örneğin, parametreler sıfırlanıp yanlış değerlere ayarlanırsa, 155. satırdaki çıkarma işlemi tam sayı taşması nedeniyle başarısız olabilir.

function quoteConvert(
        uint256 _amountToConvert,
        address _account
    )
        external
        view
        returns (
            uint256 newUserFactor,
            uint256 newTotalFactor,
            uint256 newUserWeightedFactor,
            uint256 newWeightedTotalFactor
        )
    {
        if (_amountToConvert == 0 || rewardMultiplier.length == 0 || weighting.length == 0)
            return (0, 0, 0, 0);

        UserInfo storage userInfo = userInfos[_account];
        uint256 accumulated = _amountToConvert + userInfo.converted;

        uint256 factorAccuNoWeighting = 0;
        uint256 i = 1;
        while (i < rewardTier.length && accumulated > rewardTier[i]) {
            factorAccuNoWeighting += (rewardTier[i] - rewardTier[i - 1]) * rewardMultiplier[i - 1];
            i++;
        }
        factorAccuNoWeighting += (accumulated - rewardTier[i - 1]) * rewardMultiplier[i - 1];

        uint256 factorToEarnNoWeighting = (factorAccuNoWeighting / DENOMINATOR) - userInfo.factor;

Liste 2.2: CakeRush.sol

Daha da kötüsü, parametreler sıfırlandıktan hemen sonra (yeni parametreler ayarlanmadan önce, örneğin arka plan çalıştırma yoluyla) kullanıcıların convert veya convertWithCakePool fonksiyonunu çağırması; 141-142. satırlardaki mantık nedeniyle sözleşme içinde kaydedilen toplam ve ağırlıklı faktörlerin sıfırlanmasına yol açabilir.

Etki Parametrelerin sıfırlanması, tutarsız ve hatalı duruma yol açabilir.

Öneri Eski parametreleri temizledikten sonra yeni parametreleri ayarlayın.

Projeden Geri Bildirim Cake rush kampanyası başladıktan sonra çarpanlar sıfırlanmayacaktır.

2.1.2 mCake ödüllerinin tekrarlanan talepleri

Açıklama Sözleşmede CAKE tokenlarını kilitledikten sonra, kullanıcılar fonksiyon aracılığıyla ödül olarak mCake tokenları talep edebilir. Ancak fonksiyon, kullanıcıların ödülleri birden fazla kez talep etmesine olanak tanıyan bir sorun içermektedir. Aşağıdaki kod segmentinde, miktar kullanıcının miktarından büyükse, kullanıcıya toplam tutarda transfer veya depozit yapılacaktır. Doğru uygulama yalnızca geri dönmelidir; bu nedenle mevcut uygulama, bir kullanıcının mCake ödüllerini tekrar tekrar talep etmesine etkin biçimde olanak tanımaktadır.

function claim(bool _isStake) external nonReentrant {
        UserInfo storage userInfo = userInfos[msg.sender];
        if (claimedMCake[msg.sender] >= userInfo.converted) revert AlreadyClaimed();
        if (_isStake && userInfo.converted > 0) {
            if (masterCakepie == address(0)) revert MasterCakepieNotSet();
            IERC20(mCakeOFT).safeApprove(address(masterCakepie), userInfo.converted);
            IMasterCakepie(masterCakepie).depositFor(
                address(mCakeOFT),
                address(msg.sender),
                userInfo.converted
            );
        } else if (userInfo.converted > 0) {
            IERC20(mCakeOFT).transfer(msg.sender, userInfo.converted);
            emit Claim(msg.sender, userInfo.converted);
        }

        claimedMCake[msg.sender] = userInfo.converted;
    }

Liste 2.3: CakeRush.sol

Etki Kullanıcılar mCake ödüllerini tekrar tekrar talep edebilmektedir.

Öneri Ödül talep mantığını gözden geçirin.

2.2 Ek Öneri

2.2.1 Başlatma fonksiyonlarındaki parametrelerin kontrol edilmesi

Açıklama CakeRush ve PancakeStakingBNBChain sözleşmelerinin başlatma fonksiyonlarında, başlatmanın ardından değiştirilemeyen parametreler bulunmaktadır. Bu parametrelerin başlatma fonksiyonlarında kontrol edilmesi önerilmektedir.

function __CakeRush_init(
        address _cake,
        address _mCakeOFT,
        address _masterCakepie
    ) public initializer {
        __Ownable_init();
        __ReentrancyGuard_init();
        __Pausable_init();
        cake = _cake;
        mCakeOFT = _mCakeOFT;
        masterCakepie = _masterCakepie;
    }

Liste 2.4: CakeRush.sol

Etki Yok

Öneri Başlatma fonksiyonlarındaki parametreleri kontrol edin.

2.2.2 CakeRush sözleşmelerindeki parametrelerin kontrol edilmesi

Açıklama CakeRush sözleşmesinde, ödül dağıtımına ilişkin çeşitli parametreler eklenebilmektedir. Ancak bu parametrelerin sözleşmedeki varsayımlara göre doğru şekilde ayarlandığına dair herhangi bir kontrol bulunmamaktadır. Özellikle, setMultipler ve setTimeWeighting fonksiyonlarında ekstra koşulların kontrol edilmesi gerekmektedir (yani rewardTier ve weightedTime dizisinin monoton artan özelliği).

function setMultiplier(
        uint256[] calldata _multiplier,
        uint256[] calldata _tier
    ) external onlyOwner {
        if (_multiplier.length == 0 || (_multiplier.length != _tier.length)) revert LengthInvalid();

        for (uint8 i = 0; i < _multiplier.length; ++i) {
            if (_multiplier[i] == 0) revert InvalidAmount();
            rewardMultiplier.push(_multiplier[i]);
            rewardTier.push(_tier[i]);
            tierLength += 1;
        }
    }

Liste 2.5: CakeRush.sol

Etki Yok

Öneri Parametreleri ayarlayan fonksiyonlardaki parametreleri kontrol edin.

2.2.3 Değiştiricilerdeki ekstra koşullar

Açıklama CakeRush sözleşmesinde, _onlyPancakeStaking değiştiricisi gereksiz bir koşul içermektedir. Bu değiştiricinin anlamına göre, msg.sender != pancakeStaking kontrolü yeterli olacaktır.

modifier _onlyPancakeStaking() {
        if (pancakeStaking == address(0) || msg.sender != pancakeStaking)
            revert OnlyPancakeStaking();
        _;
    }

Liste 2.6: CakeRush.sol

Etki Yok

Öneri Değiştiricide gereksiz koşulları kaldırın.

2.3 Not

2.3.1 Potansiyel merkezileşme riski

Açıklama CakeRush'ın sahibi, kritik yapılandırmaları değiştirmek için önemli ayrıcalıklara sahiptir. Bu durum, tek bir başarısızlık noktası oluşturmaktadır. Bir saldırgan sahibi ele geçirirse, tüm sistemi işlevsiz hale getirebilir.

Ayrıca, sözleşmedeki CAKE tokenları açıkça VECake sözleşmesine kilitlenmez. Bunun yerine, CakeRush sahibinin tüm bu CAKE'leri çekmesine olanak tanır; bu da sahibin çektikten sonra CAKE tokenlarını kilitlemesi gerektiği anlamına gelir. Ancak bu mantık kod düzeyinde güvence altına alınmamıştır, bu da merkezileşme endişelerini beraberinde getirir.

Projeden Geri Bildirim Ekip, riski azaltmak için sahibi çok imzalı (multisig) bir yapı olarak belirlemektedir.

3. Uyarılar ve Açıklamalar

3.1 Sorumluluk Reddi

Bu denetim raporu, yatırım tavsiyesi veya kişisel öneri niteliği taşımamaktadır. Bir tokenın, token satışının veya herhangi bir ürün, hizmet ya da diğer varlıkların potansiyel ekonomisini dikkate almaz ve bu şekilde yorumlanamaz. Hiçbir kuruluş, herhangi bir token, ürün, hizmet veya diğer varlıkları alıp satma kararı vermek de dahil olmak üzere hiçbir şekilde bu rapora güvenmemelidir.

Bu denetim raporu, belirli bir projeyi veya ekibi onaylamaz ve rapor herhangi bir projenin güvenliğini garanti etmez. Bu denetim, akıllı sözleşmelerin tüm güvenlik sorunlarının keşfedileceğine dair herhangi bir garanti vermez; yani değerlendirme sonucu, başka güvenlik sorunlarının olmadığını garanti etmez. Tek bir denetim kapsamlı kabul edilemeyeceğinden, akıllı sözleşmelerin güvenliğini sağlamak amacıyla bağımsız denetimler ve kamuya açık bir hata ödül programıyla devam edilmesini her zaman öneririz.

Bu denetimin kapsamı, Bölüm 1.1'de belirtilen kodla sınırlıdır. Açıkça belirtilmedikçe, dilin kendisinin güvenliği (örneğin Solidity dili), temel derleme araç zinciri ve bilgi işlem altyapısı kapsam dışındadır.

3.2 Denetim Prosedürü

Denetimi aşağıdaki prosedüre göre gerçekleştiriyoruz.

• Güvenlik Açığı Tespiti Önce akıllı sözleşmeleri otomatik kod analizörleriyle tarıyor, ardından bunların raporladığı sorunları manuel olarak doğruluyoruz (reddediyor veya onaylıyoruz).

• Anlamsal Analiz Akıllı sözleşmelerin iş mantığını inceliyor ve otomatik bir bulanıklaştırma aracı (araştırma ekibimiz tarafından geliştirilmiştir) kullanarak olası güvenlik açıkları üzerinde daha ileri araştırmalar yürütüyoruz. Sonuçları çapraz kontrol etmek için bağımsız denetçilerle olası saldırı senaryolarını da manuel olarak analiz ediyoruz.

• Öneri Geliştiricilere gaz optimizasyonu, kod stili vb. dahil olmak üzere iyi programlama pratiği perspektifinden bazı yararlı tavsiyeler sunuyoruz.

Aşağıda temel somut kontrol noktalarını gösteriyoruz.

3.2.1 Yazılım Güvenliği

• Yeniden giriş (Reentrancy)

• Hizmet Reddi (DoS)

• Erişim kontrolü

• Veri işleme ve veri akışı

• İstisna yönetimi

• Güvenilmez harici çağrı ve kontrol akışı

• Başlatma tutarlılığı

• Olay işlemleri

• Hataya açık rastgelelik

• Vekil sisteminin hatalı kullanımı

3.2.2 DeFi Güvenliği

• Anlamsal tutarlılık

• İşlevsellik tutarlılığı

• İzin yönetimi

• İş mantığı

• Token işlemi

• Acil durum mekanizması

• Oracle güvenliği

• Beyaz liste ve kara liste

• Ekonomik etki

• Toplu transfer

3.2.3 NFT Güvenliği

• Yinelenen öğe

• Token alıcısının doğrulanması

• Zincir dışı meta veri güvenliği

3.2.4 Ek Öneri

• Gaz optimizasyonu

• Kod kalitesi ve stili

Not Önceki kontrol noktaları temel olanlardır. Denetim sürecinde projenin işlevselliğine göre daha fazla kontrol noktası kullanabiliriz.