XZ arka kapısı: “Bu bir kimlik doğrulama atlatması değil, RCE; ayrıca geçitli ve yeniden oynatılamaz”

• xz arka kapısına ilişkin tersine mühendislik ön analizine göre bu davranış basit bir kimlik doğrulama atlatması değil, uzaktan kod çalıştırmaya (RCE) daha yakın
• Hook'lanmış RSA_public_decrypt içinde sunucu host key imzasının sabit bir Ed448 anahtarıyla doğrulandığı akış temel unsur olarak öne çıkıyor
• İmza doğrulamasını geçerse payload system() fonksiyonuna iletilip çalıştırılabiliyor
• Analiz, izin alınarak paylaşılan ön bulgulara dayanıyor; Bluesky gönderisi alıntı gönderiler veya gömülü içerikler içeriyor
• Arka kapı geçitli ve yeniden oynatılamaz olarak özetleniyor; bu nedenle aynı girdinin basitçe tekrar kullanıldığı saldırılardan farklı değerlendirilmesi gerekiyor

---

xz arka kapısının yürütme akışı

• İzin alınarak paylaşılan tersine mühendislik ön analizi, hook'lanmış RSA_public_decrypt üzerine odaklanıyor
  • Sunucunun host key için imzasını sabit bir Ed448 anahtarıyla doğruluyor
  • Doğrulamadan sonra payload system() fonksiyonuna iletiyor

Sınıflandırma ve kısıtlar

• Bu davranış, kimlik doğrulama atlatması değil uzaktan kod çalıştırma (RCE) olarak sınıflandırılıyor
• Arka kapı, gated/unreplayable özelliklerine sahip olarak özetleniyor
• Orijinal Bluesky gönderisi alıntı gönderiler veya başka gömülü içerikler içeriyor

[GN⁺]

Hacker News görüşleri

• Bu konuya dair ek tersine mühendislik sonuçları var. Backdoor’un dizgeleri gizlemek için kullandığı prefix trie’dan çıkarılmış sembol yeniden eşleme bilgilerini içeriyor ve tersine mühendislik/analizin kendisinden de saklanmaya çalışmış gibi görünüyor
  https://gist.github.com/smx-smx/a6112d54777845d389bd7126d6e9...
  Çözümlenmiş dizgelerin tam listesi burada
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01
  OpenSSL’in iç yapısına çok hâkim olmayan biri olarak bakınca, N değerinin rsa_st içindeki n alanından alındığı anlaşılıyor
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Bu değer bir BIGNUM ve değişken uzunluklu bir tip gibi görünüyor
  https://github.com/openssl/openssl/blob/56e63f570bd5a479439b...
  Backdoor, uzaktaki saldırgandan gelen sertifikadan bu değeri çıkarıp ChaCha20 ile çözmeyi deniyor; başarılı olursa sonucu system()’e veriyor. system(), mevcut sürecin çalıştığı kullanıcı yetkileriyle tek satırlık bir shell script’i çalıştıran basit bir sarmalayıcıya yakın
  Doğru anladıysam bu, açık anahtar atlatmadan daha kötü. Açık anahtar atlatma olsaydı, teoride yalnızca oturum açmaya çalışan kullanıcının yetkileri elde edilirdi ve sıkılaştırılmış SSH yapılandırmalarında root girişinin engellenmiş olma ihtimali yüksekti
  Ama bu, sshd sürecinin kendi bağlamında uzaktan kod çalıştırma olduğu için, root olarak çalışan bir sshd ise payload da root olarak çalıştırılabilir. Yaygın bir uzaktan kod çalıştırma olarak pratikte neredeyse en kötü senaryoya yakın

  • Uygun sandboxing, SELinux ve hafifletme teknikleri varsa saldırganın root yetkisiyle bir şeyler yapmasını engelleyebilir. Ancak SSH daemon’una etkili biçimde sandbox uygulamak çok zordur
  • Akıl almaz. 1 milyar bilgisayarın yetkileriyle ne yapılacağına nasıl karar verilir, hayal bile edemiyorum

