Blockchain Sızma Testi (Penetration Testing) Nedir? Tanımlar ve Sınırlar

Önceki makale olan From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing, blockchain penetration testing'in neden gerekli olduğunu ortaya koymuştu. Bu makale ise konunun ne olduğuna odaklanarak, blockchain penetration testing'in tanımlarını ve sınırlarını daha ayrıntılı olarak inceliyor.

Blockchain penetration testing için yaygın olarak kabul edilmiş resmi bir tanım bulunmamaktadır ve önerilen tanımların çoğu bunu diğer risk azaltma önlemleriyle birbirine karıştırmaktadır; bu nedenle audit, scan ve bug bounty gibi etiketler, her biri farklı bir amaca hizmet etse de bazen penetration testing'in bir parçası olarak dahil edilmektedir. Bu durum, belirli bir çalışmanın gerçekte neyi doğruladığını anlamayı zorlaştırmaktadır. Hem akademideki hem de sektördeki uygulamalardan yola çıkan başlangıç noktamız kasıtlı olarak basittir: blockchain penetration testing, adından da anlaşılacağı gibi, onlarca yıldır tanımlanmış bir disiplin olan penetration testing'in web3 ekosistemine uygulanmasıdır ve çalışan bir web3 ortamına karşı düşmanca (adversarial), bütünsel bir sistem değerlendirmesi olarak gerçekleştirilir. Bu bilinen disiplinden başlayıp, web3'ün tehdit modeline ve test uzmanlarından beklenen değerlendirme yeteneğine ne kattığını sormak gerekir.

Blockchain penetration testing, üzerinde anlaşılmış bir ortam ve katılım kuralları (rules of engagement) çerçevesinde, istismar edilebilir yolları ve kontrol zincirlerini doğrulamak amacıyla, çalışan bir sistem üzerinde gerçekleştirilen düşmanca, uygulamalı bir değerlendirmedir. Kod düzeyindeki güvenlik denetimlerini (security audit) tamamlayıcı niteliktedir ve bağımsız olarak da talep edilebilir [1].

Bu süreç, tekil zayıflıklar yerine yolları arar ve açık yetkilendirme, kapsam, erişim varsayımları ve güvenlik kısıtlamaları altında yürütülür. Bu makale üç soruya yanıt vermektedir: blockchain penetration testing nedir, özellikle bir audit'in genellikle sağladığı kanıtların ötesinde neyi doğrulayabilir ve bir kurum üst düzeyde nasıl başlayabilir.

Web3'ün kattığı şey: para yönetimi tehdit modeli

Web3, geleneksel penetration testing yüzeylerini korur: bulut altyapısı, web siteleri, API'ler, kimlikler, ayrıcalıklı erişim, tedarikçiler ve operasyonel araçlar. Bu tehdit modelini yalnızca blockchain'e özgü bir modelle değiştirmek yerine, web3 bunu, aynı zayıf noktaların doğrudan değeri yetkilendiren, hesaplayan veya taşıyan eylemlere yol açabildiği sistemlere doğru genişletir.

Bu genişlemeyi üç özellik şekillendirir.

• Birincisi, dijital varlıklar doğrudan aktarılabilir. Doğru işlem veya para çekme yoluna erişen bir saldırgan, geleneksel ödemelerde kullanılan aynı geri alma ve mutabakat mekanizmalarından geçmeden değeri taşıyabilir.

• İkincisi, imzalama genellikle para taşıyan bir eylemdir. Kriptografik olarak geçerli bir imza, bir anahtarın bir payload'u yetkilendirdiğini kanıtlar; tek başına, bir operatörün doğru hedefi görüp görmediğini, işlemi anlayıp anlamadığını veya amaçlanan onay politikasını takip edip etmediğini kanıtlamaz.

