XZ Utils vakası: İki yılı aşkın bir güven operasyonu ve onu yakalayan yarım saniye

29 Mart 2024 Cuma, Türkiye saatiyle 18.51. Andres Freund adlı bir yazılım geliştirici, açık kaynak güvenlik e-posta listesi oss-security’ye “xz/liblzma’da SSH sunucusunun ele geçirilmesine yol açan arka kapı” başlıklı bir ileti gönderdi. Freund, son haftalarda Debian’ın geliştirme sürümü sid’i çalıştıran bilgisayarlarında tuhaf belirtiler gördüğünü yazıyordu. SSH ile yapılan girişler işlemciyi beklenenden fazla meşgul ediyordu ve hata ayıklama aracı Valgrind hata veriyordu. Freund bunun cevabını bulmuştu: “XZ’nin ana deposu ve sürüm arşivlerine arka kapı yerleştirilmiş.”

Freund’un ölçümüne göre var olmayan bir kullanıcıyla yapılan SSH girişi, arka kapıdan önce 0,299 saniye, sonra 0,807 saniye sürüyordu. Yani fark yarım saniyeydi. Freund iletisinde kendisinin “bir güvenlik araştırmacısı ya da tersine mühendis olmadığını” da not etti.

Arka kapıyı yerleştiren, projeye dışarıdan sızmış biri değildi. Projenin bakımcılarından biri olan, iki yılı aşkın süredir projeye katkı veren ve sürümleri kendi imzasıyla yayımlayan Jia Tan’dı. Bu vaka dosyası, o iki yılı projenin e-posta listesinden, kod deposundan, dağıtımların hata kayıtlarından ve olayın ardından yayımlanan tersine mühendislik analizlerinden takip ediyor. Hikâye, bir tedarik zinciri saldırısının yıllar içinde adım adım nasıl kurulduğunu gösteriyor.

Arka plan, bir gönüllünün taşıdığı kütüphane

XZ Utils, Linux dağıtımlarında yaygın kullanılan bir veri sıkıştırma aracı. İçindeki liblzma kütüphanesi başka pek çok programın da kullandığı bir bileşen. Projenin uzun süredir bakımını yapan kişi Lasse Collin. Collin, 2022’de e-posta listesinde projeyi “ücretsiz bir hobi projesi” olarak tanımlıyordu.

Bu kütüphanenin SSH sunucusuyla ilişkisi ilk bakışta açık değil. Freund’un açıkladığına göre SSH sunucusu OpenSSH, liblzma’yı doğrudan kullanmıyor. Ancak Debian ve diğer bazı dağıtımlar OpenSSH’ı, sistem yöneticisi systemd’ye durum bildirebilmesi için yamalıyor ve bu iş için kullanılan libsystemd kütüphanesi liblzma’ya bağlı. Sonuç olarak bu dağıtımlarda SSH sunucusu çalışırken liblzma da belleğe yükleniyor. Arka kapının hedefi de SSH sunucusuydu.

2021-2022, yardımsever bir yabancı

Jia Tan adı projenin e-posta listesinde ilk kez 29 Ekim 2021’de görünüyor. İlk katkı tamamen zararsızdı: Kod düzenleyicilerinin projenin yazım düzenine uymasını sağlayan bir ayar dosyası. Jia Tan’ın depoda kullandığı jiat0218@gmail.com adresinden gelen ilk değişiklik, “jiat75” kullanıcı adıyla, 7 Şubat 2022’de Collin tarafından depoya alındı. “Jia Tan” adını taşıyan ilk değişiklik ise 10 Haziran 2022’de projenin ana dalına girdi.

Kaspersky’nin olaydan sonra yaptığı incelemeye göre Jia Tan’ın GitHub hesabı 26 Ocak 2021’de açılmıştı. Hesap 2022 başından itibaren XZ’nin yanı sıra OSS-Fuzz, cpp-docs ve wasmtime gibi başka projelere de katkı vererek 500’den fazla yama gönderdi. Kaspersky’ye göre bu, büyük olasılıkla uydurma bir kimlikti.

2022, bakımcıya baskı

Jia Tan’ın katkıları sürerken e-posta listesinde başka isimler belirdi. Bu e-postaları, yazılım mühendisi Russ Cox’un olayın ardından hazırladığı ayrıntılı zaman çizelgesi “baskı e-postaları” olarak sınıflandırıyor.

28 Nisan 2022’de Jigar Kumar adlı bir hesap, listede bekleyen bir yamanın tartışmasında yakındı: “Yamalar bu listede yıllarca bekliyor.” 19 Mayıs’ta Dennis Ens adlı başka bir hesap, Collin’in diğer projesi XZ for Java’nın “hâlâ bakılıp bakılmadığını” sordu. 27 Mayıs’ta Kumar yeniden yazdı: “Bir aydan fazla geçti ve birleştirilmeye hiç yaklaşılmadı. Şaşırtıcı değil.”

