~$4.1M Kayıp: Taiko, SecondFi Açıkları

Geçen hafta (2026/06/22 - 2026/06/28) 2 önemli güvenlik olayı tespit edilmiş ve yaklaşık 4,1 milyon dolar doğrulanmış kayıpla sonuçlanmıştır.

Tarih	Olay	Tür	Tahmini Kayıp
2026/06/22	Taiko	Anahtar Ele Geçirme & Hatalı Doğrulama	~$1.7M
2026/06/23	SecondFi	Kriptografik Uygulama Açığı	~$2.4M

Taiko: Saldırgan, açıkta kalan bir SGX enclave imzalama anahtarını eksik bir doğrulama politikasıyla birleştirerek kötü amaçlı bir kanıtlayıcıyı yetkili bir örnek olarak kaydetti; bu durum, kapsamlı nitelik uygulaması olmadan yalnızca geçerli doğrulamanın yetersiz kaldığını ortaya koydu.
SecondFi: Bir kriptografik uygulama açığı, saldırganların yalnızca genel işlem verilerini kullanarak adres düzeyindeki imzalama anahtarlarını kurtarmasına olanak tanıdı; bu durum, Ed25519 spesifikasyonundan görünürde küçük bir sapmanın tam anahtar ele geçirilmesine yol açabileceğini gösterdi.

Haftanın Öne Çıkanı: Taiko Olayı

Taiko olayı öne çıkarılmıştır; çünkü saldırı, SGX tabanlı bir kanıt doğrulama sistemini tehlikeye atmak için iki bağımsız güvenlik açığını (açıkta kalan bir enclave imzalama anahtarı ve eksik bir doğrulama politikası) birleştirdi. Olay, TEE güven zincirinin her katmanının güvenlik özelliklerini bağımsız olarak uygulaması gerektiğini; geçerli bir doğrulama imzası zincirinin denetlenmemiş çalışma zamanı niteliklerini telafi etmediğini göstermektedir.

22 Haziran 2026'da Taiko'nun SGX tabanlı kanıt doğrulama akışı Ethereum üzerinde istismar edildi ve yaklaşık 1,7 milyon dolar kayıpla sonuçlandı [1]. Saldırgan, genel bir GitHub deposuna yüklenmiş olan açıkta kalan enclave imzalama özel anahtarını kullanarak DEBUG modunda başlatılan bir kanıtlayıcı enclave için SIGSTRUCT'ı imzaladı. Zincir üstü doğrulama sözleşmesi DEBUG enclave'leri reddetmediğinden saldırgan kendisini yetkili bir örnek olarak kaydetti, sahte kanıt verileri gönderdi ve L1 sözleşmelerinin var olmayan bir L2 durumunu kabul edip köprü fonlarını serbest bırakmasına neden oldu.

Arka Plan

Taiko, belirli bir L2 durumunun veya zincirler arası mesajın kabul edilip edilmeyeceğine karar vermek için bir kanıt sistemine dayanan köprüye sahip bir Ethereum Katman-2 rollup'ıdır. Bu kanıt sisteminin bir parçası olarak Taiko, SGX kanıtlayıcılar kullanmaktadır: kanıt sonuçlarını enclave tarafından korunan anahtarlarla imzalayan, fiziksel makinelerdeki SGX enclave'leri içinde çalışan zincir dışı programlar.

Zincir Dışı (fiziksel makine)               Zincir Üstü (Ethereum)
┌─────────────────────────┐                ┌────────────────────────────────────┐
│  SGX Kanıtlayıcı Enclave│                │  SgxVerifier                       │
│  - kanıt üretir         │── DCAP quote ─→│  ├─ registerInstance()             │
│  - örnek anahtarı tutar │                │  │  └─ AutomataDcapV3Attestation   │
│                         │── imzalı kanıt→│  └─ verifyProof()                  │
└─────────────────────────┘                └────────────────────────────────────┘

SGX ve DCAP'a Genel Bakış

SGX'in temel kavramı enclave'dir: CPU tarafından izole edilmiş bir program ortamı. MRENCLAVE, enclave'in başlangıç kodu, verileri, sayfa düzeni ve ilgili meta verilerinin ölçümüdür; enclave derlemesinin özeti olarak düşünülebilir. MRSIGNER, enclave imzalama genel anahtarının özeti olup yayıncı kimliğini temsil eder.