• Üçüncüsü, bir kurum kendi sözleşmelerini dağıttığında -ürünler zincir üzerinde daha zengin işlevsellik eklerken bu giderek daha yaygın hale gelmektedir- bu sözleşmeler herkes tarafından çağrılabilir ve birleştirilebilir niteliktedir. Harici kullanıcılar ve diğer sözleşmeler bunları kurumun kontrol edemediği sıralarda çağırabilir. Bu nedenle güvenlik, yalnızca her bileşene değil, aynı zamanda kimliklerin, uygulamaların, politikaların, imzalama sistemlerinin, hesaplama mantığının ve sözleşmelerin nasıl etkileşime girdiğine de bağlıdır.

Ortaya çıkan riski bir para yönetimi zinciri (money-handling chain) olarak modelliyoruz -zincir dışı (off-chain) imzalama niyeti, onay ve fon mantığı kontrolleri, zincir üzerindeki (on-chain) işlemlere yol açar (ve giderek artan biçimde, kurumun kendi dağıttığı sözleşmelere)- ve bu adımları destekleyen bulut, web, API ve kimlik katmanlarıyla birlikte ele alınır [1]. Bir saldırgan sıradan bir dayanak noktasıyla başlayıp birkaç kontrol boyunca ilerleyebilir: imzalama için sunulan şeyi manipüle edebilir, ayrıcalıklı bir iş akışına erişebilir, bir yetkilendirme boşluğundan yararlanabilir veya fon mantığının amaçlanmayan bir durum geçişini kabul etmesine neden olabilir.

Belirleyici bileşim boşluğu, zincir dışı (off-chain) ile zincir üzeri (on-chain) arasındaki geçiştir (handoff): kimlik, arayüz, onay, imzalama ve fon mantığı kontrollerinin, amaçlanan eylem zincir üzeri bir işleme dönüştüğünde bu eylemi koruyup korumadığı. Her saldırı zincirin bütününü kat etmez. Önemli olan nokta, güvence hedefinin katmanlar arası olmasıdır: tek başına sağlam görünen kontroller, çalışan para yönetimi sistemi boyunca birleşerek yine de istismar edilebilir bir yol oluşturabilir.

Blockchain penetration testing ne yapar

Blockchain penetration testing, bu bileşim boşluğunu kanıta dönüştürür. Yetkilendirilmiş kapsam ve üzerinde anlaşılmış kurallar dahilinde, test uzmanları katmanlar arası varsayımları saldırı senaryolarına çevirir, bu senaryoları çalışan ortama karşı uygular ve bunların tekrarlanabilir bir yol ile somut bir etki oluşturup oluşturmadığını belirler. Çıktı, yolu destekleyici kanıtlarla, önem derecesiyle (severity), giderim (remediation) rehberliğiyle ve üzerinde anlaşılan düzeltmelerin yeniden test edilmesiyle ilişkilendirir - birbirinden bağımsız bir zayıflık listesinde durup kalmaz.

Ayırt edici özelliği, benzersiz bir araç kutusu değil, uzman web3 güvenlik yargısıdır. Test uzmanları, geleneksel bulut, web, API, kimlik ve ayrıcalıklı erişim yüzeylerinden gelen kanıtları birbirine bağlarken; saklama (custody), işlem niyeti, onay politikası, para çekme akışları, fon hesaplama ve zincir üzeri işlem davranışını (dağıtılmış sözleşmeler dahil) yorumlamalıdır. Araçlar keşif veya doğrulama sürecine destek olabilir, ancak gözlemlenen koşulların güvenilir bir para taşıma yolu oluşturup oluşturmadığını uzman değerlendirmesi belirler.

Değerlendirme yöntemlidir, kanıta dayalıdır ve belirli bir zaman noktasına özgüdür. Sonuçları, test edilen sistemler, sürümler, konfigürasyonlar, erişim varsayımları ve koşullar için geçerlidir. Potansiyel yollar incelenir; doğrulanmış istismar edilebilir yollar tekrarlanabilir kanıtlarla belgelenir.