7 Haziran’da Kumar daha da ileri gitti. Yeni bir bakımcı gelmeden ilerleme olmayacağını, bakımcının “ilgisini kaybettiğini” yazdı. Collin ertesi gün verdiği yanıtta ilgisini kaybetmediğini, ancak kendi ifadesiyle uzun süredir devam eden ruh sağlığı sorunları ve başka nedenlerle projeye ayırabildiği gücün sınırlı kaldığını anlattı. Aynı yanıtta bir isim de verdi: Son dönemde liste dışında Jia Tan ile çalıştığını ve “belki gelecekte daha büyük bir rolü olacağını” yazdı. Collin, bakımcı listesinde değişiklik için 5.4.0 sürümünün sonrasının uygun bir zaman olabileceğini de ekledi.

Baskı bu yanıttan sonra da sürdü. 14 Haziran’da Kumar, “bu hızla” 5.4.0’ın o yıl çıkacağından çok şüpheli olduğunu ve değişikliğin neden 5.4.0’a kadar bekletildiğini sordu. 21 Haziran’da Ens, Collin’in sağlık sorunlarına üzüldüğünü yazdıktan sonra “topluluğun daha fazlasını istediğini” ve projelerden birinin bakımının neden devredilmediğini sordu. 22 Haziran’da Kumar bu kez doğrudan Jia Tan’a seslendi: “Jia, son değişikliklerin olduğunu görüyorum. Bunu neden kendin birleştirmiyorsun?”

29 Haziran’da Collin, Jia Tan’ın liste dışında çok yardım ettiğini ve “pratikte zaten eş bakımcı” olduğunu yazdı. En azından XZ Utils için bakım değişikliğinin başladığını da duyurdu.

Kaspersky’nin değerlendirmesine göre Jigar Kumar, Nisan-Haziran 2022 arasında Collin’i erişimi Jia Tan’a devretmesi için sıkıştıran altı mesaj gönderdi. Dennis Ens ise Collin’in listede paylaştığı kişisel bir zorluğu kullanan sert bir mesaj yazdı.

2023, anahtarlar el değiştiriyor

Projenin deposundaki sürüm etiketleri devrin nasıl gerçekleştiğini gösteriyor. Olaydan önce Collin’in etiketlediği son sürüm, 11 Ocak 2023’te yayımlanan 5.4.1 oldu. 18 Mart 2023’teki 5.4.2 ise Jia Tan’ın etiketlediği ilk sürümdü.

Haziran 2023’te Hans Jansen adlı bir katkıcı, projeye ifunc adlı bir özellik için yamalar gönderdi. ifunc, GNU araçlarının bir özelliği. Bir program başlarken, işlemciye göre bir fonksiyonun hangi sürümünün kullanılacağına karar veren küçük bir “seçici” fonksiyon çalıştırıyor. Jansen’in yamalarını 27 Haziran’da Collin depoya aldı, ifunc’ı kütüphanenin hata denetim kodunda kullanan değişikliği ise aynı gün Jia Tan birleştirdi. Freund’un 2024’teki analizine göre arka kapı, programın akışına tam olarak bu seçici fonksiyonların yerine geçerek giriyordu. Kaspersky’ye göre Hans Jansen hesabı bu performans yamasından sonra sessizliğe gömüldü ve ancak arka kapı yerleştirildikten aylar sonra yeniden ortaya çıktı.

7 Temmuz 2023’te Jia Tan, Google’ın açık kaynak projelerini sürekli test eden OSS-Fuzz altyapısında XZ’nin ayarlarını değiştirdi. Değişikliğin açıklamasına göre ifunc, OSS-Fuzz’ın kullandığı bir hata yakalama aracıyla uyumlu değildi ve bu yüzden test derlemelerinde kapatılmalıydı. Bu değişiklikle XZ, OSS-Fuzz’da ifunc kapalı olarak test edilmeye başlandı.

Şubat 2024, arka kapı yerleşiyor

23 Şubat 2024’te Jia Tan depoya “Tests: Add a few test files.” (Birkaç test dosyası ekle) açıklamasıyla bir değişiklik gönderdi. Eklenen dosyalardan ikisi, bad-3-corrupt_lzma2.xz ve good-large_compressed.lzma, arka kapının asıl yükünü gizlenmiş hâlde taşıyordu. Projenin test dosyalarını tanımlayan belgeye eklenen açıklamaya göre ilki, ortasındaki veri bozuk olan bir test dosyasıydı. Freund’a göre bu dosyalar 5.6.0 sürümünde hiçbir testte kullanılmıyordu bile.

Bir gün sonra, 24 Şubat’ta, Jia Tan 5.6.0 sürümünü etiketledi. Arka kapının kilit parçası depoda değil, dağıtılan sürüm arşivlerindeydi. Freund’un tespitine göre bu arşivlerdeki build-to-host.m4 adlı derleme dosyasına eklenen bir satır, depoda yoktu. GitHub’ın depodan otomatik ürettiği “kaynak kodu” arşivlerinde de bu satır bulunmuyordu. Yani depoyu inceleyen biri, arşivi derleyen sistemlerde ne olduğunu göremiyordu.

