XZ arka kapı olayı: ilk analiz sonuçları

• XZ Utils/liblzma arka kapısı, 29 Mart 2024'te Openwall OSS-security posta listesinde kamuya açıklandı ve saldırganın nihai hedefinin systemd tabanlı dağıtımlardaki OpenSSH sunucusu sshd içine uzaktan kod çalıştırma yeteneği yerleştirmek olduğu düşünülüyor
• Enfeksiyon zinciri, XZ deposundaki test dosyaları ve derleme altyapısını kullanan çok aşamalı bir ekleme sürecinden oluşuyordu; build-to-host.m4, bad-3-corrupt_lzma2.xz ve good-large_compressed.lzma üzerinden geçerek kötü amaçlı nesne dosyası derleme sırasında liblzma ile linkleniyordu
• Arka kapı içeren XZ 5.6.0 ve 5.6.1, bazı büyük tedarikçilerin beta ve deneysel derlemeleriyle dağıtıldı; CVE-2024-3094 ise 10 ciddiyet puanıyla sınıflandırıldı
• İkili arka kapı, GLIBC'nin IFUNC mekanizmasını ve cpuid çağrı yolunu kötüye kullanarak yükleniyor; ardından OpenSSL/libcrypto ile ilgili işlevleri hook'layarak enfekte makinedeki bağlantıları izlemeye çalışıyor
• Kötü amaçlı kod, /usr/bin/sshd çalışıp çalışmadığını ve kill switch ortam değişkenini kontrol ediyor; trie tabanlı dizge işleme, dinamik sembol çözümleme ve rtdl-audit çalışma zamanı yamasıyla analiz ve tespiti zorlaştırıyor

---

Olayın özeti ve etki alanı

• 29 Mart 2024'te Openwall OSS-security posta listesindeki mesaj ile XZ arka kapısının keşfi kamuya açıklandı
• XZ, birçok büyük Linux dağıtımına entegre edilmiş bir sıkıştırma yardımcı programı
• Riskin özü, arka kapı içeren liblzma kütüphanesinin bazı systemd tabanlı dağıtımlarda OpenSSH sunucu süreci sshd ile bağlanabilmesi
  • Ubuntu, Debian ve RedHat/Fedora Linux, OpenSSH'nin systemd özelliklerini kullanması için yamalandığından bu kütüphaneye bağımlı
  • Arch Linux ve Gentoo'nun etkilenmediği değerlendiriliyor
• Saldırganın nihai hedefinin, başkalarının kullanamayacağı bir sshd uzaktan kod çalıştırma yeteneği eklemek olduğu düşünülüyor
• Tek bir kötü amaçlı yama, sahte paket veya typo-squatting paketleri etrafında dönen diğer tedarik zinciri saldırılarından farklı olarak bu olay, dünya çapındaki SSH sunucularının ele geçirilmesine neredeyse ulaşan çok aşamalı bir operasyon niteliğinde

Arka kapının yerleştirilme yöntemi

• liblzma arka kapısı, derleme süreci ile test dosyalarını birlikte kullanarak iki düzeyde eklendi
  • Nihai paketi üreten derleme altyapısı kaynak kodu, build-to-host.m4 eklenerek değiştirildi
  • Test senaryosu dosyalarının içine gizlenmiş betik ve ikili bileşenler derleme sırasında çıkarıldı
• Enfeksiyon akışı üç dosya etrafında ilerliyordu
  • build-to-host.m4: sonraki aşama betiğini çıkaran derleme betiği
  • bad-3-corrupt_lzma2.xz: shell betiğinin gizlendiği test dosyası
  • good-large_compressed.lzma: kötü amaçlı ikili nesnenin gizlendiği test dosyası
• Çıkarılan kötü amaçlı ikili bileşen, derleme sürecinde normal kütüphane ile linklenerek Linux depolarına taşınabiliyordu
• Büyük tedarikçiler bu kötü amaçlı bileşeni beta ve deneysel derlemeler içinde dağıttı
• XZ Utils ihlaline CVE-2024-3094 atandı ve ciddiyet puanı azami değer olan 10 olarak belirlendi

Başlıca zaman çizelgesi

