Xzbot: xz arka kapısı için notlar, honeypot ve exploit demosu

 (github.com/amlweems)
1 puan yazan GN⁺ 2024-04-02 | 1 yorum | WhatsApp'ta paylaş
  • xzbot, xz arka kapısını (CVE-2024-3094) incelemek için bir depo olup honeypot, ED448 açık anahtar yaması, arka kapı payload biçimi ve uzaktan kod yürütme demosunu birlikte sunar
  • Honeypot, OpenSSH’ye basit bir yama uygulayarak arka kapı biçimiyle eşleşen açık anahtar N değeriyle gelen bağlantı denemelerini sshd günlüklerine kaydeder
  • ED448 yaması, arka kapının imza doğrulama ve payload şifre çözmede kullandığı sabit kodlanmış açık anahtarı kullanıcının oluşturduğu anahtarla değiştirerek arka kapının tetiklenmesini sağlar
  • Arka kapı payload’u, SSH sertifikasının CA imza anahtarı N değerine yerleştirilir; a * b + c ile istek tipi oluşturulur ve Type 2, null ile sonlandırılmış komutu system() ile çalıştırır
  • Demo CLI, savunmasız SSH sunucusuna bağlanıp komut çalıştırma akışını gösterir; başarılı bir istismar INFO ve üzeri günlük üretmez

xzbot’un kapsamı ve bileşenleri

  • xzbot, xz arka kapısı CVE-2024-3094’ü incelemek için bir projedir
  • Dört bileşen içerir
    • honeypot: exploit denemelerini tespit etmek için sahte savunmasız sunucu
    • ed448 patch: liblzma.so’yu kendi ED448 açık anahtarını kullanacak şekilde yamalar
    • backdoor format: arka kapı payload biçiminin özeti
    • backdoor demo: ED448 özel anahtarının bilindiği varsayımıyla RCE’yi tetikleyen CLI

Honeypot: OpenSSH yamasıyla denemeleri tespit etme

  • openssh.patch, arka kapı biçimiyle eşleşen açık anahtar N değeriyle gelen bağlantı denemelerini kaydetmek için OpenSSH’ye uygulanan basit bir yamadır
  • Akış, openssh-portable deposunu klonladıktan sonra yamayı uygulayıp autoreconf, configure, make çalıştırma şeklindedir
  • Bağlantı denemeleri sshd günlüklerinde xzbot: magic 1 [preauth] ve payload bayt dizisi biçiminde görünür

ED448 açık anahtar yaması

  • Arka kapı, imza doğrulama ve payload şifre çözme için sabit kodlanmış ED448 açık anahtarı kullanır
  • Bu açık anahtar kullanıcının sahip olduğu bir anahtarla değiştirilirse arka kapı tetiklenebilir
  • Depo, saldırganın ED448 açık anahtarını ve seed=0 ile oluşturulmuş yedek açık anahtar değerini birlikte sunar
  • Başlangıç adımı, arka kapıyı içeren liblzma.so.5.6.1 paylaşımlı nesnesini hazırlamaktır
    • Örnek kaynak olarak xz-utils 5.6.1-1 Debian snapshot’ı verilir
    • pwntools kurulduktan sonra patch.py liblzma.so.5.6.1 çalıştırılırsa liblzma.so.5.6.1.patch oluşturulur
    • Ardından değiştirilmiş liblzma.so.5.6.1.patch paylaşımlı nesnesi kullanılarak sshd çalıştırılır
  • assets içinde örnekler bulunur