Landlock’taki tek nokta

Aynı günlerde depoya daha sessiz bir değişiklik girdi. Jia Tan’ın 26 Şubat’ta yazdığı ve 28 Şubat’ta depoya giren değişiklik, açıklamasına göre XZ’nin Linux’taki Landlock desteğini kontrol eden testi “düzeltiyordu”. Landlock, Linux çekirdeğinin bir programın erişebileceği dosyaları kısıtlamasına imkân veren bir korumalı alan (sandbox) özelliği. XZ’nin komut satırı araçları xz ve xzdec, bu özelliği kendilerini kısıtlamak için kullanıyor.

Yeni test, CMake ile yapılan derlemelerde küçük bir C programını derlemeye çalışıyor ve derleme başarılıysa Landlock’u açıyordu. Ancak programın içine, satır başına tek başına bir nokta konmuştu. Bu nokta programın hiçbir zaman derlenmemesine, dolayısıyla CMake derlemelerinde Landlock’un hiçbir zaman açılmamasına yol açıyordu. Collin bu noktayı arka kapının duyurulmasından bir gün sonra, 30 Mart 2024’te kaldırdı. Düzeltmenin başlığı “CMake: Sabote edilmiş Landlock korumalı alan kontrolünü düzelt”, açıklaması tek cümleydi: “Hiçbir zaman açmadı.”

Mart 2024, düzeltme görünümündeki güncelleme

Arka kapı bazı yapılandırmalarda Valgrind hatalarına ve çökmelere yol açtı. Freund’a göre bunun nedeni, bazı yapılandırmalarda yığın belleğinin arka kapının beklediğinden farklı düzenlenmesiydi. 9 Mart’ta Jia Tan, Valgrind’in “yanlış hata raporunu” düzelttiğini söyleyen bir değişiklik ve “Tests: Update two test files.” (İki test dosyasını güncelle) açıklamalı bir değişiklik gönderdi ve aynı gün 5.6.1’i etiketledi. Freund’a göre bu “düzeltmeler” sorunları gidermeye yönelikti ve arka kapının kodu da bunlara göre ayarlanmıştı.

Kaspersky’nin aktardığına göre güvenlik şirketi Huntress’ten bir araştırmacının hazırladığı görselleştirme, zararlı değişikliklerin, yani 23-26 Şubat ve 8-9 Mart 2024’teki commit’lerin, hesabın olağan çalışma saatlerinin dışında yapıldığını gösteriyordu.

systemd ile zaman yarışı

Bu sırada başka bir projede, arka kapının tüm düzenini bozabilecek bir değişiklik ilerliyordu. Matteo Croce’nin 27 Şubat’ta yazdığı ve 5 Mart 2024’te systemd’nin ana dalına giren değişiklik, libsystemd’nin liblz4, libzstd ve liblzma kütüphanelerini en baştan değil, yalnızca gerektiğinde yüklemesini sağlıyordu. Değişikliğin açıklamasına göre amaç, sistem açılışında kullanılan initrd görüntüsünün boyutunu küçültmekti. Bu değişiklik 11 Haziran 2024’te yayımlanan systemd 256 sürümüyle kullanıcılara ulaştı.

Arka kapı, SSH sunucusunun libsystemd üzerinden liblzma’yı açılışta yüklemesine dayanıyordu. Russ Cox’un zaman çizelgesine göre bu değişiklik, “görünüşe göre saldırıyı boşa çıkaracaktı”.

Mart 2024, dağıtımlara son itiş

Arka kapı artık hazırdı ve openSUSE’nin açıklamasına göre zararlı sürüm 7 Mart’tan beri Tumbleweed’deydi. Geriye daha fazla dağıtıma yayılması kalıyordu.

25 Mart 2024’te Hans Jansen hesabı aylar sonra yeniden ortaya çıktı ve Debian’a 5.6.1 sürümünün alınması için talepte bulundu. Talebe göre yeni sürüm, Valgrind’de yanlış uyarıya yol açan bir hatayı düzeltiyordu ve “yalnızca hata düzeltmeleri” içeriyordu.

Ertesi gün talebe iki destek geldi. krygorin4545 adlı bir hesap, “Bu hatayı ben de görüyorum. Fazladan Valgrind çıktısı bazı testlerimin başarısız olmasına yol açıyor” diye yazdı ve işine devam edebilmek için yeni sürümü istediğini belirtti. misoeater91 adlı bir hesap ise sorunu bir hafta önce fark ettiğini, neredeyse bir hata kaydı açacağını yazdı ve “Teşekkürler Hans!” diye ekledi. Kaspersky bu iki hesabı büyük olasılıkla sahte destek hesapları olarak değerlendiriyor.

Debian 5.6.1’i 27 Mart’ta geliştirme dalına aldı. 28 Mart’ta Jia Tan bu kez Ubuntu’nun hata kayıt sistemine yazdı. “Merhaba! XZ Utils’in bakımcılarından biriyim” diye başlayan talep, 5.6.1’in “yalnızca hata düzeltmesi içeren” bir sürüm olarak Debian’dan Ubuntu’ya alınmasını istiyordu. Bu kayıt bugün en üstünde büyük harflerle şu notla duruyor: “Bu, bir arka kapı yerleştirme girişimidir.”

