Binance’in 6,3 milyar dolarlık olayı: ne oldu ve risk nasıl azaltılır

Binance’in ön bulguları, haziran ve eylül aylarında çalışanların sistemlerinin ele geçirilmesini, ardından 20 Ekim’de şirket içi yapay zekâ araçları üzerinden daha geniş bir sızmayı anlatıyor. Saldırganlar iki iş arkadaşının bilgisayarına ulaştı ve konteyner dağıtımı için kullanılan bir token buldu. 29 Ekim’de bu token ile cüzdan imzalama sistemlerine ulaşan ve yetkisiz transferleri başlatan kötü amaçlı kod dağıttılar.

Saldırganlar imzalama hizmetini kullanarak bir EIP-7702 yetki devri de oluşturdu. Bu, saldırganın denetimindeki kodun bir Ethereum cüzdanı adına işlem yapmasına izin veriyordu. Söz konusu izin, Binance’in para çekme sistemlerinden bağımsız olarak blokzincir üzerinde bulunuyordu. Para çekme işlemlerinin durdurulması izni kaldıramadı. Binance’in blokzincir üzerinde ayrı bir iptal işlemi yapması gerekti.

Buradaki önemli ayrım, bir faaliyeti durdurmak ile onu mümkün kılan yetkiyi kaldırmak arasındadır. Bir cihazı değiştirmek, bir dağıtım kimlik bilgisini iptal etmek ve başka bir sistemdeki bir izni kaldırmak, sızmanın farklı bölümlerini ele alır.

Bir dizüstü bilgisayar, bir dağıtım sistemi ve hassas bir hizmet farklı işler yapar. Birine erişim otomatik olarak bir sonrakini açtığında risk büyür. Çalınan bir token, saldırganın yazılımı değiştirmesine izin verebilir. Bu yazılım daha sonra çalışanın doğrudan hiçbir zaman sahip olmadığı yetkilerle hareket edebilir.

Dört soru, bu ilerleyişin nerede kesilebileceğini belirlemeye yardımcı olur:

1. Kimlik bilgilerinin açığa çıkması. Bir saldırgan, tek bir çalışanın cihazından üretim ortamına nasıl bir erişim elde edebilir?
2. Dağıtım yetkileri. Bu erişimle çalışan kodu kim değiştirebilir?
3. Hizmet yetkilendirmesi. Hassas bir hizmet, bu koddan hangi işlemleri kabul eder?
4. Kalıcı erişim. İlk hesap devre dışı bırakıldıktan sonra hangi yeni izinler kalabilir?

Amaç, yetkinin sistemler arasında nasıl aktarıldığını sınırlamak ve sızma sırasında oluşturulan her ek erişimi belirleyip iptal etmektir. Sonraki bölümlerde bu amacı destekleyen dört denetimi inceliyoruz.

Denetim 1. Bir dizüstü bilgisayarın açığa çıkarabileceği kimlik bilgilerini azaltın

Bir kimlik bilgisi saldırgan için değerlidir, çünkü başka bir sistem onu yetki kanıtı olarak kabul eder. Çalışanların cihazlarında daha az üretim kimlik bilgisi bulundurmak, bir araç, depo veya tarayıcı oturumu ele geçirildiğinde çalınabilecek bilgileri azaltır.

Rutin işlerde bir çalışan çoğu zaman bir hizmeti yeniden başlatmak gibi bir işlemi talep etme iznine ihtiyaç duyar. İşlemi gerçekleştiren kimlik bilgisi, ayrı bir yürütme kimliğinde kalabilir. Açığa çıkma riskini azaltmak hem gereksiz kopyaları kaldırmayı hem de kalan kimlik bilgilerini yönetmeyi gerektirir:

• Uygun olduğunda rutin doğrudan erişimin yerine kapsamı dar biçimde tanımlanmış işlemler koyun.
• Farklı görevler için ayrı kimlikler kullanın, kapsamlarını ve geçerlilik sürelerini sınırlayın.
• Kimlik bilgilerinin, sahiplerinin ve nasıl iptal edileceklerinin envanterini tutun.

Bu yaklaşım, OWASP’ın gizli bilgi yönetimi rehberindeki ilkeyi uygular: insanların gizli bilgilerle doğrudan temasını azaltın ve her kimliğe yalnızca ihtiyaç duyduğu erişimi verin. Böylece çalınan bir iş istasyonu daha az yeniden kullanılabilir kimlik bilgisi açığa çıkarır ve müdahale ekibi hâlâ iptal edilmesi gerekenlerin kime ait olduğunu bilir.

Denetim 2. Dağıtım haklarını üretim yetkileri olarak değerlendirin

Bir gizli bilgi bir kişiden saklanırken o kişinin dağıttığı koda sunulabilir. Bu kodu değiştirebilen biri gizli bilgiyi okuyabilir, bir iç API’yi çağırabilir veya uygulamanın hizmet hesabı olarak hareket edebilir. Bu nedenle dağıtım erişimi, ortaya çıkan iş yükünün izinlerine göre değerlendirilmelidir.