Arka kapı payload biçimi

  • Arka kapı, SSH sertifikasıyla bağlanırken payload’un CA imza anahtarı N değeri içine yerleştirilmesiyle tetiklenebilir
  • Bu payload’un saldırganın ED448 anahtarıyla şifrelenmiş ve imzalanmış olması gerekir
  • Dış yapı şu alanlardan oluşur
    • a: 32 bit
    • b: 32 bit
    • c: 64 bit
    • ciphertext: 240 bayt
  • İstek tipi a * b + c ile türetilir
    • Değer 3’ten büyükse arka kapı işlemeyi atlar
    • Type 1: amacı bilinmiyor ve 0 bayt bekliyor
    • Type 2: null ile sonlandırılmış payload’u system() ile çalıştırır
    • Type 3: amacı bilinmiyor ve 48 bayt imza verisi bekliyor
  • ciphertext, ED448 açık anahtarının ilk 32 baytı simetrik anahtar olarak kullanılarak chacha20 ile şifrelenir
    • Bu nedenle exploit denemeleri, verilen 32 baytlık anahtarla çözülebilir
  • Şifresi çözülmüş ciphertext içinde 114 baytlık imza, x ve y adlı 1 bitlik alanlar, uzunluk, komut dizesi vb. bulunur
    • x veya y ayarlanırsa biraz farklı bir kod yoluna gidilir
  • İmza, RFC-8032 ED448 imzasıdır
    • Girdi; 32 bit magic değeri, komuttan önceki 5 baytlık alan, isteğe bağlı olarak komutun length baytı ve sunucu hostkey’inin SHA-256 özetinin ilk 32 baytını içerir

Exploit demo CLI

  • CLI Go ile kurulur
    • go install github.com/amlweems/xzbot@latest
  • xzbot -h üç ana seçeneği gösterir
    • -addr: SSH sunucu adresi, varsayılan 127.0.0.1:2222
    • -seed: xz arka kapı anahtarıyla eşleşmesi gereken ED448 seed’i, varsayılan 0
    • -cmd: system() ile çalıştırılacak komut, varsayılan id > /tmp/.xz
  • Örnek, 127.0.0.1:2222 adresindeki savunmasız SSH sunucusuna bağlanıp id > /tmp/.xz komutunu çalıştırır
  • Savunmasız sunucuda system() çağrı konumuna watchpoint ayarlanırsa sshd sürecinin id > /tmp/.xz çalıştırdığı görülebilir
  • Çalıştırmadan sonra /tmp/.xz içinde uid=0(root) gid=0(root) groups=0(root) çıktısının kaldığı bir örnek sunulur

Süreç ağacı ve günlük özellikleri

  • Normal SSH bağlantısının süreç ağacı, sshd kullanıcı oturumu ve shell ile devam eder
  • Arka kapı çalıştırma örneği, xzbot -cmd 'sleep 60' sonrasında sshd: root [priv], sshd: root [net], sh -c sleep 60, sleep 60 öğelerinin göründüğü bir biçimdedir
  • Başarılı bir istismar INFO ve üzeri günlük girdisi oluşturmaz

Kaynaklar

İlgili okumalar