• 19 Ocak 2024: Yeni maintainer jiaT75, XZ web sitesini GitHub Pages'e taşıdı
• 15 Şubat 2024: build-to-host.m4, .gitignore dosyasına eklendi
• 23 Şubat 2024: Kötü amaçlı betik aşamasını içeren iki “test dosyası” eklendi
• 24 Şubat 2024: XZ 5.6.0 yayımlandı
• 26 Şubat 2024: CMakeLists.txt içine Landlock güvenlik özelliğini engelleyen bir commit girdi
• 4 Mart 2024: Arka kapı, Valgrind ile ilgili sorunlara yol açtı
• 9 Mart 2024: İki test dosyası güncellendi, CRC işlevi değiştirildi ve Valgrind sorunu “düzeltildi”
• 9 Mart 2024: XZ 5.6.1 yayımlandı
• 28 Mart 2024: Hata keşfedildi ve Debian ile RedHat'e bildirildi
• 28 Mart 2024: Debian, XZ 5.6.1'i 5.4.5-0.2 sürümüne geri aldı
• 29 Mart 2024: OSS-security posta listesinde kamuya açık e-posta yayımlandı
• 29 Mart 2024: RedHat, arka kapılı XZ'nin Fedora Rawhide ve Fedora Linux 40 beta ile dağıtıldığını doğruladı
• 30 Mart 2024: Debian, derlemeleri durdurdu ve yeniden derleme sürecini başlattı
• 2 Nisan 2024: XZ'nin ana geliştiricisi arka kapı olayını kabul etti

Enfeksiyon zincirinin 3 aşaması

• 1. aşama: değiştirilmiş build-to-host.m4

  • XZ'nin resmi GitHub deposu sürümleri kötü amaçlı test dosyalarını içeriyordu, ancak bu dosyaların çalıştırılma fırsatı olmadığından başlangıçta zararsız görünüyordu
  • Enfeksiyonu başlatan kötü amaçlı kodun, jiaT75 kontrolündeki xz[.]tukaani.org üzerinden sunulan sürüme dahil edildiği düşünülüyor
  • Dağıtımların çoğu bu URL'yi kullandı ve indirilen sürümde kötü amaçlı kod içeren build-to-host.m4 dosyası yer aldı
  • build-to-host.m4, derleme sırasında çalışıyor ve bad-3-corrupt_lzma2.xz içindeki “bozuk” veriyi tr ile düzelttikten sonra xz -d ile açıyor
  • Açma işleminin sonucunda daha sonra /bin/bash ile çalıştırılacak bir shell betiği bulunuyor

• 2. aşama: eklenmiş shell betiği

  • Kötü amaçlı .m4 dosyasının eklediği betik, Linux makinede mi çalıştığını ve amaçlanan derleme sürecinin içinde mi yürütüldüğünü kontrol ediyor
  • Sonraki aşamanın yürütülmesi için good-large_compressed.lzma kullanılıyor
  • Bu dosya XZ ile normal biçimde sıkıştırılmış olsa da, açılmış veri içinde çöp veri bulunuyor
  • Betik, veriyi çıkarmak için head pipeline'ını eval ile çalıştırıyor
  • Her head komutu ya sonraki 1024 baytı atlıyor ya da sonraki 2048 bayt ya da 724 baytı çıkarıyor
  • Toplam 33.492 bayt çıkarılıyor
  • tail, dosyanın son 31.265 baytını tutuyor ve kalanını yok sayıyor
  • Ardından tr ile temel yer değiştirme uygulanarak obfuscation çözülüyor; ikinci XZ komutu dönüştürülmüş baytları raw lzma akışı olarak açıyor ve sonucu shell'e iletiyor

• 3. aşama: arka kapı nesnesinin çıkarılması

  • Son aşamadaki shell betiği, beklenen ortamda çalışıp çalışmadığını görmek için çeşitli koşulları kontrol ediyor
  • Projenin IFUNC kullanacak şekilde yapılandırılıp yapılandırılmadığını doğruluyor
  • GCC ile derlenip derlenmediğini kontrol ediyor
  • Ardından betiğin kullanacağı belirli dosyaların projede mevcut olup olmadığını doğruluyor
  • Bu aşama, good-large_compressed.lzma içindeki farklı bir offset'te gizlenmiş nesne dosyasını çıkarıyor
  • Çıkarma süreci, birden çok komutu sıralı biçimde çalıştırıyor ve her komutun çıktısını sonraki komutun girdisine veriyor
  • XZ aracıyla good-large_compressed.lzma açılıyor
  • eval $i ve birden çok head çağrısı kullanılıyor
  • RC4'e benzeyen özel bir algoritma ile ikili veri çözümleniyor
  • Çözülen sıkıştırılmış dosya tekrar XZ ile açılıyor
  • Baş kısmındaki bazı baytlar kaldırıldıktan sonra sonuç liblzma_la-crc64-fast.o olarak kaydediliyor
  • Son olarak betik, liblzma içindeki crc_x86_clmul.h dosyasında is_arch_extension_supported işlevini değiştiriyor
  • __get_cpuid çağrısını _get_cpuid olarak değiştirerek tek bir alt çizgiyi kaldırıyor
  • Bu değişiklik, arka kapı nesnesinin kütüphaneye linklenmesini sağlıyor