Lütfen üzerinde anlaşılan yüzey boyunca yapılan sistematik çalışmanın, her zayıflığın veya saldırı yolunun keşfedileceğini garanti edemeyeceğini ve sorumlu bir çalışmanın test uzmanlarının bir ihlal (breach) gerçekleştireceğini garanti etmediğini unutmayın.

Kurumsal bir web3 ortamında, bu senaryodan kanıta süreci beş bağlantılı yetenek üzerinden -aynı para yönetimi zincirinin test edilebilir yüzeyleri- işler. Bunlar, zinciri destekleyen altyapıyı, üç zincir dışı kontrolünü ve geçiş yaptığı zincir üzeri işlemleri kapsar; birbirlerine bağlıdırlar çünkü tek bir yol bunlardan birkaçını kat edebilir:

• Üretim (production) ortamı ve otomasyon operasyonları: test uzmanları erişim, dağıtım, gizli anahtarlar (secrets) veya operasyonel kontrollerin bir para yönetimi eylemine doğru zincirlenip zincirlenemeyeceğini doğrular, operasyonel dayanak noktasını erişilebilir etkisine bağlayan kanıt üretir.

• Web ve dApp ön yüzleri, yetkilendirme ve imzalama niyeti: test uzmanları, bir kullanıcıya veya operatöre sunulan işlemin nihayetinde yetkilendirilen eylemden farklılaşabilir olup olmadığını doğrular; manipüle edilmiş akışı ve sonuçta ortaya çıkan imzalanmış veya gönderilmiş davranışı kayıt altına alır.

• İmzalama, onay ve para çekme yetkilendirme zincirleri: test uzmanları kimliklerin, rollerin, politika kontrollerinin veya onay adımlarının atlatılıp atlatılamayacağını veya birleştirilip birleştirilemeyeceğini doğrular; sırayı ve bunun mümkün kıldığı yetkisiz eylemi belgeler.

• Fon iş mantığı: test uzmanları bakiyelerin, limitlerin, mutabakatın, para çekme kurallarının veya durum geçişlerinin amaçlanmayan koşulları kabul edip etmediğini doğrular; yalnızca teknik bir kusur değil, tekrarlanabilir bir iş etkisi yolu yakalar.

• Zincir üzeri işlemler ve dağıtılmış sözleşmeler: test uzmanları, kurumun zincir üzeri etkileşimlerinin düşmanca çalışma zamanı koşulları altında nasıl davrandığını doğrular; kurumun kendi sözleşmelerini dağıttığı durumlarda, bu sözleşmelerin çalışma zamanı davranışını uygularlar ve gözlemlenen sonucun işlem düzeyindeki kanıtını korurlar. Kod düzeyindeki güvence, ilgili Code Audit'in rolü olarak kalır.

Part 4: Web3 Attack Surfaces: A Penetration Testing Overview, temel amacı değiştirmeden bu yüzeyleri ve bağlantılarını haritalandırır: üzerinde anlaşılan çalışan ortam boyunca koşulların tekrarlanabilir bir etkiye zincirlenip zincirlenmediğini belirlemek.

Diğer güvence yöntemleri arasındaki yeri

En açık karşılaştırma güvence hedefi üzerinden yapılır: çalışmanın desteklemesi amaçlanan karar ve üretmesi beklenen kanıt. Aşağıdaki şekilde gösterildiği gibi, yöntemler örtüşebilir, disiplinler işbirliği yapabilir ve bir ekibin yalnızca statik, diğerinin yalnızca dinamik olduğunu varsaymak faydalı bir sınır oluşturmaz. Aynı hedef -dağıtılmış bir sözleşme, bir bulut veya RPC yüzeyi, bir imzalama sistemi- bu disiplinlerden birden fazlasının kapsamına girebilir; farklı olan, sistem üzerinde münhasır bir hak talebi değil, her birinin vurguladığı güvence hedefidir.