• Bu backdoor performans sorunu yüzünden bulunmasaydı, daha sonra bulunma olasılığının ne kadar olduğunu merak ediyorum. Performans sorununu koddaki bir hata/düzeltilebilir kusur olarak anlamıştım; bunu yakalayabilecek araçların olup olmadığı da önemli
  Bu tür sorular, bu tip backdoor’ların ilk kez mi görüldüğünü yoksa yalnızca ilk kez mi ortaya çıkarıldığını anlamak açısından çok ilgili

  • Kötü niyetli IT aktörlerinin çok olduğu bir ortamda yaklaşık 1 yıl çalışmış biri olarak, bulunma olasılığının her zaman epey yüksek olduğunu düşünüyorum. Gizliliği korumak hayal etmesi zor ölçüde enerji gerektirir; gerçeğin tutarlılığını korumak da aynı şekilde
    Küçük bir hata her şeyi yıkabilir; bazen tek bir cümle bile zincirleme reaksiyon başlatıp incelikle kurulmuş bir planı ortaya çıkarır
    Ceza soruşturmaları her gün böyle yürür. Polis işinde kaynak kısıtları vardır, ama yazılıma her gün hobi olarak analiz yapanlar, bunu hobi gibi sürekli yapan uzmanlar ve meslek olarak yapan uzmanlar bakar
    Sonunda bir gün bulunma olasılığı yüksekti
    XZ saldırısı çok iyi yürütülmüş ve neredeyse bir başyapıt. Bir devlet kurumunun dâhil olmuş olmasına şaşırmam. Ama aynı zamanda inanılmaz şanslıydı. Şu anda sorun olarak işaretlenen şeylerden biri bile bulunmuş olsaydı, yalnızca ben değil birçok meslektaşım da uzun bir takibe girerdi
    Çıkarılabilecek sonuçlardan biri şu: xz/liblzma açık kaynak olmasaydı böyle bir sorunu bulmak imkânsız olurdu. Elbette açık kaynak olduğu için en başta mümkün hale gelmiş bir yanı da var; ama bunun Windows ya da MacOS’un içinde olduğunu hayal edin
  • Exploit kullanılmamış olsaydı bulunma olasılığı oldukça düşük olurdu. Saklandığı yer iyi seçilmişti. Fiilen kod tabanının dışındaydı; denetçilerin bakmadığı bir yerdeydi
    Ancak kullanmazsanız amacınıza ulaşamazsınız. Ne kadar çok kullanılırsa ileride tespit edilme olasılığı da o kadar artar. SolarWinds ile karşılaştırılabilir
  • Önümüzdeki birkaç ay boyunca birçok kişinin bu yönde epey kafa yoracağını düşünüyorum. Sorun bunun kod incelemesi mi, yoksa bir tür davranış analizi mi olduğu
    Kişisel olarak system() çağrısı biraz özensizdi ve bir ikili işlev tarayıcısının o yolu potansiyel olarak bulabileceğini düşünüyorum
  • Bunu yakalamak zor olurdu gibi geliyor. sshd yaması kabul edilebilir bir aşama olan linkleme zamanında gerçekleşiyor; bu analiz doğruysa bu bir master key backdoor’u da değil, dolayısıyla tipik oturum açma denetim izleri yok. Ayrıca sshd’nin başka süreçler başlatması başlı başına elbette izin verilebilir bir şey
    Çok sıkı bir SELinux politikası, sshd’nin shell dışında bir şey çalıştırmasını yakalayabilir; ama bu düzeyde sıkılaştırma çok nadirdir
    Hedefin dışından keşfetme meselesi de zaten bir bakıma denenmiş oldu. Birçok kişi payload’a valgrind vb. ile baktı ama göremedi. Debug ortamında bulunmamak için de oldukça iyi korunmuş. Çünkü payload’ın altındaki görünür altyapı ASan gibi araçlarla uyumlu değil
    Linklense bile kod main()’den çok önce çalıştığı için, debugger ile liblzma çevresini kurcalasanız da genelde çalıştığı anı gözlemleyemezsiniz
    strace olsaydı süreç oluşturulduktan sonraki tüm sistem çağrılarını ve linker davranışını görebilirdi. Ancak şu ana kadar anlaşıldığı kadarıyla payload bu aşamada etkinleşip etkinleşmeyeceğine karar vermek için sistem çağrısı yapmıyor; argv, environ vb. şeylere bakıyor gibi görünüyor
  • İlginç bir bağlantı olarak, Ken Thompson saldırısının da PWB’de bellek performansı hatası yüzünden keşfedildiği akla geliyor
    [0] https://en.wikipedia.org/wiki/PWB/UNIX
    [1] https://news.ycombinator.com/item?id=38020792