İkili arka kapının yüklenme yöntemi

• XZ'nin özgün kodunda CRC hesaplaması için lzma_crc32 ve lzma_crc64 adlı özel işlevler bulunuyor
• Bu iki işlev, ELF sembol tablosunda GLIBC'nin IFUNC türü olarak saklanıyor
  • IFUNC, dinamik bağlayıcının paylaşımlı kütüphane yüklenirken hangi işlevin kullanılacağını dinamik olarak seçmesini sağlıyor
  • XZ, modern işlemci özellikleri olan CLMUL, SSSE3 ve SSE4.1'i kontrol edip optimize CRC işlevlerinin kullanılıp kullanılmayacağına karar vermek için bunu kullanıyor
• İşlemci özelliklerini kontrol etmek için cpuid komutu gerekiyor ve GLIBC'nin sağladığı __get_cpuid sarmalayıcısı çağrılıyor
• Kötü amaçlı betik __get_cpuid adını _get_cpuid olarak değiştirince, kod çağrısı arka kapı nesne dosyası içindeki _get_cpuid sembolüne bağlanıyor
• İlk arka kapı kodu, lzma_crc32 ve lzma_crc64 aynı değiştirilmiş _get_cpuid işlevini kullandığı için iki kez çağrılıyor
  • Daha önce çalışıp çalışmadığını anlamak için basit bir sayaç kullanılıyor
  • lzma_crc64 IFUNC, _get_cpuid çağrısını yaptığında sayaç değeri 1 ise son giriş noktasına yönlendirme süreci başlıyor

Çalışma zamanı davranışı ve hook hedefleri

• Arka kapı, çalışan sürecin temel bilgilerini içeren yapılarını başlatıyor
• Hardcode edilmiş offset'lerle Global Offset Table(GOT) adresini buluyor ve içindeki cpuid işaretçisini tespit ediyor
• Ardından bu işaretçiyi ana kötü amaçlı işleve çevirerek sanki cpuid çağrılıyormuş gibi kötü amaçlı işlevi çalıştırıyor
• Ana hedef, enfekte makineye gelen bağlantıları izleyebilmek için belirli işlevleri hook'lamak
• Hedef alınan işlevler libcrypto ile ilişkili
  • RSA_public_decrypt: özel anahtarla imzalanmış şifreli metni çözmek için kullanılıyor
  • EVP_PKEY_set1_RSA: belirli bir context için RSA anahtarını ayarlamakta kullanılıyor
    • Modern SSH sunucu sürümlerinde bulunmuyor, ancak bağımsız SSH anahtar üretim aracında kullanılıyor
  • RSA_get0_key: RSA anahtarını almakta kullanılıyor
• Hook süreci, çeşitli iç yapı erişimlerini ve süreç başına yapı manipülasyonunu gerektiriyor; kötü amaçlı kod buna ek olarak analizden kaçınma kontrolleri de yürütüyor

Çalışma ortamı kontrolleri ve analizden kaçınma teknikleri

• sshd ve kill switch kontrolü

  • Arka kapı önce sembol adreslerini dinamik olarak çözümleyen ld-linux dinamik bağlayıcısını parse ediyor
  • Mevcut çalışma ortamının ölçütlere uyup uymadığını kontrol ediyor
  • Mevcut sürecin /usr/bin/sshd olup olmadığını doğruluyor
  • Kill switch'in varlığını kontrol ediyor
  • Geçerli süreç adı argv[0] içinden çıkarılıyor
  • Tüm süreç ortam değişkenleri parse edilerek iç dizge tablosundaki değerlerle eşleşip eşleşmedikleri kontrol ediliyor
  • Eşleşen bir ortam değişkeni varsa ya da süreç sshd değilse kötü amaçlı kod çalışmayı durduruyor
  • İç tablodaki tek değişken olan yolAbejyiejuvnup=Evjtgvsh5okmkAvj, bu bağlamda kill switch görevi görüyor

