CrowdStrike CSAgent.sys çökmesinin nedenine dair ilk ayrıntılar

 (twitter.com/patrickwardle)
1 puan yazan GN⁺ 2024-07-22 | 1 yorum | WhatsApp'ta paylaş
  • Dünya genelindeki Windows çökmeleri, CrowdStrike CSAgent.sys’in hatalı bir bellek adresine başvurmuş olmasına dayanan bir akışla ilk aşamada analiz edildi
  • Sorunlu komut mov r9d, [r8] idi; R8 içinde, işaretçi dizisinden indeksle alınmış eşlenmemiş bir adres bulunuyordu
  • C-00000291-...xxx.sys dosyaları kernel sürücüsü değil, CSAgent.sys’in okuduğu karartılmış veri gibi görünüyordu; CrowdStrike bunların Channel Files yapılandırma dosyaları olduğunu doğruladı
  • CrowdStrike, C-00000291- dosyasının mantık hatasını tetikleyerek OS çökmesine yol açtığını açıkladı ve Channel File içindeki null byte’ın neden olduğu tahminini reddetti
  • Bu dağıtım, sürüm güncellemesi değil içerik güncellemesi olarak işlendiği için bazı istemcilerin staging kontrollerini baypas eden vakalar oldu; crash report ise neden analizinin temel ipucu hâline geldi

CSAgent.sys çökme akışı

  • İlk analiz, CrowdStrike’ın CSAgent.sys dosyasının tersine mühendisliğine ve tek bir crash dump’a dayanan statik analizdi
    • Windows sistemi veya VM olmadan materyaller paylaşılarak ek inceleme talep edilmişti
    • CSAgent.sys, VirusTotal’a yüklenmiş dosya temel alınarak analiz edildi: VirusTotal örneği
  • Çökme noktası mov r9d, [r8] komutuydu
    • R8 eşlenmemiş bir adresti
    • Bu değer, RAX içindeki işaretçi dizisinden RDX indeksiyle (0x14 * 0x8) alınan adresti
  • C-00000291-...32.sys gibi diğer .sys dosyaları gerçek sürücüler değil, karartılmış veri gibi görünüyordu
    • CSAgent.sys’in bu dosyalara başvurduğuna veya bunları okuduğuna dair emareler vardı
    • Dosyalar silindiğinde çökmenin çözülmesi nedeniyle, dosya içeriğinin CSAgent.sys çökmesini etkilemiş olabileceği ihtimali gündeme geldi
    • Debugging yapılırsa bunun daha kolay doğrulanabileceği de eklendi
  • Paylaşılan .zip içinde birden fazla CSAgent.sys sürümü, IDB ve çeşitli C-....sys dosyaları yer alıyordu
    • En yeni dosyalardan birinin “fix” içeriyor gibi göründüğü açıklaması vardı
    • Paylaşım bağlantısı: Google Drive zip

Channel Files ve CrowdStrike’ın doğruladıkları

  • Kevin Beaumont, soruna yol açan .sys dosyalarının channel update files olduğunu ve hatalı formatın üst seviye CS sürücüsünü çökerttiğini yazdı
  • CrowdStrike’ın teknik açıklaması ilk analizle aynı yönü doğruluyor
    • C-...sys dosyaları kernel sürücüsü değil, Channel Files adlı yapılandırma dosyalarıdır
    • C-00000291- bir mantık hatasını tetikledi ve bunun sonucunda CSAgent.sys üzerinden OS çökmesi meydana geldi
    • Bağlantı: CrowdStrike teknik açıklaması
  • Bazıları boş bir 0x0 Channel File’ın neden olduğunu tahmin etti, ancak CrowdStrike sorunun Channel File içindeki null byte ile ilgili olduğunu reddetti
    • Malware Utkonos, dosyanın 0xaaaaaaaa ile başlaması gerektiğine dair kontrolü işaret etti: ilgili gönderi
  • Channel update’in bazı istemcilerin staging kontrollerini baypas ederek dağıtıldığı doğrulandı
    • Bazı IT sorumluları, CrowdStrike politikasında en son sürümü yok sayacak şekilde ayar yaptıklarını; ancak bu güncelleme sürüm güncellemesi değil içerik güncellemesi olduğu için baypas edildiğini doğruladı
    • İlgili gönderi: ResetEra başlığı
  • CrowdStrike patentlerinde de channel files ifadesi birçok kez geçiyor
    • Örnek olarak US11822515B2 ve US11645397B2’den bahsediliyor
    • Arama terimi channel file assignee:(Crowdstrike, Inc.)

