3 puan yazan GN⁺ 4 시간 전 | 2 yorum | WhatsApp'ta paylaş
  • GitHub’da barındırılan onlarca açık kaynak proje, hacker’lar tarafından ele geçirilerek koda parola hırsızı kötü amaçlı yazılım enjekte edildi; bunun üzerine Microsoft bu projelere erişimi engelledi ve soruşturma başlattı
  • Etkilenen projelerin çoğu, bulut hizmeti Azure ile Claude Code, Gemini CLI, VS Code gibi yapay zeka geliştirme uygulamalarıyla kod yazarken kullanılan araçlarla ilgili
  • Kullanıcılar yapay zeka kodlama uygulamalarında enfekte aracı açtığında parolalar ve hassas kimlik bilgileri çalınacak şekilde çalışıyor
  • GitHub’a göre en az 70 proje devre dışı bırakıldı; Microsoft bazı depoları geçici olarak kaldırdıktan sonra inceleme sonrası geri yükledi
  • Bu olay, popüler açık kaynak kodları hedef alan tedarik zinciri saldırılarının son örneklerinden biri ve Microsoft’un açık kaynak projelerinin birkaç hafta içinde ikinci kez ihlal edildiği bildiriliyor

Olayın özeti ve Microsoft’un yanıtı

  • Hacker’ların projeleri ele geçirip koda parola çalan kötü amaçlı yazılım enjekte ettiğine dair bulgular doğrulanınca Microsoft, GitHub üzerindeki onlarca açık kaynak projeye erişimi engelledi ve ihlalin nasıl gerçekleştiğini araştırıyor
  • Etkilenen projelerin çoğu, Azure bulut hizmeti ve Claude Code, Gemini’nin komut satırı arayüzü, VS Code gibi yapay zeka geliştirme uygulamalarında kodlama için kullanılan araçlarla bağlantılı
  • Etkilenen araçları gerçekte kaç kişinin indirdiği hemen belirlenemedi
  • Microsoft, depoları kaldırdığını doğruladı; haberi ilk olarak 404 Media duyurdu
    • Microsoft sözcüsü Ben Hope: "Potansiyel kötü amaçlı içeriği araştırırken bazı depoları geçici olarak kaldırdık"
    • Bazı depolar inceleme sonrasında geri yüklendi, bazıları ise çalışmalar sürerken çevrimdışı kalabilir
    • Etkilenen depolardan içerik indirmiş olabilecek az sayıdaki müşteriye bildirim yapıldı; ek işlem gerektiren bir durum tespit edilirse mevcut destek kanalları üzerinden doğrudan iletişime geçilecek
  • TechCrunch’ın sorusuna yanıt olarak etkilenen müşterilerin kesin sayısı hemen paylaşılmadı

Kötü amaçlı yazılım nasıl çalışıyor

  • Güvenlik şirketi Cloudsmith ve topluluk temelli kötü amaçlı yazılım analiz sitesi OpenSourceMalware, bu hack olayını ilk işaret edenler arasında yer aldı
  • Kötü amaçlı yazılım, kullanıcıların yapay zeka kodlama uygulamalarında enfekte aracı açması halinde parolaları ve diğer hassas kimlik bilgilerini çalacak şekilde çalışıyor
  • Microsoft’a ait kod barındırma sitesi GitHub’da proje sayfalarına erişildiğinde, en az 70 proje "devre dışı (disabled)" olarak görünüyor
    • Gösterilen mesaj: "GitHub Hizmet Şartları’nın ihlali nedeniyle bu depoya erişim GitHub çalışanları tarafından devre dışı bırakıldı"

Bunun bir tedarik zinciri saldırısı olması bağlamı

  • Bu olay, son aylarda yaygın kullanılan açık kaynak projeleri ele geçirip bu kodu kuran çok sayıda kullanıcıya kötü amaçlı yazılım bulaştıran vakaların en yenisi
  • Bu tür hack’ler "tedarik zinciri (supply chain)" saldırıları olarak adlandırılıyor ve birçok yazılım ürününde yaygın olarak kullanılan ya da belirli kullanıcı gruplarının kullandığı kodları hedef alıyor
    • Bu tür hedefler, bulut sistemlerine ve büyük miktarda müşteri verisine erişim yetkisine sahip olabildiği için hacker’lar açısından avantajlı olabilir
  • Açık kaynak projelerinin tek geliştiricilerinin hedef alınması nadir değil; bazıları geliştiricinin güvenini kazanmayı amaçlayan uzun vadeli girişimlerin parçası oluyor
  • Ancak Microsoft gibi, bu tür saldırılara karşı savunma için kaynaklara sahip büyük teknoloji şirketlerinin ihlal edilmesi alışılmadık bir durum