• trie tabanlı dizge işleme

  • Arka kapının ayırt edici özelliklerinden biri, dizge işlemleri için tek bir trie yapısı kullanması
  • İşlev adı gibi sabitleri doğrudan karşılaştırmak ya da dizge hash'iyle kıyaslamak yerine, trie arama sonucunun belirli sabit değerle aynı olup olmadığına bakıyor
  • ELF header magic değeri, trie içinde 0x300 döndürüyor
  • system işlev adı 0x9F8 dönüş değeriyle eşleşiyor
  • Trie sadece karşılaştırma için değil, host binary içindeki dizgeleri bulmak için de kullanılıyor
  • Örneğin ssh-2.0 gibi dizge işaretçisini kullanan işlevlerde, arka kapı gövdesinde şüpheli veri bırakmamak için dizge host binary içinde aranıyor
  • Uygulama 16 baytlık bitmask kullanıyor
  • Her yarı, 0x00-0x3F ve 0x40-0x7F giriş baytı aralıklarına karşılık geliyor
  • Trie yaprak düğümleri 2 bayt uzunluğunda; 3 bit bayrak olarak kullanılıyor, geri kalanı ise değer ya da sonraki düğüm konumu için ayrılıyor

Sembol çözümleme ve rtdl-audit hook'lama

• sembol çözümleme rutinleri

  • Arka kapıda ELF Symbol yapısını bulmak için en az 3 sembol çözümleme rutini bulunuyor
  • Tüm sembol çözümleme işlevleri, trie içinde aranacak anahtarı girdi olarak alıyor
  • Bu çözücülerden biri, tüm sembolleri dolaşarak istenen anahtara sahip sembolü buluyor ve bulduğunda Elf64_Sym yapısını döndürüyor
  • Bu yapı daha sonra arka kapının iç yapılarını doldurmak ve gerekli işlev işaretçilerini saklamak için kullanılıyor
  • Bu süreç, Windows tehditlerinde sık görülen API hashing rutinlerine benziyor
  • Arka kapı daha sonra şifreleme rutinlerinde kullanacağı çok sayıda OpenSSL libcrypto işlevini arıyor
  • Bulup çözdüğü işlevlerin sayısını izliyor ve bu değeri normal çalışmaya devam edip etmeyeceğine ya da durup durmayacağına karar vermek için kullanıyor

• lzma_alloc üzerinden kötüye kullanılan sahte allocator

  • Bir başka sembol çözücü, liblzma'nın kendi işlevi olan lzma_alloc'ı kötüye kullanıyor
  • lzma_alloc, varsayılan allocator malloc ya da özel bir allocator kullanarak belleğin verimli biçimde ayrılmasına yardımcı olan bir işlev
  • XZ arka kapısında bu işlev, sahte bir allocator aracılığıyla başka bir sembol çözücü gibi davranıyor
  • Normalde “allocation size” olarak kullanılan parametre, aslında trie içindeki sembol anahtarı olarak kullanılıyor
  • Bu numaranın amacı, arka kapı analizini zorlaştırmak
  • Arka kapı çalışma sırasında sembolleri dinamik olarak çözüyor; tüm sembolleri bir kerede çözmekle ya da yalnızca ihtiyaç anında çözmekle sınırlı değil
  • Çözülen semboller, normal OpenSSL işlevlerinden makinede komut çalıştıran system gibi işlevlere kadar uzanıyor

• rtdl-audit çalışma zamanı yaması

  • Arka kapı, işlev hook'lamak için dinamik bağlayıcının rtdl-audit özelliğini kullanıyor
  • Normalde rtdl-audit, geliştiricilerin özel paylaşımlı kütüphane yazarak sembol çözümleme gibi bağlayıcı olaylarına ilişkin bildirim almasını sağlayan bir özellik
  • XZ arka kapısı, ayrı bir paylaşımlı kütüphane yazmak yerine bellekte zaten kayıtlı olan varsayılan arayüzü çalışma zamanında yamalayarak sembol çözümleme rutinini ele geçiriyor
  • Dinamik bağlayıcının bellek alanındaki dl_audit global değişkeninde saklanan kötü amaçlı audit_iface yapısı, symbind64 callback adresini içeriyor
  • Dinamik bağlayıcı bu callback'i çağırdığında, tüm sembol bilgisi arka kapının kontrolüne geçiyor ve hedef işlevler için kötü amaçlı adres döndürülerek hook işlemi tamamlanıyor
  • dl_audit ve dl_naudit adresleri, dl_main ve dl_audit_symbind_alt işlevleri disassemble edilerek elde ediliyor
  • Arka kapıda komut çözümleme için dahili, minimal bir disassembler bulunuyor ve bu araç *audit adresleri gibi belirli değerleri bulmak için geniş ölçüde kullanılıyor

Doğrulanan arka kapılı dağıtımlar ve tespit bilgileri

