Harmony Cross-Shard ONE Basımı + ~47 Milyon Dolarlık Anahtar Kayıpları

Geçtiğimiz hafta (2026/08/10 - 2026/08/16) içinde, toplamda yaklaşık 47 milyon dolar kayıpla ilgili aşağıdaki 5 dikkat çekici güvenlik olayı öne çıkıyor.

Tarih	Olay	Tür	Tahmini Kayıp
2026/08/10	Coinsbuy	Özel Anahtar İhlali	~$7.9M
2026/08/10	Bilinmeyen Balina Cüzdanı	Özel Anahtar İhlali	~$25M
2026/08/12	Harmony	Doğrulama Sorunu	Bilinmiyor*
2026/08/13	Kite	Özel Anahtar İhlali	~$14M
2026/08/15	Fox	İş Mantığı Hatası	~$117K

*Harmony, doğrulanmış birinci dalga 4 Milyar ONE basımını ve yaklaşık 3.01 Trilyon ONE'ın sahte olarak üretildiğine dair daha kapsamlı bir yeniden yapılandırmayı bildirdi; bunun yaklaşık 2.385 Trilyon ONE'ı transfer edildi [1]. Olay öncesi fiyat olan ~$0.001183 üzerinden, sahte üretilen miktarın nominal değeri ~$3.56 Milyar'dır, ancak bu değer ONE'ın toplam arzının kabaca 200 katıdır ve token'ın piyasa değerini fazlasıyla aşmaktadır; dolayısıyla bu ne gerçekleştirilebilir ne de gerçekleşmiş olduğu doğrulanmış bir kayıptır. Harmony, o zamandan beri zinciri saldırı öncesi bir kontrol noktasına geri sararak sahte durumu (state) ortadan kaldırmıştır [2]. Bu nedenle Harmony toplam kayıplardan hariç tutulmuştur.

Seçim Nedenleri

Harmony: Zincir uygulamasındaki bir tekrar-koruma (replay-protection) hatasının, Harmony ekosistemi genelinde büyük ölçekte yetkisiz yerel token ihracına imkan sağlaması nedeniyle seçilmiştir. Soruşturma sırasında ayrı bir pre-staking quorum doğrulama zayıflığı da tespit edilmiştir, ancak bu zayıflığın istismardaki rolü doğrulanmamıştır.

Haftanın Öne Çıkanı: Harmony

Harmony bu hafta öne çıkarılmıştır çünkü hata, bir uygulama sözleşmesinde değil, zincirin kendi uygulamasında yer almaktaydı; bu, bir bütün Katman-1'in temel varlığını (base asset) şişirebildiği için alışılmadık derecede yüksek etkili bir başarısızlık türüdür.

12 Ağustos 2026'da, parçalı (sharded) bir Katman-1 blok zinciri olan Harmony, çapraz-parça (cross-shard) makbuz tekrar oynatma (replay) hatası nedeniyle yerel ONE token'ının yetkisiz basımına uğradı. Hedef parçalar (destination shards), kaynak komitenin (source committee) imzası tarafından kapsanmayan alanları kullanarak zaten tüketilmiş bir makbuzu tanımlıyordu; böylece bir saldırgan, yalnızca bu alanları değiştirerek gerçek, önceden kredilendirilmiş bir makbuzu yeniden sunabilir ve kaynak parçada (source shard) karşılık gelen bir borç işlemi olmadan tekrar kredilendirebilirdi. Harmony, doğrulanmış birinci dalga 4 Milyar ONE basımını, yaklaşık 3.01 Trilyon ONE sahte üretim ve sahte-basım yapan bir cüzdan tarafından yaklaşık 2.385 Trilyon ONE transferini içeren daha kapsamlı bir yeniden yapılandırma ile uzlaştırıyordu; bunların hiçbiri doğrulanmış gerçekleşmiş kayıp değildir ve nihai etki geri sarma (rollback) ve borsa uzlaştırmasına (reconciliation) bağlı kalmaktadır [1][2]. Soruşturma sırasında Harmony, ayrı bir pre-staking quorum doğrulama hatası tespit etti, ancak istismarın buna dayanıp dayanmadığını doğrulamadı.

Arka Plan

Harmony, parçalı (sharded) bir Katman-1 blok zinciridir. Her parça (shard) kendi bağımsız durumunu (state) tutar, dolayısıyla bir kaynak parça, hedef parçadaki bir hesabı doğrudan değiştiremez. Parçalar arasında değer taşımak için Harmony, asenkron, makbuz tabanlı bir tasarım kullanır: kaynak parça göndericiyi borçlandırır ve bir çapraz-parça makbuzu (cross-shard receipt) yayınlar, hedef parça ise daha sonra alıcıyı kredilendirir.