• İkili payload içinde kodlanmış bir dize var gibi görünüyor
  https://gist.github.com/q3k/af3d93b6a1f399de28fe194add452d01...
  Bu dize bir kill switch olarak çalışıyor
  https://piaille.fr/@zeno/112185928685603910
  Eğer gerçekten öyleyse, azaltma yöntemlerinden biri şu olabilir

  echo "yolAbejyiejuvnup=Evjtgvsh5okmkAvj" | sudo tee -a /etc/environment  
  

  • Mutlaka -a eklenmeli. Aksi halde environment dosyasını silebilirsiniz. Ayrıca genel olarak doğru olan, kötü amaçlı kod içermeyen bir sürüme yükseltip yeniden başlatmaktır
  • Fazla tuhaf. Kendi sistemini korumanın bir yolunu bırakmak isteyen bir devlet aktörü kokusu çok güçlü

• Backdoor’un tam olarak ne yaptığını kısaca açıklayabilir misiniz? Bunu henüz biliyor muyuz? Backdoor’un kendisi payload değil gibi; kötü amaçlı bir sıkıştırılmış dosya mı gerekiyor, yoksa sshd sürecine hook atıp uzaktaki saldırganın kötü amaçlı paketlerini mi dinliyor, merak ediyorum
  Orijinal metin, saldırganın SSH oturumunun kimlik doğrulama öncesi aşamasında kötü amaçlı payload gönderebildiği izlenimi veriyor; ama exploit’in neden hiçbir zaman ortaya çıkmayabileceğini de anlamıyorum. Kod reverse engineering ile çözülebiliyorsa bir proof of concept de yazılabilir değil mi?
  Sonuçta saldırgan bu backdoor’a sahip bir makineyi nasıl kontrol ediyor?

  • Doğru şekilde çalındığında açılan bir kapı düşünün. Gizli vuruşu bilmeyen biri için sadece duvar gibi görünür ve duvar gibi davranır. Gizli vuruş yoksa, en başta açıldığını kanıtlamanın bile bir yolu olmayabilir
    Buradaki durum da benzer. xz şüpheli bir şey yapmadan önce bazı verileri çözmeyi deniyor. Asimetrik bir yöntem olduğu için gizli şifreleme anahtarını vermeden de çözme doğrulaması yapılabiliyor. Çünkü karşılık gelen açık anahtara sahip
    Gizli anahtarı bulmak pratikte imkânsız olduğundan ve payload’un şifresi çözülemezse belirgin biçimde farklı davranmadığından, exploit kodu hiçbir zaman yayımlanmayabilir. Exploit kodu oluşturmanın tek yolu gizli anahtarın bir şekilde bulunması; pratikte de bu ancak backdoor geliştiricisinin sızdırmasıyla mümkün
  • Okuduklarıma göre saldırı vektörü şöyle görünüyor. sshd başlarken libsystemd’yi yüklüyor, o da hack kodunu içeren XZ kütüphanesini yüklüyor
    XZ kütüphanesi, RSA imzalarını doğrulayan OpenSSL fonksiyonlarının kendi sürümlerini enjekte ediyor
    Biri SSH’ye giriş yaparken kimlik doğrulama için imzalı bir SSH sertifikası sunduğunda, bu değiştirilmiş fonksiyonlar çağrılıyor
    Sertifika, normal giriş sürecinde kullanıcı adı veya rol gibi assertion bilgileri içerebilir ve bu bilgiler, sertifikanın belirli bir kullanıcı girişinde geçerli olup olmadığını belirlemeye yarar. Ancak değiştirilmiş fonksiyon, belirli bir saldırgan anahtarıyla imzalanmış bir sertifika algılarsa, sertifikanın bazı alt alanlarını çıkarıp sistem komutu olarak çalıştırıyor. Çalışma bağlamı sshd, yani root kullanıcısı
    Ne yazık ki saldırganın imzalama anahtarını bilmiyoruz; yalnızca hack kodunun doğrulamada kullandığı açık anahtarı biliyoruz. Temelde saldırgan, enfekte sistemde root olarak keyfi komut çalıştırma imkânına sahip ve geride en fazla başarısız bir giriş denemesi kadar iz kalır. İnternete açık sistemlerde bu tür denemeler zaten çok olur
  • Henüz tam olarak ne yaptığı bilinmiyor gibi. Ancak “replay edilemez” kısmını şöyle anlıyorum: Payload yanlışsa veya saldırgan anahtarının imzası doğrulanmazsa backdoor normal davranışa geri dönüyor
    Kritik nokta, saldırganın anahtar imzasının gerekli olması. O anahtar sızmadıkça veya RSA algoritması kırılmadıkça, başka araştırmacıların ya da üçüncü tarafların bu backdoor’u kötüye kullanması imkânsız. RSA kırılırsa bundan çok daha büyük sorunlarımız olur
  • Açık anahtarlı kriptografi doğru kullanıldıysa ve istismar edilebilir bir bug yoksa, reverse engineering yapsanız bile proof of concept oluşturamazsınız
  • Dağıtılan exploit kaynak kod değil ikiliydi ve test verilerinin içine ustaca gizlenmişti. Ayrıca payload’u doğrulamak için yayımlanmamış bir özel anahtar kullanıyor
    Şu an için exploit’i yalnızca saldırgan çalıştırabildiğinden tarama yapmak da imkânsız. Performans düşüşü gibi ikincil etkiler dışında tespit edilmesi zor; nitekim gerçekten de böyle fark edildi