Penetration testing ve kod düzeyinde audit

Kod düzeyindeki audit'in adlandırılmış biçimi olan bir Code Audit, öncelikli olarak kodda (tasarım, mimari ve protokol varsayımları da dahil) güvence oluşturur. Uzman incelemesini tespit araçlarıyla birleştirir, dinamik teknikler de içerebilir ve üzerinde anlaşılan denetim kapsamına karşı imzalı bir rapor üretir. Sözleşmeler, zincirler, köprüler (bridges), rollup'lar, cüzdanlar veya diğer uygulamalar için audit, tasarımın ve kodun amaçlanan güvenlik özelliklerini karşılayıp karşılamadığını sorar.

Penetration testing, öncelikli olarak üzerinde anlaşılmış, çalışan bir kurumsal ortam boyunca gerçek koşulların tekrarlanabilir bir etkiye zincirlenip zincirlenemeyeceğini belirler. Dağıtılmış uygulamalar, kimlikler, konfigürasyonlar, iş akışları, iş mantığı, imzalama sistemleri ve sözleşme çağrıları arasındaki etkileşimi takip eder, ardından yolun tekrarlanması ve giderilmesi için gereken kanıtları kaydeder.

Bu, bir yetenek yasağı değil, amaç ve kanıt açısından bir farktır. Auditörler testler yürütebilir, bileşenleri fuzz edebilir ve çalışma zamanı davranışını araştırabilir; penetration test uzmanları da bir yolu anlamak için konfigürasyonları, uygulama mantığını ve uygulama detaylarını inceleyebilir. Yöntemler örtüşebilir ve ekipler birlikte çalışabilir. Hizmetler birbirini tamamlayıcıdır, birbirinin yerine geçmez: tek başına audit genellikle bu kurum çapındaki çalışma zamanı istismar edilebilirlik kanıtını sağlamaz, penetration testing ise bir audit tarafından kapsanan uygulama ve protokol özelliklerindeki kod düzeyindeki güvencenin yerini almaz.

Bu nedenle, canlı bir kurumsal yolda bir sözleşmenin düşmanca davranışı penetration testing kapsamına girebilirken, sözleşme kodunun kendisi hakkındaki güvence ilgili Code Audit'e yönlendirilir.

Tarama, bug bounty'ler ve özelleşmiş testler

Zafiyet taraması (vulnerability scanning), bilinen imzalar, açığa çıkmış servisler, eksik yamalar ve yaygın konfigürasyon sorunları genelinde otomatik bir genişlik sağlar. Tekrarlanabilir görünürlüğü destekler ve keşif (reconnaissance) sürecine katkıda bulunabilir; penetration testing ise uzman odaklı derinlik ekler ve koşulların anlamlı bir yola zincirlenip zincirlenemeyeceğini belirler.

Bir bug bounty, bağımsız araştırmacıları yayınlanmış kurallar altında uygun bulguları bildirmeye davet eder. Sürekli, topluluk kaynaklı (crowdsourced) modeli uzun kuyruklu (long-tail) sorunları ortaya çıkarabilirken, bir penetration testing çalışması üzerinde anlaşılmış bir ortamı yöntemli olarak incelemek ve konsolide edilmiş kanıt, önem derecesi, giderim rehberliği ve yeniden test sunmak için bir ekip görevlendirir. Bu iki model birbirini tamamlar ve hiçbiri eksiksiz keşfi garanti etmez.

