Ethereum(ETH) düğüm güvenliği güncellendi: İkili kurulumlarda Java kontrolü

Ethereum düğüm istemcileri Teku ve Besu, eMudhra sertifika otoritesindeki güvenlik olayının ardından Docker imajlarındaki güven listelerini değiştirdi. İkili dosyalarla kurulum yapan operatörlerin ayrı Java çalışma zamanındaki sertifika deposunu da kontrol etmesi gerekiyor.

Teku ekibi, güvenlik düzeltmesini içeren 26.10.3 sürümünü 27 Ekim’de önerilen güncelleme olarak yayımladı. Besu da 26.10.2 sürümünde ilgili güven listesini değiştirdi; düzeltme yalnızca Docker imajlarına uygulanıyor.

İki güncelleme de Docker imajlarından emSign ECC Root CA - G3, emSign Root CA - G1, emSign Root CA - G2 ve AAA Certificate Services’a duyulan güveni kaldırdı. Besu ekibi, G1’in kaldırılmasının önleyici bir tedbir olduğunu belirtti.

Bu adımlar, eMudhra’nın oluşturduğu bir ara sertifika otoritesinin özel anahtarının açık sertifikalardan elde edilebildiğinin ortaya çıkmasının ardından atıldı. Bu anahtarla oluşturulan sertifikalar, sorun giderilmemiş Java çalışma zamanlarında geçerli sertifikalar gibi kabul edilebilir.

eMudhra, 26 Ekim tarihli açıklamasında bir betik hatasının zayıf anahtara sahip bir ara sertifika otoritesi oluşturduğunu bildirdi. Şirket, sorunu tespit ettikten sonra 14 saat içinde bu otoriteyi iptal ettiğini, incelemede kendi altyapısının ve müşteri verilerinin ihlal edilmediğini açıkladı.

Mozilla’nın olay kaydında bir katılımcı, sorunlu altı anahtarla imzalanmış 107.107 sertifikanın 20 Ekim Kore saatiyle 18.40 ile 22 Ekim 07.02 arasında e-Szignó kayıtlarında yer aldığını yazdı. Bunların 106.050’si tek bir alan adı için hazırlanmış kavram kanıtlama sertifikalarıydı.

eMudhra, sorunlu ara sertifika otoritesi üzerinden kamuya açık, güvenilir son kullanıcı sertifikaları vermediğini söyledi. Mozilla kaydında başka bir tarafın sorunlu anahtarlarla imzaladığı sertifikalar da yer alıyor; bu nedenle iki açıklamadaki sayılar aynı toplamı ifade etmiyor. Kayıtlarda bir sertifikanın bulunması, onun gerçek bir saldırıda kullanıldığını da göstermiyor.

Sertifikalar, HTTPS bağlantılarında karşı sunucunun kimliğini doğrulamak için kullanılıyor. Java varsayılan olarak sertifikaların iptal edilip edilmediğini kontrol etmediğinden, ilgili kök sertifika otoritesi güven deposunda kalırsa yalnızca iptal işlemi bağlantıyı engellemeyebilir.

Teku ekibi, ayarlarında HTTPS adresi bulunmayan varsayılan ana ağ düğümlerinin etkilenmediğini bildirdi. Risk değerlendirmesi düğüm istemcisinin adına göre değil, gerçek bağlantı ayarlarına bakılarak yapılmalı.

Yama uygulanmamış Java çalışma zamanı kullanan ve harici imzalayıcıya, uzak beacon node’a, execution client’a ya da builder’a HTTPS üzerinden bağlanan sistemlerde risk oluşabilir. Sunucuyu taklit etmek için saldırganın iletişimi araya girerek kesebilmesi gerekir.

Sertifika otoritesi kullanmayan düğümler arası P2P iletişimi bu sorundan etkilenmiyor. Teku ekibinin açıkladığı kapsam tüm düğüm bağlantılarını değil, sertifika güvenine dayanan HTTPS bağlantılarını içeriyor.

Besu’da ayrıca kontrol edilmesi gereken bir ayar var: --rpc-http-tls-ca-clients-enabled etkinleştirildiğinde, Java’nın varsayılan güven deposundaki otoritelerin imzaladığı istemci sertifikaları kabul ediliyor. Besu ekibi bu ayarı yüksek riskli olarak sınıflandırdı.

Bu ayar etkinse saldırganın RPC portuna erişebilmesi durumunda, iletişimi araya girerek kesmesine gerek kalmadan sorun ortaya çıkabilir. Varsayılan ayarlardaki Besu düğümleri etkilenmiyor; Besu ekibi gerçek bir istismar vakası bildirilmediğini söyledi.

Docker imajları kendi Java çalışma zamanını içerdiğinden ana bilgisayardaki Java’yı güncellemek konteyner içindeki çalışma zamanını değiştirmiyor. Teku’nun ikili dağıtımları ile Besu’nun tar ve zip paketleri operatörün kurduğu Java’yı kullanıyor. Bu nedenle operatörler kurulum yöntemini, çalışan Java sürümünün sertifika deposunu ve HTTPS/TLS ayarlarını ayrı ayrı kontrol etmeli.