• Bu kadar çok Linux sunucusunun her gün kullandığı kritik bir paketin, finansman eksikliği yüzünden asıl yazar tarafından sürdürülemez hâle gelmesini anlamak zor. Açık kaynakta bir şeylerin değişmesi gerekiyor
  Çözümlerden biri, belirli bir ölçeğin üzerindeki şirket veya işletmelere bakım maliyeti ödemeyi zorunlu kılan bir lisans olabilir

  • İnsanlar böyle bir lisansa şiddetle karşı çıkar. “Artık özgür değil” diye büyük bir tepki başlar ve ilgili kişi/kuruluş cancel edilir
  • Gerçekten finansman eksikliği mi, yoksa tükenmişlik mi merak ediyorum
  • Önerilen AB Cyber Resilience Act çözüm rolünü üstleniyor. Kısaca, ister güvenlik duvarı ister tost makinesi olsun, ürünün ömrü boyunca ortaya çıkan güvenlik açıklarından satıcı sorumlu oluyor
    Dolayısıyla satıcının açık kaynağı güvenli tutmak için motivasyonu oluşuyor. Bakımcıya para vermek, kod denetimi yaptırmak veya katkı sağlaması için tam zamanlı birini işe almak gibi
  • Önemli olmak ile gerekli olmak farklı şeyler. Bu paket önemli olmaktan çok gerekli bir paket
  • xz kadar karmaşık bir şeye neden ihtiyaç olduğunu anlamak zor. bzip2 kodu küçük ve tek bir kişinin zamanının çok küçük bir kısmıyla bile bakımı yapılabilir olmalı

