BTCPay, açık kaynaklı ve kendi sunucusunda çalışan bir ödeme işleme platformu olarak, işletmelerin Bitcoin ve Lightning ödemelerini aracı veya ek ücret olmadan kabul etmesini sağlıyor. Platform, Namecheap gibi alan adı sağlayıcılarından donanım cüzdan üreticisi Foundation’a ve bağımsız yayınlara kadar geniş bir kullanıcı kitlesine hizmet veriyor. 2020 ile 2024 arasında Namecheap, BTCPay üzerinden 73 milyon dolarlık Bitcoin geliri elde etti. BTCPay, Bitcoin ödemelerini en fazla egemenlik sunan yöntem olarak öne çıkarıyor.
Ancak bu egemenlik modelinin gizli bir maliyeti var. BTCPay kendi sunucusunda çalıştığı için, kullanıcılar adına merkezi bir operatörün güvenlik yamalarını otomatik olarak uygulaması mümkün değil. Her işletme, borsa ve cüzdan altyapısı kendi sunucusunu kendi takvimine göre güncellemek zorunda. Kritik bir güvenlik açığı aktif olarak istismar edildiğinde, bazı operatörler hızlıca yama yaparken, diğerleri saldırıya uğradıklarını fark etmeden zarar görebiliyor.
Son güvenlik açığı, kimlik doğrulaması gerektirmeyen uzaktaki bir saldırganın BTCPay Server örneğine erişerek .macaroon dosyalarını çalmasına olanak tanıdı. Macaroon’lar, Lightning Network Daemon (LND) tarafından API kimlik doğrulaması için kullanılan kimlik bilgisi dosyaları. Bu dosyaya sahip olan kişi, ilgili Lightning node’unu tamamen kontrol edebiliyor; kanalları kapatabiliyor, ödeme gönderebiliyor ve bakiyeyi boşaltabiliyor.
BTCPay, fonların çalındığını doğruladı. Donanım cüzdan üreticisi Foundation’ın Lightning node’u bir gecede boşaltıldı. Bitcoin yayını Citadel21 de benzer şekilde zarar gördü. Her iki durumda da hırsızlıklar, kamuya açık uyarı yapılmadan önce gerçekleşti. Kaç node’un etkilendiği veya toplamda ne kadar fonun çalındığına dair resmi bir rakam paylaşılmadı.
Bu olayın ardından yaşananlar, standart bir yama sürecinden daha karmaşık. Çünkü macaroons dosyaları, yazılım güncellense bile diskte kalmaya devam ediyor. Yani, saldırı sırasında bu dosyaları ele geçiren kişiler, operatör kök anahtarı silip tüm kimlik bilgilerini yeniden oluşturana kadar node’a erişimini sürdürebiliyor. Sadece yazılımı güncellemek, macaroons dosyalarını döndürmeden tam bir çözüm sağlamıyor.
Açığın keşfi: Otomatik tarama değil, kayıp yaşayan bir geliştirici
Bu güvenlik açığı, otomatik tarama araçlarıyla tespit edilmedi. Sparrow Wallet’ın geliştiricisi Craig Raw, kendi sunucusunda yaşadığı kaybı analiz ederek açığı ortaya çıkardı.
BTCPay’in kurucusu Nicolas Dorier, “Bir geliştiricinin kayıp yaşaması ve logları analiz ederek sorunu anlaması bizim için büyük bir şanstı. Bu açık, otomatik AI taramalarında tespit edilmedi, ancak yaşanan kayıpla ortaya çıktı.” dedi. Kimlik doğrulama katmanlarındaki mantık hatalarının otomatik araçlar tarafından yakalanmasının zorluğu biliniyor. Ancak bu durum, Bitcoin’in açık kaynaklı altyapısının güvenlik araçlarının gelişim hızından daha hızlı büyüdüğünü ve aradaki boşluğun, operatörlerin kendi kayıp raporlarını incelemesiyle kapatıldığını gösteriyor.
BTCPay’deki bu açık, aynı hafta Coldcard donanım cüzdanlarında Mart 2021’den kalan bir firmware hatasının istismar edilmesiyle 1.719 BTC (yaklaşık 111 milyon dolar) çalınmasıyla gündeme geldi. Bu hata, bazı cihazlarda anahtar gücünü 128 bitten 40 bite kadar düşürerek fiziksel erişim olmadan brute-force saldırılarına açık hale getirdi.
Her iki olay da Bitcoin protokolünü etkilemedi. Saldırılar, protokolün etrafında inşa edilen cüzdanlar, ödeme işlemcileri ve altyapı katmanlarını hedef aldı. Gerçek paranın Bitcoin’in uygulama katmanında daha fazla dolaşmasıyla, saldırı yüzeyinin bireysel operatörlerin güvenlik kapasitesinden daha hızlı genişlediği dikkat çekiyor.
Uzaktan erişim kısıtlamasının anlamı
Gündeme yansıyan adım, BTCPay’in 2.4.2 sürümünde Docker dağıtımlarında LND API’sine dışarıdan erişimi geçici olarak kapatması oldu. Bu, operatörler kimlik bilgilerini döndürüp yamaları uygulayana kadar saldırı etkisini sınırlamayı amaçlıyor. Artık BTCPay domain’i veya Tor adresi üzerinden bağlanan harici cüzdanlar Lightning API’ye erişemiyor.
Bu bağlantıya bağımlı olan işletmeler için bu durum bir kesinti anlamına geliyor. Kendi reverse proxy’sini, yönlendirilmiş portunu veya BTCPay dışında bir harici yolu kullananlar için ise kısıtlama geçerli değil. Ancak bu kullanıcıların da kimlik bilgilerini manuel olarak döndürmesi gerekiyor; çünkü BTCPay’i güncellemek, ayrı yönetilen erişim yollarını kapatmıyor.
BTCPay, bu değişikliğin geçici olduğunu ve güvenlik sağlandığında uzaktan erişim seçeneğini yeniden sunmayı planladığını belirtiyor. Ancak asıl soru, uzaktan cüzdan erişiminin geri gelip gelmeyeceğinden ziyade, kendi sunucusunda çalışan modelin mevcut ödeme hacmini sürdürebilecek kapasitede olup olmadığı.
Burada net bir çözüm yok. Bitcoin ödemelerini kendi sunucusunda kabul etmek, güveni en aza indiren yöntem. Node’unuzu, anahtarlarınızı, Lightning kanallarınızı ve mutabakat yolunuzu tamamen siz kontrol ediyorsunuz. Hiçbir şirket bakiyenizi donduramaz, işlemlerinizi reddedemez veya verilerinizi sizin onayınız olmadan bir düzenleyiciye iletemez. BTCPay’in varlık nedeni de bu ve bu sayede yüzlerce işletme, çeşitli cüzdan altyapıları ve büyüyen bir kullanıcı tabanı oluştu.
Ancak kendi sunucusunda çalıştırmak, aynı zamanda tek savunma hattı olmanız anlamına geliyor. Kritik bir açık ortaya çıktığında, güvenliğiniz; uyarıyı fark etmenize, sunucunuzu güncellemenize, kimlik bilgilerinizi döndürmenize ve node’unuzda yetkisiz bir işlem olup olmadığını denetlemenize bağlı. Tüm bunlar, saldırganlar aktifken gerçekleşmek zorunda. Merkezi bir güvenlik ekibi, olay müdahale planı veya otomatik yama dağıtımı yok. Sadece bir blog yazısı, bir sürüm numarası ve sonrasında yaşanacaklar var.
Bu durum, kendi sunucusunda çalıştırmaya karşı bir argüman değil. Asıl mesele, bu modelin ölçekli kullanımda neler gerektirdiğini anlamak. Gerçek ticaret hacmi arttıkça – sadece Namecheap üzerinden 73 milyon dolar ve tüm BTCPay kullanıcıları toplamında çok daha fazlası – bireysel operatörlerin güvenlik yükü artık amatör bir uğraş olmaktan çıkıyor ve operasyonel bir risk haline geliyor.
Sonraki adımlar
BTCPay, kapsamlı bir olay incelemesi (postmortem) yayımlayacağını açıkladı. 2.4.2 sürümü ayrıca Greenfield API’deki iki faktörlü kimlik doğrulama atlatma açığını kapatıyor ve hesap oluşturulduktan beş dakika sonra Basic Authentication’ı varsayılan olarak devre dışı bırakıyor. Böylece ilgili açıkların etkisi azaltılıyor. Ayrıca, herkese açık fatura oluşturma işlemleri sınırlandırıldı ve dokuz kontrolcü metodu yönlendirilemez olarak işaretlendi; böylece yanlışlıkla HTTP üzerinden erişilebilen uç noktalar kapatıldı.
Bunlar iyi birer önlem. Ancak asıl soru yapısal: Bitcoin’in ödeme altyapısı büyüdükçe, güvenlik maliyetini kim üstlenecek? Eğer yanıt hâlâ “herkes kendi sunucusunu çalıştırıp kendisi günceller” ise, bu model ancak her operatörün yeterli zamanı, uzmanlığı ve dikkati olduğu sürece çalışabilir. Kullanıcı tabanı genişledikçe ve riskler büyüdükçe bu sürdürülebilir olmayabilir.
Bitcoin Red Team’in AI destekli denetimi önemli bir adım oldu ve birçok açık tespit edildi. Ancak aktif olarak istismar edilen bu açık gözden kaçtı. Otomatik araçların görebildiğiyle, sadece kendi kayıp raporlarını inceleyen operatörlerin bulabildiği arasındaki bu fark, en yakından izlenmesi gereken nokta.
Şu anda odaklanılan konu, BTCPay’in yayımlayacağı olay incelemesinin bu açığın haftalarca mı yoksa aylarca mı var olduğunu ortaya koyup koymayacağı ve Bitcoin Red Team’in açık kaynaklı güvenlik araçlarının bu tür kör noktaları kapatıp kapatamayacağı. Çünkü eğer kapatamazsa, bir sonraki istismarın tespit edilmesi için yine birinin zarar görmesi gerekecek.
Bu içerik hazırlanırken faydalanılan kaynaklar: ainvest.com
