300'den Fazla Tor Çıkış Rölesine El Konularak SSH Şifreleri Çalındı

Bir güvenlik araştırmacısının tespitine göre, saldırganlar Ekim ayının başında 300'den fazla Tor çıkış rölesinin kontrolünü ele geçirdi ve bu röleleri SSH bağlantılarını kendi sunucularına yönlendirmek için kullandı. 1-5 Ekim tarihleri arasında Tor üzerinden bir SSH sunucusuna şifre ile bağlanan ve araya giren sunucunun host anahtarını kabul eden kullanıcıların giriş bilgileri çalınmış olabilir.

Saldırı Nasıl Kurgulandı?​

Tor ağında çıkış röleleri, trafiğin ağdan çıkıp gerçek hedefe ulaştığı son halkayı oluşturur. Saldırganlar, ele geçirdikleri rölelerin yapılandırma dosyalarını (torrc) değiştirerek SSH trafiğine karşılık gelen 22 numaralı porta erişimi açtı. Daha önce bu portu engelleyen 342 röle yeniden yapılandırıldı; exit özelliği bulunmayan 24 röle ise exit konumuna getirildi. Aynı değişiklik kapsamında şifreli posta portları IMAPS ve POP3S kapatılırken POP3 ve IMAP gibi düz metin destekli portlar büyük çoğunluğunda açıldı.
Kaba takma adıyla yayın yapan araştırmacı, 2 Ekim'de Tor üzerinden bir SSH bağlantısı kurduğunda host anahtarının değiştiğine dair uyarı aldı. Bunun üzerine exitmap aracını kullanarak yaklaşık 3.000 çıkış rölesinin tamamını taradı ve 333 rölenin SSH trafiğini aynı 12 araya girme sunucusuna yönlendirdiğini belirledi. Genel dizin verilerine dayanan ayrı bir analizde ise 59 farklı operatöre ait 377 rölenin 1-4 Ekim tarihleri arasında saldırganın çıkış politikasına geçtiği saptandı.

Şifreler Nasıl Ele Geçirildi?​

Araya girme sunucusu, bağlantıyı kesen kullanıcıya kendi host anahtarını sundu. Gerçek sunucunun anahtarını daha önce bilen kullanıcılar OpenSSH'ın "uzak host kimliği değişti" uyarısıyla karşılaşırken ilk kez bağlananlar yeni bir anahtarı kabul etmek için standart bir istemle karşılaştı. Anahtarı kabul edip şifresiyle giriş yapan kullanıcı, şifresini araya giren sunucuya teslim etmiş oldu. Araya giren sunucu gerçek sunucuya bağlanmayı sürdürdüğünden oturum normal görünüyordu; bu sırada her komut izlenebilir hale geldi. Çalınan şifreyle ayrıca sudo yetkisi denetlendi ve base64 kodlu bir Perl yükleyicisi çalıştırıldı.
Anahtar tabanlı SSH girişleri bu yöntemle ele geçirilemedi. SSH kimlik doğrulama protokolü gereği istemcinin imzası her oturuma özgü bir tanımlayıcı içerdiğinden, araya giren sunucu için üretilen imza gerçek sunucuya karşı işe yaramaz. Şifre ise oturum içinde şifreli biçimde iletildiğinden ve oturumun karşı ucundaki sunucu —bu durumda araya giren sunucu— tarafından okunabildiğinden doğrudan ele geçirilebilir.

Quetzalcoatl Ailesi ve Ebury Arka Kapısı​

Etkilenen röle ailelerinin en büyüğü olan Quetzalcoatl'ı yöneten Zimmer, 7 Ekim'de yayımladığı olay sonrası analizde iki sunucusunda Ebury 1.8.3 sürümünün bulunduğunu açıkladı. Ebury, 2009'dan bu yana aktif olan ve OpenSSH içine yerleşen bir arka kapı ile kimlik bilgisi çalma yazılımıdır. ESET'in 2024 yılında yayımladığı rapora göre Ebury, 2009-2023 yılları arasında 400.000 sunucuya bulaşmış; 2023 sonu itibarıyla 100.000'den fazla sunucu hâlâ enfekte durumdaydı.
Zimmer'ın aktardığına göre saldırgan, 28 Ağustos'ta yönetim sunucusuna operatör hesabının şifresiyle ilk denemede giriş yaptı, beş dakika içinde root yetkisi elde etti ve Ebury'yi kurdu; ardından bir saatten kısa süre içinde ikinci sunucuya da sızdı. Zimmer, temel nedenin kendi hatalarından kaynaklandığını belirtti: SSH girişi, sudo ve yedek parolasında aynı şifre kullanılmış, bu şifre her iki sunucuda da düz metin olarak saklanmış ve internet'e açık yönetim sunucusunda SSH şifre doğrulaması etkin bırakılmıştı. Saldırganın bu şifreye nasıl ulaştığı bilinmiyor. 2 Ekim'de çıkış yapılandırma dosyaları, günlüklerde herhangi bir giriş, sudo komutu veya cron görevi izi bırakmadan yeniden yazıldı. İki röle 09:34 UTC'de saldırganın politikasını yayımlamaya başladı ve bu durum yaklaşık 52 saat sürdü.
Zimmer ayrıca "çevrimdışı" olduğunu sandığı ana anahtarların aslında çevrimdışı olmadığını ortaya koydu: Kopyalar, yönetim sunucusundaki çalışma istasyonu yedeğinde bulunuyordu ve saldırganın zaten ele geçirdiği şifreyle şifrelenmişti. Zimmer, ailedeki tüm röleleri ve köprüyü devre dışı bırakarak her iki sunucuyu da sildi.