Örneğin, BlockSec'in Blockchain Security Testing'i, penetration testing'in bir üst kümesi veya alt kümesi değil, kardeş bir programdır. Özelleştirilmiş altyapının uygulama doğruluğunu ve dayanıklılığını doğrulamak için diferansiyel test (differential testing), fuzzing, özel dağıtım (private deployment), büyük ölçekli RPC hizmet reddi (denial-of-service) testi ve node veya küme (cluster) altyapı testi de dahil olmak üzere özelleşmiş motorlar kullanır [2]. Blockchain penetration testing, çalışan para yönetimi sistemi boyunca kurum düzeyinde, katmanlar arası yollara odaklanır. Uygulama barındırma (hosting) ve uygulama CI/CD'si penetration testing yüzeyine yönlendirilir; node ve küme altyapısı ile büyük ölçekli RPC dayanıklılığı ise Blockchain Security Testing'e yönlendirilir. Bir mimari her ikisine de ihtiyaç duyabilir.

Yakın hedefler de kesin yönlendirme gerektirir. Sözleşme kod düzeyindeki güvence, ilgili Code Audit'e yönlendirilir. MPC, TSS ve TEE tasarımları dahil olmak üzere anahtar saklama (key-custody) uygulamalarının kriptografik doğruluğu, Wallet Security Audit'e yönlendirilir. Ödeme tarafındaki agentic sistemler, Agentic Payment Security'ye yönlendirilir [1]. Penetration testing, üzerinde anlaşılan kurumsal kapsamın bir parçasını oluşturduğunda çevredeki imzalama iş akışını, operasyonel agent'ları veya uygulama yolunu da inceleyebilir.

Bu bir yönlendirme rehberidir, bir sıralama değildir. Tek bir sistem birden fazla güvence hedefi oluşturabilir ve bu nedenle koordineli bir değerlendirme setini gerektirebilir; etiketler birbirini dışlamaz.

Yargı alanına (jurisdiction) ve kurum sınıfına bağlı olarak, testler bir düzenleyici gereklilik veya denetleyici bir beklenti olabilir ve bazı düzenlemeler bağımsız bir üçüncü tarafın olmasını zorunlu kılar; Part 1 bu ayrımları açıklamaktadır [3]. Düzenleyici uygulanabilirlik, hukuk müşaviri ile teyit edilmelidir.

Nasıl başlanır

Karardan önce, şu üç soruyla başlayabiliriz: Hangi sistemler fon taşımaktadır? Şu anda hangi güvence kanıtı mevcuttur? Hangi kontrol zinciri henüz düşmanca (adversarial) bir şekilde doğrulanmamıştır? Yanıtlar, hizmeti isim bazında erken seçmeden güvence boşluğunu belirler.

Ardından bir kapsam belirleme (scoping) görüşmesi, hedefi, erişim varsayımlarını, güvenlik önlemlerini ve beklenen teslimatları hizalayabilir. Part 3: Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing, çalışmayı operasyonel hale getirmek için gereken yetkilendirmeyi, güvenliği ve koordinasyonu ele almaktadır [4].

Bu konuda harekete geçmeye hazır olduğunuzda, test başlamadan önce hedefi, kanıtı ve güvenlik önlemlerini hizalamak için scope your assurance gap with BlockSec.

Saldırı yüzeyi rehberlerine devam edin:

• Part 4: Web3 Attack Surfaces: A Penetration Testing Overview

Bu serinin yakında yayınlanacak diğer bölümleri:

• Part 5: Authorization and Signing Security: Web, dApps, and Mobile
• Part 6: Cloud and CI/CD Security: Automated Operations Attack Surfaces
• Part 7: Treasury Control-Plane Security: Signing and Withdrawal Approvals
• Part 8: Exchange Ledger Security: Theft Paths and Data-Plane Logic

Blockchain Penetration Testing pillar page, çalışma düzeyindeki bakış açısını sunmaktadır.

Referanslar

İlk görünüm sırasına göre numaralandırılmıştır.

1. BlockSec, Blockchain Penetration Testing.
2. BlockSec, [Blockchain Security Testing], yakında yayınlanacak.
3. BlockSec, From Incidents to Regulation: Why Crypto Institutions Need Blockchain Penetration Testing.
4. BlockSec, Rules of Engagement and Production Safety for Institutional Blockchain Penetration Testing.