• arka kapı içeren kaynak dağıtımları

  • xz-5.6.0
    • MD5: c518d573a716b2b2bc2413e6c9b5dbde
    • SHA1: e7bbec6f99b6b06c46420d4b6e5b6daa86948d3b
    • SHA256: 0f5c81f14171b74fcc9777d302304d964e63ffc2d7b634ef023a7249d9b5d875
  • xz-5.6.1
    • MD5: 5aeddab53ee2cbd694f901a080f84bf1
    • SHA1: 675fd58f48dba5eceaf8bfc259d0ea1aab7ad0a7
    • SHA256: 2398f4a8e53345325f44bdd9f0cc7401bd9025d736c6d43b372f4dea77bf75b8

• analiz edilen başlıca artifact'ler

  • bad-3-corrupt_lzma2.xz: 86fc2c94f8fa3938e3261d0b9eb4836be289f8ae
  • build-to-host.m4: b4dd2661a7c69e85f19216a6dbbb1664
  • good-large_compressed.lzma: 540c665dfcd4e5cfba5b72b4787fec4f
  • liblzma_la-crc64-fast.o: 212ffa0b24bb7d749532425a46764433

• arka kapı içerdiği bilinen kütüphaneler

  • Debian Sid liblzma.so.5.6.0
    • MD5: 4f0cf1d2a2d44b75079b3ea5ed28fe54
    • SHA1: 72e8163734d586b6360b24167a3aff2a3c961efb
    • SHA256: 319feb5a9cddd81955d915b5632b4a5f8f9080281fb46e2f6d69d53f693c23ae
  • Debian Sid liblzma.so.5.6.1
    • MD5: 53d82bb511b71a5d4794cf2d8a2072c1
    • SHA1: 8a75968834fc11ba774d7bbdc566d272ff45476c
    • SHA256: 605861f833fc181c7cdcabd5577ddb8989bea332648a8f498b4eef89b8f85ad4

• tespit adları

  • Kaspersky ürünleri, saldırıyla ilişkili kötü amaçlı nesneleri HEUR:Trojan.Script.XZ ve Trojan.Shell.XZ olarak tespit ediyor
  • Kaspersky Endpoint Security for Linux, Critical Areas Scan görevinin bir parçası olarak SSHD süreç belleğindeki kötü amaçlı kodu MEM:Trojan.Linux.XZ olarak tespit ediyor
  • Sağlanan Yara kuralı, CVE-2024-3094 ile ilişkili kötü amaçlı get_cpuid işlevini bulmak için liblzma_get_cpuid_function kuralıdır

[GN⁺]

Hacker News görüşleri

• Bu cümlenin gerçekte yaşananları olduğundan küçük gösterdiğini düşünüyorum.
  Arka kapının teknik yönlerinden daha korkutucu olan şey, sosyal mühendisliğin miktarı ve seviyesi. Arka kapı nihai üründü; bunun yerleştirilebilmesini sağlayan şey ise o noktada xz projesinin tamamının zaten uzun süredir kötü niyetli aktörlerin, yani “Jia Tan”ın ve çevresindekilerin kontrolüne geçmiş olmasıydı. Bakım sorumlusuna karşı bir yıldan uzun süre psikolojik savaş yürüttüler ve ne bakım sorumlusu ne de başka biri bunu fark etti.
  Casus romanı gibi bir olay; böyle bir şey mümkünse, şu anda başka projelerde daha neler oluyor diye merak ediyorum.
  Arka kapı kodunun kendisinde de aynı düşünce tarzı görülüyor. Yalnızca zararsız görünmeye çalışmakla kalmıyor; commit mesajları, yorumlar, değişken adları, komut seçimleri vb. üzerinden dışarıdan bakıldığında ne yaptığına dair aktif biçimde bir anlatı kuruyor, gerçekte ise tamamen farklı bir şey yapacak şekilde tasarlanmış. Kodu ilk inceleyen kişinin önce kendi anlayışından şüphe etmesine, sonra bir bug’dan şüphelenmesine, ancak epey sonra kötü niyetten şüphelenmesine yol açan bir yapı.

  • Gerçekten inanılması zor bir seviye. Komplo teorisi gibi gelebilir ama asıl yazarın zaman ayıramaz hâle gelmesi ve sonunda sahipliği kötü niyetli bir aktöre devretmesi için gerçek dünyada bir psikolojik operasyon yürütülmüş olabilir mi diye de merak ediyorum.
    Umarım hangi istihbarat kurumları varsa bu olayı daha derinlemesine araştırıyordur.
  • Umarım bu olaydan ders çıkarılır. Gerçekte çok şey oluyor. Dünyanın dört bir yanındaki devlet destekli kurumlar ve karaborsa örgütleri arasında görevi arka kapı elde etmek olan pek çok yapı var ve finansmanları da bol. Bu onların işi.
    Arka kapılarla ilgili her HN başlığında bu olasılığın paranoya ya da alüminyum folyo şapka muamelesi görerek reddedilmesini görmek sinir bozucu. Sanki hiç yaşanmayan bir şeymiş gibi davranılıyor; oysa bu sefer yakalanmış somut bir örnekten ibaret, yakalanmamış olanlar ise sayısız.
    Bu olay açık kaynak bir proje olduğu için keşfedilmesi nispeten daha kolaydı, buna rağmen şansımız yaver gitti. Şimdi kapalı kaynak ürünleri düşünün: arka kapı yerleştirmek, bir kuruluşa sızma ya da onu baskı altına alma meselesine indirgeniyor. Böyle şeyler sık sık olur. Kimse inanmak istemez ama yaygındır. Teknik altyapı şirketlerinde çalışmış kişilerin anlatacak birkaç hikâyesi vardır. NDA’ler ya da daha ağır sebepler yüzünden anlatmak zordur ama gerçekten olur.
  • Kodu inceleyen kişinin kendi anlayışından şüphe etmesini sağladığı noktasına tamamen katılıyorum. Bu işe giren manipülasyon, titizlik, sabır ve inat şaşırtıcı düzeyde.
    Bu, birinin takıntısının ürünü olabilir; ya da bu tür işleri birden çok proje üzerinde 9’dan 5’e mesai gibi yürüten özel bir güvenlik şirketinin veya devlet aktörünün işi olabilir.