Red Hat’in açıklamasına göre Fedora tarafında Fedora 40’ın beta sürümü ve geliştirme dalı Rawhide etkilenen sürümleri içeriyordu. Fedora 38 ve 39 ise hiçbir zaman etkilenen paketin aday güncellemesini almadı. openSUSE’nin açıklamasına göre sürekli güncellenen dağıtımları Tumbleweed ve MicroOS, zararlı sürümü 7 Mart’tan 28 Mart’a kadar içeriyordu. openSUSE Leap ve SUSE Linux Enterprise ise ayrı derlendiği için etkilenmedi.

29 Mart 2024, yarım saniye

Freund’un iletisi bu noktada geldi. Freund, Linux’un performans izleme aracı perf ile programın akışının arka kapı etkinken ve değilken nerede ayrıştığını izleyerek ilerlemişti. İletisinde arka kapının yalnızca belirli koşullarda devreye girdiğini anlatıyordu: Program /usr/sbin/sshd olarak çalışmalı, TERM ortam değişkeni tanımlı olmamalı, LANG tanımlı olmalı, LD_DEBUG ve LD_PROFILE tanımlı olmamalı ve bazı hata ayıklama ortamları algılanmamalıydı. Freund’a göre arka kapı bazı hata ayıklama araçlarını tespit edebiliyordu. Arka kapıyı ikili dosyadan ilk kez ayrı olarak çıkaran kişi ise Freund’un aktardığına göre Florian Weimer’di.

Freund, “üst kaynağın” yani projenin kendisinin işin içinde olduğu açık olduğu için projeye hata bildirmediğini, önce Debian’ın güvenlik ekibine, ardından dağıtımların ortak güvenlik listesine haber verdiğini yazdı. ABD siber güvenlik ajansı CISA’ya da bir dağıtım tarafından bilgi verildi. Red Hat açığa CVE-2024-3094 numarasını verdi. CVE kaydına göre açığın puanı 10 üzerinden 10. Freund, Jia Tan’ın hesabı ele geçirilmiş olabilir mi sorusuna da kendi cevabını verdi: Haftalardır süren faaliyet ve “düzeltmeler” hakkında çeşitli listelerde yapılan yazışmalar göz önüne alındığında değişiklikleri yapan kişi ya doğrudan işin içindeydi ya da sistemi çok ciddi biçimde ele geçirilmişti. Freund ikincisini “daha az olası” buluyordu.

Arka kapının teknik analizi

Freund’un iletisinin ardından günler ve aylar içinde pek çok araştırmacı arka kapıyı parça parça çözdü. Aşağıdaki anlatım, Gynvael Coldwind’in betik aşamalarını açıklayan 30 Mart 2024 tarihli analizine ve Kaspersky’nin Nisan ve Haziran 2024’te yayımladığı iki teknik incelemesine dayanıyor.

Birinci aşama, bozuk görünen dosya

Her şey sürüm arşivindeki build-to-host.m4 dosyasına eklenen satırla başlıyordu. Coldwind’in analizine göre bu satır, derleme sırasında bad-3-corrupt_lzma2.xz dosyasını okuyor ve tr komutuyla bazı karakterleri yer değiştiriyordu: sekme ile boşluk ve tire ile alt çizgi. Bu basit değiş tokuş, “bozuk” görünen dosyayı geçerli bir xz arşivine dönüştürüyordu. Açılan arşivin içinden “####Hello####” satırıyla başlayan ilk betik çıkıyordu.

İkinci aşama, parçalanmış ve şifrelenmiş yük

İlk betik, Coldwind’e göre 5.6.1’de beş kez tekrarlanan bir kontrolle yalnızca Linux’ta çalıştığından emin oluyor, ardından good-large_compressed.lzma dosyasını işliyordu. Dosya, art arda çalışan head komutlarıyla 1024 bayt atlanıp 2048 bayt alınarak parçalanıyor, böylece dosyaya serpiştirilmiş dolgu bölümleri ayıklanıyordu. Kalan veri belirli bir noktadan kesiliyor, tr ile yapılan bir yerine koyma şifresinden geçiriliyor ve ham LZMA biçiminde açılıyordu. Çıkan şey ikinci betikti.

İkinci betik, Freund’un aktardığı koşulları kontrol ediyordu: x86-64 işlemcili bir Linux sistem, GCC derleyicisi, GNU bağlayıcısı ve bir Debian ya da RPM paketi derlemesi. Freund son koşulun büyük olasılıkla sorunu araştıranların yeniden üretmesini zorlaştırmak için konduğunu değerlendiriyor.