Tekrarlanan ihlal işaretleri

  • Ars Technica’ya göre bu olay, son birkaç hafta içinde Microsoft açık kaynak projelerinin ihlal edildiği bilinen ikinci vaka
  • Güvenlik araştırmacılarına göre mayıs ortasında, geliştiricilerin uygulama oluşturmasına yardımcı olan Microsoft açık kaynak projesi Durable Task hacklendi
  • OpenSourceMalware, bu son olayı Durable Task projesinin "yeniden ihlal edilmesi (re-compromise)" olarak tanımlıyor
    • Bu da Microsoft’un ilk girişimde hacker’ları tamamen temizleyememiş olabileceğini ya da bunun tamamen ayrı yeni bir ihlal olabileceğini düşündürüyor

2 yorum

 
brainer 1 시간 전

Acaba şifremi değiştirsem bile MS hesabımda oturum açma girişimlerinin hâlâ bana gelmesinin nedeni bu olabilir mi?

 
GN⁺ 4 시간 전
Hacker News yorumları
  • Bu tamamen bir tahmin ve kişisel gözlem ama, eski RBAC modeli zaten neredeyse çökmüştü ve şimdi tamamen kırılmış gibi görünüyor
    Kodlama asistanlarıyla mühendislerin birbiriyle ilgisiz birden fazla projeye aynı anda dokunması, özellikle de eskiden vakit olmadığı için yapılamayan deneylere girişilmesiyle şirket içindeki tedarik zinciri riskinin ciddi biçimde arttığını düşünüyorum
    Bunun doğrudan bağlantılı olduğunu söylemiyorum ama etkisi olduğunu hissediyorum; ayrıca bugünlerde birçok yerde geliştiricilerin ve yöneticilerin insanları kişisel cihazlarında rastgele AI kodlama yapmaya teşvik etmesi de yakında sorun çıkaracak gibi görünüyor
    Son tedarik zinciri olayları arasında ortak bir eğilim olmadığını düşünmek zor; ayrıca bu tür saldırılarda uzmanlaşmış hacker gruplarının olmasının nedeni de getirinin yüksek olması

    • Açık olmak gerekirse, üstteki yorum bunun bağlantılı olduğunu kesin olarak söylemiyordu ama bunun AI ya da vibe coding ile hiçbir ilgisi yok
      Bu, çok eskiden beri var olan geliştirici bağımlılık kurulumu güvenlik eksikliğinin ve Shai Halud solucanının bir devamı
      Hackerlar geliştiricileri bir şey kurmaları için kandırmanın kolay olduğunu ve geliştirici makinelerinde kimlik bilgileri, bulut CLI'ları, MCP gibi hassas veriler bulunduğu için bunların ideal hedefler olduğunu fark etti
    • Bizim şirkette de benzer. “AI ile mümkün olduğunca çok şey yapmazsan geride kalırsın” gibi bir öğreti yayılmış durumda
      Güvenlik umursanmadan sürünün en önde koşmaya çalışılması, geçmişteki IoT çılgınlığının aynısını tekrarlıyor gibi
    • Toplam proje sayısına kıyasla insan sayısının çok az olduğunu yıllardır söylüyordum ama yönetim, projelerin çoğunun atıl durumda olduğunu, bu yüzden kişi başına çok fazla iş verilmesinin sorun olmayacağını söyledi
      Sonuç işte bu oldu
    • Rol tabanlı erişim kontrolü yani RBAC'nin başka bir şeyle değiştirilmesi gerektiğini mi, yoksa şu anda kullanılan belirli RBAC modellerinin mi çöktüğünü merak ediyorum
      Bana göre adı biraz kafa karıştırıcı olsa da geleceğin capability tabanlı güvenlik modeli olduğunu düşünüyorum
  • Başlıktaki ifade bile önyargılı ve metin de sanki bu açık kaynağın suçuymuş gibi yazılmış
    Üstelik denenmiş bir tedarik zinciri saldırısının sorumluluğunu Microsoft'a yüklüyor gibi, bu da daha da komik
    Microsoft did not immediately provide the specific number of customers affected, when asked by TechCrunch. deniyor ama TechCrunch, açık kaynağın zaten böyle işlediğini açıklamıyor
    Microsoft'u eleştirebildiğim zaman eleştirmeyi severim ama bu olayda Microsoft'un güvenli ve doğru adımları attığını düşünüyorum
    Haberde sanki her şey tamamen Microsoft'un hatasıymış ve ihlalin kapsamını sınırlamış olması da utanılacak bir şeymiş gibi yazılmış
    steal passwords of AI developers ifadesi de bunun “AI geliştiricileri” mi yoksa “AI kullanan geliştiriciler” mi olduğu konusunda tuhaf bir ima bırakıyor
    Tedarik zinciri saldırısına dair açıklama da gerçek anlamını değil, yalnızca sonucu ve saldırı yüzeyinin nedenlerini anlatıyor; bu yüzden bu haberin çok kötü olduğunu düşünüyorum

    • TechCrunch çok özensiz ve güvenilmesi zor
      Bizzat çalıştığım bir konuyu haber yaparken arama motoru optimizasyonu için gerçekleri uydurduğunu gördüm ve düzelttirmenin de bir yolu yoktu
    • O cümlede neyin sorunlu olduğunu anlamıyorum
      Microsoft'un kurumsal güvenlik sorunları var ve GitHub Actions'ı düzgün şekilde kilitleyememesi, merge request'lerin CI/CD'yi baypas etmesine izin vermesi bunu destekledi ya da ortaya çıkardı
      Bu, AI'dan önce de var olan bir Microsoft sorunu ve tartışmalı bir konu da değil: https://www.cisa.gov/sites/default/files/2025-03/CSRBReviewO...
      AI çağında bu sorun endemik hale geldi ve silahlaştırılıyor
    • O halde olay sonrası analizi nasıl değerlendirdiğini merak ediyorum
      Gerçekte ne oldu ve bunu nasıl okumak gerekiyor?
  • İlgili gibi görünen yazılar
    https://news.ycombinator.com/item?id=48418318 (The Blight Reaches Microsoft: 73 Repos Disabled in 105 Seconds)
    https://news.ycombinator.com/item?id=48450543 (Miasma Worm Hits Microsoft Again: Azure Functions Action and 72 Other Repositories Disabled After Supply Chain Attack Targeting AI Coding Agents)
    https://news.ycombinator.com/item?id=48416155
    https://news.ycombinator.com/item?id=48416269 (Miasma Worm Targets AI Coding Agents via GitHub Repos)

    • Enfekte olan tüm depolarda solucanı düzeltip kaldırabilen bir hafifletme aracı yaptılar ve bununla ilgili de bir yazı yazdılar
      Pazartesi günü Hades kampanyası Composer, Go ve Pip desteği ekledi. Ondan önce yalnızca NPM ve yapay zeka asistan editörlerini destekliyordu; Ruby de vardı ama bugünlerde Rubygems kullanan pek kimse kalmamış gibi görünüyor
      Microsoft’un bile gözden kaçırdığı nokta, bunun kod ekosistemindeki tüm platformlarda çalışan ilk solucan olması. Geliştirici host’larında, sunucularda ve CI/CD çalıştırıcılarında çalışıyor ve bu makinelerin erişebildiği tüm depolara solucanı yayıyor
      Bu solucanı yenmek için tüm bilgisayarları, AWS EC2, Google Cloud Platform, Azure ve Kubernetes kümelerini aynı anda %100 kapatmak gerekir. Kelimenin tam anlamıyla tüm altyapıya yayılıyor
      APT28 kötü amaçlı yazılımlarında her zamanki gibi kill switch, host dilini ru_RU.KOI8-R olarak ayarlamak, yani LANG ortam değişkenini bu şekilde belirlemek. Bunu yapınca yayılma mekanizması devre dışı kalıyor
      Hafifletme aracı: https://github.com/cookiengineer/antimiasma
      Blog yazısı: https://cookie.engineer/weblog/articles/malware-insights-mia...
  • Bunun büyük olasılıkla geleneksel kişisel erişim tokenlarının özensiz kullanımından kaynaklandığından kuvvetle şüpheleniyorum
    AI ajanına o tuhaf openclaw cihazından token verecekseniz, ayrıntılı yetkilendirilmiş tokenlar kullanmanız gerekir
    Benim GitHub hesabım politikaları tamamen farklı 3 kuruma yayılmış durumda ve classic tokenların hâlâ izinli olması bana biraz şaşırtıcı geliyor
    En azından her kuruluş için elle izin vermek gerekmeli

    • AI ajanları ayrı bir güvenlik öznesi olmalı ve yalnızca ihtiyaç duydukları depo veya kuruluşlar için özel erişim tokenları verilmesi gerektiğini düşünüyorum
      İnsan hesabı için “basılmış” erişim tokenlarını AI ajanına vermek, yeni nesil bir “şifreyi post-it’e yazıp bırakmak” gibi hissettiriyor
    • Doğru, ama ayrıntılı tokenların izin yönetimi tam bir kâbusa yakın
      Hangi iş için tam olarak neyin gerekli ve doğru olduğunu anlamak kolay değil
      Üstelik yazılım geliştiriciler çoğu zaman yetkilerden çok koda odaklanmanın daha önemli olduğunu düşünüyor ve izinleri başkasının sorumluluğu sayıyor
    • Sebep classic PAT ise, bu son GitHub depolarının ötesinde ek özel depoların da risk altında olabileceği anlamına gelmiyor mu?
    • Herkese açık depo scraping’i için düşük yetkili bir hesabın classic tokenını kullanıyorum
      Kuruluş düzeyindeki izinler benim kullanımım için gayet yeterli olur gibi görünüyor
  • Dün kişisel Microsoft hesap şifremi sıfırlamak zorunda kaldım. Çünkü Romanya’dan giriş denemesi olduğuna dair bir iki faktörlü kimlik doğrulama bildirimi aldım
    Şifreyi nasıl ele geçirdiklerini bilmiyorum. Sahip olduğum tek Microsoft ürünü Xbox
    Yapay zekadan önce bile Microsoft bana elek gibi delik deşik geliyordu; keşke şirket Microsoft’tan uzaklaşabilse ama artık bağımlı hale geldik

    • Kişisel Microsoft hesabında şifresiz oturum açmayı devre dışı bırakacak şekilde ayarlamak neredeyse imkânsız
      Bu yüzden gerçekte hesabınız muhtemelen bu şekilde yapılandırılmıştır ve aldığınız MFA isteği iki faktörlü doğrulama değil, yalnızca hesaba erişim denemesi olabilir
      Ben de günde birkaç kez böyle istekler aldım ve telefonda Microsoft Authenticator uygulamasını kurduğunuzda, yüz, parmak izi veya PIN gibi bir kilit varsa sistemin bunu zorla şifresiz yönteme çevirdiğini fark ettim
      Bunu aşmak için Authenticator uygulamasında hesabı kurarken bu tür kilitlerin hepsini kapatmanız gerekiyor
      Microsoft hesabını çok kullanmadığım için artık Authenticator yerine ayrı bir e-postayla doğrulama yapıyorum
      Bunun böyle çalışıyor olması başlı başına delilik ama muhtemelen Microsoft içinde birileri şifresiz oturum açma KPI’larını tutturmaya çalışıyordur
    • Çalıştığım bazı kuruluşlarda, şifre doğru olsun ya da olmasın çok faktörlü kimlik doğrulama istemi gösteriliyordu. Amaç saldırganın zamanını daha fazla boşa harcatmaktı
      Microsoft da bunu yapıyor mu, emin değilim
  • Birinin bu kadar çok depoya obfuscate edilmiş dosyaları nasıl ekleyebildiğini açıklamasını isterim. Hiç mi kod incelemesi yok?
    Başlık da yanıltıcı. setup, depoda çalışan kişilerin otomatik olarak çalıştıracağı bir yapılandırma ekliyor ve bu kişilerin VSCode, Cursor, Claude, Gemini kullanıyor olması gerekiyor
    Codex, opencode ve diğer yürütme harness'larını kullananlar muhtemelen güvendedir
    Ayrıntılar: https://www.stepsecurity.io/blog/miasma-worm-hits-microsoft-...

    • Büyük bir şirkette çalışan yakın bir arkadaşım var. Hangi şirket olduğunu söyleyemem ama bir S&P 500 şirketi
      Epey uzun süredir orada çalışıyor ama sorumlu olduğu projenin gerçekte nasıl göründüğünü hiç görmemiş; depoyu klonlamış ve kullanılan dili biliyor, o kadar
      Her şey kabaca yapay zekayla birbirine yapıştırılıyor. Bu proje, şirket genelindeki ürünün kimlik doğrulama ve yetkilendirme sistemi
      Kendi sözleriyle: “Bütün gün sadece Tab'a basıyorum ve incelemelere ‘istenen davranış’ yazıyorum. İncelemelerin hepsini de yapay zeka yapıyor, insan müdahalesi yok. CEO ve CTO bunu gerçekten böyle yapmamızı istiyor. Bir şey bozulursa kimse nasıl çalıştığını bilmiyor çünkü gerçek koda bakan olmadı. Performans değerlendirmesi yaptığımız işe göre değil, kullandığımız token sayısına göre yapılıyor”
      Şu anda birçok şirketin böyle olması muhtemel; gerçekten kod incelemesi olmadığını düşünmek de mantıksız değil
    • Kötü amaçlı commit'lerin çoğu yazar olarak github-actions gösteriyor
      Bu, dahili GitHub CI/CD tarafında kimlik doğrulama yaptıkları anlamına geliyor ve bu tür commit o kadar çok ki, herhangi bir otomasyon aracının saman yığını içindeki zehri bulması zor
      Bu yüzden bunun Eylül 2025'teki GitHub güvenlik ihlali ile bağlantılı olduğu söyleniyor
      “Beş deponun GitHub yıldızlarının toplamı 1.459 ve bunun 1.225'i tek başına mantine-datatable'dan geliyor. Yıldızlar, kaç geliştiricinin kaynağı yerelde checkout etmiş olabileceğine dair kaba bir vekil göstergedir ve bu saldırının hedeflediği kitle de budur.”
      “Tüm commit'ler imzasızdı, github-actions kimliğiyle geliyordu ve chore: update dependencies [skip ci] mesajıyla birlikte aynı altı dosyalık izi bırakıyordu. Beş depoyu 49 saniyede taramak, bunun insan commit'i değil otomasyon olduğunu gösteriyor. Bu, önceki enfeksiyondan yazma yetkili GitHub token'larını toplayıp ardından bu token'ların eriştiği tüm depolara kalıcılık yükünü iten Shai-Hulud'un kendi kendine yayılma modeliyle örtüşüyor.”
      https://safedep.io/miasma-worm-ai-coding-agent-config-inject...
      Gerçekte nasıl çalıştığı: https://safedep.io/config-files-that-run-code/
      Bu kişilerle bir alakam yok ama şu anda neler olup bittiğine dair bulduğum en basit ve en ayrıntılı açıklama bu
    • Bir iş arkadaşım ciddi ciddi, “Artık kodun çoğunu üretiyorsak, o kodu gerçekten kim baştan sona okuyor?” diye sordu
      Küçük bir şirket ama bazı insanların yapay zekaya bir nevi iman eder gibi güvenmek istemesi neredeyse dini bir dürtü gibi geliyor
      Ben ürettiğim kodun %90'ından fazlasını, sanki junior geliştirici kodu gözden geçiriyormuşum gibi okuyorum
      Şu anda yeni bir özelliği epey yoğun biçimde vibe coding ile geliştiriyorum ama GitHub PR'ları yeniden düzgün çalışmaya başladığında hepsini dikkatle okuyacağım
    • Depoya push atabilen bir hesap ele geçirildiyse PR incelemesi gerekmemiş olurdu
  • Bu insanlara Secure Boot'un kök CA sertifikalarını mı emanet ediyoruz?

    • 2023 güvenlik incelemesinde başarısız olan şirketten mi bahsediyorsun? [0]
      “Yukarıda açıklanan kusurların her biri tek tek ele alındığında anlaşılabilir olabilir. Ancak hepsi bir araya geldiğinde Microsoft'un kurumsal kontrolleri, yönetişimi ve güvenliğe ilişkin şirket kültüründeki bir başarısızlığa işaret ediyor.”
      Microsoft'un ürün ve hizmetleri her yerde. Dünyanın en önemli teknoloji şirketlerinden biri, belki de en önemlisi. Bu konum, en üst düzeyde küresel sorumluluk getiriyor. Finansal ya da pazara çıkış baskılarının siber güvenliği ve Microsoft müşterilerinin korunmasını zayıflatmaması için, CEO'dan başlayan sorumlu ve güvenlik odaklı bir şirket kültürü gerekiyor.
      “Ne yazık ki bu inceleme boyunca komite, Microsoft'un hem kurumsal güvenlik yatırımlarını hem de sıkı risk yönetimini düşük önceliğe koyan bir şirket kültürüne işaret eden bir dizi operasyonel ve stratejik karar tespit etti. Bu kararlar, dünya çapındaki Microsoft müşterileri için önemli maliyet ve zarara yol açtı.”
      “Komite, Microsoft'un güvenlik kültürünü düzeltmesi gerektiğine inanıyor.”
      [0] https://www.cisa.gov/resources-tools/resources/CSRB-Review-S...
    • Secure Boot'un güven kökü genelde Microsoft sertifikaları değil, OEM sertifikalarıdır; bu daha da kötü olabilir: https://www.binarly.io/blog/pkfail-untrusted-platform-keys-u...
      Her hâlükârda Microsoft sertifikalarını kaldırıp kendi sertifikanızı kaydetmekte özgürsünüz
    • “Güven”den çok “zorla kabul etmek zorunda olmak” gibi
      Bu olay da sadece Microsoft'un güvenliği ciddiye alan bir şirket olmaktan çok başlı başına bir güvenlik sorunu olma geçmişinin devamı
    • Microsoft'a güvenlik konusunda güvenmek aptallık olur
      Son 40 yılda bunu önemsemediğini defalarca gösterdi
  • Fark etmiş olmakta geç kalmış olabilirim ama bir süredir, “kod kötü” gibi nedenlerle yapay zeka kullanmak istemeseniz bile güvenlik denetimi için yapay zeka kullanmayı düşünmeniz gerektiğini söylüyorum
    En azından koddaki açıkları tarayan araçlar kullanılmalı
    Saldırı vektörü yalnızca veri çalan eklentiler değil; kullandığınız neredeyse her yazılımdaki 0-day açıklar ve elinde LLM olan script kiddie'lerin web servislerinize saldırması da buna dahil
    Hack'ler artacak ve daha da kötüleşecek, bu yüzden siber güvenlik denetimine ve denetim araçlarına yatırım yapmayan yerleri yeniden düşünmek gerekir

  • Kimse kendi makinesinde npm install ya da pip install çalıştırmamalı
    Uygun sandboxing(https://github.com/ashishb/amazing-sandbox) düzenli olarak kullanılırsa bu tür saldırıların etki alanı büyük ölçüde azaltılabilir

    • Docker arka ucu komutları rootless container içinde mi çalıştırıyor?
      Koda göz gezdirdim ama bunu doğrulayacak bir kısım göremedim
    • Docker ciddi bir sandboxing stratejisi değil
    • npm install ya da pip install komutlarını kendi makinesinde çalıştırmayın deniyorsa, bunun yerine ne öneriliyor?
      Yani sandbox dışında kurulum yapmayın mı denmek isteniyor?
    • Burada bir tespit bileşeni de var mı?
      Geliştirmeyi sandbox içinde yapmak güzel ama bir sonraki adım prod'a dağıtım
      Sandbox içinde kötü niyetli bir davranış gerçekleştiğini nasıl anlayacağız da o zararlı kodu daha fazla dağıtmayacağız?
  • Microsoft'un GitHub'ının, kullanım şartları ihlali nedeniyle Microsoft Azure ve diğer tüm kullanıcıların Microsoft kod tabanına erişimini durdurmuş olması gereğinden fazla komik
    Şu organizasyon şemasını gerçekten hissettiriyor: https://www.businessinsider.com/big-tech-org-charts-2011-6