• Şimdiye kadar ilginin arka kapının çalışmayı başarıp hedeflerine nasıl ulaştığına odaklanması doğal.
  Yine de hatalara ve aşırı tasarlanmış kısımlara dair daha derin bir analiz de görmek isterim. Bryan Cantril röportajında [1] Andrés, bunun dağıtım biçimini bile mutlaka bilerek hazırlanmış bir şey değil, hazır arka kapı bileşeni gibi durduğunu ve bu yüzden birçok aptalca yanı olduğunu söylüyor. Örneğin kendisini araştırmaya yönelten sembol tablosu sorgusu böyleydi.
  Benzer şekilde, neden RC4 ile 48 baytın kesilip çıkarıldığını da merak ediyorum [2].
  Daha fazla zamanları ya da daha iyi bir ekipleri olsaydı bunu nasıl daha iyi yapabilecekleri veya nerede daha büyük hata yaptıkları hakkında bir şeyler duymak isterim.
  [1] https://youtu.be/jg5F9UupL6I?si=gvXsYFXgagkGOMd4
  [2] https://twitter.com/matthew_d_green/status/17744729080201014...

• Doğru anladıysam, işe yarar bir sertleştirme önlemi her dinamik bağlantılı kütüphanenin kendi GOT’una sahip olmasını sağlamak ve dinamik bağlama bittikten sonra tabloyu salt okunur olarak işaretlemek olabilir. Yani dinamik sınırın ötesinden diğer taraftaki ifunc girdilerinin yamalanmasını engellemek.
  Bu, bir yerlere bağlanan ama çalıştırılmayan kodun tedarik zinciri güvenliğini iyileştirebilir.
  Daha da ileri gidip ifunc’ı bildirime dayalı bir şekilde uygulamak, böylece bağlanan her kütüphanede keyfî kod yürütülmesine yol açmamak daha iyi olabilir. Geriye dönük uyumluluk nedeniyle bunu bugün uygulamak zor olurdu ama uzun vadede katmanlı şekilde devreye alınabilir gibi görünüyor. Örneğin bir kütüphane “bildirime dayalı link ifunc” özellik bitiyle derlenirse, dinamik linker bağlı tüm kütüphanelerde aynı özellik bayrağı yoksa çalıştırmayı başarısız kılabilir.

  • Başka bir açıdan bakınca sorun derleme sistemi.
    Günümüzde çoğu kütüphane derlemesi, Turing-tam bir ortam gerektiren son derece karmaşık ve anlaşılması güç betiklerin çalıştırılmasıyla yapılıyor. Bu, saldırgana sonsuz bir saldırı yüzeyi veriyor ve derleme süreci ele geçirilirse fırsat doğuyor.
    Yürütücünün yalnızca sınırlı bir durum makinesi olduğu bildirime dayalı derleme süreçlerine geçmek yardımcı olur. Tüm kaynak parçalarının yeniden üretilebilir olması şartını da düşünmeye değer.
  • Hem doğru hem değil; ama çoğunlukla değil. Bu yaklaşım ifunc’ın bu şekilde basitçe kullanılmasını engellerdi, ancak önemli olan şu: bu arka kapının yazarı, hassas bir sürecin adres alanına giren bir kütüphaneye keyfî kod enjekte edebildi.
    O noktadan sonra tüm savunmalar etkisiz kalır. İsterse GOT’u yeniden yazılabilir olarak eşleyebilir; böyle bir davranış “şüpheli” diye tespit edilebilse ya da işletim sistemi bu geçişi engelleyebilse bile, enjekte edilmiş kod kontrol akışını yüzlerce farklı yolla tersine çevirebilir. Keyfî okuma/yazma, kod yürütme, her şey mümkündür. Bu aşamadaki bir ihlali engelleyecek güvenlik hafifletmesi yoktur. İsterse özel anahtarı sızdırıp doğrudan saldırgana gönderebilir ya da bir shell açabilir. Bu aşamada koruma tasarlamaya çalışmak boşuna.
  • Dinamik bağlama tamamlandıktan sonra tabloyu salt okunur olarak işaretlemek ne yazık ki işe yaramaz. Dinamik bağlama tembel yapılır; bu yüzden “tamamlandığı” bir an yoktur.
    Doğru fonksiyon işaretçisi ilk çağrıldığında yüklenir ve stub yerine tabloya eklenir; bu an keyfî derecede uzak bir gelecek olabilir. Nitekim gtk uygulamaları gibi büyük kütüphane ekosistemlerinde bağlı fonksiyonların çoğu hiç çağrılmaz.
  • Ana makine mimarisi için derliyorsanız ifunc’ı hiçbir kayıp olmadan tamamen kapatabilirsiniz. Gentoo’da -march=native ile derlemek yaygındır ve glibc’nin USE bayraklarında -multiarch ayarlamak ifunc’ı devre dışı bırakmayı kolaylaştırır. Olumsuz bir etki görmedim.
  • Kütüphane içe aktarmalarını sandbox içine alabilen bir programlama dili var mı?