Coldwind, 5.6.1’deki ikinci betikte ilginç bir ayrıntı daha buldu: Test dosyaları klasöründe belirli imza dizileri arayan bir “eklenti” düzeneği. Bu imzaları taşıyan bir dosya bulunursa, iki imza arasındaki bayt dizisi çıkarılıp şifresi çözülerek çalıştırılacaktı. Coldwind iki sürümde de bu imzaları taşıyan bir dosya bulamadı. Bu düzenek, özgün test dosyalarına dokunmadan ileride yeni yükler eklemeye imkân veren bir kanca gibi görünüyordu.

Üçüncü aşama, kütüphaneye yerleşen nesne dosyası

İkinci betik son olarak test dosyasını yeniden açıyor, AWK ile yazılmış ve RC4’e benzeyen bir algoritmayla şifresini çözüyor ve sonucu bir kez daha açıyordu. Coldwind’e göre ortaya çıkan, 5.6.0’da 88.792, 5.6.1’de 88.664 bayt büyüklüğünde, liblzma_la-crc64-fast.o adlı derlenmiş bir nesne dosyasıydı. Bu dosya liblzma’nın derleme ve bağlama sürecine örülüyor, böylece dağıtımın ürettiği liblzma paketi arka kapıyı içeriyordu.

Dördüncü aşama, SSH sunucusunun içine kanca

Kaspersky’nin analizine göre arka kapı, liblzma’nın açılışta CRC fonksiyonunu seçtiği ifunc anında devreye giriyordu. Bu aşamada dinamik bağlayıcının denetim arayüzünü bellekte değiştirerek sonradan yüklenen sembolleri izleyebiliyordu. SSH sunucusu, RSA_public_decrypt fonksiyonunu çözmeye geldiğinde, arka kapı bu fonksiyonun adresini kendi koduna yönlendiriyordu. Kaspersky, OpenSSH 9.7p1 üzerinde yaptığı incelemede RSA_public_decrypt’i birincil, RSA_get0_key’i ikincil hedef olarak tespit etti.

Arka kapı analizi zorlaştırmak için de önlemler alıyordu. Kaspersky’ye göre kullandığı metinleri kendi içinde düz olarak tutmuyor, bunları SSH sunucusunun kendi dosyasında arıyordu. Sembolleri ihtiyaç anında çözüyor ve içinde küçük bir disassembler barındırıyordu. Ayrıca bir “kapatma anahtarı” vardı: yolAbejyiejuvnup adlı ortam değişkeni Evjtgvsh5okmkAvj değerine sahipse arka kapı çalışmayı durduruyordu.

Beşinci aşama, imzalı komutlar

Saldırgan, komutunu bağlantı sırasında gönderdiği bir OpenSSH sertifikasının açık anahtar alanına gizliyordu. Filippo Valsorda’nın arka kapıyı tersine mühendislikle inceleyen araştırmacılardan aktardığı ön analize göre, kancalanan fonksiyon bu alandan bir yük çıkarıyor, sabit bir ChaCha20 anahtarıyla şifresini çözüyor ve sabit bir Ed448 anahtarıyla imzalanıp imzalanmadığını kontrol ediyordu. Valsorda’ya göre yük ya da imza geçersizse arka kapı normal davranışa dönüyordu. Bu da anahtarı elinde tutmayan birinin arka kapıyı kullanamaması, hatta ağ üzerinden güvenilir biçimde tespit edememesi demekti.

Kaspersky’nin Haziran 2024’teki analizi tabloyu tamamladı. Saldırganın Ed448 açık anahtarı, arka kapının x86 kodu içinde komutların dizilişine gizlenmişti. İmzalanan veri, hedef sunucunun kendi açık anahtarının SHA-256 özetini de içeriyordu. Bu yüzden bir sunucuya gönderilen komut ele geçirilse bile başka bir sunucuda yeniden kullanılamıyordu.

Kaspersky arka kapının dört komut türünü belgeledi:

• Kapıyı aralamak: Kapalıysa root girişini açmak, isteğe bağlı olarak PAM kimlik doğrulamasını devre dışı bırakmak ve ardından herhangi bir şifreyi ya da sahte bir anahtarı kabul edecek kancaları kurmak.
• Her şifreyi kabul etmek: Root girişini açıp saldırganın herhangi bir kullanıcı adı ve şifreyle giriş yapabilmesini sağlamak.
• Komut çalıştırmak: Gönderilen komutu system fonksiyonuyla, istenirse belirli bir kullanıcı ve grup kimliğiyle çalıştırmak.
• Oturumu kapatmak: Giriş öncesi oturumu yürüten süreci sonlandırmak.

Arka kapı izlerini de siliyordu. Kaspersky’ye göre komut işlendikten sonra gelen anahtarı boş bir anahtarla değiştiriyor, böylece zararlı veri kayıtlara düşmüyordu. Kayıt fonksiyonunu da kancalıyordu: Başarılı giriş mesajlarını başarısız giriş denemesi gibi görünecek şekilde yeniden yazıyor, “Connection closed by” ile başlayan mesajlara kısa süre izin veriyor, diğer mesajları ise tamamen siliyordu. Kaspersky arka kapıyı “pek çok kendine özgü yanı olan, son derece gelişmiş bir tehdit” olarak tanımlıyor.