• Şu anda xz deposuna girince GitHub kullanım şartlarını ihlal ettiği için devre dışı bırakılmış görünüyor. Devre dışı bırakılması kendi başına anlaşılır, ama GitHub’ın kodu ve geçmişi bırakıp bir banner göstermesini, yalnızca kötüye kullanılabilecek özellikleri kapatmasını isterdim
  Böylece araştırmacılar ve diğer insanlar exploit’ten ders çıkarabilir. Daha önemsiz bir durumda bir kütüphane kötü amaçlı kod barındırdığı için deposu kaldırılmışsa, insanlar bunu sadece önemsiz bir şey diye geçiştirebilir

  • Otomasyon araçlarının indirmesini istemiyor olabilirler
  • Bu deponun GitHub event’lerini CSV olarak burada görebilirsiniz: https://github.com/emirkmo/xz-backdoor-github
    Kaynak koduyla ilgileniyorsanız bulması kolay. Bu kod ve Git deposu, dünyanın dört bir yanındaki çeşitli Git depolarına bağlı ve sürümlerde de kaynak birkaç kez paketlenmiş durumda
  • xz’nin kendi Git mirror’ı var; tüm commit’leri görebilirsiniz

• Pek bilinmeyen bir açık kaynak oyunun fiilî bakımcısı olarak, geliştiricilerin gelip gittiğini gördüm. Değerli katkıların hepsini olduğu gibi birleştiriyorum.
  Bazı işbirlikçiler, çeşitli kodlama stilleriyle C ve C++’ın birbirine karıştığı bir ortamda özelliklerin epey derinine iniyor. Uygulama ayrıntılarının tamamını her zaman kavrayamıyorum ama aklımın bir köşesinde, biri gerçekten kötü bir arka kapı koyarsa projenin biteceği düşüncesi var.
  Neyse ki oyun çok obscure ve saldırı yüzeyi de çok küçük. Yine de iyi niyetle Windows ikili dosyalarını imzalama hevesimi durdurdu.
  Bu xz arka kapısı gerçekten devasa bir kâbus; asıl geliştiriciler ve buna karışan herkes adına üzülüyorum.

  • Elbette doğru, ama bu yalnızca yazılıma özgü bir sorun değil. Hatta anlamlı bir açıdan buna “sorun” denip denemeyeceğinden de emin değilim.
    Orman yolunda yürürken geçen bir araba sizi öylece ezip geçebilir. Sürücünün yakalanmama ihtimali yüksektir, bunu engellemenin yolu yoktur ve polis de yanınızda değildir. Yazılım arka kapılarından çok daha korkutucu olan bu senaryo, aslında bir şeyler yaparak yaşayabilmek için kabul etmek zorunda olduğumuz asgari risklerden biridir. Gerçekte böyle şeyler de olur.
    Ama sonuçta insanların büyük çoğunluğu başkalarına aktif olarak zarar vermeye çalışmaz. İnsanın yaptığı her şey hep bu varsayım üzerine kuruluydu ve hâlâ öyle.
    Kod incelemelerini biraz daha sıkılaştırmanın, linter’ları, CI’ı ve örüntü eşleştirmeyi daha çok kullanmanın, kod imzalamayı daha yaygınlaştırmanın ve insanların kimliklerini doğrulamanın bu tür olayları engelleyeceği yanılsaması asıl sorun. Bu, dünyayı her ayrıntı düzeyinde yönetip kontrol edebileceğimiz ve etmemiz gerektiği yönündeki Silicon Valley tarzı sanrının bir belirtisi. Böyle “tedaviler”, engellemeye çalıştıkları hastalıktan çok daha kötü olabilir.
  • ZeroMQ’dan merhum Pieter Hintjens, Optimistic Merging adlı uygulamayı savunuyordu. Bu, katkıları kod incelemesini veya CI sonuçlarını beklemeden hemen birleştirme yaklaşımıdır. Gevşek birleştirme ölçütleri kullanmak tamamen alakasız bir yaklaşım değil.
    [1]: http://hintjens.com/blog:106
    Katkıcıların projeye keyifle katıldığı bir topluluk oluşturmanın avantajını anlıyorum. Ama bu, projeyi net bir vizyon ya da yön olmadan büyütüyor ve sonunda başkalarının katkılarını ortak bir standarda uydurmak için bakımcıya aşırı yük bindiren bir yöntem gibi gelmişti.
    Gerçek kod incelemesi gelecekte belirsiz bir zamana erteleniyor; o zaman incelemenin titiz olup olmayacağı, kimin sorumluluk alıp bunu yapacağı ya da sorunları düzelteceği de belirsiz. Sonuçta kullanıcılara ne dağıtıldığını kontrol edemeyen bir kaos reçetesi gibi geliyor.
    Kötü amaçlı kod dağıtımı sorunu da var. İlgili blog yazısının yorumlarında da bu konu geçiyor ve Pieter, xz vakasıyla birebir aynı senaryoyu anlatıyor.
    “Mallory’nin sabırlı ve aldatıcı olduğunu, yeterince uzun süre geçerli bir katkıcı gibi davranarak projenin kontrolünü ele geçirdiğini ve ardından yavaş yavaş arka kapı yerleştirdiğini varsayalım. O zaman dikkatli kod incelemesi de yardımcı olmaz. Mallory’nin bakımcı olacak kadar güven kazanması yeterlidir; bu, mümkün olup olmama değil, yöntem meselesidir.”
    Kendisi “en iyi savunma topluluğun büyüklüğü ve çeşitliliğidir” sonucuna varıyor.
    Ama dikkatli kod incelemesinin bu tür olayların gerçekleşme olasılığını gerçekten azaltabileceğini düşünüyorum. İster güvenilir katkıcıdan ister dışarıdan gelsin, tüm katkıları titizlikle incelerseniz garip davranışları veya “A yapıyor” denip gerçekte B yapan commit’leri daha erken yakalama olasılığı artar.
    Optimistic Merging’in daha büyük ve daha çeşitli bir topluluğa yol açıp açmadığı da tartışmalı. Katı katkı yönergelerine sahip olup da aktif toplulukları olan pek çok proje var. Ayrıca kötü amaçlı yamaların ne zaman ve nasıl yakalanacağına yanıt vermiyor.
    xz’deki sorun küçük bir topluluk değil, topluluğun hiç olmamasıydı. Tek bir kötü niyetli aktör projenin kontrolünü ele geçirdi ve neredeyse hiç kimsenin denetimi yoktu. Katkı yönergeleri topluluk büyüklüğünde bir etken değildi; Optimistic Merging kullanılmış olsun ya da olmasın bu olay yaşanacaktı.
    [2]: http://hintjens.com/blog:106/comments/show#post-2409627
  • Şirketlerin ağ çevresi güvenliği için muazzam çaba harcarken, geliştirme organizasyonlarında rutin olarak brew install cask ya da vi/emacs/vscode eklentileri kurulduğunu görmek beni hep şaşırtıyor.
    Rust, varsayılanları en güvenli olan programlama dili/topluluk olarak görülebilir; işaretçi numaralarına neredeyse izin vermeyecek düzeyde güvenlik öncelikli bir tasarıma sahip. Ama en yaygın ve önerilen kurulum yolu şöyle; ben de tam bir ikiyüzlü olarak sık sık böyle yapıyorum.
    https://www.rust-lang.org/tools/install
    Bu sadece bir örnek. “Bunu curl ile çekip sh’e pipe et” diyerek uzaktan kod çalıştırmayı kendi kendimize açarken, aynı anda birinin unsafe bloğu üzerine tartışma alışkanlığı çok fazla insanda kas hafızasına dönüşmüş durumda.
  • Açıkçası iyi niyetimizin istismar edildiğini fark etmemiz yalnızca an meselesiydi. “Hızlı kır, hızlı düzelt” ya da “projemin sahipliğini devralacak biri var mı?” gibi davranışlar sorun davet ediyor; ama açık kaynak, kodlamaya yönelik ücretsiz bir sevgi emeği olduğu sürece bunlar olmadan yaşamayı hayal etmek de zor.
    Böyle bir şeyin yaşanması üzücü ama şaşırtıcı değil. Bu tür kötü niyetli aktörlere karşı daha iyi araçların, üstelik açık kaynak olarak, ortaya çıkmasını umuyorum.