• İlk 3 aşama açısından bu yazı, son 2 haftada bilinenlere çok fazla bir şey eklemiyor. Akış şeması olan iyi bir derleme yazısı sayılır.
  Ancak ikili dosyayı bu kadar ayrıntılı analiz eden kısım yeni görünüyor.
  Orada yer alan kaynak kod nasıl oluşturulmuş olabilir? Disassembler çalıştırıp kodun ne yaptığını anladıktan sonra tüm adları açıklayıcı adlarla mı değiştirdiler? 2 haftada yapılmış bir iş için oldukça büyük bir başarı gibi görünüyor.

  • Yazar GReAT.
    Global Research & Analysis Team, Kaspersky Lab
    https://securelist.com/author/great/
    Yazının yazarı Kaspersky Lab’in zararlı yazılım analiz ekibi gibi göründüğünden, ikili dosya tersine mühendisliğinde epey iyi olma ihtimalleri yüksek.
  • Beyaz ekran görüntüsünde kullanılan araç, bir decompiler olan IDA Pro.
    https://hex-rays.com/ida-pro/

• Asıl merak ettiğim şey, xz incelemesini tetikleyen SSH başlangıç gecikmesinin tam olarak neyden kaynaklandığı. Bunu ortaya çıkaran oldu mu?

  • Her bağlantıda ek ECC işlemi yapıyor, ama modern CPU’larda bunun 500 ms sürmesi beklenmez.
    Kodu tersine mühendislik edenlere göre komut mesajının SSH host anahtarıyla da ilişkilendirilmesi gerekiyormuş. Bu yüzden host anahtarı RSA anahtarıysa, her bağlantıda ek bir RSA şifre çözme işlemi de yapmış olabilir.
    Bu, gecikmenin nedeni olmaya yeterli gibi görünüyor.
  • Bunu kasıtlı yapmış olabilirler.
    Dışarıdan, önce kod enjeksiyonu denemeden sunucunun enfekte olup olmadığını anlamanın kolay bir yolu.

• Yazarlar glibc iç yapısını çok derinlemesine biliyor. Kaynak kodun içine boynunuza kadar gömülmeden bilinmeyecek türden şeyler ve birçok yeni teknik var.
  Özel ELF parser’ı ve disassembler o kadar karmaşık ki, bu kodun geçmişte başka bir yerde kullanılmadığını ya da gelecekte tekrar kullanılmayacağını hayal etmek zor.
  Bu olayın hak ettiği düzeyde ciddi bir soruşturma görüp görmeyeceğini merak ediyorum, ama pek öyle olacak gibi durmuyor.