crash report ve macOS System Extensions ipuçları

  • crash report, CrowdStrike çökmesini anlamak için bir araçtı ve macOS’teki başka bir 0day’i ortaya çıkarmak için de kullanılmıştı
    • İlgili Black Hat sunumunun başlığı “The Hidden Treasure of Crash Reports?” idi
    • Bağlantı: Black Hat sunum sayfası
  • Apple’ın 3rd-party kext’i kullanımdan kaldırıp user-mode System Extensions’a geçmesi olumlu değerlendiriliyor
    • Ancak bu geçiş sürecinde kernel panic, yetki yükseltme ve güvenlik araçlarının unload edilmesi sorunlarının yaşandığı yazıldı
  • macOS’te user-mode System Extensions’ı destekleyen kernel kodunda çok sayıda bug vardı; kullanıcı moduna taşınan güvenlik araçlarının Apple’ın temel kext’lerinde geniş çaplı kernel panic’e yol açtığı vakalar yaşandı
  • Çekirdek macOS System Extension framework’ündeki yetki yükseltme sorunu için CVE-2019-8805’ten bahsediliyor
  • System Extensions işleme kusurları nedeniyle yetkisiz kod veya kötü amaçlı yazılım güvenlik araçlarının unload edilmesini tetikleyebilir
    • Örnek olarak, en güncel macOS’te bile güvenilir System Extension olarak çalışan LuLu güvenlik duvarının sonlandırılabileceği yazıldı
    • Bu bug yalnızca LuLu’ya özgü bir sorun değildir

İlgili okumalar