OWASP’ın CI/CD güvenliği rehberi, depo değişikliklerini, işlem hattı yapılandırmasını ve yürütme sunucularını aynı güvenlik sorununun parçaları olarak ele alır. Koruma, dağıtım öncesindeki kodu ve dağıtım sonrasındaki izinlerini kapsamalıdır:

• Üretim kodu için inceleme şartı koyun ve otomasyonun çalıştırdığı depo dalını koruyun.
• Ana betiğin yanı sıra görev tanımlarındaki, bağımlılıklardaki ve başlatma girdilerindeki değişiklikleri de denetleyin.
• İş yüklerine yalnızca işlevleri için gereken kimlik bilgilerini ve ağ erişimini verin.

İki denetim grubu birlikte çalışmalıdır. Depo ve dağıtım izinleri kodu kimin değiştirebileceğini belirler. Ayrı kimlik, sunucu ve ağ politikaları ise kod çalışmaya başladığında neler yapabileceğini sınırlar. Merkezi gizli bilgi depolaması açığa çıkma riskini azaltırken bu politikalar gizli bilgiyi kullanan programı sınırlar.

Denetim 3. Yalnızca çağıranı değil, işlemi de yetkilendirin

Bir imzalama hizmeti özel anahtarını gizli tutarken zararlı bir imzalama isteğini yine de kabul edebilir. Aynı ayrım bir veritabanı veya bulut API’si için de geçerlidir: bir iş yükünün kimliğini doğrulamak çağıranı belirler, yetkilendirme ise neler yapabileceğine karar verir.

OWASP her istekte yetkilendirmenin kontrol edilmesini ve açıkça izin verilmedikçe erişimin reddedilmesini önerir. İsteği alan hizmette bu, hem işlemi hem de hedefini kontrol etmek demektir: izin verilen ödeme alıcıları ve tutarları, veritabanı işlemleri veya altyapı değişiklikleri.

Sonuç, çağırana zaten güvenilse bile istenen işlemi değerlendiren bir hizmet olmalıdır. Otomasyon, işin nasıl talep edildiğini yönetir. Hedef hizmet ise hangi işlemleri kabul edeceğini yönetir.

Denetim 4. Sızma sırasında oluşturulan erişimi iptal edin

Bir saldırgan, başka bir kimlik bilgisi eklemek veya ek izinler vermek için meşru bir kimliği kullanabilir. MITRE ATT&CK, hesap manipülasyonunu, bulut kimlik bilgileri ve SSH anahtarları eklemek de dâhil olmak üzere erişimi korumanın veya artırmanın bir yolu olarak belgeler. İlk oturumu devre dışı bırakmak bu değişiklikleri mutlaka kaldırmaz.

Binance’in blokzincir üzerindeki yetki devri, müdahale ekiplerinin neden izinleri doğrudan etkilenen sistemde incelemesi gerektiğini gösterir. Olayın kontrol altına alınması, hem ilk giriş noktasını hem de onun üzerinden oluşturulan yetkiyi kapsamalıdır:

• Hangi otomasyon kimliklerinin ek kimlik bilgileri oluşturabileceğini veya izin verebileceğini sınırlayın.
• Müdahale planına yeni oluşturulan hesapları, oturumları ve yetki devirlerini ekleyin.
• Durdurulmuş bir görevi olayın kontrol altına alındığının kanıtı saymak yerine, iptali izni uygulayan sistemde doğrulayın.

Bu adımlar, müdahale ekiplerine araştırılacak ve iptal edilecek belirli bir kimlik ve izin kümesi sunar. Ayrıca kontrol altına alma sürecini test edilebilir kılar: ekip, etkilenen hizmete giden bilinen her yolun gerçekten kapatıldığını kontrol edebilir.

Bu denetimler farklı katmanlarda çalışır: çalışanın cihazı, dağıtım sistemi, hedef hizmet ve müdahale süreci. Her katmanın bir sorumlusu ve başka bir katman ele geçirildiğinde kendi kısıtlarının geçerliliğini doğrulama yolu olmalıdır.

Otomasyon yönetim platformları, bu sorunun bir çalışanın isteği ile üretimde yürütme arasındaki bölümünü ele alır. Semaphore UI’da bir ekip tanımlı bir görev hazırlayabilir, kimin çalıştırabileceğini veya değiştirebileceğini denetleyebilir ve görevi ayrı bir kimlikle yürütebilir. Hedef hizmet içindeki yetkilendirme ve başka yerlerde oluşturulmuş izinlerin iptali, ilgili sistemlerin ve müdahale ekibinin sorumluluğunda kalır.