• Bu arka kapının ortaya attığı sorular var. Aynı ekip ya da benzer bir ekip tarafından yerleştirilmiş başka hangi arka kapılar var? Bu tür ekiplerden kaç tanesi faal? Bu tür sızma saldırılarına açık bağımlılık sayısı ne kadar? Sektörümüzde bu tür gizli operasyonların hedef alabileceği saldırı yüzeyi ne kadar geniş?
  apache httpd, postgres, mysql, nginx, openssh, dropbear ssh, haproxy, varnish, caddy, squid, postfix gibi başlıca ağ servislerinin, bunların tüm bağımlılıklarının ve o bağımlılıkların tüm committer grafiklerinin çıkarılması; nerelerin en yüksek değere sahip olup en az izlendiğini anlamak için ilk adım olabilir.
  Bu, birinin böyle bir şeyi denediği ilk örnek olamaz. Yalnızca başarısız olup açığa çıkan ilk örnek. Linux çekirdeğine yönelik denenip yakalanmış arka kapıları biliyoruz, ama bu uzaktan yapılan bir saldırı ve tamamen farklı nitelikte.

  • Neden herkesin yaptığı gibi zero-day kullanmak yerine arka kapı oluşturmaya karar verdiler?
    Neden tespit edilse bile bir hata gibi görünebilecek masum görünümlü bir şey dağıtmak yerine, tam işlevli bir arka kapı uygulayıp dağıtım yöntemini de gizlemeye çalıştılar?
    Bunlar bilinçli kararlar olmalı. Bunun nedeni, hedefin ne olduğuna dair ipucu verebilir.
  • Debian’ın, root olarak çalışan ve internetten bağlantı alan bir servisin gereksiz kütüphaneler yüklemesine neden olacak şekilde neden yama yaptığını da sormak gerekiyor.