Tor Projesi'nin Müdahalesi ve Etkilenen Rölelerin Tespiti​

Kaba, bulgularını 2 Ekim akşamı Tor Projesi'nin ağ sağlığı ekibine iletti. Ekip, politika değişikliğini kendi izleme sistemleriyle de fark etmişti. 4 Ekim'de Quetzalcoatl ailesiyle iletişime geçildi; Zimmer, değişikliğin kendisinden kaynaklanmadığını doğrulayarak rölelerin kötü olarak işaretlenmesini istedi ve sunucularında Tor'u durdurdu. Dizin yetkilileri aynı gün 18:00 UTC'de etkilenen rölelere BadExit ve MiddleOnly bayraklarını oylamaya başladı; bayraklar 21:00 UTC'de mutabakatta yerini aldı. BadExit bayrağı, Tor istemcilerinin söz konusu röleyi hiçbir zaman çıkış olarak kullanmaması anlamına gelir. 5 Ekim sabahı Quetzalcoatl'a ait 55 sunucuda betikle yeniden başlatma gerçekleşti; saldırganın politikası hâlâ yerindeydi. Bunu kimin başlattığı bilinmiyor. Dizin yetkilileri o saatte etkilenen röleleri ağdan reddetmeye başlamıştı ve 5 Ekim 17:00 UTC itibarıyla saldırganın politikasını taşıyan hiçbir röle mutabakatta kalmamıştı. 9 Ekim'e kadar da geri dönen olmadı.
Zirve noktasında, 4 Ekim'de, saldırganın çıkış politikasını taşıyan rölelerin Tor'un çıkış kapasitesindeki ağırlıklı payı yüzde 7,46'ya ulaşmıştı. Tor Metrics verilerine göre Exit bayrağı taşıyan röle sayısı 3-5 Ekim arasında yaklaşık 370 azaldı ve 18 Ekim itibarıyla bu düşüş telafi edilemedi.

Diğer Operatörlerin Nasıl Ele Geçirildiği Sorusu Açık​

Quetzalcoatl ailesinin dışındaki 58 operatörün sunucularına nasıl girildiği henüz netlik kazanmadı. Dizin verisi analizine göre 1 Ekim'de listelenen rölelerin 71'i FranTech Solutions (BuyVM markası) üzerinde barındırılıyordu ve bu rölelerin tamamına yakını saldırganın politikasına geçti; başka ağlarda barındırılan 9.054 röleden yalnızca 13'ü etkilendi. 21 operatöre ait 40 röle, 1 Ekim'de beş buçuk dakika içinde —çoğunlukla yapılandırma yeniden yükleme yoluyla— değişti; bu durum, tek bir aktörün tüm 40 sunucuya önceden erişim sağlamış olduğuna işaret ediyor. ESET adına Ebury araştırmalarını yürüten Marc-Etienne M. Léveillé, şifrenin ele geçirilmesi için en olası senaryonun zaten Ebury çalıştıran bir sunucudan gerçekleştirilen bir giriş olduğunu; barındırma sağlayıcısının ele geçirilmesinin ise bir diğer olasılık olduğunu belirtti. Kaba da FranTech/BuyVM'deki 27 ele geçirilmiş sunucudan 26'sını sayarak sağlayıcı düzeyinde bir güvenlik ihlali yaşanıp yaşanmadığını sorguladı. Léveillé, Ebury 1.8.3 sürümünün en az Haziran 2026'dan bu yana dolaşımda olduğunu ve güncellenmiş bir tespit betiği yayımladığını açıkladı.

Relay Operatörleri İçin Kontrol Listesi​