Bir API hizmetini yeniden başlatması gereken nöbetçi bir mühendisi düşünün. Bir bakım sorumlusu, hedef sunucuları ve yeniden başlatmanın nasıl yapılacağını sabitleyen bir playbook ile Task Template hazırlar. Mühendis, üretime SSH oturumu açmadan görevi başlatır ve sonucu okur. Aşağıdaki iki yol aynı yeniden başlatmayı gerçekleştirir, ancak yürütme kimlik bilgisini farklı taraflarda tutar.

Yeniden başlatma akışını oluşturmak birbiriyle bağlantılı dört adım gerektirir: kısıtlı bir yürütme kimliği oluşturmak, kullanıcıların neleri çalıştırabileceğini veya değiştirebileceğini tanımlamak, yürütme ortamını seçmek ve sonucu görünür kılmak. Bu adımlar tamamlandığında aynı yaklaşım dağıtımlara da genişletilebilir.

Çalınan bir operatör oturumu, hesabın çalıştırmasına izin verilen işlemleri hâlâ talep edebilir. İzin verilen bir yeniden başlatma bile tekrar tekrar tetiklendiğinde hizmeti aksatabilir. Yapılandırılmış akışı gerçekçi bir operatör hesabıyla hazırlık ortamında test edin. Hem neler yapabildiğini hem de ekibin kötüye kullanıma nasıl yanıt vereceğini ele alın:

• Görev ve girdi izinleri. Alternatif dallar, envanterler ve argümanlar dâhil olmak üzere gerçek rolleri ve başlatma seçeneklerini deneyin.
• Amaçlanan işlemin ötesinde erişim. Runner sürecinin ulaşabildikleri de dâhil olmak üzere diğer şablonlara, kimlik bilgilerine ve üretim sistemlerine erişimi kontrol edin.
• Tespit ve operasyonel etki. Sonuçları kimin aldığını, beklenmeyen faaliyetleri kimin araştırdığını ve tekrarlanan çalıştırmaların kabul edilemez aksamalara yol açıp açamayacağını doğrulayın.
• İptal. Oturum ve token iptalini test edin, yürütme kimliğinin başka yerlerde oluşturabileceği izinleri belirleyin.

Test hesabının koruduğu erişimi belgeleyin ve işlemin amacını aşan tüm yolları kapatın. Ekip, bu alıştırmayı hem çalınan bir oturumun neler yapabileceğini hem de bu kötüye kullanımın nasıl tespit edilip kontrol altına alınacağını bilerek tamamlamalıdır.

Erişim denetimleri, uç nokta koruması ve nasıl müdahale edeceğini bilen bir ekiple birlikte çalışır. Hazırlanan akışı, insanların ortak anahtarlara ve belgelenmemiş kestirme yollara dönmeden kullanabileceği kadar pratik hâle getirin. Birkaç günlük uygulamayla destekleyin:

• Tanımadığınız kurulum araçlarını ve iş görüşmesi ödevlerini, kurumsal kimlik bilgileri, ana makineden bağlanmış dizinler veya iç ağ erişimi bulunmayan, tek kullanımlık yalıtılmış ortamlarda çalıştırın.
• Şüpheli faaliyetlerin erken ve suçlama olmadan bildirilmesini kolaylaştırın. İnsanlara açık bir iletişim noktası ve olay müdahale yolu sunun.
• Görevler değiştikçe erişimi gözden geçirin, kontrollü bir acil erişim prosedürü sürdürün ve olay yaşanmadan önce iptal işlemlerini prova edin.

Bu uygulamalar, önleme, tespit ve kurtarmayı günlük işlerle ilişkilendirir. Sorumluluklar değiştikçe erişim modelinin doğru kalmasına yardımcı olur ve şüpheli bir olay yaşandığında ekibe tanıdık bir müdahale yolu sunar.

Temel ders, ele geçirilmiş tek bir kimliğin ne kadar yetki biriktirebileceğini sınırlamaktır. Dizüstü bilgisayarlarda daha az kimlik bilgisi, incelenmiş otomasyon, kısıtlı yürütme sunucuları ve üretim hizmetlerindeki yetkilendirme, saldırganın izleyebileceği yolları azaltır.

Semaphore bu denetimlerin birkaçını tekrarlanabilir bir akışın parçası hâline getirir: hazırlanmış görevler, ayrı çalıştırma ve düzenleme izinleri, merkezden sağlanan kimlik bilgileri ve görünür yürütme kayıtları. Operatörler işlerinin gerektirdiği işlemleri alırken bakım sorumluları bunların arkasındaki kodun ve kimlik bilgilerinin denetimini korur.

Sık kullanılan bir üretim işlemiyle başlayın: görev şablonunu hazırlayın, gerekli operatör izinlerini atayın ve yerine geçtiği doğrudan bağlantıyı kaldırmadan önce ortaya çıkan erişimi test edin. İlerlemenin yararlı ölçüsü, saldırganın bir sonraki ele geçirdiği hesapla ne kadar az şey yapabildiğidir.