1 yorum

 
GN⁺ 2024-04-02
Hacker News yorumları

  • Herkesin kötüye kullanabileceği bir uzaktan kod çalıştırma açığı olmak yerine saldırganın özel anahtarını gerektirecek şekilde tasarlanmış olması oldukça ilginç
    İronik biçimde, güvenlik bilinci çok yüksek bir zafiyet gibi görünüyor

    • Asıl niyet muhtemelen arka kapının ömrünü uzun tutmaktı
      Herkesin girebileceği kocaman bir delik açsalardı hızla keşfedilip kapatılırdı; performans düşüşü olmasaydı da geniş çapta kötüye kullanılamadığı için sessizce uzun süre hayatta kalmış olabilirdi
    • Devlet destekli bir saldırı olarak bakınca, kendi vatandaşlarının da kullanabileceği sistemlere güvenli bir zafiyet yerleştirmek epey mantıklı
      xz’ye yapılan katkıların tamamı sonunda bu arka kapıyı koymaya yönelik çalışma gibi görünüyor; örneğin kötü amaçlı yükü saklayabilecek bir test framework’ü bile oluşturmuşlar
      xz üzerinde çalışmadan önce BSD’nin libarchive’ine de katkıda bulunmuştu ve orada da bir zafiyet ortaya çıktı
    • Gerçekten devlet destekli bir exploit gibi görünüyor
      Tasarım ve uygulama inanılmaz derecede rafineydi; performans sorununun keşfe yol açması neredeyse tamamen şans gibi hissettiriyor
    • Buna NOBUS deniyor: https://en.wikipedia.org/wiki/NOBUS
    • Yük imzasına hedef SSH host anahtarının dahil edildiği anlaşılıyor; doğru mu merak ediyorum
      Öyleyse sunuculara gelişigüzel gönderilemez ve tek bir host’a göndermek bile hesaplama açısından oldukça maliyetli bir yapı demektir

  • Bu olay tüm hafta sonu aklımdan çıkmadı
    Mekanizma ilginç ve iyi bir obfuscation derlemesi; sosyal mühendislik kısmı ise açık kaynak bakımcılarına utanç verici derecede tanıdık bir hikâye
    En ilginç olan, saldırı vektörü olarak kötü test verisini seçmeleri: iyi bir arşiv hazırlayıp yapısal olarak manipüle ettikten sonra fuzz test için kötü veri olarak kullanınca geri kalan adımlar inanılmaz kolaylaşıyor
    İlerisi için söylemek gerekirse, bu tür manipülasyonların ikili desen grafiklerinde görünmesi gerekir gibi geliyor
    Yöntemlerin geri kalanı, yük belirlendikten sonra büyük ölçüde sıradan obfuscation’a yakındı; ama aynı desenle başka test dosyalarına fark ettirmeden “yama” ya da tamamen yeni bir arka kapı eklenebilecek olması en parlak hamleydi
    GitHub’ın depoyu gizleyip kaldırması hiç yardımcı olmadı; bu olayı analiz etmeyi zorlaştırdı

    • Kullandığımız açık kaynak araçların derleme zamanı bağımlılıkları şüpheli görünmeye başladı
      O bağımlılığın özellikle xz’yi tercih ettiğini ve kurulu değilse, kolaylık özelliğiymiş gibi host makineye xz’yi de kurduğunu fark ettim
      Diğer bağımlılıklarda böyle davranmaması biraz tuhaf
      Bu tür uzun oyunlar ürkütücü; “kötülük” fiilen çalıştırılana kadar neyin kötü niyetli, neyin sadece garip olduğunu bilemiyorsunuz
    • Temel nedenlerden biri, test girdisi olarak kullanmak üzere depoya ikili dosyalar eklemek gibi görünüyor
      Özellikle bir test hatasını kanıtlamak için kullanılan “ikili çöp” dosyasıysa, kötü amaçlı içeriği saklamak için fazlasıyla iyi bir yer
    • Depoyu kaldırarak sonunda yalnızca saldırganların koda ve bilgi birikimine erişebilmesine yol açtılar

  • Topluluğun, özellikle de amlweems’in bu kadar hızlı kavram kanıtı kodu uygulayıp belgelemesi çok etkileyici
    Kripto işlevinde veya yük yükleme işlevinde ek zafiyetler yoksa, anahtar kırılana kadar diğer saldırganların tamamına bir güvenlik açığı açmamış bile olabilir
    Sonraki adım zafiyetli dağıtımları tespit etmenin yolunu bulmak; bu kolay görünmüyor. Ayrıca hardcoded anahtarla birilerinin SSH sunucularını aktif biçimde tarayıp taramadığını izleme yöntemini upstream’e eklemek de mümkün olabilir

    • Bu, orijinal exploit’in değil anahtarı değiştirilmiş sürümün kavram kanıtı
      Orijinal sürüm için kavram kanıtı, yayımlanmamış saldırgan özel anahtarını gerektiriyor
    • Saldırganın özel anahtarı olmadan ağ üzerinden zafiyetli bir dağıtımı tespit etmek zor olmaktan çok imkânsız görünüyor
      Yapılabilecek en iyi şey daha ince benchmark’lar olur; ama rastgele bir internet host’unun yavaş olmasının nedeni zafiyetli olması mı, uzakta olması mı, yoksa bilgisayarın kendisinin yavaş olması mı bilemezsiniz
      Geçmişte o host’a bağlantı denemelerinin ne kadar sürdüğüne erişiminiz de yok; yönlendirme değişiklikleri de var

  • Bu kavram kanıtını anormal süreç davranışı tespit araçlarıyla deneyen var mı merak ediyorum
    Carbon Black, AWS GuardDuty, Sysdig gibi ürünler buna giriyor; bu ürün ailesi, bunun gerçekten dağıtılmış olması hâlinde birinin nispeten hızlı fark edip etmeyeceğini test etmek için tam uygun bir örnek gibi görünüyor

    • Exploit’in normal sıkıştırma davranışını ne kadar benzer biçimde taklit ettiğine ya da onun içine ne kadar saklandığına bağlı olduğunu düşünüyorum
      GuardDuty, CrowdStrike veya Carbon Black gibi EDR’ler gibi süreçlerin içine bakmadığı için yakalaması zor olur; Sysdig ise konteynerlere ve bulut altyapısına baktığından exploit’in kendisini yakalaması zor görünüyor
      Ancak ayrıcalık yükseltmeden sonra tehdit aktörünün sonraki eylemlerinde anormallik yakalama ihtimali var
      Sonuçta exploit’in kendisini yakalama olasılığı en yüksek olanlar, endpoint süreçlerini izleyen EDR’ler veya upstream özgür/açık kaynak yazılımlardaki güvenlik sorunlarını izleyen yazılım tedarik zinciri değerlendirmesi gibi görünüyor
      İlginç biçimde bu daha büyük bir güvenlik konusuna bağlanıyor
      Geliştirme ekipleri performans düşüşü ve izolasyon önlemleri sırasında kullanıcı deneyimi sorunları nedeniyle sunuculara EDR kurmaktan hoşlanmayabilir; özgür/açık kaynak yazılım kullanımını sınırlayan politikalardan da hoşlanmayabilir
      Bu exploit, kurumsal düzeydeki “zafiyetin” tam ortasına saplanıyor; konuma göre maruziyeti sürdürmek için de düzeltmek için de gerekçe doğuyor
    • Sysdig cuma günü bir blog yayımladı
      “Çalışma zamanı tespitinin bir yolu, SSHD’nin kötü amaçlı kütüphaneyi yükleyip yüklemediğini izlemektir. Bu tür paylaşımlı kütüphaneler dosya adında sık sık sürüm bilgisini içerir” dedi
      Başka güvenlik şirketlerinde görmediğim gerçek tespit kuralı içeriği de blogda var
      https://sysdig.com/blog/cve-2024-3094-detecting-the-sshd-bac...
    • Bu ürün ailesinin tamamının çoğunlukla şişirme güvenlik ürünleri olduğunu düşünüyorum

  • Aşağıdaki bağlantıyı yanlış okumuştum; özgün içeriği kayıt amacıyla bırakıyorum
    Aynı e-posta dizisinin aşağısına bakınca, arka kapıyı commit eden kişinin yakın zamanda çekirdeğe katkı da yapmış gibi göründüğü söylenmişti; ama asıl analiz gerçekten çok iyi, bu tür yazıları okumak faydalı
    https://www.openwall.com/lists/oss-security/2024/03/29/10

    • Bu yama serisini Jia Tan değil, Lasse göndermiş
      Lasse de bunun hiç acil olmadığını ve bu merge window'a girmeyeceğini söylemişti; aklı başında kimse Lasse'yi kötü niyetli bir aktör olmakla suçlamıyor
    • Aksi kanıtlanana kadar Lasse Collin, Jia Tan değildir
    • Referans verilen yama serisi henüz çekirdeğe girmedi
    • Tesadüf olabilir ama JiaT75, havacılıkta kaçırılma anlamına gelen transponder kodu 7500'e oldukça benziyor

  • Bu olayın birkaç yıl önceki Audacity olayıyla saçma derecede çok benzer yanı var
    Cookie guy, bıçaklandığını ve federal polisin olaya dahil olduğunu iddia etmişti; bu da olayın 4chan'den çok daha büyük bir aktörle bağlantılı olma ihtimaline işaret ediyor
    O dönemde birçok kişi yalnızca Muse Group'un ilgili olduğunu sanıyordu ama belki de bir Rus devlet aktörüydü
    Bundan önce Audacity'de çok sayıda telemetri ve arka kapı olduğunu, fork ettikten sonra bunları ilk commit'te kaldırdığını iddia etmişti
    Belki Audacity'de de gerçekten bir arka kapı vardır; kaynak kodunu kontrol etmek gerekecek

    • Dikkatli olmak lazım, APT28 epey tehlikeli
      Son zamanlarda operasyonlarını APT29 ile birleştiriyorlar; ben olsam cozy bear'ı uyandırmazdım
    • Cookie guy kim?

  • Derleme zamanındaki honeypot openssh.patch https://github.com/amlweems/xzbot/blob/main/openssh.patch olmadan, gerçek exploit'in çalışma zamanında bunu nasıl yaptığını merak ediyorum
    Zincir opensshd -> systemd bildirimi -> geçici bağımlılık olarak dahil edilen xz idi; liblzma.so.5.6.1 belleğe yüklendikten sonra nasıl geriye doğru openssh_RSA_verify'a ulaşıp hook ya da patch uyguladığını bilmek istiyorum

    • liblzma yüklenirken ELF'in GOT tablosuna kötü amaçlı kodun adresini patch'liyor
      libcrypto'dan önce yüklenmişse bir sembol denetim işleyicisi kaydediyor; muhtemelen glibc'ye özgü bir özellik gibi görünüyor ve libcrypto'nun sembolü çözümlendiğinde bildirim alıp GOT patch'ini erteleyebiliyor
    • ifunc

  • Bu exploit'in yalnızca SSH bağlantısı geldiğinde mi çalıştığını bilen var mı merak ediyorum
    GitHub'daki string listesinde DISPLAY ve WAYLAND_DISPLAY yer alıyor
    https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
    Bunların SSH ile açık bir ilgisi yok; dolayısıyla bağlantı yokken de bir şey yapmış olma ihtimali var
    Kodu çalıştırmış ama SSH sunucusunu internete açmadığı için güvende olduğunu varsayan kişiler için önemli olabilir

    • Muhtemelen bir terminal açıksa ya da GUI oturumunda çalışıyorsa exploit'in devreye girmesini engelleyen bir kill switch olma ihtimali yüksek
      Yani birinin tespit, yeniden üretme veya debug etmeye çalıştığı durumlardan kaçınmak için konmuş bir düzenek
    • X11 oturum yönlendirmesiyle de ilgili olabilir
      Güvenilmeyen bir makineye bağlanırken kapatılmazsa bağlanan taraf açısından yaygın bir güvenlik açığına dönüşür

  • “Başarılı istismar log girdisi oluşturmaz” ifadesi, bu exploit fark edilmeseydi saldırganın ele geçirilmiş host üzerinde ilgili “bağlantı” için tek bir sshd log'u olmadan root olarak rastgele komut çalıştırabileceği anlamına mı geliyor, merak ediyorum

    • Evet
      Uzaktan kod çalıştırma, log düşülmeden önceki bağlantı aşamasında gerçekleşiyor
    • Yine de karşılık gelen bir login olmadan SSH trafiği kalmış olurdu
      Acaba hangi anomali tespiti bunu yakalayabilirdi

  • Test dosyalarını ayrı bir depoya ayırıp derleme sırasında kullanılamaz hâle getirmek bu saldırıyı zorlaştırabilir miydi, merak ediyorum
    Mantık şu: Derlemeye dahil olabilen her şey insan tarafından okunabilir olmalı

    • “Derlemeye dahil olabilen her şey insan tarafından okunabilir olmalı” genel olarak benimsenmesi iyi olacak bir ilke
      Bu saldırıyı bir uçak kazası gibi ele alıp tekrar başarılı olma ihtimalini azaltacak yeni kurallar getirmeliyiz
      Katkıda bulunan herkesin tek tek doğrulanması mümkün olmasa bile, gürültülü test verileri kolayca ayrılabilir olmalı