Bir çapraz-parça makbuzu, transferin kendisini kayıt eder:

type CXReceipt struct {
    TxHash    common.Hash
    From      common.Address
    To        *common.Address
    ShardID   uint32
    ToShardID uint32
    Amount    *big.Int
}

Hedef parça, çıplak bir makbuza güvenmez. Makbuz, bir Merkle kanıtı, kaynak blok başlığı ve kaynak komitenin bu başlık üzerindeki taahhüt (commit) imzasını taşıyan bir CXReceiptsProof içinde seyahat eder:

type CXMerkleProof struct {
    BlockNum      *big.Int
    BlockHash     common.Hash
    ShardID       uint32
    CXReceiptHash common.Hash
    ShardIDs      []uint32
    CXShardHashes []common.Hash
}

type CXReceiptsProof struct {
    Receipts     CXReceipts
    MerkleProof  *CXMerkleProof
    Header       *block.Header
    CommitSig    []byte
    CommitBitmap []byte
}

Normal doğrulama yolu, kanıtı imzalı kaynak başlığa ve onun komite imzasına karşı doğrular:

VerifyIncomingReceipts()
  -> IsSpent()
  -> ValidateCXReceiptsProof()
      -> VerifyHeaderSignature()
          -> verifySignature()
              -> DecodeSigBitmap()
              -> IsQuorumAchievedByMask()
              -> aggSig.VerifyHash()

Kaynak parça borçlandırma işlemini tam olarak bir kez gerçekleştirdiğinden, hedef parçanın her çapraz-parça makbuzunun yalnızca bir kez tüketildiğinden emin olması gerekir.

Zafiyet Analizi

Çapraz-parça uzlaştırma (settlement) yolu iki sorun içeriyordu: tüketilmiş bir makbuzun tanımlanma şeklindeki bir tekrar-koruma (replay-protection) zayıflığı ve bir pre-staking quorum doğrulama zayıflığı.

Çapraz-Parça Makbuz Tekrarı (Replay)

Tekrar-koruma mekanizması, bir makbuzun "tüketilmiş" işaretini kaydediyor ve arıyordu, ancak anahtarı Merkle kanıtının iki değiştirilebilir alanından geliyordu:

CXMerkleProof.ShardID
CXMerkleProof.BlockNum

Bloom sert çatallanması (hardfork), bunu mainnet üzerinde epoch 2964'te (13 Temmuz 2026) güçlendirdi; bu, IsCXMerkleProofReplayFixEpoch ile kontrol ediliyordu [3]: imzalı Header.Epoch()'u bu epoch'ta veya sonrasında olan bir kanıt için, IsSpent() ve WriteCXReceiptsProofSpent(), tüketilmiş-işaret anahtarını bu iki alan yerine imzalı kaynak başlıktan (Header.ShardID ve Header.Number) türetir. Ancak, güçlendirilmiş anahtarlama geriye dönük olarak hiçbir zaman uygulanmadı — Header.Epoch()'u bu çatallanmadan önceki bir kanıt için, her iki fonksiyon da eski (legacy) geri düşüş (fallback) mekanizmasını MerkleProof.ShardID ve MerkleProof.BlockNum'a koruyarak sürdürdü; ValidateCXReceiptsProof() bu epoch'lar için bunları asla imzalı başlığa bağlamadı.

Bu iki alan, yalnızca kaynak Header'ı kapsayan taahhüt imzasının (commit signature) dışında kalır. Header'ı değiştirmek VerifyHeaderSignature()'da başarısız olurdu, ancak MerkleProof.ShardID veya MerkleProof.BlockNum'ı değiştirmek hiçbir kontrolü bozmuyordu — ne başlık imzasını, ne de bu epoch'lar için bunları hiçbir zaman Header'a bağlamayan kanıt doğrulamasını. Eski tüketilmiş-işaret anahtarı bu doğrulanmamış alanlardan türetildiğinden, bir makbuzun tekrar-koruma kimliği, kanıtın kalanını doğrulayan imzadan koparıldı: aynı imzalı başlık ve makbuzları taşıyan ancak farklı MerkleProof.ShardID veya MerkleProof.BlockNum değerlerine sahip iki kanıt, tüketilmiş takip amaçları için farklı olarak değerlendiriliyordu.

Pre-Staking Quorum Kontrolü

İkinci bir hata pre-staking quorum doğrulamasını etkiledi. uniformVerifier.IsQuorumAchievedByMask() mantığı, eşiği aşağıdakiyle karşılaştırıyordu:

len(mask.Publics)