Tor Projesi'nin bildirisi, Linux röle operatörlerine Relay Search üzerinden kendilerinin ayarlamadığı bir Exit bayrağı veya çıkış politikası olup olmadığını denetlemelerini tavsiye ediyor. Zimmer'ın paylaştığı bulgulara göre Ebury implantının belirtileri şunlar: /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 yolunda setuid yetkili ve hiçbir pakete ait olmayan bir dosya; libkeyutils.so.1 sembolik bağlantısının bu dosyaya yönlendirilmesi; @event-0YsOG9WSOE adlı soyut UNIX soketi; ssh.service cgroup'u içinde çalışan sahte bir /sbin/rsyslogd süreci; 185.225.226[.]62 IP adresi. Zimmer, şüphelenilen bir sunucuya asla şifre yazılmaması gerektiği konusunda uyardı: "Ebury onu yakalar." Rootkit'i atlatmak için H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash komutuyla bir kabuk başlatılması öneriliyor.
İmplantta Ebury tespit edilmesi durumunda Tor Projesi'nin önerdiği adımlar şunlar: röleyi çevrimdışına al, diski ve günlükleri silmeden önce yedekle, temizlemek yerine sıfırdan yükle, yeni bir röle kimliği oluştur ve eski anahtarları çalınmış say, sunucudaki tüm kimlik bilgilerini değiştir. Yeniden kurulum önemlidir; zira implant Zimmer'ın sunucusunda yeniden başlatmadan sonra da varlığını sürdürdü. Olayı bildirmek için [email protected] adresi kullanılabilir.

Sıkça Sorulan Sorular​

Saldırıdan etkilenip etkilenmediğimi nasıl anlayabilirim?​

1-5 Ekim tarihleri arasında Tor üzerinden bir SSH sunucusuna şifre ile bağlandıysanız ve sunucunun host anahtarını kabul ettiyseniz risk altında olabilirsiniz. OpenSSH istemcisi kabul edilen anahtarı known_hosts dosyasına kaydeder. Kaba'nın bağlantısını kesen araya girme sunucusu ED25519 SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E parmak izine sahip bir anahtar kullandı; ancak diğer araya girme sunucuları farklı anahtarlar kullanmış olabilir.

Ebury arka kapısı nedir ve nasıl tespit edilir?​

Ebury, 2009'dan bu yana aktif olan ve OpenSSH içine gizlenen bir arka kapı ile kimlik bilgisi çalma yazılımıdır. /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2 yolunda setuid yetkili ve hiçbir pakete ait olmayan bir dosya, libkeyutils.so.1 sembolik bağlantısının bu dosyaya yönlendirilmesi, @event-0YsOG9WSOE adlı soyut UNIX soketi ve ssh.service cgroup'u içinde çalışan sahte bir /sbin/rsyslogd süreci implantın belirtileri arasında sayılıyor. dpkg -V ve debsums bu dosyayı yakalamıyor; bu nedenle kurtarma sistemi veya çevrimdışı disk görüntüsü üzerinden kontrol yapılması öneriliyor.

Saldırganlar Tor rölelerin kontrolünü nasıl ele geçirdi?​

Quetzalcoatl ailesinde Zimmer'ın aktardığına göre saldırgan, yönetim sunucusuna tek şifre kullanan bir hesapla giriş yaptı ve Ebury'yi kurdu. Diğer 58 operatörün nasıl ele geçirildiği henüz netlik kazanmadı. FranTech/BuyVM barındırma altyapısındaki rölelerin orantısız biçimde etkilenmiş olması, sağlayıcı düzeyinde bir ihlal olasılığını gündeme getiriyor; ancak bu kesinleşmiş değil.

Tor Projesi saldırıyı nasıl durdurdu?​

Araştırmacı kaba, 2 Ekim akşamı bulgularını Tor Projesi'nin ağ sağlığı ekibine iletti. Ekip, politika değişikliğini kendi izleme sistemleriyle de fark etmişti. 4 Ekim'de etkilenen rölelere BadExit ve MiddleOnly bayrakları oylandı ve 21:00 UTC itibarıyla mutabakatta yerini aldı. 5 Ekim 17:00 UTC'ye kadar saldırganın politikasını taşıyan hiçbir röle mutabakatta kalmadı.

Anahtar tabanlı SSH girişleri de bu saldırıdan etkilendi mi?​

Hayır. SSH kimlik doğrulama protokolü gereği istemcinin imzası her oturuma özgü bir tanımlayıcı içerdiğinden, araya giren sunucu için üretilen imza gerçek sunucuya karşı kullanılamaz. Araya giren sunucu, anahtar tabanlı bir girişi kendisi kabul edip sahte bir kabuk gösterebilir; ancak gerçek sunucuya bu yöntemle ulaşamaz. Şifreler ise oturum içinde iletildiğinden ve oturumun karşı ucundaki sunucu tarafından okunabildiğinden doğrudan ele geçirilebilir.