• Sonuçta bu işi görünür kılan Valgrind hatasına ve SSH yavaşlamasına yol açan backdoor bug’ını analiz eden oldu mu?

  • Görünüşe göre açıkça hatalı bir bellek yazımıydı: https://www.mail-archive.com/[e-mail]...
    Valgrind “düzeltmesi” ifunc’ı devre dışı bırakmaktı; bunun sonucunda backdoor devre dışı kaldı ve hata ortadan kalktı.
    Yavaşlama, bildiğim kadarıyla backdoor’un yaptığı tüm sembol ve komut aramalarından kaynaklanıyordu.

• Tersinden bakarsak, saldırganın script ve kodlarda tespitten kaçınmak için harcadığı çabayı düşününce, tüm bu proje dikkat dağıtma amaçlı olabilir ya da aynı anda birden fazla deneme yürütülürken bir yedek plan olabilir.
  Böyle şeylerden bir adım önde olmak için ne yapmak gerekir? Topluluğun SSHD’ye odaklanması, sistemin genelindeki başka bölümleri etkiler mi? Başka teknik ya da sosyal yönleri?
  Alüminyum folyo şapka eğlenceli.

  • İyimser değilim. Flathub’daki flatpak ikili dosyalarının içeriğini gerçekten denetleyen neredeyse kimse yok. Gerçekten kaynaktan mı derlendi? Yazar öyle olduğunu kanıtlıyor gibi bir durum. Böyle bir backdoor kadar sofistike bir iletim mekanizmasına bile gerek olmayabilir.
  • Her şeyi kendiniz yazabilir ve doğrulanmış geliştiricilerden oluşan özel bir ekibiniz olabilir.
    Ya da Microsoft gibi bir yerden kapalı kaynak satın alıp, kodu daha sıkı inceleyecek kaynakları ve iradeleri olmasını umabilirsiniz.
    Ayrıca garip ağ etkinliğini ve yetki yükseltme girişimlerini tespit edecek iyi bir güvenlik operasyonları ekibine sahip olma yaklaşımı da her zaman var.
  • Benzer backdoor’ların bir adım önünde olmak için sshd trafiğini bir spiped tüneli içine sarmayı düşünüyorum. Spiped kaynak koddan derleniyor ve statik linkleniyor; son kararlı sürümü 2021’den.
  • Açık kaynak katkıcılarından şüphelenmek benim alüminyum folyo şapka fikrim. Belirli bir ülkeden oldukları için de değil, gerçekten hiç yüz yüze tanışılmamış gibi göründükleri için de değil.
    Sadece, üzerinde çalıştığı proje dışında geçmişi ya da izi olmayan katkıcılar bundan sonra tehlike işareti olarak görülmeli.
  • Alüminyum folyo şapkaya gerek yok. FOSS projelerine, daha ünlü olmadan önce de backdoor yerleştiriliyordu; bu seferki fark bunu devlet destekli aktörlerin yapması.
    Eski gruplardan GOBBLES, ADM, ac1db1tch3z, ~el8 de bunları yapıyordu; isec.pl gibi özel sektör “güvenlik araştırmacıları” da yaptı.
    Bu sefer sorun olan, devlet aktörlerinin temel projeleri düşük ücretle ayakta tutan şirket kapitalizmi dönemini istismar ediyor olması. Kötü niyetli aktörlerin hedeflerine ulaşmak için kaynakları fiilen sınırsız.
    Bu da sonuçta NSO, Zerodium gibi organizasyonlara yönelik talebi ve bu organizasyonların doğuşunu yaratmış oldu.
    Ondan önce exploit ve backdoor’ların değeri neredeyse yoktu; hacker’lar Qualys gibi şirketlerden sponsorluk ya da işe alım bekliyordu.

• Google’ın sıfır gün açıklarına yönelik hack analizlerini birkaç kez gördüm; onlar da gerçek dışı derecede etkileyiciydi, ama bu hack tarihin en büyüklerinden biri olacak gibi.

• xz deposunun GitHub’a yeniden yüklendiğini gördüm; Lasse ve yeni bir katkıcı temizlik yapıyordu. ifunc desteğini kaldırmışlar ve blob olmadan test dosyaları üretilebilsin diye test dosyası üretme kodunu depoya commit etmişler. Doğru yönde çalışıyorlar gibi görünüyor.