ve bunu imzalayanların sayısı olarak değerlendiriyordu. Ancak mask.Publics, gerçekte imzalayan doğrulayıcılar (validator) kümesi değil, bir parça ve epoch için tam komite açık anahtarları listesidir; gerçekte imzalayan küme, imzalayan bit haritası (signer bitmap) ile temsil edilir. Bunun sonucunda, boş bir imzalayan bit haritası bile quorum eşiğini geçebiliyordu, çünkü kontrol, etkin bit haritası bitlerini değil, komite büyüklüğünü ölçüyordu. Kimlik (tüm sıfırlar) toplu BLS imzasıyla birleştiğinde, bu durum, pre-staking dönemi bir kaynak başlığın yeterli quorum'a sahip görünmesine yol açabiliyordu.

Saldırı Analizi

Saldırgan, çatallanmadan önceki bir kaynak-parça blokundan gerçek, önceden işlenmiş bir çapraz-parça makbuzuyla başladı ve ardından yalnızca doğrulanmamış kanıt kimliğini değiştirerek onu tekrar oynattı. Sahte ONE dört istismarcı cüzdanına basıldı. Aşağıdaki analiz 0xf3d4e8b1...8242c7f ve 0x9a756ef9...b0a4d678 işlemlerine dayanmaktadır.

Adım 1: Saldırgan, çatallanmadan önceki bir kaynak-parça blokundan geçerli bir tarihsel CXReceiptsProof elde etti. Kanıt, geçerli makbuzlar, geçerli bir kaynak blok başlığı ve geçerli bir kaynak komite taahhüt imzası içeriyordu.
Adım 2: Hedef parça, bu makbuzu daha önce bir kez tüketmiş ve tüketilmiş işaretini, Merkle-kanıt alanlarından türeterek yazmıştı.
Adım 3: Saldırgan, yalnızca doğrulanmamış kanıt kimlik alanlarını değiştirdi ve imzalı başlığı ile imza tarafından kapsanan tüm alanları değişmeden bıraktı:
```
MerkleProof.ShardID
MerkleProof.BlockNum
```
Adım 4: Değiştirilmiş kanıt, sonraki bir hedef-parça blokunda gelen bir makbuz olarak sunuldu. IsSpent(), tüketilmiş-işaret anahtarını değiştirilmiş alanlardan türetti ve önceki işareti bulamadı, böylece makbuz tüketilmemiş görünüyordu.
Adım 5: ValidateCXReceiptsProof() kanıtı yine de kabul etti, çünkü değiştirilmiş kimlik alanları imza kapsamında değildi ve doğrulanmış her alan değişmeden kaldı: başlık özeti (hash) ve giden-makbuz özeti, Merkle-kanıt blok özeti ve makbuz özeti, makbuz özetleri, ve taahhüt imzası ile bit haritası.
Adım 6: ApplyIncomingReceipt() hedef parçada çalıştırıldı ve db.AddBalance(*cx.To, cx.Amount) aracılığıyla alıcıyı tekrar kredilendirdi. Kaynak parçada karşılık gelen bir borçlandırma gerçekleşmedi, çünkü orijinal çapraz-parça işlemi zaten tam olarak bir kez yürütülmüştü, bu da hedef parçada yerel ONE şişmesine (inflation) yol açtı.

Sonuç

Proje tarafından doğrulanan kök neden, protokol seviyesinde bir tekrar-koruma başarısızlığıydı: bir çapraz-parça makbuzunun tüketilmiş-durum kimliği, imzalı kaynak başlığı yerine doğrulanmamış kanıt alanlarından türetiliyordu, bu nedenle zaten işlenmiş bir makbuz ikinci kez kredilendirilebiliyordu. Harmony ayrıca ayrı bir pre-staking quorum doğrulama hatasını da doğruladı, ancak kamuya açık bildirimler saldırganın burada bunu kullanıp kullanmadığını belirlemiyor.

Yamalar her iki açığı da kapatıyor [4][5][6]. Daha genel olarak, bir zincir uygulaması, zaten tüketilmiş durumu (state) tanımlamak için kullandığı her alanı doğrulamalıdır ve quorum'u tam komiteye göre değil, gerçekte imzalayan doğrulayıcılara göre değerlendirmelidir.

Referanslar

BlockSec Hakkında

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

BlockSec, saygın konferanslarda birçok blok zinciri güvenliği makalesi yayınlamış, DeFi uygulamalarının çeşitli sıfırıncı gün (zero-day) saldırılarını bildirmiş, 20 milyon doların üzerinde kurtarma sağlamak için çeşitli hack girişimlerini engellemiş ve milyarlarca dolarlık kripto para birimini güvence altına almıştır.