Enclave imzalama özel anahtarı, MRENCLAVE, ISVPRODID, ISVSVN ve ATTRIBUTES gibi enclave meta verilerini içeren SGX SIGSTRUCT'ı imzalar. Bu imza zincir üstü sözleşme tarafından doğrulanmaz; enclave başlatıldığında EINIT aşamasında SGX donanımı tarafından doğrulanır. CPU, SIGSTRUCT imzasının geçerli olduğunu ve içindeki MRENCLAVE'in gerçekte yüklenen enclave'in ölçümüyle eşleştiğini kontrol eder. Yalnızca bu doğrulama başarılı olduktan sonra enclave başlatılabilir ve sonraki raporları ile alıntıları üretebilir.

Intel SGX DCAP v3 alıntısı, üç bölüm içeren uzaktan doğrulama paketidir:

header: alıntı sürümü, doğrulama anahtarı türü, QE/PCE SVN ve satıcı gibi meta veriler.
localEnclaveReport: MRENCLAVE, MRSIGNER, ATTRIBUTES, ISVPRODID, ISVSVN ve reportData dahil olmak üzere doğrulanan uygulama enclave'inin kimliği. reportData, enclave tarafından rapor oluşturulurken yazılan 64 baytlık bir değerdir. Taiko, kanıtlayıcı örnek adresini reportData'nın ilk 20 baytında saklar.
v3AuthData: alıntı imzası, doğrulama anahtarı, QE raporu, QE rapor imzası ve PCK sertifika zinciri dahil olmak üzere alıntı için özgünlük kanıtı.

Zincir Üstü Doğrulama

Zincir üstü doğrulama sözleşmesi (AutomataDcapV3Attestation, uzaktan doğrulamadan sorumlu), Intel DCAP sertifika zinciri aracılığıyla alıntı özgünlüğünü doğrular. Sertifika zincirindeki yayıncı genel anahtarları harici olarak gönderilen alıntının bir parçası olarak sağlansa da sözleşme, zinciri adım adım doğrular ve nihai yayıncı genel anahtar özetinin sözleşmede sabit kodlanmış Intel SGX Root CA genel anahtar özetiyle eşleşmesini gerektirir [2]. Bu zincir aracılığıyla sözleşme, alıntı imzasının kapsadığı localEnclaveReport'un calldata'da rastgele değiştirilmediğini doğrular.

Taiko Kanıtlayıcı Kaydı

Bir SGX kanıtlayıcı örneğinin önce SgxVerifier.registerInstance() aracılığıyla kaydedilmesi gerekir. Kayıt sırasında çağrıcı bir DCAP alıntısı gönderir. SgxVerifier, alıntı doğrulamasını AutomataDcapV3Attestation.verifyParsedQuote()'a devreder. Alıntı geçerliyse SgxVerifier, localEnclaveReport.reportData'nın ilk 20 baytını örnek adresi olarak okur ve bunu yetkili örnek kümesine ekler.

İmza doğrulama akışı üç katmana indirgenebilir:

SGX CPU, EINIT sırasında SIGSTRUCT imzasını doğrulayarak enclave'in MRENCLAVE'ini ve imzalayan kimliğini onaylar.
DCAP sertifika zinciri ve QE raporu, alıntı imzalama anahtarını doğrular. AutomataDcapV3Attestation daha sonra bu anahtarı kullanarak alıntı imzasını doğrular ve localEnclaveReport'a güven tesis eder.
Taiko'nun kanıt doğrulayıcısı, sonraki kanıt imzalarını doğrulamak ve ilgili L2 durumunu veya zincirler arası mesajı kabul edip etmeyeceğine karar vermek için kayıtlı örnek adresini kullanır.

Güvenlik Açığı Analizi

Bu olayın temel nedeni, operasyonel bir başarısızlık ile sözleşme düzeyinde bir güvenlik açığının birleşimidir. Saldırının başarılı olması için her ikisi de gerekliydi.

Operasyonel başarısızlık: açıkta kalan enclave imzalama anahtarı. Taiko/Raiko tarafından SGX SIGSTRUCT'ı imzalamak için kullanılan enclave imzalama özel anahtarı genel bir GitHub deposuna yüklendi. MRSIGNER, karşılık gelen imzalama genel anahtarının özetidir. Bu özel anahtarı ele geçiren herkes bir kanıtlayıcı enclave'in SIGSTRUCT'ını imzalayabilir ve ortaya çıkan alıntıdaki MRSIGNER'ın Taiko'nun izin listesiyle eşleşmesini sağlayabilir.