Valsorda’nın ilk günlerdeki değerlendirmesi de çarpıcıydı: Bu, açıkta anlatılmış “belki de en iyi uygulanmış tedarik zinciri saldırısı” ve bir kâbus senaryosuydu, yani yaygın kullanılan bir kütüphanenin yetkili, yetkin ve kötü niyetli bir bakımcısı. Valsorda’ya göre arka kapı tesadüfen yakalanmış gibi görünüyordu.

Kimin işi olabilir

Jia Tan’ın, Jigar Kumar’ın, Dennis Ens’in, Hans Jansen’in ve Debian’daki destek hesaplarının arkasında kimin olduğu, kamuya açık kaynaklarda doğrulanmış değil. Kaspersky’nin sosyal mühendislik boyutunu inceleyen raporu belirli bir ülkeyi ya da grubu işaret etmiyor ve ortada küçük bir ekip mi yoksa birden fazla kimlik kullanan tek bir kişi mi olduğunun, daha fazla ayrıntı kamuoyuyla paylaşılana kadar bilinemeyeceğini belirtiyor. Bununla birlikte rapor bazı ipuçlarını sıralıyor.

Saatler. Huntress’ten bir araştırmacının görselleştirmesine göre zararlı commit’ler hesabın olağan çalışma saatlerinin dışında yapılmıştı. Kaspersky bunun için üç olasılık sayıyor: Hesabı ikinci bir kişi kullanmış olabilir, katkıcı aceleye gelmiş olabilir ya da kesintisiz mesai dışı zamana ihtiyaç duyan bir ekip çalışıyor olabilir.

Saat dilimi. Projenin deposundaki kayıtlar da bir ipucu sunuyor. Kırmızı Ekip’in depo üzerinde yaptığı sayıma göre Jia Tan adına kayıtlı 480 benzersiz commit’in 470’i +0800 saat dilimiyle kaydedilmiş. Bu, Çin, Singapur ve Malezya gibi ülkelerin kullandığı saat dilimi. Kalan 10 commit +0200 ve +0300 saat dilimlerini taşıyor. Ancak commit’teki saat dilimi, commit’i yapan bilgisayarın ayarından gelir ve kolayca değiştirilebilir. Bu yüzden tek başına bir kanıt sayılmaz.

Bağlantı ve dil. Kaspersky’ye göre Jia Tan’ın 29 Mart’taki bir IRC girişi, Witopia adlı VPN hizmetinin Singapur’daki bir çıkış noktasından yapılmıştı. Rapor, kimliklerin Singapur ve Malezya, Kuzey Avrupa ve Hindistan’a yayılan coğrafi dağılımının zorlama göründüğünü ve hesapların yazım hatalarının ve dil bilgisinin birbirine benzediğini not ediyor.

E-posta adresleri. Hesapların kullandığı adresler farklı sağlayıcılara dağılmıştı: Jigar Kumar için Proton Mail, Dennis Ens için Gmail, Hans Jansen için Outlook, krygorin4545 için Proton, misoeater91 için Tuta.

Sonrası

Debian 29 Mart’ta yayımladığı güvenlik duyurusunda etkilendiği bilinen bir kararlı sürüm olmadığını, ele geçirilmiş paketlerin test, kararsız ve deneysel dallarda olduğunu açıkladı. Paket, temiz 5.4.5 koduna geri döndürüldü. Red Hat, kurumsal dağıtımı Red Hat Enterprise Linux’un hiçbir sürümünün etkilenmediğini, Fedora 40 beta ve Rawhide kullanıcılarının ise hemen önlem alması gerektiğini duyurdu. Fedora projesi 15 Nisan 2024’te, saldırganların arka kapıyı kullanma fırsatı bulduğuna dair bir kanıt olmadığını açıkladı. Jia Tan’ın Ubuntu’daki talebi “düzeltilmeyecek” olarak kapatıldı. CISA da kullanıcılara 5.4.6 gibi temiz bir sürüme dönmelerini önerdi. Kaspersky’nin değerlendirmesine göre Arch Linux ve Gentoo bu arka kapıdan etkilenmedi.

Zararlı sürümün gerçek kullanıcılara ulaştığı openSUSE, müdahalesini 12 Nisan 2024’te ayrıntılı olarak anlattı. SUSE’nin ürün güvenliği ekibi, duyurudan birkaç gün önce XZ 5.6.x sürümlerinde tuhaf bir şey olduğuna dair bir ipucu almıştı. Freund’un ayrıntılı raporu ise duyurudan bir gün önce, 28 Mart Perşembe akşamı, dağıtımların ortak güvenlik listesi üzerinden geldi. Ekip aynı gün Tumbleweed’de XZ’yi eski koda geri döndürdü. Arka kapının içeriği henüz bilinmediği için şüpheli XZ ile derlenmiş bütün paketleri attı ve hepsini güvenli bir yedekten yeniden derledi. openSUSE, kamuoyuna duyuru yapıldığında bütün etkilenen ürünler için güncellemelerin yayımlanmış olduğunu belirtiyor. 29 Mart’taki duyurusunda ise arka kapının kullanılıp kullanılmadığının bilinmediğini, karmaşıklığı nedeniyle bir ihlalin sistem üzerinde tespit edilmesinin büyük olasılıkla mümkün olmadığını yazdı. Bu yüzden SSH’ı internete açık Tumbleweed sistemleri için sıfırdan kurulum ve erişilmiş olabilecek kimlik bilgilerinin değiştirilmesini önerdi.

