GitHub, kötü amaçlı VSCode uzantısı üzerinden 3.800 deponun ihlal edildiğini doğruladı
(bleepingcomputer.com)- GitHub iç depolarından yaklaşık 3.800’ü, bir çalışanın kötü amaçlı bir VS Code uzantısı yüklemesinin ardından ihlal edildi; mevcut değerlendirme sızıntının kapsamını iç depolarla sınırlıyor
- GitHub, truva atına dönüştürülmüş uzantıyı VS Code Marketplace’ten kaldırdı, enfekte uç noktayı izole etti ve derhal olay müdahalesi başlattı
- TeamPCP, GitHub kaynak koduna ve yaklaşık 4.000 depodaki özel koda eriştiğini iddia ediyor ve çalınan veriler için en az 50 bin dolar talep ediyor
- VS Code uzantıları resmî mağazadan yüklenen eklentiler olsa da, geçmişte kimlik bilgisi hırsızlığı, madenci, fidye yazılımı işlevleri ve kripto para hırsızlığı yapan uzantılar da tespit edildi
- GitHub, etkilenen depolar dışındaki müşteri verilerinin ihlal edildiğine dair bir kanıt olmadığını söyledi; platformu 180 milyondan fazla geliştirici kullanıyor
GitHub ihlali doğruladı ve yanıt verdi
- GitHub, bir çalışanın kötü amaçlı bir VS Code uzantısı yüklemesinin ardından yaklaşık 3.800 iç deponun ihlal edildiğini doğruladı
- Adı açıklanmayan, truva atına dönüştürülmüş uzantı VS Code Marketplace’ten kaldırıldı ve ihlal edilen cihaz koruma altına alındı
- GitHub, X paylaşımında “zararlı VS Code uzantısıyla bağlantılı bir çalışan cihazı ihlalini tespit edip engellediğini” belirterek, kötü amaçlı uzantı sürümünün kaldırıldığını, uç noktaların izole edildiğini ve derhal olay müdahalesine başlandığını açıkladı
- Mevcut değerlendirmeye göre faaliyetin kapsamı GitHub iç depolarındaki sızıntıyla sınırlı; saldırganın öne sürdüğü yaklaşık 3.800 depo sayısı da soruşturma bulgularıyla büyük ölçüde örtüşüyor
- GitHub, bir gün önce BleepingComputer’a iç depolara yönelik yetkisiz erişim iddiasını soruşturduğunu söylemiş ve etkilenen depolar dışında depolanan müşteri verilerinin ihlal edildiğine dair bir kanıt bulunmadığını eklemişti
TeamPCP iddiaları ve VS Code uzantılarının riski
- Hacker grubu TeamPCP, Breached siber suç forumunda GitHub kaynak koduna ve “yaklaşık 4.000 depodaki özel koda” eriştiğini iddia ederek, çalınan veriler için en az 50 bin dolar talep etti
- TeamPCP, “Bunun bir fidye olmadığını ve GitHub’a şantaj yapmakla ilgilenmediğini” söyledi; verileri tek bir alıcıya sattıktan sonra elindeki kopyaları sileceğini belirtti
- TeamPCP daha önce geliştirici kod platformlarını hedef alan büyük çaplı tedarik zinciri saldırılarıyla ilişkilendirilmişti; hedefler arasında GitHub, PyPI, NPM, Docker bulunuyor
- TeamPCP ayrıca kısa süre önce iki OpenAI çalışanını da etkileyen “Mini Shai-Hulud” tedarik zinciri kampanyasıyla da ilişkilendirildi
- VS Code uzantıları, Microsoft’un kod düzenleyicisine işlev eklemek veya araçları entegre etmek için resmî mağaza olan VS Code Marketplace üzerinden yüklenen eklentilerdir
- VS Code Marketplace’te geçmişte de geliştirici kimlik bilgilerini ve hassas verileri çalan kötü amaçlı uzantılar tekrar tekrar tespit edildi
- Geçen yıl, toplam 9 milyon kurulum sayısına ulaşan VSCode uzantıları güvenlik riskleri nedeniyle kaldırıldı; ayrıca meşru geliştirme araçları gibi görünen 10 uzantı, kullanıcıları XMRig kripto para madencisiyle enfekte etti
- Daha sonra temel fidye yazılımı işlevlerine sahip kötü amaçlı bir uzantı VS Code Marketplace’e yüklendi; WhiteCobra adlı tehdit aktörü ise 24 kripto para hırsızı uzantı kaydettirdi
- Bu yıl ocak ayında, AI tabanlı kodlama yardımcısı olarak tanıtılan ve toplam 1,5 milyon kurulum alan iki kötü amaçlı uzantının, enfekte geliştirici sistemlerinden Çin’deki sunuculara veri sızdırdığı ortaya çıktı
- GitHub bulut platformu şu anda 4 milyondan fazla kuruluş, Fortune 100 şirketlerinin %90’ı ve 180 milyondan fazla geliştirici tarafından kullanılıyor; kullanıcılar 420 milyondan fazla kod deposuna katkıda bulunuyor
1 yorum
Hacker News yorumları
VSCode'u yapan şirket, NPM'e sahip olan şirket ve GitHub'a sahip olan şirket bir araya gelip bu soruna bir çözüm bulabilse keşke
Microsoft organizasyon şeması karikatürünün neden doğru olduğunu kusursuz biçimde gösteriyor
https://bonkersworld.net/organizational-charts
Bu kadar bariz bir risk konusunda uyarı eksikliği olduğu söylenemezdi
https://github.com/microsoft/vscode/issues/52116
Microsoft, NuGet'e de sahip olan şirket
Bir yıl önce ne yaptıklarına bakarsanız, NuGet'ten yaklaşık 700 paketi proaktif olarak kaldırdılar ama sonunda bunların yanlış pozitif olduğu ortaya çıktı
Doğru olanı yapmak kolay değil
Şaka bir yana, böyle ekosistemler en baştan ihlal edilmeye açık bir çöp tenekesi gibi tasarlanmış durumda
Katkıların sıkı biçimde incelenmediği tamamen açık ekosistemlerin hepsi bu sorunlara açık
Bundan hoşlanmıyorsanız editör uzantıları kullanmayın, düzgün şekilde denetlenmiş bir editör kullanın
Uzantıları, node paketlerini ya da PyPI paketlerini ayrıntılı incelemeden kullanmak teknik borç biriktirmektir
Hızlı çıkış yapmak için riski üstlenmektir; sonra bunu kontrollü bir şekilde geri ödersiniz ya da faiz tahsil edildiğinde bedelini ödersiniz
VS Code uzantıları uzun zamandır korkutucuydu ve son derece açık bir saldırı yolu oluşturuyordu
VSCode, belirli bir dosya biçimini tanıdığını söyleyip sürekli uzantı kurmanızı isteyen açılır pencereler gösteriyor; bu uzantıların yarısı şirkete ait mi yoksa herhangi bir geliştiriciye mi ait, belli değil
Milyonlarca kez kurulmuş uzantılar arasında bile ilk bakışta resmi şirket uzantısı gibi görünenler var
Artık yalnızca resmi şirkete ait uzantıları kurmaya çalışıyorum ama bunda bile kandırılmadığımdan emin olmak zor, bu da can sıkıcı
Bu sorun VS Code'un çok ötesine geçiyor
Tüm uzantılar ve çalıştırılabilir kodlar aynı soruna sahip
Disney'nin, bir çalışanın zararlı yazılım içeren bir BeamNG modu kurması nedeniyle hacklendiği bir olay da vardı
Güvenli kalmak isteyen şirketlerin yazılım kurulumuna sıkı kısıtlamalar getirmesi gerekir
Örneğin kurum içinde yalnızca önceden onaylanmış depolardaki npm paketlerinin ve eklentilerin kurulmasına izin vermek gibi
VSCode bağımlısı insanlardan ara sıra alay işitsem de Sublime kullanmayı sürdürdüm
“VSCode mükemmel” diye eleştirel düşünmeden inanan insanların başına bunların geldiğini görmek hoşuma gidiyor
Ben de VSCode uzantıları konusunda benzer şekilde paranoyakça dikkatli hale geldim
Eskiden Brackets, JetBrains, Sublime Text, Bluefish gibi IDE'lerde geliştirme için gereken güvenilir birkaç uzantıyla idare edebildiğimizi hatırlıyorum
Şimdiyse ne yaparsanız yapın, sanki biri ya da bir şirket o iş için özel bir uzantı üretmiş gibi görünüyor
Artık asgari uzantıyla olabildiğince çok iş yapmaya çalışıyorum
Ve kodumun geri kalanını da GitHub'dan çıkarmayı planlıyorum
Masaüstünün birkaç saniyede bir ekran görüntüsünü alıp OCR çalıştırdıktan sonra sonucu şifrelenmemiş düz metin olarak diske kaydetmeyi akıl eden bir tedarikçiden bu düzeyde bir yazılım güvenliği beklenirdi
Üstelik bu uzantıların hepsi otomatik güncelleme de yapmak istiyor
Hacker'ların bunu yapacak kadar uzun bir çalışma süresi bulmuş olması daha da şaşırtıcı
Şakayı anlamayanlar için söyleyeyim, GitHub Microsoft tarafından satın alındığından beri kendi kendini istikrarlı biçimde işletmekte giderek daha fazla zorlanıyor
Son dönemde kesintiler arttı, durum daha da kötüleşti ve haber oldu
Önceki ilgili başlık:
GitHub is investigating unauthorized access to their internal repositories - https://news.ycombinator.com/item?id=48201316 - Mayıs 2026, 321 yorum
Dün beni mağdur eden nx console uzantısının ihlal edilmiş olup olmadığını merak ediyorum
Zamanlama neredeyse birebir örtüşüyor gibi görünüyor
https://github.com/nrwl/nx-console/security/advisories/GHSA-... bakın
Umarım bu olay Microsoft'u VS Code uzantılarına açık bir izin sistemi eklemeye ve geliştirme konteyneri güvenliğini iyileştirmeye iter
Hatta daha iyisi, bunun kullanıcıların — burada geliştiriciler ve bakımcıların — Microsoft'a bağımlılıklarını azaltmalarına ve özellikle güvenliği Microsoft'a dış kaynak olarak vermeyi bırakmalarına vesile olması olurdu
Artık vscode'dan uzaklaşmak gerekiyor
Pek umutlu değilim
Bu konu 2018'den beri açık: https://github.com/microsoft/vscode/issues/52116
VS Code, Electron üzerinde inşa edildi ve Electron'da bir SUID sandbox helper vardı ya da var; bu yüzden sandboxing baş ağrıtıcı
Çünkü sandbox içinde SUID ikili dosyalarını çalıştırmak kolay değil
Linux'ta sandboxing son derece zor bir iş
Bir web tarayıcısına SUID Root vermek eskiden acemi kullanıcılarla dalga geçmek için yapılan bir şakaydı ve düşünülebilecek en kötü güvenlik hatasıydı
Bir miktar performans ek yükü var ama dünyanın sonu değil
Belki çok bariz bir şeyi gözden kaçırıyorum ama 3.800 depo gerçekten şaşırtıcı
Bu kadar çok olacağını düşünmemiştim
Başkalarının da dediği gibi bu yalnızca bir kısmı
Orta ölçekli bir teknoloji şirketinde çalışıyorum ve tek bir GitHub organizasyonunda 7.500'den fazla depo var
İki organizasyon olunca toplam kolayca 10 bini geçiyor
Elbette bunların çoğu eski, terk edilmiş, sandbox amaçlı ya da kişisel araçlar
GitHub için 100 binin üzerinde ya da daha fazla iç depo olması beni şaşırtmaz
Eskiden beş ya da altı GitHub organizasyonuna yayılmış en az 5.000 depo bulunan, ayrıca Perforce'ta daha da fazla kod olan bir şirkette çalıştım
Eski deneyler de vardı ama şirket birçok alana el atıyordu ve bazı ekipler bir sorunu çözmek için bir başka servis daha üretmekten çekinmiyordu
Benim ekibimin eski işleri kesinlikle arşivlendi
Bizim sekiz depomuz vardı ve üç kişi için bunun bile yeterince fazla olduğunu düşünüyorduk
Uber'in bir dönem 2.000 mühendise karşılık 8.000 deposu vardı - https://highscalability.com/lessons-learned-from-scaling-ube...
Bir zamanlar gıda perakendeciliğinde çalışmıştım
İlk gün dışarıdan bakınca basit bir web sitesi gibi göründüğü için ne kadar zor olabilir diye düşünmüştüm
Meğer sipariş sitesi 300'den fazla deponun birleşiminden oluşuyormuş
Bu yine de GitHub'ın bu ihlalde kaybettiğinden daha azdı
Ölçek büyüdükçe sadeliği korumak gerçekten çok emek istiyor
GitHub'da çalışırken hep takdir ettiğim şeylerden biri, şirketin büyük bir kısmının gerçekten GitHub üzerinde çalışıyor olmasıydı
Teknik olmayan ekiplerin bile, geleneksel bilgi-işi şirketlerinin SharePoint kullanması gibi, dokümanları/SOP'leri/tasarımları düzenlemek için kendi depolarına sahip olması yaygındı
Açık kaynak haline getirmenin de çeşitli yolları var
Kendi kullanıcı hesabınızla gidip açıkça script çalıştırmak yerine, kazıma ve işe yaramaz bir özelliği birleştiren bir eklentiyle anonim yükleme yapabilirsiniz
Mesela bir kayan noktalı sayının çift olup olmadığını söyleyen bir özellik gibi
Tabii böyle sayılar yok
Sonra da bunu çalıştırıp kendinizi kurban gibi gösterebilirsiniz
“Dün, kirletilmiş bir VS Code uzantısıyla ilişkili bir çalışan cihazı ihlalini tespit edip engelledik. Uzantının kötü amaçlı sürümünü kaldırdık, uç noktayı izole ettik ve derhal olay müdahalesi başlattık”
Uzantıyı kaldırmışlar, ne güzel
Bunu ancak kendi çalışanları enfekte olduktan sonra mı yapıyorlar?
Bir de neden uzantının adını açıklamıyorlar?