Sözleşme güvenlik açığı: eksik ATTRIBUTES kontrolü. Eşleşen bir MRSIGNER ile (açıkta kalan anahtar aracılığıyla izin listesini geçerek), saldırgan MRENCLAVE'i değiştirmeden aynı onaylı enclave'i DEBUG modunda başlatabildi (DEBUG bayrağı MRENCLAVE'in bir parçası değildir). Doğrulama politikası bunu yakalamalıydı, ancak AutomataDcapV3Attestation (0x5e46...dd72) uygulama enclave'inin localEnclaveReport.attributes'unu kontrol etmedi. Bir DEBUG enclave, ana bilgisayarın veya hata ayıklayıcının enclave belleğini okumasına veya değiştirmesine izin verir; bu da SGX enclave tarafından korunması gereken örnek imzalama anahtarının artık güvende olmadığı anlamına gelir.

Bu iki koşul birlikte, herhangi bir tarafın aynı kanıtlayıcı enclave kodunu DEBUG modunda başlatabileceği (meşru derlemeyle aynı MRENCLAVE'i üreterek) ve açıkta kalan imzalama anahtarını kullanarak MRSIGNER'ın Taiko'nun izin listesiyle eşleşmesini sağlayan bir SIGSTRUCT imzalayabileceği anlamına gelir. Ortaya çıkan alıntı, denetlenmeyen DEBUG niteliğini taşırken hem MRENCLAVE hem de MRSIGNER izin listelerini karşılar. AutomataDcapV3Attestation, DEBUG niteliğini reddetmediğinden bu tür bir alıntı verifyParsedQuote()'u geçer ve ardından SgxVerifier örnek adresini yetkili örnek kümesine kaydeder.

DEBUG modundaki bir enclave, belleğini ana bilgisayardan veya hata ayıklayıcıdan korumaz. Dolayısıyla enclave içinde oluşturulan örnek özel anahtarı çıkarılabilir. Bu anahtarla, anahtarı elinde bulunduran kişi L1 sözleşmelerinin kabul edeceği rastgele kanıt verilerini imzalayabilir; bu da sahte L2 durum geçişlerini ve kasadan (0x9962...15ab) yetkisiz köprü fonu serbest bırakılmasını mümkün kılar.

Saldırı Analizi

Saldırgan birden fazla işlem gönderdi. Aşağıdaki analiz iki temsili işleme dayanmaktadır: birincisi saldırganı yetkili bir örnek olarak kaydetti (0x2f44dc...277260), ikincisi ise varlıkları çalmak için sahte kanıtı çalıştırdı (0x017292...ae35ee).

Adım 1: Alıntının MRSIGNER'ının izin listesiyle eşleşmesi için açıkta kalan enclave imzalama anahtarını kullanarak SIGSTRUCT'ı imzala.
Adım 2: Enclave'i DEBUG niteliğiyle çalıştır. DEBUG, MRENCLAVE'i değiştirmez ancak localEnclaveReport.attributes'a yansır.
Adım 3: registerInstance()'ı çağır ve gerçek bir SGX alıntısı gönder. Alıntı DEBUG bitini (0x02) içeren attributes = 0x07... değerine sahipti, ancak AutomataDcapV3Attestation bu alanı kontrol etmedi ve verifyParsedQuote() true döndürdü.

Adım 4: SGX enclave belleğinden örnek özel anahtarını çıkar (DEBUG modu bellek korumasını devre dışı bıraktığından bu mümkündür) ve kötü amaçlı kanıt verilerini imzalamak için kullan.
Adım 5: L1 sözleşmelerinin var olmayan bir L2 durumunu kabul etmesi ve kasadan varlık çalınması için hazırlanmış kanıtı gönder.

Sonuç

Eksiksiz bir SGX doğrulama politikası en azından şunları yapmalıdır:

Üretim ortamlarında SGX_FLAGS_DEBUG'ı reddetmek.
MRENCLAVE, MRSIGNER, ISVPRODID ve ISVSVN'yi kontrol etmek.

DEBUG alıntıları kabul edilirse, donanım hâlâ doğru çalışıyor olabilir ancak artık beklenen bellek koruma semantiğini sağlamaz. Enclave imzalama anahtarları da hiçbir zaman genel depolara yüklenmemelidir. Açıkta kalan bir imzalama anahtarı, herhangi bir tarafın eşleşen MRSIGNER'a sahip ikili dosyalar üretmesine olanak tanır; bu da doğrulama politikasının kalan engellerini MRENCLAVE ve nitelik uygulamasına indirger.

Daha geniş bir perspektiften bakıldığında, TEE'lere dayanan herhangi bir sistem için doğrulama, imza zincirinin geçerli olduğunu ve ölçümün izin listesinde bulunduğunu doğrulamakla sınırlı kalmamalıdır. Güven zincirinin her katmanı, güvenlik özelliklerini bağımsız olarak uygulamalıdır.

Referanslar

[1] Phalcon Uyarısı: Taiko Köprüsü İstismar Tespiti
[2] Intel SGX Geliştirici Kılavuzu

Bu Haftaki Diğer Olaylar

SecondFi Olayı

23 Haziran 2026'da Cardano cüzdanı SecondFi (eski adıyla Yoroi), EMURGO tarafından geliştirilen Ed25519 imzalama uygulamasındaki kritik bir güvenlik açığını açıkladı [1]. Cüzdanın imzalama uygulaması, imzalama nonce'unu yalnızca genel işlem mesajından hesapladı ve gerekli gizli girdiyi atladı. Bu durum, dijital imzayı tek denklemli bir probleme indirgedi ve saldırganların genel zincir üstü verilerden adres düzeyindeki özel anahtarları kurtarmasına olanak tanıdı. İki ayrı saldırgan bu açığı istismar ederek 374 cüzdandan yaklaşık 2,4 milyon dolar (16 milyon ADA) boşalttı [2].

Arka Plan

SecondFi, Nisan 2026'da Yoroi'dan yeniden markalanan Cardano blok zinciri için öz saklama cüzdanıdır. Cardano'nun üç kurucu kuruluşundan biri olan EMURGO tarafından geliştirilen Yoroi, daha önce bir milyondan fazla kullanıcıya hizmet verdi.

Ed25519, Cardano'nun işlem yetkilendirmesi için kullandığı dijital imza şemasıdır. İmzalayan kişi, bir imzalama skaleri $k_{L}$ (belirli bir adres için özel anahtar) ve aynı anahtar materyaliyle ilişkili gizli bir nonce öneki $k_{R}$ tutar. Belirli bir $M$ mesajı (işlem yükü) için imzalama nonce'u $r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L$ olarak hesaplanır. $k_{R}$ gizli olduğundan, $M$ yayın sonrasında genel olsa bile $r$ gözlemciler için bilinmez kalır.

Nonce noktası $R = r \cdot B$ (burada $B$ sabit Ed25519 taban noktasıdır) ve imza skaleri $s \equiv r + H \cdot k_L \pmod{L}$ (burada $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ , nonce, genel anahtar ve mesajı bağlar) nihai imzayı $(R, s)$ oluşturur. Şemanın güvenliği, $r$ 'nin tahmin edilemez olmasına bağlıdır: bir gözlemci $r$ 'yi hesaplayabilirse, imza denklemi $k_{L}$ için çözülebilen tek bilinmeyenli doğrusal bir denklem hâline gelir.

Güvenlik Açığı Analizi

Bu güvenlik açığı, bir akıllı sözleşmede değil, SecondFi'ın cüzdan imzalama yazılımındadır.

Mevcut analizi [2] kendi araştırmamızla birleştirerek v10.0.3 ile v10.0.6 arasındaki sürümlerin (8 Haziran 2026'dan itibaren canlıda; v10.0.6.2'de düzeltildi) etkilendiğini tespit ettik. Savunmasız uygulama, imzalama nonce'unu şu şekilde hesapladı:

r = \operatorname{SHA-512}(M) \bmod L

doğru olanı yerine:

r = \operatorname{SHA-512}(k_R \mathbin\Vert M) \bmod L

Bu durum, nonce türetiminden tek gizli girdiyi ( $k_{R}$ ) kaldırdı. $M$ genel olduğundan, herkes etkilenen bir adres tarafından imzalanan herhangi bir işlem için $r$ 'yi yeniden hesaplayabilir.

$r$ bilindiğinde, $s \equiv r + H \cdot k_L \pmod{L}$ imza denklemi çözülebilir hâle gelir:

k_L \equiv (s - r) \cdot H^{-1} \pmod{L}

Sağ taraftaki tüm değerler ya genel ya da zincir üstü imza ve işlem verilerinden hesaplanabilir. Bu, bir özeti tersine çevirmek veya $A = k_L \cdot B$ 'den ayrık logaritmayı çözmek değildir; hatalı uygulama $r$ 'yi doğrudan açığa çıkardı ve anahtar kurtarmayı basit modüler aritmetiğe indirgeledi.

Etki, adres kapsamlı anahtar ele geçirmedir. Savunmasız uygulama aracılığıyla imza üreten herhangi bir adres tehlikeye girmiş olarak değerlendirilmelidir.

Aynı anımsatıcıyı yamalı bir cüzdana aktarmak, halihazırda açığa çıkan adresi korumaz; fonlar, savunmasız imzalama uygulaması aracılığıyla hiç imzalamayan yeni oluşturulmuş bir anahtara taşınmalıdır.

Saldırı Analizi

Bu saldırı, izlenebilir akıllı sözleşme etkileşimleriyle tipik bir zincir üstü istismar dizisini takip etmez. Güvenlik açığı, genel veriler ile imzalama anahtarı arasında deterministik bir ilişki ortaya koyduğundan, anahtar kurtarma çevrimdışı gerçekleştirilir.

Adım 1: SecondFi v10.0.3 ile v10.0.6 arasındaki sürümleri kullanarak işlem imzalayan hedef adresleri tespit et.
Adım 2: Her hedef için işlemin genel imza bileşenlerini ( $R$ , $s$ ) al ve zincir üstü işlem yükünden $M$ mesajını yeniden oluştur.
Adım 3: Savunmasız imzalama uygulamasının gizli nonce önekini $k_{R}$ atladığı gerçeğini istismar ederek imzalama nonce'unu $r = \operatorname{SHA-512}(M) \bmod L$ olarak hesapla.
Adım 4: Meydan okuma skalarini $H = \operatorname{SHA-512}(R \mathbin\Vert A \mathbin\Vert M) \bmod L$ olarak hesapla.
Adım 5: İmzalama skaleri için çöz: $k_L \equiv (s - r) \cdot H^{-1} \pmod{L}$ .
Adım 6: Ele geçirilen adresten rastgele işlemler imzalamak ve fonları saldırgan kontrolündeki cüzdanlara aktarmak için kurtarılan $k_{L}$ 'yi kullan.

İki ayrı saldırgan bu güvenlik açığını bağımsız olarak istismar etti. Biri iki dalgada 171 cüzdanı ele geçirirken, ikincisi ayrı bir taramada 203 cüzdanı boşalttı; toplam yaklaşık 16 milyon ADA (~2,4 milyon dolar) çalındı [2]. EMURGO daha sonra saldırganların ulaşamadan önce 129 milyon ADA'yı daha kurtardı.

Sonuç

Temel neden, Ed25519 nonce türetiminden gizli nonce önekini kaldıran ve imzalama nonce'unu genel verilerin deterministik bir fonksiyonuna indirgeyen kriptografik bir uygulama açığıydı. Etkilenen her imza, tek denklemli bir anahtar kurtarma problemine dönüştü.

Bu olay, cüzdan geliştiricilerinin özel imzalama uygulamaları yerine iyi denetlenmiş, standart Ed25519 kütüphanelerini kullanması gerektiğini vurgulamaktadır. Spesifikasyondan herhangi bir sapma, tek bir özet girdisinin atlanması gibi küçük görünse bile tüm anahtarı tehlikeye atabilir. Üretim imzalama yazılımı, özellikle anahtar türetme ve imzalama işlemlerini ele alırken dağıtım öncesinde bağımsız kriptografik denetime tabi tutulmalıdır.

Referanslar

[1] SecondFi Olay Sonrası Açıklama
[2] Tibane Labs: SecondFi Cardano Adli Analiz

BlockSec Hakkında

BlockSec, tam yığın blok zinciri güvenliği ve kripto uyumluluk sağlayıcısıdır. Müşterilerin protokollerin ve platformların tüm yaşam döngüsü boyunca kod denetimi gerçekleştirmesine (akıllı sözleşmeler, blok zinciri ve cüzdanlar dahil), saldırıları gerçek zamanlı olarak engellenmesine, olayları analiz etmesine, yasadışı fonları takip etmesine ve AML/CFT yükümlülüklerini yerine getirmesine yardımcı olan ürün ve hizmetler geliştiriyoruz.

BlockSec, prestijli konferanslarda birden fazla blok zinciri güvenlik makalesi yayımlamış, DeFi uygulamalarına yönelik birçok sıfır gün saldırısını raporlamış, 20 milyonun üzerinde doları kurtarmak için birden fazla saldırıyı engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.