Lasse Collin olaydan sonra projenin sitesinde bir açıklama sayfası yayımladı. Collin’e göre 5.6.0 ve 5.6.1 arşivlerini Jia Tan oluşturmuş ve imzalamıştı. Jia Tan’ın erişimi yalnızca GitHub’da barındırılan şeylerle sınırlıydı, ana site ve Collin’in kendi git sunucusu onun erişiminde değildi. İki bakımcının GitHub hesapları askıya alındı, Collin’inki 2 Nisan 2024’te geri açıldı. Projenin temiz yeni sürümleri 29 Mayıs 2024’te yayımlandı. Collin, zararlı test dosyalarının depodan geçmişi yeniden yazarak silinmediğini, çünkü onları çalıştıracak tetikleyici kodun hiçbir zaman depoda bulunmadığını açıklıyor.

Benzer girişimler

Olayın duyurulmasından 17 gün sonra, 15 Nisan 2024’te, Açık Kaynak Güvenlik Vakfı OpenSSF ile JavaScript projelerine ev sahipliği yapan OpenJS Vakfı ortak bir uyarı yayımladı. OpenJS’nin proje konseyi, farklı isimler kullanan ama birbiriyle örtüşen GitHub bağlantılı e-posta adreslerinden benzer mesajlar almıştı. Mesajlar, popüler bir JavaScript projesinin ayrıntı verilmeden “kritik açıkları kapatmak için” güncellenmesini istiyor ve gönderenlerin, projeye pek katkıları olmamasına rağmen yeni bakımcı yapılmasını talep ediyordu. Vakıflara göre bu yaklaşım, Jia Tan’ın XZ’de kendini konumlandırma biçimine çok benziyordu. Hiç kimseye yetki verilmedi. OpenJS, kendi barındırmadığı iki popüler JavaScript projesinde de benzer bir örüntü gördü ve durumu CISA’ya bildirdi.

Uyarı, proje bakımcılarının dikkat etmesi gereken işaretleri de sıraladı: Görece tanınmayan topluluk üyelerinin dostça ama ısrarcı ve saldırgan takibi, yeni ya da bilinmeyen kişilerin bakımcılık talebi, başka bilinmeyen kişilerin bu talepleri desteklemesi, okunabilir kaynak kod yerine ikili dosya içeren katkılar, kasıtlı olarak anlaşılmaz yazılmış kod ve incelemeyi gevşetmeye yönelik yapay bir aciliyet duygusu. Vakıflar bakımcılara kendi tepkilerini de izlemelerini öneriyor: Kendinden şüphe etmeye ya da proje için yeterince şey yapmadığını hissetmeye yol açan etkileşimler, bir sosyal mühendislik saldırısının parçası olabilir.

Bir yıl sonra hâlâ ortada

Güvenlik şirketi Binarly, 12 Ağustos 2025’te yayımladığı raporda, Docker Hub’da arka kapıyı hâlâ içeren 12 Debian Docker imajı bulduğunu açıkladı. Bunların hepsi amd64 mimarisi için, 11 Mart 2024 tarihli unstable, testing, trixie, sid, experimental ve rc-buggy etiketli imajlardı. Bu imajların üzerine kurulmuş başka imajlarla birlikte Binarly’nin bulduğu toplam sayı 35’i aşıyordu ve şirket Docker Hub’ın yalnızca küçük bir bölümünü taradığını belirtiyor. Binarly’ye göre Debian bakımcıları imajları kaldırmadı. Şirket, istismarın arka kapı anahtarına sahip kişinin SSH hizmeti çalışan cihaza ya da konteynere ağ üzerinden erişmesini gerektirdiğini, bu yüzden pratik etkinin bir ölçüde sınırlı olduğunu da not ediyor.

Hâlâ bilinmeyenler

