Uygulama Güvenliği
Akıllı Sözleşme Güvenliği
Smart Contract ya da çevirisiyle akıllı sözleşmeler, Ethereum blok zinciri üzerinde program yazmaya olanak sağlayan uygulamalar olarak tanımlanabilir. Tamamen blok zinciri üzerinde çalışır ve bir kez yazıldıktan sonra düzenlenmesi, güncellenmesi ve silinmesi mümkün değildir. Akıllı sözleşmelerin kullanımları ise kriptolojiye dayanır.
12.12.2021
Akıllı sözleşmelerden bahsedebilmek için önce Ethereum’u ve daha da öncesinde blok zincirinin yapısından bahsetmeliyiz.
Blok zinciri ya da Blockchain, 2008 yılında Satoshi Nakomoto tarafından Bitcoin için kullanılması amacıyla geliştirilen bir veri yapısıdır. Herhangi bir merkezi sunucuya ihtiyaç duymaksızın herkese açık bir şekilde kullanılabilen bir nevi defter olarak düşünülebilir. Blok zinciri bloklardan oluşur ve oluşturulacak her yeni blok, bir önceki blok adresiyle şifrelendiğinden dolayı önceki blokların verileri daima korunur ve değiştirilemez. Bitcoin, Ethereum gibi kripto paralar blok zinciri altyapısını kullanır.
Bitcoin, yalnızca para transferi, transfer defteri olarak kullanıldığından biraz ilkel bir yapıya sahiptir. Ethereum ise yapılan geliştirmelerle bir transfer defteri olmaktan çıkıp akıllı sözleşmeler ile birlikte başlı başına bir programlanabilir makine durumuna ulaşmıştır. 2015 yılında Vitalik Buterin tarafından yayınlanan Ethereum, şu anda en çok kullanılan blok zinciri statüsüne ulaşmıştır.
Akıllı sözleşmeler ise Ethereum üzerinde programlanarak yazılmış, başkaları tarafından kullanılabilen programlar olarak tanımlanır. Akıllı sözleşmeler herkes tarafından yazılıp, imzalanabilir ve kullanılabilir olduğundan ve çoğunlukla parasal işlemler yapılırken suiistimale açık hale gelmiştir.
Akıllı Sözleşme Geliştirmek
Akıllı sözleşmeler Ethereum üzerinde Solidity adlı programlama diliyle geliştirilmektedir. Solidity ECMAScript sözdizimine(syntax) benzer bir şekilde geliştirilmiş olup güvenlik ve iyileştirme süreçleri dolayısıyla da sürekli güncellenmektedir. IDE olarak Solidity derleyicisinin de bulunduğu Remix kullanılmaktadır.
Örnek olarak Ethereum üzerinde basit bir bağış uygulaması yazmak istersek:
Yukarıdaki uygulamada sözleşmeyi oluşturan kişi, hayır kurumu olarak tanımlanıyor ve sonrasında alınan bağışlar direkt olarak hayır kurumu hesabına gönderiliyor ve bağış yapan kişi bağışlar listesine ekleniyor.
Demo olarak görmek istersek:
0x583… adresiyle solda görüldüğü üzere sözleşmeyi test ağında oluşturduk. Oluştururken gas adı verilen vergiyi ödedik. Bu gas vergisi yazılan programın büyüklüğüne göre değişebilmekle beraber ne kadar gas ödenirse işlem ağda o kadar hızlı gerçekleşmektedir.
Sözleşme oluştuktan sonra 0xdD8… adresiyle de 2 Ether miktarıyla bağış yaptık. Sağda görüldüğü üzere bağışçı hesabımızdan 2 Ether + vergi eksilmiş oldu ve 2 Ether bağışçı hesabımızdan hayır kurumu hesabına aktarılmış oldu.
Görüntünün aşağısına bakılacak olursa kullanılabilen fonksiyonları görebiliyoruz. “bagisVer” fonksiyonu ile bağışımızı yaptık, “bagislar” fonksiyonu ile bağışımızı kontrol ettik, “hayir_kurumu” fonksiyonu ile de hayır kurumunun adresini doğruladık.
Görüldüğü gibi bir akıllı sözleşme oluşturmak ve kullanmak çok basit ve bu basitliğin yanında kötü niyetli kişilerin de sözleşme oluşturabileceğini düşünerek dikkatli işlem yapılmalıdır.
Akıllı Sözleşme Güvenliği
Akıllı sözleşmeler bir program oldukları için sözleşmeyi oluşturan yazılımcının, istediği her fonksiyonun oluşturmasına olanak sağlıyor. Bazı sözleşmelerde tuzak denilen dolandırıcılık faaliyetleri de söz konusu olmaktadır. Ancak Ethereum akıllı sözleşmeleri herkese açık olduğundan kaynak kodunu görebilir, ona göre önlem alıp işlem yapabilirsiniz.
Aşağıda birkaç hata ve bu hatalara karşılık karşılaşılan güvenlik sorunlarından bahsedeceğim.
Tekrarlı Giriş
Akıllı sözleşmeler kişiler tarafından kullanılırken aynı şekilde diğer sözleşmeler tarafından da kullanılabilir. Bu durum belirli tekniklerle diğer sözleşmelere saldırmanın yolunu açmaktadır. Örnek olarak bir banka sözleşmesine para yatırılıp çekilebiliyor olsun. Daha önce 100TL attığım bir sözleşmeden yine 100TL çekebiliyorum.
Para çekme fonksiyonu yukarıdaki gibi olduğunda bakiyeyi sıfırlamadan önce para gönderilip kontrol ediliyor, sonrasında kişinin bakiyesi sıfırlanıyor. Burada paranın teslim aldığını kontrol etmesinde mantıken bir hata yok ancak suiistimale açık.
Eğer başka bir sözleşme bu sözleşmeye 100TL gönderip tekrar çekmek isterse ve sözleşme daha yanıt almadan tekrar çekme işlemi yaparsa 200TL ve daha üstünü çekebilir.
Yukarıda Saldirgan isimli sözleşme, bankaya 1 Ethereum yatırıyor, sonra çekmek istiyor. Banka saldırganın bakiyesine bakıyor(1ETH) ve bakiyesi kadarını gönderiyor. Saldırgan parayı aldığı anda tekrardan çekmek istiyor. Banka saldırganın bakiyesine bakıyor(1ETH) ve bakiyesi kadarını gönderiyor. Aldıktan sonra tekrardan bu işlemler saldırganın ödediği gas vergisi bitene veya bankanın bakiyesi bitene kadar sürüyor. En sonunda işlem bittiğinde banka saldırganın adres bakiyesini sıfırlıyor. Buradaki sorun bakiyeyi gönderdikten sonra sıfırlamak oluyor. Çözüm yöntemi ise bakiyeyi göndermeden önce sıfırlayıp sonraki isteklerde bakiye sıfır olacağı için işlem kabul etmemek. Aslında çok basit bir hata ancak piyasadaki sözleşmelerin %8 kadarı bu hatayı yapmaktadır.
Varsayılan Erişim - Görünürlük
Solidity programlama dilinde public, private, external ve internal olmak üzere 4 çeşit görünürlük, erişim türü mevcuttur.
- Public: Dışarıdan ve içeriden görülebilen ve çağırılabilen erişim türü.
- Private: Yalnızca asıl sözleşme tarafından erişilebilen erişim türü.
- External: Dışarıdan görülebilen ve erişilebilen ancak içeriden erişilemeyen erişim türü.
- Internal: Yalnızca içeriden veya kalıtım yoluyla oluşturulan sözleşmeler aracılığıyla görülebilen ve erişilebilen erişim türü.
Eğer yalnızca içeriden erişilmesi gereken bir fonksiyona dış erişim hakkı verilirse iş akışından kaynaklı çağırılan fonksiyonlar tarafında hataya ve suiistimale açık hale gelinebilir.
Bu nedenle bu tür sorunları yaşamamak adına erişim tipleri doğru kullanılmalıdır, ancak unutulmamalıdır ki private erişim türüne sahip olsa bile yazılan her kod herkes tarafından açıkça görünebilmektedir.
Hizmet Reddi – DOS Saldırıları
Günlük hayatta kullanılan programlama dillerinde de sıklıkça kullanılan döngüler Solidity içerisinde de mevcuttur. Örnek olarak 100 kullanıcı içerisinde spesifik bir kullanıcıyı aramak için kullanılan döngüler geleneksel programlama dillerinde zaman kaybı (muhtemelen milisaniyeler cinsinde) dışında pek bir sorun oluşturmaz. Ancak akıllı sözleşmelerde bu durum çok farklı. Akıllı sözleşmelerde kullanılan her bir işlem, sözleşmenin vergi ödemesine yol açmaktadır.
Az önceki örnekteki gibi akıllı sözleşmede 100 kullanıcı içerisinden bir kullanıcı aramak için döngü kullanırsak bu gereğinden fazla gas vergisi ödememize yol açacaktır. Kodlar da herkese açık olduğundan saldırganlar akıllı sözleşmeyi suiistimal edip, sürekli döngünün olduğu fonksiyonu çağırarak sözleşmenin üzerinde bulunan vergi bütçesini bitirince sözleşmenin sonraki istekleri yanıtlayamaz hale gelmesine olanak sağlayabilirler.
Çözüm önerisi olarak genellikle bir kullanıcıyı aramak gibi işlemler için döngüler yerine, fonksiyonda direkt olarak kullanıcının adresi alınarak döngülerden kaçınarak işlem yapılabilir.
Bal Tuzağı – Honeypot Sözleşmeler
Bazı saldırganlar tuzak sözleşmeler hazırlayarak yatırımcıları tuzağa düşürebiliyor. Bu tarz sözleşmeler ancak kodları okunarak anlaşılabiliyor. Eğer sözleşmeye aktarılan para herkes tarafından gönderilebiliyor ancak yalnızca sahibi veya belirli kişiler tarafından çekilebiliyorsa bu sözleşmelere bal tuzağı ya da orijinal adıyla honeypot sözleşmeler denir. Solidity kullanılarak herkes tarafından akıllı sözleşme oluşturulabildiğinden dolayı bu tarz tuzaklara dikkat etmekte fayda var.
Sözleşmelerde yapılan güvenlik hataları yalnızca bunlar değil ve sözleşmeler oluşturuldukça bu hatalar da artmaya devam edecektir. SWC (Akıllı Sözleşme Zayıflık Sınıflandırması) incelenerek bu hatalardan kaçınabiliriz.
Kaynaklar:
Teşekkürler