• Bu, exploit’i uzaktan taramak için elimizde olmayan saldırganın özel anahtarına ihtiyaç olduğu anlamına geliyor gibi. Diğer tek seçenek, yerelde tespit betiği çalıştırmak.

  • Bazı tarayıcıların seçebileceği tamamen berbat bir yöntem, RSA kimlik doğrulaması sunulduğunda “potansiyel olarak savunmasız” diye işaretlemek olur. Çoğu SSH sunucusu RSA kimlik doğrulaması sunar; hatta SecSH RFC’si de bunun uygulanmasının zorunlu olduğunu söyler. Bu da insanları parola kimlik doğrulamasına geri dönmeye teşvik edebilir.
    Bu sorunun gerçek sistemlerde geniş ölçekte yayıldığı ortaya çıkmadıkça, böyle bir yaklaşım; geçmişte benzer “uzmanların” her yıl parola değiştirilmesini isteyip gerçek güvenliği düşürürken kâğıt üzerinde güvenliği daha iyi gösterdiği olaydan bile daha kötü görünüyor.
  • İstemci açık anahtarı belirli bir parmak iziyle eşleştiğinde imza doğrulama kodu çalışıyor gibi göründüğünden, zamanlama bilgisiyle tespit mümkün olabilir.
    Arka kapının imza doğrulaması yaklaşık 100µs sürecektir; dolayısıyla parmak izi eşleşen anahtarların işlenmesi, eşleşmeyenlere göre bu kadar daha uzun sürmeli. Bu zaman farkı en azından LAN üzerinde gerçekçi biçimde tespit edilebilir; tarayıcı hedefe yakın bir konumdan çalıştırılıyorsa internet üzerinden de mümkün olabilir.
    Tekrarlanan kimlik doğrulama hatalarından sonra istemci IP’sini engelleyen sistemlerde tarama daha zor olacaktır.
    (https://bench.cr.yp.to/results-sign.html Ed448 doğrulamasını yaklaşık 400 bin çevrim olarak gösteriyor; 4GHz’de bu 100µs’ye karşılık gelir.)
  • Tweet’te “yeniden oynatılamaz” deniyor. Neden yeniden oynatılamadığını merak ediyorum. Arka kapı eklenmiş sshd’nin bir challenge verdiği ve saldırganın bunu imzalaması gereken bir yapı mı var?

• Popüler olmayan bir görüş olabilir ama tüm operasyona hayranlık duymamak elde değil. Elbette kınıyorum, ama yine de hayran kalıyorum. Fikirden uygulamaya kadar gerçekten bir sanat eseri gibiydi ve bu kadar erken yakalanması büyük bir şanstı.

  • Payload, SSH oturumu açılırken rastgele 0,5 saniyelik duraklamalara yol açmasaydı muhtemelen uzun süre fark edilmeyecekti.
    Bir dahaki sefere saldırganların, insanın beklediği işlemlerde tuhaf gecikme sıçramaları oluşturmayan bir payload geliştirmesi muhtemel.
    Nedense Kim Dotcom’un yasa dışı dinleme hedefi olduğunu fark etmesi aklıma geliyor. Bunun nedeni MW3’te ping’inin aniden çok yükselmesiydi. Araştırınca yalnızca kendi paketlerinin fiziksel olarak çok uzaktaki GCSB ofisinden geçirilerek yönlendirildiği ortaya çıkmıştı. GCSB’nin Yeni Zelanda’da süresiz oturum hakkına sahip kişileri dinleme yetkisi yok. Sonunda Yeni Zelanda başbakanından kişisel bir özür almıştı.
  • “Her şeye rağmen birleştirilmemesi gereken o kişi harika bir iş çıkardı. Korkunçtu, ama harika bir işti.”
    Bence en dahice kısım, sızılacak projenin seçimiydi. Geriye dönüp “Hans”ın IFUNC pull request tartışmasını okumak insanın içini acıtıyor, ama bu projenin neden seçildiğini gerçekten çok iyi gösteriyor.
    “Jia” ve “Hans”ın arkasında kaç kişi olduğunu, iletişimi ve kod katkılarını nasıl analiz edip stratejiye döktüklerini bilmek isterdim. Mail listesinde baskı kuruyormuş gibi görünen üçüncü kişilikler gibi bazı yönler biraz özensiz kurgulanmış görünüyor.
    Bu yüzden hâlâ sofistike küçük bir ekip, hatta tek bir kişi tarafından yapılmış olma ihtimali de var. Bir devlet aktörü olsaydı, böyle bir operasyon için bütün gün sahte kişilikler oluşturup sürdüren insanların bulunacağını düşünürdüm.
    Birisi “Bu üç kullanıcının biraz kaba biçimde bastırması tuhaf, bunlar kim? Hesapların hepsi aynı dönemlerde oluşturulmuş. Şüpheli. Neden biri sahte hesaplarla bunu bu kadar ısrarla zorlasın? Araştırmalıyım” diye düşünseydi işleri zorlaşırdı. Toplam harcanan çabaya kıyasla o kısım dikkatsiz, kötü planlanmış ya da bütçesi yetersizdi.
  • Katılıyorum, ama sosyal mühendislik kısmı özellikle acımasız hissettiriyor.
  • Bence o kadar da popüler olmayan bir görüş değil. Birçok açıdan son derece etkileyici bir saldırı. İnceydi, yıllar boyunca inşa edildi ve saldırgan soruşturmayı tetikleyen tuhaf performans düşüşü hatasını yapmasaydı muhtemelen haberimiz olmayacaktı.
    Dramatik bir varsayım eklersek, saldırgan patlatacağı bilgi nükleer bombasından korkup kasıtlı olarak işi bozmuş da olabilir.
    Nihai sonucu tiksintiyle karşılarken saldırının karmaşıklığını da kabul edebiliriz.
  • “Hayranlık” doğru kelime mi bilmiyorum, ama oldukça etkileyici bir operasyon olduğu kesin.