• Jia Tan kim: Jia Tan’ın, ona destek veren hesapların ve Hans Jansen’in arkasında kimin olduğu, kamuya açık kaynaklarda doğrulanmış bir bilgi değil.
• Arka kapı kullanıldı mı: Zararlı sürüm yayımlanmış dağıtımlara ulaştı, ama bu kullanıldığı anlamına gelmiyor. Fedora, saldırganların arka kapıyı kullandığına dair bir kanıt bulmadığını açıkladı. openSUSE ise kullanılıp kullanılmadığının bilinmediğini ve sistem üzerinde tespitinin büyük olasılıkla mümkün olmadığını belirtti.
• Arka kapı ne için kullanılacaktı: Arka kapının erken yakalanması nedeniyle hangi hedeflere karşı kullanılmak istendiği bilinmiyor. Kaspersky’nin analizleri de açık bir hedef belirtmiyor.
• Eklenti düzeneği neyi bekliyordu: 5.6.1’deki ve ileride yeni yükler eklemeye imkân veren düzenek için hiçbir dosya bulunmadı.
• Collin’in kendi anlatımı: Collin, arka kapının sürümlere nasıl girdiğini ve bundan ne öğrenilebileceğini anlatan bir yazı üzerinde çalıştığını, ancak bunun düşündüğünden uzun sürdüğünü belirtiyor. Sayfasının son güncellemesi Ocak 2025 tarihli.

Vakadan çıkan dersler

Sürüm arşivi ile depo aynı şey değil. Arka kapının kilit satırı, herkesin inceleyebildiği depoda değil, yalnızca sürüm arşivlerinde bulunuyordu. Derlenen arşivin depoyla birebir örtüşüp örtüşmediğini kontrol etmek, bu tür bir farkı ortaya çıkarabilir.

Test dosyaları da koddur. Asıl yük, “bozuk test dosyası” olarak tanımlanmış ikili dosyalarda saklanıyordu ve bu dosyalar hiçbir testte kullanılmıyordu. Kullanılmayan ya da içi okunamayan dosyalar, kod incelemelerinde gözden kaçan bir alan.

Küçük değişiklikler büyük işler görebilir. Landlock kontrolündeki tek bir nokta, bir güvenlik özelliğini sessizce kapattı. Testlerde bir özelliği kapatan değişiklikler, ifunc’ın OSS-Fuzz’da kapatılması gibi, makul bir gerekçeyle sunulsa bile ayrıca incelenmeyi hak ediyor.

Tek bakımcılı projeler kritik altyapıdır. Pek çok Linux dağıtımında bulunan bir kütüphane, bakımcısının tanımıyla ücretsiz bir hobi projesi yürüten tek bir gönüllüye dayanıyordu. Saldırının ilk aşaması da bu gönüllünün üzerindeki yükü kullanan bir baskıydı. OpenSSF ve OpenJS’nin uyarısındaki işaretler, bu tür bir baskıyı erken tanımak için iyi bir kontrol listesi.

Küçük sapmalar önemlidir. Arka kapıyı ortaya çıkaran, bir güvenlik ürünü değil, yarım saniyelik bir gecikmeyi ve birkaç Valgrind hatasını görmezden gelmeyen bir geliştirici oldu.

Saldırı izleri ve tespit

Etkilenen sürümler: XZ Utils 5.6.0 ve 5.6.1 sürüm arşivleri. Arka kapı yalnızca bu arşivlerden x86-64 Linux üzerinde, GCC ve GNU bağlayıcısıyla, Debian ya da RPM paketi olarak derlenen liblzma’ya yerleşiyordu.

Dosyalar:

• Sürüm arşivindeki m4/build-to-host.m4 dosyasında depoda bulunmayan satır
• tests/files/bad-3-corrupt_lzma2.xz ve tests/files/good-large_compressed.lzma (gizlenmiş yük)
• Derleme sırasında oluşan liblzma_la-crc64-fast.o nesne dosyası

Kapatma anahtarı (Kaspersky): yolAbejyiejuvnup=Evjtgvsh5okmkAvj ortam değişkeni

Kaspersky tespit adları: HEUR:Trojan.Script.XZ, Trojan.Shell.XZ, MEM:Trojan.Linux.XZ

Arka kapıyı içeren Debian Docker imajı etiketleri (Binarly, hepsi amd64): rc-buggy-20240311, experimental-20240311, unstable-20240311, unstable-20240311-slim, trixie-20240311, trixie-20240311-slim, testing-20240311, testing-20240311-slim, sid-20240311, sid-20240311-slim

Tespit araçları: Freund’un iletisine eklenen ve Vegard Nossum’un yazdığı detect.sh betiği, SSH sunucusunun arka kapılı bir liblzma’ya bağlı olup olmadığını kontrol ediyor. Binarly de şüpheli ifunc seçicilerini tespit etmek için ücretsiz XZ.fail aracını yayımladı.

Yapılması gereken: CISA’nın önerisine göre XZ Utils 5.6.0 ya da 5.6.1 kullanan sistemler, 5.4.6 gibi temiz bir sürüme dönmeli, sistemler zararlı etkinlik belirtileri açısından incelenmeli. openSUSE, SSH’ı internete açık ve 7-28 Mart 2024 arasında güncellenmiş Tumbleweed sistemlerinin sıfırdan kurulmasını öneriyor. Binarly’nin bulgusu ise 2024 Şubat-Mart döneminde oluşturulmuş Debian testing, unstable ya da sid tabanlı konteyner imajlarının da kontrol edilmesi gerektiğini gösteriyor. Binarly’nin de kabul ettiği gibi kullanıcıların güncel imajları kullanması gerekiyor.