1 yorum

 
GN⁺ 2024-07-22
Hacker News yorumları

  • “BSOD’ye yol açan bir içerik güncellemesiymiş, silince düzeliyormuş” sözünü görür görmez bunun bozuk ikili veri ile kötü yazılmış bir parser birleşimi olduğuna £100 yatırabileceğimi düşündüm.
    Son 10 yıl kadar bilgisayarlarla epey ciddi uğraştım, siber güvenlik hiç yapmadım ama neredeyse tüm CVE’lerin, çökmelerin, hataların, performans düşüşlerinin ve acıların, ikili veriyi makinenin yeniden okuyacağı veri yapılarına deserialization etme sürecinden çıktığını düşünüyorum.
    İnsan programcılar uç durumları atlıyor, imperatif diller de buna izin veriyor. Sıkıştırma açma algoritmaları, font kontur okuyucuları, görüntü/video/ses parser’ları, oyun verisi parser’ları, XML/HTML parser’ları, OpenSSL’in sertifika/imza/anahtar parser’ları ve bu seferki CrowdStrike EDR’ın içerik parser’ı dahil hepsi buna giriyor.
    İkinci hipotezi de hesaba katıp £50 daha ekleyebilirim.

    • Bence aynı anda en az beş şey yanlış gitti. Kernel modülündeki zayıf hata işleme tüm işletim sistemini öldürdü; bozuk dosyayı sürekli parse ederek boot loop oluşturdu ve dosyayı silmedi ya da bozuk olarak işaretlemedi.
      Bozuk dosya ya iç testlerden geçti ya da iç test yoktu; ayrıca güncellemenin uygulanma zamanına ilişkin bireysel ayarlar da yok sayılmış gibi görünüyor. Üstelik tüm dünyaya aynı anda dağıtılarak hasar sınırlandırılamadı ve en başta dosya bozulmasının neden oluştuğunu da hâlâ bilmiyoruz.
    • 2023’ün en büyük 25 ortak zayıflık listesi burada: https://cwe.mitre.org/top25/archive/2023/2023_top25_list.html
      Güvenilmeyen verinin deserialization’ı (CWE-502) 15. sıradaydı; 1. sırada sınır dışı yazma (CWE-787), 4. sırada ise serbest bırakıldıktan sonra kullanım (CWE-416) vardı. 2019’dan beri her seferinde listede yer alan zayıflıklar https://cwe.mitre.org/top25/archive/2023/2023_stubborn_weaknesses.html adresinde derlenmiş.
    • “Neredeyse %100”den ziyade yaklaşık %98 gibi görünüyor. Kalan %2’yi mantık hataları, yapılandırma hataları, kötü varsayılanlar ve en baştan güvensiz tasarım seçimleri dolduruyor.
      Not: Bilgi güvenliği alanında 30 yılı aşkın süredir çalışıyorum.
    • Bunu imperatif programlamaya bağlamanın zor olduğunu düşünüyorum. Örneğin Rust imperatif ama switch’te atlanan durumları epey iyi yakalıyor.
      Buna karşılık 20 yıl önce kullandığım bir Scheme türevi fonksiyoneldi ama tüm durumların kapsanıp kapsanmadığını kontrol etmiyordu; Haskell’in ghc’sinde de birkaç yıl önce bu kontrol varsayılan olarak açık değildi. Şimdi değişti mi bilmiyorum.
    • Hangisinin daha ölümcül olduğunu bilmiyorum: fiilen hata/başarısızlık işleme olmaması mı, yoksa “kanal güncellemesinin müşterinin staging kontrolünü bypass edip herkese dağıtılması” mı?
      Bazı IT sorumluları CS politikasını en yeni sürümü yok sayacak şekilde ayarladıkları hâlde bunun “sürüm güncellemesi” değil “içerik güncellemesi” olduğu için bypass edildiğini doğruladı. İçerik güncellemesi istemciyi bozabiliyorsa staging kontrollerini veya politikaları bypass edememeli.

  • CS gibi rootkit tabanlı endpoint izleme yazılımlarının gerçekten gerekli olup olmadığı ayrı konu; bu alanı daha etik standartlara taşımak için açık kaynak alternatifler güçlü olabilir.
    Temel araç açık kaynak olursa tam olarak ne yaptığı şeffaf olur; backdoor ya da ciddi bug olmadığını kamuoyu denetleyebilir. Öte yandan güvenlik ekiplerinin zararlı yazılım imzaları sağlaması hâlâ bir iş modeli olabilir.

    • Katılmıyorum. Kolide bu yöndeki girişimlerden biri ama gerçek pratikleri ve şirket içinde kullanım biçimi tescilli ürünler kadar karanlık.
      Kullanıcı açısından açık kaynak bir izleme rootkit’inin daha iyi test edildiğine, geliştirildiğine ya da benim çıkarımı gözettiğine güvenemem. Sorun, izleme yazılımı kategorisinin tamamı. Var olmamalı. Böyle şeyler kullanan şirketler güvenliği anlamıyor, çalışanlarına güvenmiyor ve çalışmak için iyi yerler de değil.
    • Açık kaynak alternatif olarak GRR var: https://github.com/google/grr
      Google’ın tüm istemci cihazlarında bulunuyor.
    • Red team’de EDR bypass’ı için zararlı yazılım geliştiren biri olarak, EDR sistemlerinin şart olduğunu söyleyebilirim. “Rootkit tabanlı endpoint izleme” ifadesi, oyun topluluklarında sık görülen yanlış anlamalardan kaynaklanan hatalı bir tanım.
      Bu araçlar sofistike tehditlere karşı kritik koruma sağlıyor ve gerçekten yakalıyor. Windows makinelerin dahil olduğu bir testte EDR yoksa işim %90 kolaylaşıyor.
      OpenEDR gibi açık kaynak EDR’lar da var ama eski ve telemetri kalitesi kötü: https://github.com/ComodoSecurity/openedr. GitHub’daki çeşitli proof-of-concept kodlarını toplayıp üretim ortamı için EDR yapmak gerçekçi değil ve güvenli de değil.
      EDR sensörünün kendisi bir saldırı hedefi hâline geliyor. Saldırgan açısından EDR çoğu zaman tek engel olduğu için, açık kaynak yapılırsa kötü niyetli kod katkılarıyla geliştirmeyi yavaşlatma veya zafiyet yerleştirme riski artar. Güvenlik sensörü geliştirmek, karşınızdakinin kim olduğundan emin olamadığınız son derece hasmane bir ortamdır.
      Gerçekte durum neredeyse bunun tersi. Elastic Security’nin tespit kuralları gibi açık kaynak zararlı yazılım sezgisel kuralları var: https://github.com/elastic/detection-rules. Elastic de kernel driver dahil EDR sunuyor ve deneyimime göre bypass etmesi daha zor olanlardan. Windows’ta driversız bir EDR yaparsanız işim kolaylaşır.
      EDR sensörleri zaten güvenlik araştırmacıları ve saldırganlar tarafından “denetleniyor”. Zayıflık bulmak için reverse engineering ve debugging sürekli yapılıyor. EDR’ın kernel mode shellcode’u olduğu gibi alıp çalıştırması düzeyinde bir sorun bulunursa elbette yayımlanır.
    • CrowdStrike’ın sunduğu değer, imza veritabanını sürdürme ve dünya genelindeki saldırı kampanyalarını izleyebilme yeteneği. Bu, açık kaynak projelerin sahip olması zor olan ciddi kaynaklar gerektiriyor.
      Basit bir hash sorgulama programından çok daha karmaşık.
    • Güvenlik aslında sadece satın alınabilecek ya da dış kaynak kullanılabilecek bir ürün değil; ama gerçeklik böyle bir hâl aldı.

  • Test dağıtımında neden yakalanmadığını anlamak zor. Dış dünyaya dağıtıldığında sorun çıkmasına neden olan farkın ne olduğunu merak ediyorum.
    Dağıtımdan önce test etmediklerine inanmak zor; şirketlerin de üçüncü taraf bileşenleri dağıtmadan önce bir test ortamı olması gerekir. Geliştirme sırasında bir paket kurarken başarısız olması ya da sorun çıkarması yaygındır, ama kimse bunu test etmeden doğrudan üretim ortamına koymanın iyi bir fikir olduğunu düşünmez. Bu durumun neden farklı olduğunu bilmiyorum.

    • Tahminimce kod değişiklikleri için ve veri dosyaları için ayrı iki pipeline olması kuvvetle muhtemel.
      Pipeline 1’de yazılım kodu güncellemeleri önemli değişiklikler olarak görülüp üretim dışı ortamlardan ve canary testlerinden geçirilerek yeni bir “sürüm” küresel ölçekte dağıtılmış olurdu.
      Pipeline 2’de ise içerik/kanal güncellemeleri muhtemelen farklı ele alınmıştır. Bu yoldan yalnızca yeni kötü amaçlı yazılım imzaları gibi şeyler dağıtıldığından, yeni dosyanın standart biçimde bir veri dosyası olduğu ve “çalıştırılmadığı”, yalnızca okunduğu varsayılmış olabilir.
      Bu pipeline’ın kendisi başta test edilmiş ve tatmin edici şekilde çalıştığına karar verilmiş olabilir; ancak üretilen veri dosyasının bütünlüğünü doğrulayan veya daha da önemlisi, yazılımın güncel kullanım sürümüne dağıtıldığında hatasız çalıştığını kontrol eden bir test aşaması olmayabilir.
      Kanal dosyalarını her gün okuyan ajan yazılımı, Pipeline 1’de mümkün olan tüm veri dosyası boyutları ve sahte içerikler için “kapsamlı” biçimde test edilmiş olmalıydı. Hatalı veri dosyalarının elbette hata olarak reddedilmesi gerekirdi.
      Bu olayda tam senaryo, ikinci yoldaki bozuk pipeline’ın alışılmadık biçimde hatalı bir veri dosyası üretmesi ve bu belirli durumun yazılım sürümünün geliştirme/test/dağıtım pipeline’ında öngörülmemiş ya da test edilmemiş olması olabilir.
      Eğer doğruysa çıkarılacak ders açık: Yalnızca “veri” dağıtımı bile olsa, pipeline ne kadar standartlaşmış ve istikrarlı olursa olsun, geniş ölçekli dağıtımdan önce test şart. Maliyet ve gecikme artar ama buna katlanmak gerekir. Zaten insanların “güvenlik” yazılımına para ödemesi de buna benzer.
      Kurumsal müşteriler de aynı şekilde yeni dağıtım paketlerini BT ortamlarının üretim dışı alanlarında test etmeli veya tüm üretim filosuna izin vermeden önce canary dağıtımı uygulamalı.
    • Şu an eldeki sınırlı kanıtlara bakınca, bu dağıtımın çok test edilmiş olması pek olası görünmüyor. Keyfî bir SLA’yı tutturmak için tanım güncellemelerinin gevşek işletildiği ve sonunda patladığı açıklaması daha makul.
      Şirket endpoint güvenliği ve ağ anomali tespitine girmeye çalıştığında, birçok potansiyel müşteri çeşitli CVE türleri ve önem dereceleri için 4 saatlik SLA talep ediyordu. Yani 7/24 nöbetçi güvenlik mühendisleri ve 4 saatin altında tanım üretimi/dağıtımı gerekiyordu; bu 4 saat de hedeflerin %100’üne dağıtılabilir olması anlamına geliyordu.
      Zero-day için 4 saat içinde kaliteli tanımlar yazıp dağıtmak zor, bunları test pipeline’ından geçirmek daha da zor; gerçekten kapsama sağlayan yeni testler yazmaktan söz etmiyorum bile. O alanda bunun “normal” sayıldığını görünce hızla vazgeçtik. CS’nin de burada benzer şekilde çalışıyor olmasına şaşırmam.
    • Tanım güncellemesinin otomatik test dağıtımı, mevcut tanım tüketicisi sürümünü çalıştırmayıp yalnızca etkilenmeyen eski bir sürümü çalıştırmış olabilir.
    • Başarısız bir sürümün sadece “normal mühendisliğin bir parçası” gibi ele alındığı yerler gördüm. Kimse mükemmel değildir gibi.
    • Hiç test yapmadıklarına inanmak zor. Virüs imzalarını motora karşı test etmiş ama nihai sürüm çıktısı olan .sys dosyasını kontrol etmemiş olmaları ve paketleme aşamasında bir bug girmiş olması ihtimalini merak ediyorum.
      Bu yine de kötü bir durum, ama hiç test etmeden yayınladılarsa gerçekten şok edici düzeyde ihmalkârlık olur.

  • Anlamadığım şey çok daha az teknik ama daha önemli bir nokta: Etki alanı neden bu kadar büyüktü?
    Çok daha az kritik servislerde bile otomatik izleme ve rollback ile çok daha yavaş dağıtımlar yaptım. Önce müşteri trafiği olmayan betaya dağıtılır, sorun yoksa filonun küçük bir kısmına geçilir, ardından güncellemeyi alan host oranı yavaşça artırılır.
    Bu yöntemle sorun anında durdurulurdu; bunun yaygın uygulama olduğunu sanıyordum.

    • Bu bir yazılım güncellemesi değil, imza veritabanı güncellemesiydi. Mümkün olduğunca hızlı dağıtılması gereken türden.
      Yeni bir virüs öğrendiğinizde, o zaten sahada yayılmıştır; bu yüzden her dakika önemlidir. Bir gün geciktirip sunucunun 20 saat önce ele geçirildiğini öğrenmek istemezsiniz.
    • Kod güncellemeleri için canary release prosedürü olsa bile, yapılandırma güncellemeleri ayrı bir kanal gibi görünüyor.
      Muhtemelen beklenti, potansiyel olarak kırıcı değişiklikleri istemeseniz de en yeni virüs tespit kurallarını almaya devam etmenizdi. Kaçırılan edge case, test edilmemiş yapılandırmanın mevcut kodu bozması durumu.
      Kaynak tamamen tahmin, haber makalesinde alıntılamayın.
    • Bu olayın etkisi düşünüldüğünde, ilk dağıtım için büyük bir Windows istemci staging ortamı olması gerekirdi.
      Bu sorunu önlemenin ya da en azından oluşma riskini azaltmanın birçok yolu vardı, ama her zamanki gibi kâr insanların önüne geçti.
    • Kendi kuruluşlarında kendi yazılımlarını kullanıyor gibi görünmüyorlar. Muhtemelen kendi şirketleri içinde bile bunun pek faydalı bir yazılım olduğunu düşünmüyorlar.
    • Yanıt başlığının içinde cevap var. Kıyas için, bir AV şirketinde çalışırken, MS’in bildirdiği sayılar doğruysa çok daha büyük bir müşteri tabanına günde yaklaşık 4 kez güncelleme gönderiyorduk.

  • Bu olayda Microsoft’un rolünün neredeyse hiç tartışılmaması şaşırtıcı. Microsoft, doğrudan çökmeye yol açan hatanın sorumlusu değil; ancak Windows’un böyle durumlara dayanıklı olmasını sağlayacak teşviklerin, yani kâr ve rekabet baskısının eksik olduğu bir ortam yarattı.
    Microsoft, iş istasyonu bilişimi alanında fiilen tekel konumunda ve artık altyapıya yakın bir yerde durduğu için ürününün güvenliğini, güvenilirliğini ve işlevlerini garanti etme konusunda özen yükümlülüğü var.
    Rekabet olmadığı için Microsoft, Windows’ta yenilik yapmayı bıraktı; bunların bir kısmı bu kesintiyi önleyebilirdi. Örneğin CrowdStrike, macOS ve Linux’ta kullanıcı alanında çalışıyor; Windows, CrowdStrike’ın kullanıcı alanında çalışması için gereken işlevleri sağlayamıyor mu?
    Uygulama sandboxing alanındaki yenilikler, CrowdStrike’ın talep ettiği düzeyde denetim yetkisine duyulan ihtiyacı azaltamaz mıydı?
    Microsoft, dünya bilişim altyapısının anahtarlarını fiilen rekabetsiz biçimde elinde tutuyor ve neredeyse hiç denetlenmiyor. Windows bir zamanlar Microsoft gelirinin %80’inden fazlasını oluşturuyordu, ancak şimdi yaklaşık %10 seviyesine düştü.
    Özel bir şirketin para peşinde koşmasında sorun yok; ancak ürün hastanelerin, havayollarının ve kritik altyapının işletilmesi için vazgeçilmezse, kârlılığı artırmak için yalnızca yapay zeka asistanlarına ve reklamlara bel bağlayamaz.
    Bence Microsoft tüketicilere karşı özen yükümlülüğünü ihmal etti ve CrowdStrike bunun bir belirtisi. Hükümetler masaüstü çalışma alanı pazarında rekabeti ciddi biçimde teşvik etmeli ya da Microsoft Windows ürününü düzenlemeye tabi tutmalı.

    • Doğru. Birçok cephede yaşanan bir başarısızlık ve onlarca yıldır süren sistemsel çürümenin işareti.
      Windows gelir payının düşmesinin bir avantajı, MS’in artık Windows’u dokunulamaz bir kutsal alan gibi görüp elinde tutmayabilecek olması.

  • CrowdStrike’ı doğrudan kullanmıyorum ve bildiğim kadarıyla sistemime hiç kurmadım. Son şirket cihazımda buna benzer bir şey çalışıyor gibiydi; yanılıyorsam düzeltin.
    CS sürücüsü önce kuruluyor ve kaldırılamıyor; muhtemelen uzaktan izleyici bunu tespit ediyor ve imzalı bir sürücü olduğu için kurcalanmasını da zorlaştırmak üzere epey çaba harcanmış gibi görünüyor.
    Peki bu sürücü, son kullanıcının istediği gibi silebileceği imzasız bir veri dosyasını mı yüklüyor? Böyle bir dosyayı son kullanıcı keyfi olarak ekleyip sürücünün yapmaması gereken biçimde davranmasına yol açabilir mi?
    Kötü niyetli bir aktörün kötü amaçlı bir veri dosyası kullanarak başka bir büyük çaplı kesinti yaratmasını ya da daha kötüsü kernel yetkisi elde etmesini neyin engellediğini merak ediyorum.

    • Bu dosyalar, yönetici yetkisi olsa bile kullanıcı tarafından silinemez veya değiştirilemez. Mümkün olsaydı antivirüsü kapatmak fazla kolay olurdu.
      Bu ancak dosya sistemini başka bir işletim sisteminden bağlayarak mümkün; genelde BitLocker bunu engeller.

  • CrowdStrike müşterilerinin bu tür güncellemelerin yayınlanması konusunda söz hakkı var mı, yoksa CrowdStrike’ın şirketin tüm makinelerinde tam uzaktan kod çalıştırma yetkisine sahip olmasını öylece kabul mü ediyorlar?
    En azından sertifika otoriteleri ve kriptografi tarafındaki insanların bunu kendi sistemlerinden uzak tutabilmesini umarım.

    • CrowdStrike gibi üçüncü bir tarafa sürekli uç nokta güvenliğini dış kaynak olarak verirken, korunacak tüm uç noktalar üzerinde uzaktan kod çalıştırma ve ring 0 yetkisi vermemenin bir yolu var mı bilmiyorum.
      CrowdStrike’ın bu kısmı otomatikleştirmesi zaten ürünün özü.
    • Biz hayattayken otonom araçların otomatik güncellemeleri milyonlarca insanı öldürecek.
      Belki de bunu göremeyiz. Çünkü o milyonlardan biri biz olabiliriz.
    • “İçerik”, yani neyin kötü amaçlı yazılım sayılacağına ilişkin otomatik güncellemeler zorunludur ve güncellemeyi geciktirme seçeneğini baypas eder: https://twitter.com/patrickwardle/status/1814367918425079934

  • Bu “kanal dosyasının” CS sürücüsü tarafından imzalanıp doğrulanıp doğrulanmadığını bilen var mı merak ediyorum. Değilse ring 0 rootkit’e giden büyük bir açık gibi görünüyor.
    Kanal dosyasını kurmak için yetki gerekir, ama bir kez mümkün olduğunda sistemin çok daha derinlerine saklanabilir. Kanal dosyası segmentation fault’a neden olabiliyorsa muhtemelen daha fazlasını da yapabilir.
    Bu kadar yüksek yetkide çalışan bir şeye giren tüm girdiler en azından bütünlük kontrolünden geçmelidir. Bu temel bir şey. Kanal dosyasının basitçe silinebiliyor olması bile kurcalamaya karşı bir mekanizma olmadığını düşündürüyor.