<![CDATA[TurkTeam | Türk Siber Güvenlik Topluluğu - Siber Güvenlik Haberleri]]> https://www.turkteam.org/ Sun, 25 Oct 2026 19:04:32 +0000 MyBB <![CDATA[INTERPOL Serengeti III: Afrika'da 10.909 Kötü Amaçlı Ağ Çökertildi, 1.462 Tutuklama]]> https://www.turkteam.org/konu-interpol-serengeti-iii-afrika-da-10-909-kotu-amacli-ag-cokertildi-1-462-tutuklama.html Sun, 25 Oct 2026 11:45:27 +0300 BilgeKagan]]> https://www.turkteam.org/konu-interpol-serengeti-iii-afrika-da-10-909-kotu-amacli-ag-cokertildi-1-462-tutuklama.html [Resim: attachment.php?aid=430]
Selamlar,

INTERPOL, Afrika'nın en büyük siber suç operasyonlarından birini, Operation Serengeti III'ü duyurdu. 29 Haziran - 31 Ağustos 2026 arasında 21 ülkeden kolluk kuvvetleri 10.909 kötü amaçlı ağı çökertti, 1.462 şüpheliyi tutukladı ve 105 milyon dolardan fazla yasadışı fonu geri aldı. BleepingComputer konuyu aktardı. Rakamların büyüklüğü kadar, kullanılan dolandırıcılık taktikleri de bireysel kullanıcılar için öğretici. Burada operasyonu ve çıkarılacak dersleri özetliyorum.

Konuda anlatılacaklar
  1. Rakamlarla Serengeti III
  2. Hangi suç türleri hedeflendi?
  3. Operasyon vurguları
  4. YZ'nin rolü
  5. Bireysel korunma dersleri

1. Rakamlarla
Kod:
Katılan ülke : 21 Çökertilen ağ : 10.909 Tutuklama : 1.462 Geri alınan fon : 105 milyon USD+ Tespit edilen mağdur: 65.929 Bağlantılı kayıp : 385 milyon USD+

2. Hangi suç türleri?
Operasyon; siber destekli dolandırıcılık, fidye yazılımı, iş e-postası ele geçirme (BEC), çevrimiçi dolandırıcılıklar ve dijital şantajı hedefledi. INTERPOL'ün Afrika Siber Tehdit Değerlendirmesi 2026 raporu, yapay zekanın kıtadaki siber suçları giderek kolaylaştırdığına ve mali kayıpların arttığına işaret ediyor.

3. Operasyon vurguları
  • Uganda: İki ülkeler arası dolandırıcılık çetesi çökertildi, Asya'daki mağdurları hedefleyen yatırım/emeklilik dolandırıcılığından 365 yabancı uyruklu tutuklandı. Dönüşümlü çağrı merkezi modeli, sahte ticaret platformları ve sahte siteler kullanılıyordu.
  • Angola: İki yasadışı kripto madenciliği merkezi çökertildi, 9 şüpheli tutuklandı, 2.000'den fazla madencilik cihazı ve altı yasadışı güç trafosu ele geçirildi.
  • Nijerya: Büyük ölçekli bir oltalama/BEC operasyonu; yaklaşık 2,1 milyon e-posta adresi toplanmıştı. Ayrı bir soruşturmada 2,4 milyon dolardan fazla suç geliri kripto ile aklanmıştı.

4. YZ'nin rolü
INTERPOL, raporunda yapay zekanın kıtada siber suç faaliyetini giderek daha fazla kolaylaştırdığını vurguluyor. Operasyon, Group-IB, Kaspersky, Fortinet gibi özel sektör ortaklarının istihbarat ve teknik analiz desteğiyle yürütüldü.

5. Bireysel korunma dersleri
Bu suçların çoğu son kullanıcıyı hedefliyor. Korunma için:
  1. Yatırım "fırsatlarına" şüpheyle yaklaşın. Garantili yüksek getiri vaadi klasik dolandırıcılık işaretidir.
  2. BEC'e karşı ikinci kanaldan doğrulama yapın. E-posta ile gelen havale/IBAN değişikliği taleplerini telefonla teyit edin.
  3. Oltalamaya karşı bağlantı ve göndericileri dikkatle kontrol edin; aciliyet baskısı uyarı işaretidir.
  4. E-posta sızıntısını kontrol edin. 2,1 milyon adres toplandığı düşünüldüğünde, adresinizin sızıp sızmadığını düzenli kontrol etmek önemli.
  5. Kripto ile ödeme baskısı neredeyse her zaman dolandırıcılık işaretidir.

Sonuç
Serengeti III, siber suçun sınır tanımadığını ama uluslararası iş birliğinin en etkili silah olduğunu gösteriyor. Rakamların arkasındaki taktikler (yatırım dolandırıcılığı, BEC, oltalama) tam da günlük hayatta karşılaştığımız tehditler. Çevrenizde yatırım dolandırıcılığına maruz kalan oldu mu?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   13-t13-interpol-serengeti-3.png (Dosya Boyutu: 120.71 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=430]
Selamlar,

INTERPOL, Afrika'nın en büyük siber suç operasyonlarından birini, Operation Serengeti III'ü duyurdu. 29 Haziran - 31 Ağustos 2026 arasında 21 ülkeden kolluk kuvvetleri 10.909 kötü amaçlı ağı çökertti, 1.462 şüpheliyi tutukladı ve 105 milyon dolardan fazla yasadışı fonu geri aldı. BleepingComputer konuyu aktardı. Rakamların büyüklüğü kadar, kullanılan dolandırıcılık taktikleri de bireysel kullanıcılar için öğretici. Burada operasyonu ve çıkarılacak dersleri özetliyorum.

Konuda anlatılacaklar
  1. Rakamlarla Serengeti III
  2. Hangi suç türleri hedeflendi?
  3. Operasyon vurguları
  4. YZ'nin rolü
  5. Bireysel korunma dersleri

1. Rakamlarla
Kod:
Katılan ülke : 21 Çökertilen ağ : 10.909 Tutuklama : 1.462 Geri alınan fon : 105 milyon USD+ Tespit edilen mağdur: 65.929 Bağlantılı kayıp : 385 milyon USD+

2. Hangi suç türleri?
Operasyon; siber destekli dolandırıcılık, fidye yazılımı, iş e-postası ele geçirme (BEC), çevrimiçi dolandırıcılıklar ve dijital şantajı hedefledi. INTERPOL'ün Afrika Siber Tehdit Değerlendirmesi 2026 raporu, yapay zekanın kıtadaki siber suçları giderek kolaylaştırdığına ve mali kayıpların arttığına işaret ediyor.

3. Operasyon vurguları
  • Uganda: İki ülkeler arası dolandırıcılık çetesi çökertildi, Asya'daki mağdurları hedefleyen yatırım/emeklilik dolandırıcılığından 365 yabancı uyruklu tutuklandı. Dönüşümlü çağrı merkezi modeli, sahte ticaret platformları ve sahte siteler kullanılıyordu.
  • Angola: İki yasadışı kripto madenciliği merkezi çökertildi, 9 şüpheli tutuklandı, 2.000'den fazla madencilik cihazı ve altı yasadışı güç trafosu ele geçirildi.
  • Nijerya: Büyük ölçekli bir oltalama/BEC operasyonu; yaklaşık 2,1 milyon e-posta adresi toplanmıştı. Ayrı bir soruşturmada 2,4 milyon dolardan fazla suç geliri kripto ile aklanmıştı.

4. YZ'nin rolü
INTERPOL, raporunda yapay zekanın kıtada siber suç faaliyetini giderek daha fazla kolaylaştırdığını vurguluyor. Operasyon, Group-IB, Kaspersky, Fortinet gibi özel sektör ortaklarının istihbarat ve teknik analiz desteğiyle yürütüldü.

5. Bireysel korunma dersleri
Bu suçların çoğu son kullanıcıyı hedefliyor. Korunma için:
  1. Yatırım "fırsatlarına" şüpheyle yaklaşın. Garantili yüksek getiri vaadi klasik dolandırıcılık işaretidir.
  2. BEC'e karşı ikinci kanaldan doğrulama yapın. E-posta ile gelen havale/IBAN değişikliği taleplerini telefonla teyit edin.
  3. Oltalamaya karşı bağlantı ve göndericileri dikkatle kontrol edin; aciliyet baskısı uyarı işaretidir.
  4. E-posta sızıntısını kontrol edin. 2,1 milyon adres toplandığı düşünüldüğünde, adresinizin sızıp sızmadığını düzenli kontrol etmek önemli.
  5. Kripto ile ödeme baskısı neredeyse her zaman dolandırıcılık işaretidir.

Sonuç
Serengeti III, siber suçun sınır tanımadığını ama uluslararası iş birliğinin en etkili silah olduğunu gösteriyor. Rakamların arkasındaki taktikler (yatırım dolandırıcılığı, BEC, oltalama) tam da günlük hayatta karşılaştığımız tehditler. Çevrenizde yatırım dolandırıcılığına maruz kalan oldu mu?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   13-t13-interpol-serengeti-3.png (Dosya Boyutu: 120.71 KB / İndirme Sayısı: 1) ]]> <![CDATA[İran Bağlantılı Prince of Persia 2016'dan Beri İlk Kez ABD'de C2 Barındırdı]]> https://www.turkteam.org/konu-iran-baglantili-prince-of-persia-2016-dan-beri-ilk-kez-abd-de-c2-barindirdi.html Sun, 25 Oct 2026 11:44:19 +0300 BilgeKagan]]> https://www.turkteam.org/konu-iran-baglantili-prince-of-persia-2016-dan-beri-ilk-kez-abd-de-c2-barindirdi.html [Resim: attachment.php?aid=428]
Selamlar,

Semperis'in raporuna göre İran devleti bağlantılı Prince of Persia (diğer adıyla Infy) grubu, bu yıl komuta-kontrol (C2) sunucularından birini ABD'de çalıştırdı; bu, 2016'dan beri ilk kez. SecurityWeek konuyu aktardı. Yaklaşık 20 yıldır faal olan ve çoğunlukla İranlı muhalifler ile ABD/Avrupa/Orta Doğu'daki kurumları hedefleyen grup, uzun bir sessizliğin ardından dikkat çeken bir altyapı tercihi yaptı. Burada olayı ve savunma çıkarımlarını ele alıyorum.

Konuda anlatılacaklar
  1. Prince of Persia kim?
  2. Üç aylık sessizlik
  3. ABD'de barınma: Namecheap paylaşımlı hosting
  4. Tornado zararlısı
  5. Savunma çıkarımları

1. Prince of Persia kim?
Tomer Bar'ın (Semperis) izlediği grup, neredeyse yirmi yıldır faal. Hedefleri çoğunlukla İranlı muhalifler, yanında ABD, Avrupa ve Orta Doğu'daki kamu ve özel kuruluşlar.

2. Üç aylık sessizlik
Bir başka firmanın Şubat 2026 raporundan bir hafta sonra grup bir C2 sunucusunu kapattı ve diğerlerini taşıdı, ardından üç ay boyunca operasyonlarını durdurdu. Bu, Semperis'in doğruladığı en uzun kesinti. Operasyonlar 27 Mayıs'ta yeni bir C2 ile yeniden başladı; yedi gün içinde Tonnerre adlı zararlı tek bir mağdurdan 1.800'den fazla dosya sızdırdı.

3. ABD'de barınma
Ağustos'ta Bar, muhtemelen 7 Temmuz'da kurulan, Tornado'nun ikinci aşamasını destekleyen yeni bir sunucu buldu. Bu sunucu ABD'deydi; grubun 2016'dan beri ülke içinde C2 barındırmasının ilk örneği. Daha da ilginci, saldırganlar VPS yerine binlerce alan adının bulunduğu Namecheap paylaşımlı hosting'e geçti. Bar'ın ifadesiyle: "Prince of Persia'yı saklanırken bulmayı en son bekleyeceğimiz yerdi." 24 Ağustos'ta grup, Cloudflare arkasında gizlenen başka bir Tornado ikinci aşama sunucusu kurmaya başladı; Semperis, ABD sunucusunun ifşa olduğunu fark ettiklerini düşünüyor.

4. Tornado zararlısı
Tornado, grubun en yeni zararlı ailesi; yeteneklerinden biri bir Telegram botu üzerinden dosya çalmak. Araştırma özetlerine göre grup HTTPS ve Telegram API tabanlı C2, DGA alan adları ve RSA ile doğrulanan istekler kullanıyor.

5. Savunma çıkarımları
  1. Coğrafi kökene göre güven olmaz. "ABD IP'si = güvenli" varsayımı tehlikeli; devlet aktörleri de ülke içi bulut/hosting kullanıyor.
  2. Paylaşımlı hosting C2'si tespiti zordur. Meşru sitelerle aynı IP'yi paylaştığı için salt IP engelleme yetmez; alan adı ve davranış bazlı tespit gerekir.
  3. Şüpheli Telegram trafiğini izleyin. Semperis, kurumlara IoC'leri araçlarına eklemeyi ve Telegram trafiğini gözlemlemeyi öneriyor.
  4. DGA alan adlarını avlayın. Algoritmik üretilmiş alan adlarına giden DNS sorguları güçlü bir göstergedir.

Sonuç
Prince of Persia vakası, atıf ve altyapı takibinin ne kadar değerli olduğunu gösteriyor. Uzun soluklu bir aktörün altyapı alışkanlığını değiştirmesi, savunucular için hem yeni bir risk hem de yeni bir tespit fırsatı. Siz C2 tespitinde IP'ye mi, alan adı/davranışa mı güveniyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   12-t12-prince-of-persia-tornado.png (Dosya Boyutu: 118.57 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=428]
Selamlar,

Semperis'in raporuna göre İran devleti bağlantılı Prince of Persia (diğer adıyla Infy) grubu, bu yıl komuta-kontrol (C2) sunucularından birini ABD'de çalıştırdı; bu, 2016'dan beri ilk kez. SecurityWeek konuyu aktardı. Yaklaşık 20 yıldır faal olan ve çoğunlukla İranlı muhalifler ile ABD/Avrupa/Orta Doğu'daki kurumları hedefleyen grup, uzun bir sessizliğin ardından dikkat çeken bir altyapı tercihi yaptı. Burada olayı ve savunma çıkarımlarını ele alıyorum.

Konuda anlatılacaklar
  1. Prince of Persia kim?
  2. Üç aylık sessizlik
  3. ABD'de barınma: Namecheap paylaşımlı hosting
  4. Tornado zararlısı
  5. Savunma çıkarımları

1. Prince of Persia kim?
Tomer Bar'ın (Semperis) izlediği grup, neredeyse yirmi yıldır faal. Hedefleri çoğunlukla İranlı muhalifler, yanında ABD, Avrupa ve Orta Doğu'daki kamu ve özel kuruluşlar.

2. Üç aylık sessizlik
Bir başka firmanın Şubat 2026 raporundan bir hafta sonra grup bir C2 sunucusunu kapattı ve diğerlerini taşıdı, ardından üç ay boyunca operasyonlarını durdurdu. Bu, Semperis'in doğruladığı en uzun kesinti. Operasyonlar 27 Mayıs'ta yeni bir C2 ile yeniden başladı; yedi gün içinde Tonnerre adlı zararlı tek bir mağdurdan 1.800'den fazla dosya sızdırdı.

3. ABD'de barınma
Ağustos'ta Bar, muhtemelen 7 Temmuz'da kurulan, Tornado'nun ikinci aşamasını destekleyen yeni bir sunucu buldu. Bu sunucu ABD'deydi; grubun 2016'dan beri ülke içinde C2 barındırmasının ilk örneği. Daha da ilginci, saldırganlar VPS yerine binlerce alan adının bulunduğu Namecheap paylaşımlı hosting'e geçti. Bar'ın ifadesiyle: "Prince of Persia'yı saklanırken bulmayı en son bekleyeceğimiz yerdi." 24 Ağustos'ta grup, Cloudflare arkasında gizlenen başka bir Tornado ikinci aşama sunucusu kurmaya başladı; Semperis, ABD sunucusunun ifşa olduğunu fark ettiklerini düşünüyor.

4. Tornado zararlısı
Tornado, grubun en yeni zararlı ailesi; yeteneklerinden biri bir Telegram botu üzerinden dosya çalmak. Araştırma özetlerine göre grup HTTPS ve Telegram API tabanlı C2, DGA alan adları ve RSA ile doğrulanan istekler kullanıyor.

5. Savunma çıkarımları
  1. Coğrafi kökene göre güven olmaz. "ABD IP'si = güvenli" varsayımı tehlikeli; devlet aktörleri de ülke içi bulut/hosting kullanıyor.
  2. Paylaşımlı hosting C2'si tespiti zordur. Meşru sitelerle aynı IP'yi paylaştığı için salt IP engelleme yetmez; alan adı ve davranış bazlı tespit gerekir.
  3. Şüpheli Telegram trafiğini izleyin. Semperis, kurumlara IoC'leri araçlarına eklemeyi ve Telegram trafiğini gözlemlemeyi öneriyor.
  4. DGA alan adlarını avlayın. Algoritmik üretilmiş alan adlarına giden DNS sorguları güçlü bir göstergedir.

Sonuç
Prince of Persia vakası, atıf ve altyapı takibinin ne kadar değerli olduğunu gösteriyor. Uzun soluklu bir aktörün altyapı alışkanlığını değiştirmesi, savunucular için hem yeni bir risk hem de yeni bir tespit fırsatı. Siz C2 tespitinde IP'ye mi, alan adı/davranışa mı güveniyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   12-t12-prince-of-persia-tornado.png (Dosya Boyutu: 118.57 KB / İndirme Sayısı: 1) ]]> <![CDATA[Terk Edilmiş Popcorn Time: 2 Milyondan Fazla Cihaza Uzaktan Kapatma (CVE-2026-30612)]]> https://www.turkteam.org/konu-terk-edilmis-popcorn-time-2-milyondan-fazla-cihaza-uzaktan-kapatma-cve-2026-30612.html Sun, 25 Oct 2026 11:40:21 +0300 Tonyukuk]]> https://www.turkteam.org/konu-terk-edilmis-popcorn-time-2-milyondan-fazla-cihaza-uzaktan-kapatma-cve-2026-30612.html [Resim: attachment.php?aid=424]
Selamlar,

İlginç ve öğretici bir vaka: Hollandalı güvenlik firması Eye Security, Kasım 2025 ile Mart 2026 arasında sahibi olmadığı 2 milyondan fazla bilgisayara güncelleme göndererek, terk edilmiş Time4Popcorn uygulamasındaki tehlikeli bir güncelleyiciyi kapattı. The Hacker News "Operation IXIM" olarak bilinen bu operasyonu detaylandırdı. Burada güvensiz güncelleyici (updater) riskini ve kendi yazılım dağıtımınız için çıkarılacak dersleri ele alıyorum.

Konuda anlatılacaklar
  1. Time4Popcorn nedir, sorun ne?
  2. CVE-2026-30612 teknik özeti
  3. Güncelleyici neden botnet yakıtı olabilirdi?
  4. Operation IXIM: güncelleyiciyi kendine karşı kullanmak
  5. Kullanıcılar ne yapmalı?
  6. Geliştiriciler için ders: güvenli güncelleme

1. Time4Popcorn nedir?
Popcorn Time, yaklaşık on yıl önce popüler olan, BitTorrent üzerinden korsan film/dizi yayınlayan ücretsiz bir uygulamaydı. Orijinali 2014'te kapandı, ama aynı adla çalışan kopyalar sürdü. Time4Popcorn bu terk edilmiş kopyalardan biri. Eye Security, bir müşterinin dizüstünde sürekli artık kayıtlı olmayan bir web adresine ulaşmaya çalışan Updater.exe bulunca olayın ipini çekti.

2. CVE-2026-30612
CISA'nın 9.8 puanladığı açık şu sürümleri etkiliyor:
Kod:
Windows : 6.2.1.18 ve öncesi macOS : 6.2.1.17 ve öncesi Android : 3.5.0.173 ve öncesi
Güncelleyici, bilgisayar açılır açılmaz arka planda çalışıyor, yeni sürümü şifresiz bağlantı üzerinden kontrol ediyor ve kimin gönderdiğini doğrulamadan gelen her şeyi en yüksek yetkiyle (Windows'ta SYSTEM, Mac'te root) kuruyordu.

3. Neden botnet yakıtı?
Çağırdığı web adresleri terk edildiği için, doğru adresi kaydeden herhangi biri hâlâ o adresi arayan tüm makinelere kendi programını sunabilirdi. Böyle bir erişimle saldırgan fidye yazılımı kurabilir, kayıtlı parolaları çalabilir veya makineyi bir botnete katabilirdi. Eye, adreslerden birini kaydettiğinde saniyede yaklaşık 50 istek geldi; altı ayda 3,8 milyondan fazla farklı donanım kimliği göründü (tahmin: 2,5-3 milyon Windows, 250-350 bin Mac).

4. Operation IXIM
Yama çıkaracak şirket kalmadığı için Eye, hukuki görüş aldıktan sonra güncelleyiciyi kendisine karşı kullandı: makinelere sadece güncelleyiciyi durdurup devre dışı bırakan, hiçbir dosya silmeyen ve hiçbir veri toplamayan bir güncelleme gönderdi. Aralık 2025'e kadar 1 milyondan fazla sistem güncellendi, trafik %90 azaldı. Mart'ta operasyonu durdurdu ve kontrol ettiği 15 adresi Shadowserver Vakfı'na devretti.

5. Kullanıcılar ne yapmalı?
Eye'in tavsiyesi net: Popcorn Time'ı kaldırın. Güncelleyiciyi kapatmak uygulamayı güvenli yapmıyor; çünkü uygulama 2014 tarihli, güvenlik sandbox'ı kapalı bir tarayıcı motoru üzerinde çalışıyor. Elle kapatmak isteyenler için:
Kod:
# Windows sc.exe stop "Update service" sc.exe config "Update service" start= disabled # macOS launchctl unload -w /Library/LaunchDaemons/PT.updd.plist
Android'de güncelleyici uygulamaya gömülü olduğu için tek çözüm uygulamayı silmek.

6. Geliştiriciler için ders
Bu olay, kendi yazılımına otomatik güncelleme koyan herkes için bir kontrol listesi:
  1. Güncellemeleri imzalayın ve istemcide imzayı doğrulayın. Doğrulanmamış payload asla çalıştırılmamalı.
  2. Güncelleme kanalını HTTPS/TLS ile koruyun; şifresiz kontrol kabul edilemez.
  3. Terk etme planınız olsun. Proje biterse güncelleme altyapısını güvenli şekilde kapatmak veya domainleri elde tutmak gerekir.
  4. En az yetkiyle kurun. SYSTEM/root ile kör körüne kurulum, tek bir zayıf halkayı tam ele geçirmeye çevirir.

Sonuç
Operation IXIM hem terk edilmiş yazılımın ne kadar tehlikeli olabileceğini hem de güvenli güncelleme tasarımının önemini gösteriyor. Kullandığınız uygulamalardan arka planda sessizce güncelleyici çalıştıran var mı, hiç baktınız mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   08-t08-time4popcorn-ixim.png (Dosya Boyutu: 124.02 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=424]
Selamlar,

İlginç ve öğretici bir vaka: Hollandalı güvenlik firması Eye Security, Kasım 2025 ile Mart 2026 arasında sahibi olmadığı 2 milyondan fazla bilgisayara güncelleme göndererek, terk edilmiş Time4Popcorn uygulamasındaki tehlikeli bir güncelleyiciyi kapattı. The Hacker News "Operation IXIM" olarak bilinen bu operasyonu detaylandırdı. Burada güvensiz güncelleyici (updater) riskini ve kendi yazılım dağıtımınız için çıkarılacak dersleri ele alıyorum.

Konuda anlatılacaklar
  1. Time4Popcorn nedir, sorun ne?
  2. CVE-2026-30612 teknik özeti
  3. Güncelleyici neden botnet yakıtı olabilirdi?
  4. Operation IXIM: güncelleyiciyi kendine karşı kullanmak
  5. Kullanıcılar ne yapmalı?
  6. Geliştiriciler için ders: güvenli güncelleme

1. Time4Popcorn nedir?
Popcorn Time, yaklaşık on yıl önce popüler olan, BitTorrent üzerinden korsan film/dizi yayınlayan ücretsiz bir uygulamaydı. Orijinali 2014'te kapandı, ama aynı adla çalışan kopyalar sürdü. Time4Popcorn bu terk edilmiş kopyalardan biri. Eye Security, bir müşterinin dizüstünde sürekli artık kayıtlı olmayan bir web adresine ulaşmaya çalışan Updater.exe bulunca olayın ipini çekti.

2. CVE-2026-30612
CISA'nın 9.8 puanladığı açık şu sürümleri etkiliyor:
Kod:
Windows : 6.2.1.18 ve öncesi macOS : 6.2.1.17 ve öncesi Android : 3.5.0.173 ve öncesi
Güncelleyici, bilgisayar açılır açılmaz arka planda çalışıyor, yeni sürümü şifresiz bağlantı üzerinden kontrol ediyor ve kimin gönderdiğini doğrulamadan gelen her şeyi en yüksek yetkiyle (Windows'ta SYSTEM, Mac'te root) kuruyordu.

3. Neden botnet yakıtı?
Çağırdığı web adresleri terk edildiği için, doğru adresi kaydeden herhangi biri hâlâ o adresi arayan tüm makinelere kendi programını sunabilirdi. Böyle bir erişimle saldırgan fidye yazılımı kurabilir, kayıtlı parolaları çalabilir veya makineyi bir botnete katabilirdi. Eye, adreslerden birini kaydettiğinde saniyede yaklaşık 50 istek geldi; altı ayda 3,8 milyondan fazla farklı donanım kimliği göründü (tahmin: 2,5-3 milyon Windows, 250-350 bin Mac).

4. Operation IXIM
Yama çıkaracak şirket kalmadığı için Eye, hukuki görüş aldıktan sonra güncelleyiciyi kendisine karşı kullandı: makinelere sadece güncelleyiciyi durdurup devre dışı bırakan, hiçbir dosya silmeyen ve hiçbir veri toplamayan bir güncelleme gönderdi. Aralık 2025'e kadar 1 milyondan fazla sistem güncellendi, trafik %90 azaldı. Mart'ta operasyonu durdurdu ve kontrol ettiği 15 adresi Shadowserver Vakfı'na devretti.

5. Kullanıcılar ne yapmalı?
Eye'in tavsiyesi net: Popcorn Time'ı kaldırın. Güncelleyiciyi kapatmak uygulamayı güvenli yapmıyor; çünkü uygulama 2014 tarihli, güvenlik sandbox'ı kapalı bir tarayıcı motoru üzerinde çalışıyor. Elle kapatmak isteyenler için:
Kod:
# Windows sc.exe stop "Update service" sc.exe config "Update service" start= disabled # macOS launchctl unload -w /Library/LaunchDaemons/PT.updd.plist
Android'de güncelleyici uygulamaya gömülü olduğu için tek çözüm uygulamayı silmek.

6. Geliştiriciler için ders
Bu olay, kendi yazılımına otomatik güncelleme koyan herkes için bir kontrol listesi:
  1. Güncellemeleri imzalayın ve istemcide imzayı doğrulayın. Doğrulanmamış payload asla çalıştırılmamalı.
  2. Güncelleme kanalını HTTPS/TLS ile koruyun; şifresiz kontrol kabul edilemez.
  3. Terk etme planınız olsun. Proje biterse güncelleme altyapısını güvenli şekilde kapatmak veya domainleri elde tutmak gerekir.
  4. En az yetkiyle kurun. SYSTEM/root ile kör körüne kurulum, tek bir zayıf halkayı tam ele geçirmeye çevirir.

Sonuç
Operation IXIM hem terk edilmiş yazılımın ne kadar tehlikeli olabileceğini hem de güvenli güncelleme tasarımının önemini gösteriyor. Kullandığınız uygulamalardan arka planda sessizce güncelleyici çalıştıran var mı, hiç baktınız mı?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   08-t08-time4popcorn-ixim.png (Dosya Boyutu: 124.02 KB / İndirme Sayısı: 1) ]]> <![CDATA[Oracle Ekim 2026 CPU: 1.295 Yama, 95 Kritik Açık ve Fusion Middleware Önceliği]]> https://www.turkteam.org/konu-oracle-ekim-2026-cpu-1-295-yama-95-kritik-acik-ve-fusion-middleware-onceligi.html Sun, 25 Oct 2026 11:39:32 +0300 Tonyukuk]]> https://www.turkteam.org/konu-oracle-ekim-2026-cpu-1-295-yama-95-kritik-acik-ve-fusion-middleware-onceligi.html [Resim: attachment.php?aid=423]
Selamlar,

Oracle, Ekim 2026 Critical Patch Update'ini (CPU) yayımladı. Bu çeyreklik toplu yama, onlarca ürün genelinde 1.295 yeni düzeltme getiriyor. SecurityWeek'in Tenable analizine dayandırdığı habere göre bunlar 1.209 benzersiz CVE'yi kapsıyor ve 95'i kritik seviyede. Bu kadar geniş bir yama setinde "neyi önce yamalamalı" sorusu kritik hale geliyor. Burada dağılımı ve önceliklendirme mantığını ele alıyorum.

Konuda anlatılacaklar
  1. Rakamlarla CPU
  2. En çok yama alan ürünler
  3. eMudhra için ayrı Java uyarısı
  4. Yama önceliklendirme mantığı
  5. Sonraki tarihler

1. Rakamlarla CPU
Kod:
Toplam yeni yama : 1.295 Benzersiz CVE : 1.209 Kritik : 95
Oracle bu açıklardan hiçbirini vahşi doğada sömürülüyor olarak işaretlemedi, ancak ürünlerine yönelik sömürü girişimi raporları aldığını periyodik olarak hatırlatıyor.

2. En çok yama alan ürünler
Kod:
Fusion Middleware : 206 (134'ü kimlik doğrulamasız uzaktan sömürülebilir) E-Business Suite : 194 Siebel CRM : 122 Communications : 110 PeopleSoft : 109 JD Edwards : 102 MySQL : 98 Java SE : 55
Özellikle Fusion Middleware'deki 134 kimlik doğrulamasız uzaktan sömürülebilir CVE, internete dönük ortamlar için en acil başlıktır.

3. eMudhra için ayrı Java uyarısı
Oracle, CPU'dan bir gün sonra Java'nın (ve Oracle'ın) eMudhra zayıf anahtar olayına yanıtını içeren CVE-2026-91403 için ayrı bir uyarı ve güvenlik alarmı yayımladı. eMudhra olayını daha önce forumda ele almıştık; CI ve Java trust store'larınızın güncel olmasına dikkat edin.

4. Yama önceliklendirme mantığı
1.295 yamayı aynı anda uygulamak çoğu kurum için imkansız. Pratik bir sıralama:
  1. İnternete dönük + kimlik doğrulamasız + kritik olanlar önce. Fusion Middleware'deki 134 CVE bu kategoride.
  2. CVSS yanında EPSS'e bakın. Sömürü olasılığı yüksek olanları öne alın.
  3. Veri kritikliğine göre veritabanı (MySQL) ve kimlik sistemlerini önceliklendirin.
  4. Varlık envanterinizle eşleşen CVE'leri filtreleyin; kullanmadığınız ürünlerin yamalarını sona bırakın.
Basit bir filtreleme fikri (EPSS API ile):
Kod:
curl -s "https://api.first.org/data/v1/epss?cve=CVE-XXXX,CVE-YYYY" | python3 -m json.tool

5. Sonraki tarihler
Oracle, 17 Kasım ve 15 Aralık'ta Critical Security Patch Update (CSPU) yayınlayacak; bunlar her ayın üçüncü Salısı çıkıyor. Bir sonraki çeyreklik CPU ise 19 Ocak 2027'de.

Sonuç
Dev CPU'larda asıl mesele yama sayısı değil, doğru sıralama. Varlık envanteri, maruziyet ve EPSS üçlüsüne bakarak kritik birkaç yüz yamayı öne alan ekipler, kaynaklarını en iyi kullanır. Siz Oracle yamalarını hangi ölçüte göre sıralıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   07-t07-oracle-ekim-2026-cpu.png (Dosya Boyutu: 125.51 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=423]
Selamlar,

Oracle, Ekim 2026 Critical Patch Update'ini (CPU) yayımladı. Bu çeyreklik toplu yama, onlarca ürün genelinde 1.295 yeni düzeltme getiriyor. SecurityWeek'in Tenable analizine dayandırdığı habere göre bunlar 1.209 benzersiz CVE'yi kapsıyor ve 95'i kritik seviyede. Bu kadar geniş bir yama setinde "neyi önce yamalamalı" sorusu kritik hale geliyor. Burada dağılımı ve önceliklendirme mantığını ele alıyorum.

Konuda anlatılacaklar
  1. Rakamlarla CPU
  2. En çok yama alan ürünler
  3. eMudhra için ayrı Java uyarısı
  4. Yama önceliklendirme mantığı
  5. Sonraki tarihler

1. Rakamlarla CPU
Kod:
Toplam yeni yama : 1.295 Benzersiz CVE : 1.209 Kritik : 95
Oracle bu açıklardan hiçbirini vahşi doğada sömürülüyor olarak işaretlemedi, ancak ürünlerine yönelik sömürü girişimi raporları aldığını periyodik olarak hatırlatıyor.

2. En çok yama alan ürünler
Kod:
Fusion Middleware : 206 (134'ü kimlik doğrulamasız uzaktan sömürülebilir) E-Business Suite : 194 Siebel CRM : 122 Communications : 110 PeopleSoft : 109 JD Edwards : 102 MySQL : 98 Java SE : 55
Özellikle Fusion Middleware'deki 134 kimlik doğrulamasız uzaktan sömürülebilir CVE, internete dönük ortamlar için en acil başlıktır.

3. eMudhra için ayrı Java uyarısı
Oracle, CPU'dan bir gün sonra Java'nın (ve Oracle'ın) eMudhra zayıf anahtar olayına yanıtını içeren CVE-2026-91403 için ayrı bir uyarı ve güvenlik alarmı yayımladı. eMudhra olayını daha önce forumda ele almıştık; CI ve Java trust store'larınızın güncel olmasına dikkat edin.

4. Yama önceliklendirme mantığı
1.295 yamayı aynı anda uygulamak çoğu kurum için imkansız. Pratik bir sıralama:
  1. İnternete dönük + kimlik doğrulamasız + kritik olanlar önce. Fusion Middleware'deki 134 CVE bu kategoride.
  2. CVSS yanında EPSS'e bakın. Sömürü olasılığı yüksek olanları öne alın.
  3. Veri kritikliğine göre veritabanı (MySQL) ve kimlik sistemlerini önceliklendirin.
  4. Varlık envanterinizle eşleşen CVE'leri filtreleyin; kullanmadığınız ürünlerin yamalarını sona bırakın.
Basit bir filtreleme fikri (EPSS API ile):
Kod:
curl -s "https://api.first.org/data/v1/epss?cve=CVE-XXXX,CVE-YYYY" | python3 -m json.tool

5. Sonraki tarihler
Oracle, 17 Kasım ve 15 Aralık'ta Critical Security Patch Update (CSPU) yayınlayacak; bunlar her ayın üçüncü Salısı çıkıyor. Bir sonraki çeyreklik CPU ise 19 Ocak 2027'de.

Sonuç
Dev CPU'larda asıl mesele yama sayısı değil, doğru sıralama. Varlık envanteri, maruziyet ve EPSS üçlüsüne bakarak kritik birkaç yüz yamayı öne alan ekipler, kaynaklarını en iyi kullanır. Siz Oracle yamalarını hangi ölçüte göre sıralıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   07-t07-oracle-ekim-2026-cpu.png (Dosya Boyutu: 125.51 KB / İndirme Sayısı: 1) ]]> <![CDATA[Storm-0940 ARTEX ile ConnectWise'ı Vurdu: Dakikada 2.900 Denemeyle Makine Hızı]]> https://www.turkteam.org/konu-storm-0940-artex-ile-connectwise-i-vurdu-dakikada-2-900-denemeyle-makine-hizi.html Sun, 25 Oct 2026 11:38:43 +0300 Tonyukuk]]> https://www.turkteam.org/konu-storm-0940-artex-ile-connectwise-i-vurdu-dakikada-2-900-denemeyle-makine-hizi.html [Resim: attachment.php?aid=422]
Selamlar,

Microsoft, ConnectWise Cloud Backup tedarik zinciri saldırısını Çin devleti bağlantılı Storm-0940 aktörüne atfetti. Dikkat çeken yön: aktör, açık kaynaklı ajan tabanlı bir sızma testi çerçevesi olan ARTEX'i kullanarak keşif, parola püskürtme ve OAuth kötüye kullanımını "makine hızına" çıkardı. SecurityWeek ve CyberScoop konuyu aktardı. Bu, YZ ajanlarının saldırı hızını nasıl değiştirdiğini gösteren somut bir vaka. Burada olayı ve kurumsal savunma adımlarını özetliyorum.

Konuda anlatılacaklar
  1. ARTEX nedir?
  2. Olay zinciri: parola püskürtmeden OAuth kötüye kullanımına
  3. Rakamlar: 2.250 kiracı, 2.900 deneme/dakika
  4. Kalıcılığın kurnazlığı: uygulama kimlik bilgisi değiştirme
  5. Savunma: servis sorumlusu girişlerini izlemek

1. ARTEX nedir?
Microsoft'a göre ARTEX, herhangi bir YZ modeliyle çalışabilen, Go ile yazılmış ve Next.js ön yüzü olan çok ajanlı bir LLM sistemidir. Keşiften veri sızdırmaya kadar otonom bir sızma testini çok az insan müdahalesiyle yürütebiliyor; keşfedilen varlık ve zafiyetleri bir grafa topluyor. Microsoft birden fazla coğrafyadaki tehdit aktörünün ARTEX'i kullandığını belirtiyor.

2. Olay zinciri
  • Eylül 2026 başından itibaren Storm-0940 ARTEX'i yüzlerce kurumu hedeflemek için kullandı (havacılık, savunma, otomotiv, enerji, finans, kamu, hukuk, üretim, medya, yarı iletken, yazılım, düşünce kuruluşları).
  • 10-14 Ekim arası, sekiz kurumda 327 hesaba karşı otomatik, kiracılar arası parola püskürtmesi yapıldı.
  • 15 Ekim'de ConnectWise'a yöneldi; ele geçirilmiş ConnectWise uygulama kimlik bilgileriyle müşteri Microsoft 365 ortamlarına erişti.
SecurityWeek'e göre Huntress, saldırganların yüzlerce M365 kiracısına (300'den fazla Entra kiracısı dahil) eriştiğini gözlemledi.

3. Rakamlar
Kod:
Hedeflenen hesap (8 kurum) : 327 Pik hız : 2.900 deneme/dakika Başarısız giriş olayı : 151.000+ Denenen kiracı sayısı : 2.250+
Microsoft, bazı ortamlarda ajanların kimlik doğrulamasının ötesine geçip Microsoft Graph üzerinden keşif, uygulama kimlik bilgisi değişikliği ve ayrıcalıklı rol değişiklikleri yaptığını belirtiyor.

4. Kalıcılığın kurnazlığı
En önemli savunma dersi burada: saldırganlar uygulama kimlik bilgilerini değiştirerek, etkilenen uygulama temizlendikten sonra bile erişimlerini sürdürdü. Yani sadece "kötü uygulamayı kaldırmak" yetmiyor; uygulamaya eklenmiş yeni sırlar/sertifikalar da temizlenmeli.

5. Savunma kontrol listesi
  1. Servis sorumlusu (service principal) girişlerini izleyin. Microsoft, bu girişleri sonraki Graph aktivitesi, dizin değişiklikleri ve kaynak erişimiyle ilişkilendirmeyi öneriyor.
  2. OAuth uygulama izinlerini denetleyin. Yüksek yetkili üçüncü taraf uygulamalar, kendi kapsamının ötesine erişim sağlayabilir.
  3. Uygulama kimlik bilgisi/sertifika eklemelerini alarmlayın. Beklenmeyen yeni secret bir kalıcılık göstergesidir.
  4. Koşullu erişim ve zorunlu MFA ile parola püskürtmeyi zorlaştırın.
  5. Ani, yüksek hacimli başarısız giriş (dakikada binlerce) için eşik tabanlı tespit kurun.

Sonuç
Bu vaka, YZ'nin saldırı temellerini değil hızını değiştirdiğini gösteriyor. Dakikada binlerce deneme ve saatler içinde kalıcı erişim, insan hızında yazılmış oyun kitaplarının makine hızına çıkmış hali. Savunma da aynı ölçekte otomasyon ister. Siz OAuth uygulama izinlerinizi en son ne zaman denetlediniz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   06-t06-storm0940-artex-connectwise.png (Dosya Boyutu: 122.11 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=422]
Selamlar,

Microsoft, ConnectWise Cloud Backup tedarik zinciri saldırısını Çin devleti bağlantılı Storm-0940 aktörüne atfetti. Dikkat çeken yön: aktör, açık kaynaklı ajan tabanlı bir sızma testi çerçevesi olan ARTEX'i kullanarak keşif, parola püskürtme ve OAuth kötüye kullanımını "makine hızına" çıkardı. SecurityWeek ve CyberScoop konuyu aktardı. Bu, YZ ajanlarının saldırı hızını nasıl değiştirdiğini gösteren somut bir vaka. Burada olayı ve kurumsal savunma adımlarını özetliyorum.

Konuda anlatılacaklar
  1. ARTEX nedir?
  2. Olay zinciri: parola püskürtmeden OAuth kötüye kullanımına
  3. Rakamlar: 2.250 kiracı, 2.900 deneme/dakika
  4. Kalıcılığın kurnazlığı: uygulama kimlik bilgisi değiştirme
  5. Savunma: servis sorumlusu girişlerini izlemek

1. ARTEX nedir?
Microsoft'a göre ARTEX, herhangi bir YZ modeliyle çalışabilen, Go ile yazılmış ve Next.js ön yüzü olan çok ajanlı bir LLM sistemidir. Keşiften veri sızdırmaya kadar otonom bir sızma testini çok az insan müdahalesiyle yürütebiliyor; keşfedilen varlık ve zafiyetleri bir grafa topluyor. Microsoft birden fazla coğrafyadaki tehdit aktörünün ARTEX'i kullandığını belirtiyor.

2. Olay zinciri
  • Eylül 2026 başından itibaren Storm-0940 ARTEX'i yüzlerce kurumu hedeflemek için kullandı (havacılık, savunma, otomotiv, enerji, finans, kamu, hukuk, üretim, medya, yarı iletken, yazılım, düşünce kuruluşları).
  • 10-14 Ekim arası, sekiz kurumda 327 hesaba karşı otomatik, kiracılar arası parola püskürtmesi yapıldı.
  • 15 Ekim'de ConnectWise'a yöneldi; ele geçirilmiş ConnectWise uygulama kimlik bilgileriyle müşteri Microsoft 365 ortamlarına erişti.
SecurityWeek'e göre Huntress, saldırganların yüzlerce M365 kiracısına (300'den fazla Entra kiracısı dahil) eriştiğini gözlemledi.

3. Rakamlar
Kod:
Hedeflenen hesap (8 kurum) : 327 Pik hız : 2.900 deneme/dakika Başarısız giriş olayı : 151.000+ Denenen kiracı sayısı : 2.250+
Microsoft, bazı ortamlarda ajanların kimlik doğrulamasının ötesine geçip Microsoft Graph üzerinden keşif, uygulama kimlik bilgisi değişikliği ve ayrıcalıklı rol değişiklikleri yaptığını belirtiyor.

4. Kalıcılığın kurnazlığı
En önemli savunma dersi burada: saldırganlar uygulama kimlik bilgilerini değiştirerek, etkilenen uygulama temizlendikten sonra bile erişimlerini sürdürdü. Yani sadece "kötü uygulamayı kaldırmak" yetmiyor; uygulamaya eklenmiş yeni sırlar/sertifikalar da temizlenmeli.

5. Savunma kontrol listesi
  1. Servis sorumlusu (service principal) girişlerini izleyin. Microsoft, bu girişleri sonraki Graph aktivitesi, dizin değişiklikleri ve kaynak erişimiyle ilişkilendirmeyi öneriyor.
  2. OAuth uygulama izinlerini denetleyin. Yüksek yetkili üçüncü taraf uygulamalar, kendi kapsamının ötesine erişim sağlayabilir.
  3. Uygulama kimlik bilgisi/sertifika eklemelerini alarmlayın. Beklenmeyen yeni secret bir kalıcılık göstergesidir.
  4. Koşullu erişim ve zorunlu MFA ile parola püskürtmeyi zorlaştırın.
  5. Ani, yüksek hacimli başarısız giriş (dakikada binlerce) için eşik tabanlı tespit kurun.

Sonuç
Bu vaka, YZ'nin saldırı temellerini değil hızını değiştirdiğini gösteriyor. Dakikada binlerce deneme ve saatler içinde kalıcı erişim, insan hızında yazılmış oyun kitaplarının makine hızına çıkmış hali. Savunma da aynı ölçekte otomasyon ister. Siz OAuth uygulama izinlerinizi en son ne zaman denetlediniz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   06-t06-storm0940-artex-connectwise.png (Dosya Boyutu: 122.11 KB / İndirme Sayısı: 1) ]]> <![CDATA[LiteLLM Saldırı Zinciri: İptal Edilmeyen Tek Anahtar Nasıl PyPI'ya Uzandı?]]> https://www.turkteam.org/konu-litellm-saldiri-zinciri-iptal-edilmeyen-tek-anahtar-nasil-pypi-ya-uzandi.html Sun, 25 Oct 2026 11:35:38 +0300 Tonyukuk]]> https://www.turkteam.org/konu-litellm-saldiri-zinciri-iptal-edilmeyen-tek-anahtar-nasil-pypi-ya-uzandi.html [Resim: attachment.php?aid=419]
Selamlar,

21 Ekim'de PyPI ve Docker'a yüklenen zararlı litellm==1.107.0 sürümünü daha önce konuşmuştuk. LiteLLM ekibi saldırının nasıl başladığını adım adım anlatan bir inceleme yayımladı. Başlangıç noktası şaşırtıcı derecede sıradan: Mayıs ayında herkese açık bir repoya yanlışlıkla gönderilen ve hiç iptal edilmeyen tek bir ana anahtar. Burada zinciri halka halka açıyorum.

Konuda anlatılacaklar
  1. Halka 0: Herkese açık repoya düşen ana anahtar
  2. Halka 1: Ajan platformundan GitHub token'ına
  3. Halka 2-3: Geçici branch'lerle sır toplama
  4. Halka 4-5: Benzer isimli fork'tan zararlı sürüm
  5. Halka 6-7: İz temizleme
  6. Python başlangıç kancası tehlikesi
  7. Çıkarılacak dersler

1. Halka 0: Sızan ana anahtar
LiteLLM'in zaman çizelgesine göre (saatler UTC):
Alıntı:27 Mayıs 18:53 - opencode.json dosyası, Agent Platform ana anahtarını içerecek şekilde herkese açık bir LiteLLM-Labs reposuna gönderildi.
Hata hızla fark edildi, commit force-push ile üstüne yazıldı ve anahtarların iptal edilmesi gerektiği belirlendi. Ancak ana anahtarın iptali hiç gerçekleşmedi. Force-push bir sırrı geri almaz; git geçmişi üstüne yazılsa bile sır bir kez dışarı çıktıysa yakılmalıdır.

2. Halka 1: GitHub token'ına geçiş
LiteLLM Agent Platform, kendinden barındırılan bulut ajanlarının GitHub'a PR açabilmesi için deneysel bir projeydi ve bir GitHub kimlik doğrulama token'ıyla yapılandırılmıştı. Bu token:
  • Bir servis hesabına bağlı değildi,
  • yetkileri daraltılmamıştı,
  • organizasyon sahibinin hesabına bağlı bir GitHub CLI OAuth token'ıydı.
10 Ekim 21:13-21:28 arası saldırgan, iptal edilmeyen ana anahtarla Agent Platform API'sine ulaştı ve 21:27'de ilgili uç nokta çağrısıyla sahibin GitHub CLI token'ını aldı. Bu noktadan sonra tüm repolara sahip seviyesinde erişimi vardı. Önemli ayrıntı: GitHub CLI token'ları 2FA sonrası üretilir ve hassas işlemlerdeki ek 2FA doğrulamasına tabi değildir.

3. Halka 2-3: Sır toplama
10 Ekim 22:11-22:12 arası saldırgan, ci-tmp önekli geçici branch'lerde iş akışları çalıştırarak altı sırrı (GH_TOKEN ve RELEASE_PLEASE_TOKEN dahil) bir webhook.site uç noktasına gönderdi, sonra çalışmaları dakikalar içinde sildi. 12 Ekim'de ise çeşitli özel repolarda iş akışları çalıştırıp tüm repo sırlarını aynı uca sızdırdı.

4. Halka 4-5: Zararlı sürüm
21 Ekim sabahı (UTC):
Kod:
10:08:34 branch korumasını geçersiz kılarak main'e push 10:46:39 staging iş akışı, kaynak benzer isimli "Berri-AI/litellm" fork'una ayarlandı (gerçek repo: BerriAI/litellm) 11:08:53 üretim yayın hattı başladı 11:39-11:40 yedi adet litellm==1.107.0 wheel PyPI'ya yüklendi 11:46:56 Docker Hub ve GHCR imajları yayımlandı
LiteLLM, normalde bir sürümün yetkili bir mühendis tarafından tetiklenip ofisteki fiziksel bir cihaza kilitli özel bir hesapça onaylanması gerektiğini, ancak daha sık sürüm için bu kuralı geçici olarak gevşettiklerini belirtiyor. Saldırgan tam da bu gevşetilmiş kuralı kullandı.

5. Halka 6-7: İz temizleme
11:53-11:54 arası üretim ve staging çalışma kayıtları silindi. 12:06'da bir araştırmacı saldırıyı bildirdi. 13:23 civarı PyPI, 1.107.0'ı karantinaya aldı.

6. Payload: Python başlangıç kancası
Microsoft'un analizine göre zararlı sürümün kritik yanı: bir uygulamanın LiteLLM'i import etmesine bile gerek yoktu. Etkilenen ortamda Python'ı başlatmak, kimlik bilgisi/sır/ortam değişkeni çalan payload'u tetikliyordu. Bu, .pth / sitecustomize tarzı başlangıç kancası riskinin canlı bir örneği.

7. Çıkarılacak dersler
  1. Sızan sır = yakılacak sır. Force-push veya "üstüne yazdık" asla iptal yerine geçmez. Her sızan anahtarı hemen döndürün (rotate).
  2. Token'ları daraltın ve servis hesabına bağlayın. Organizasyon sahibinin geniş kapsamlı kişisel token'ı otomasyona verilmez.
  3. Sürüm onayındaki dört göz ilkesini gevşetmeyin. "Hız için geçici" istisnalar tam da saldırıya davetiye çıkardı.
  4. Kaynak repo bütünlüğünü doğrulayın. Benzer isimli fork (Berri-AI vs BerriAI) klasik typosquat tuzağı.
  5. Bağımlılıkları hash ile sabitleyin. pip --require-hashes, npm ci ve imaj digest'leri bu tür bir sürümü kapıda durdurur.

Sonuç
LiteLLM saldırısı, tedarik zinciri güvenliğinin en sık tekrarlanan dersini bir kez daha gösterdi: en zayıf halka çoğu zaman unutulmuş bir anahtar ya da gevşetilmiş bir süreç kuralı. Sizin CI/CD hattınızda sürüm onayı kaç kişinin eline bakıyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   03-t03-litellm-saldiri-zinciri.png (Dosya Boyutu: 111.69 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=419]
Selamlar,

21 Ekim'de PyPI ve Docker'a yüklenen zararlı litellm==1.107.0 sürümünü daha önce konuşmuştuk. LiteLLM ekibi saldırının nasıl başladığını adım adım anlatan bir inceleme yayımladı. Başlangıç noktası şaşırtıcı derecede sıradan: Mayıs ayında herkese açık bir repoya yanlışlıkla gönderilen ve hiç iptal edilmeyen tek bir ana anahtar. Burada zinciri halka halka açıyorum.

Konuda anlatılacaklar
  1. Halka 0: Herkese açık repoya düşen ana anahtar
  2. Halka 1: Ajan platformundan GitHub token'ına
  3. Halka 2-3: Geçici branch'lerle sır toplama
  4. Halka 4-5: Benzer isimli fork'tan zararlı sürüm
  5. Halka 6-7: İz temizleme
  6. Python başlangıç kancası tehlikesi
  7. Çıkarılacak dersler

1. Halka 0: Sızan ana anahtar
LiteLLM'in zaman çizelgesine göre (saatler UTC):
Alıntı:27 Mayıs 18:53 - opencode.json dosyası, Agent Platform ana anahtarını içerecek şekilde herkese açık bir LiteLLM-Labs reposuna gönderildi.
Hata hızla fark edildi, commit force-push ile üstüne yazıldı ve anahtarların iptal edilmesi gerektiği belirlendi. Ancak ana anahtarın iptali hiç gerçekleşmedi. Force-push bir sırrı geri almaz; git geçmişi üstüne yazılsa bile sır bir kez dışarı çıktıysa yakılmalıdır.

2. Halka 1: GitHub token'ına geçiş
LiteLLM Agent Platform, kendinden barındırılan bulut ajanlarının GitHub'a PR açabilmesi için deneysel bir projeydi ve bir GitHub kimlik doğrulama token'ıyla yapılandırılmıştı. Bu token:
  • Bir servis hesabına bağlı değildi,
  • yetkileri daraltılmamıştı,
  • organizasyon sahibinin hesabına bağlı bir GitHub CLI OAuth token'ıydı.
10 Ekim 21:13-21:28 arası saldırgan, iptal edilmeyen ana anahtarla Agent Platform API'sine ulaştı ve 21:27'de ilgili uç nokta çağrısıyla sahibin GitHub CLI token'ını aldı. Bu noktadan sonra tüm repolara sahip seviyesinde erişimi vardı. Önemli ayrıntı: GitHub CLI token'ları 2FA sonrası üretilir ve hassas işlemlerdeki ek 2FA doğrulamasına tabi değildir.

3. Halka 2-3: Sır toplama
10 Ekim 22:11-22:12 arası saldırgan, ci-tmp önekli geçici branch'lerde iş akışları çalıştırarak altı sırrı (GH_TOKEN ve RELEASE_PLEASE_TOKEN dahil) bir webhook.site uç noktasına gönderdi, sonra çalışmaları dakikalar içinde sildi. 12 Ekim'de ise çeşitli özel repolarda iş akışları çalıştırıp tüm repo sırlarını aynı uca sızdırdı.

4. Halka 4-5: Zararlı sürüm
21 Ekim sabahı (UTC):
Kod:
10:08:34 branch korumasını geçersiz kılarak main'e push 10:46:39 staging iş akışı, kaynak benzer isimli "Berri-AI/litellm" fork'una ayarlandı (gerçek repo: BerriAI/litellm) 11:08:53 üretim yayın hattı başladı 11:39-11:40 yedi adet litellm==1.107.0 wheel PyPI'ya yüklendi 11:46:56 Docker Hub ve GHCR imajları yayımlandı
LiteLLM, normalde bir sürümün yetkili bir mühendis tarafından tetiklenip ofisteki fiziksel bir cihaza kilitli özel bir hesapça onaylanması gerektiğini, ancak daha sık sürüm için bu kuralı geçici olarak gevşettiklerini belirtiyor. Saldırgan tam da bu gevşetilmiş kuralı kullandı.

5. Halka 6-7: İz temizleme
11:53-11:54 arası üretim ve staging çalışma kayıtları silindi. 12:06'da bir araştırmacı saldırıyı bildirdi. 13:23 civarı PyPI, 1.107.0'ı karantinaya aldı.

6. Payload: Python başlangıç kancası
Microsoft'un analizine göre zararlı sürümün kritik yanı: bir uygulamanın LiteLLM'i import etmesine bile gerek yoktu. Etkilenen ortamda Python'ı başlatmak, kimlik bilgisi/sır/ortam değişkeni çalan payload'u tetikliyordu. Bu, .pth / sitecustomize tarzı başlangıç kancası riskinin canlı bir örneği.

7. Çıkarılacak dersler
  1. Sızan sır = yakılacak sır. Force-push veya "üstüne yazdık" asla iptal yerine geçmez. Her sızan anahtarı hemen döndürün (rotate).
  2. Token'ları daraltın ve servis hesabına bağlayın. Organizasyon sahibinin geniş kapsamlı kişisel token'ı otomasyona verilmez.
  3. Sürüm onayındaki dört göz ilkesini gevşetmeyin. "Hız için geçici" istisnalar tam da saldırıya davetiye çıkardı.
  4. Kaynak repo bütünlüğünü doğrulayın. Benzer isimli fork (Berri-AI vs BerriAI) klasik typosquat tuzağı.
  5. Bağımlılıkları hash ile sabitleyin. pip --require-hashes, npm ci ve imaj digest'leri bu tür bir sürümü kapıda durdurur.

Sonuç
LiteLLM saldırısı, tedarik zinciri güvenliğinin en sık tekrarlanan dersini bir kez daha gösterdi: en zayıf halka çoğu zaman unutulmuş bir anahtar ya da gevşetilmiş bir süreç kuralı. Sizin CI/CD hattınızda sürüm onayı kaç kişinin eline bakıyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   03-t03-litellm-saldiri-zinciri.png (Dosya Boyutu: 111.69 KB / İndirme Sayısı: 1) ]]> <![CDATA[Brotli Açığı CVE-2026-111497 Sadece Node.js Değil: Bun, Python ve Envoy Yama Rehberi]]> https://www.turkteam.org/konu-brotli-acigi-cve-2026-111497-sadece-node-js-degil-bun-python-ve-envoy-yama-rehberi.html Sun, 25 Oct 2026 11:34:43 +0300 Tonyukuk]]> https://www.turkteam.org/konu-brotli-acigi-cve-2026-111497-sadece-node-js-degil-bun-python-ve-envoy-yama-rehberi.html [Resim: attachment.php?aid=418]
Selamlar,

Node2Shell olarak duyulan CVE-2026-111497 için çoğu kişi "Node.js'i güncelledim, bitti" diye düşündü. Oysa açık Node.js'in kendi kodunda değil, Google'ın Brotli sıkıştırma kütüphanesinin decoder kısmında. Bu kütüphaneyi kendi içinde taşıyan her yazılımın ayrıca güncellenmesi gerekiyor. The Hacker News, Bun, Python Brotli/brotlicffi paketleri ve Envoy'un da etkilendiğini duyurdu. Burada hangi sürüme geçmeniz gerektiğini ve sistemde etkilenen kopyaları nasıl bulacağınızı topluyorum.

Konuda anlatılacaklar
  1. Açık nedir, neden bu kadar yaygın?
  2. Brotli kütüphanesinin düzeltilmiş sürümleri
  3. Bun: fetch bile tetikleyebilir
  4. Python: requests/urllib3 ve brotlicffi
  5. Envoy ve Istio
  6. Sunucunuzda kontrol komutları

1. Açık nedir?
NVD kaydına göre sorun, Brotli decoder'ında (c/dec/decode.c) bir tampon taşması. Özel hazırlanmış bir Brotli akışı, kimlik doğrulaması olmayan uzak bir saldırganın decoder durum belleğini bozmasına, bellek içeriği sızdırmasına, servisi çökertmesine veya potansiyel olarak kod çalıştırmasına yol açabiliyor. Zayıflık türleri: CWE-787 (sınır dışı yazma) ve CWE-252 (dönüş değerinin kontrol edilmemesi). Upstream puanı CVSS 4.0: 9.2.

Önemli bağlam:
  • The Hacker News'e göre açık, OpenAI'nin kırmızı takım kampanyası sırasında bulundu.
  • Imperva, resmi bir Node.js derlemesinde kod çalıştırmayı gösterdi. Diğer yazılımlarda bu henüz gösterilmedi ve gerçek dünyada saldırı raporu yok.
  • Brotli HTTP'de Content-Encoding: br olarak her yerde kullanıldığı için, sıkıştırılmış veriyi açan istemci ve sunucular saldırı yüzeyinde.

2. Düzeltilmiş Brotli sürümleri
NVD: etkilenen aralık 1.0.3 ile 1.2.0 arası. Güncel düzeltilmiş sürümler:
Kod:
Brotli 1.0.x -> 1.0.10 Brotli 1.1.x -> 1.1.1 Brotli 1.2.x -> 1.2.1

3. Bun
Bun güvenlik bildirimi (GHSA-663w-cv8g-jj2p):
  • Etkilenen: 1.0.21 ile 1.4.4 öncesi. Düzeltilmiş: 1.4.4 (Brotli 1.2.1 ile geliyor).
  • Tetikleyen API'ler: fetch (varsayılan olarak Accept-Encoding içinde br gönderir ve yanıtı otomatik açar), node:zlib içindeki brotliDecompress türevleri ve brotli formatlı DecompressionStream.
  • Yani bağlandığınız kötü niyetli bir sunucu veya şifresiz bağlantıda araya giren biri decoder'a veri gönderebilir.
  • bun build --compile ile üretilmiş tek dosyalık yürütülebilirler, yeniden derlenene kadar etkilenmiş kalır.
Kod:
bun --version bun upgrade bun build --compile ./src/index.ts --outfile mytool
Geçici çözüm olarak Bun, istek bazında fetch(url, { decompress: false }) kullanımını ve güvenilmeyen veriyi brotli API'lerine vermemeyi öneriyor.

4. Python
PyPA danışma kaydı (PYSEC-2026-4323) iki paketi kapsıyor:
  • Brotli (Google'ın CPython bağlaması): 1.2.0 dahil tüm sürümler etkileniyor, düzeltme 1.2.1.
  • brotlicffi: düzeltme 1.2.1.0 (21 Ekim 2026).
Kritik nokta: Bu paketlerden biri kuruluysa urllib3/requests, brotli ekstrası ile httpx ve aiohttp gibi yaygın HTTP istemcileri Brotli yanıtlarını otomatik açıyor. Yani sizin kodunuz brotli'yi hiç import etmese bile saldırgan kontrolündeki bir sunucudan gelen yanıt decoder'a ulaşabilir.
Kod:
pip show brotli brotlicffi 2>/dev/null | grep -E "Name|Version" pip install -U "brotli>=1.2.1" "brotlicffi>=1.2.1.0" pip-audit | grep -i brotli

5. Envoy ve Istio
Envoy bildirimi (GHSA-3wvj-j6qm-62mr, Critical 9.2):
Kod:
Etkilenen : v1.39.2, v1.38.5, v1.37.7, v1.36.11 Düzeltilmiş: v1.40.0, v1.39.3, v1.38.6, v1.37.8, v1.36.12
Sadece Brotli decompressor yapılandırılmış Envoy dağıtımları etkileniyor. The Hacker News, Istio için de yama yayımlandığını aktarıyor; Istio kullanıyorsanız kendi bildirimine bakın.
Kod:
envoy --version grep -rn "envoy.compression.brotli.decompressor" /etc/envoy/ 2>/dev/null

6. Sunucunuzda etkilenen kopyaları bulmak
Brotli birçok yazılımın içine gömülü geldiği için tek bir komut her şeyi bulmaz:
Kod:
dpkg -l | grep -i brotli # Debian/Ubuntu rpm -qa | grep -i brotli # RHEL/Fedora sudo lsof 2>/dev/null | grep -i libbrotlidec | awk '{print $1}' | sort -u node -v ; bun --version 2>/dev/null
Gömülü kopyalar (statik derlenmiş araçlar, konteyner imajları) için SBOM tabanlı tarama gerekir. Trivy veya Grype ile imajlarınızı tarayıp "brotli" geçen bileşenleri ayıklayabilirsiniz.

Sonuç
Bu açık, tedarik zincirinde "tek kütüphane, yüzlerce kopya" sorununun tipik örneği. Node.js'i güncellemek yetmiyor; Bun, Python ortamları, Envoy/Istio ve gömülü kopyaları da tek tek kapatmak gerekiyor. Siz ortamınızda Brotli'yi nerelerde buldunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   02-t02-brotli-bun-python-envoy.png (Dosya Boyutu: 123.75 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=418]
Selamlar,

Node2Shell olarak duyulan CVE-2026-111497 için çoğu kişi "Node.js'i güncelledim, bitti" diye düşündü. Oysa açık Node.js'in kendi kodunda değil, Google'ın Brotli sıkıştırma kütüphanesinin decoder kısmında. Bu kütüphaneyi kendi içinde taşıyan her yazılımın ayrıca güncellenmesi gerekiyor. The Hacker News, Bun, Python Brotli/brotlicffi paketleri ve Envoy'un da etkilendiğini duyurdu. Burada hangi sürüme geçmeniz gerektiğini ve sistemde etkilenen kopyaları nasıl bulacağınızı topluyorum.

Konuda anlatılacaklar
  1. Açık nedir, neden bu kadar yaygın?
  2. Brotli kütüphanesinin düzeltilmiş sürümleri
  3. Bun: fetch bile tetikleyebilir
  4. Python: requests/urllib3 ve brotlicffi
  5. Envoy ve Istio
  6. Sunucunuzda kontrol komutları

1. Açık nedir?
NVD kaydına göre sorun, Brotli decoder'ında (c/dec/decode.c) bir tampon taşması. Özel hazırlanmış bir Brotli akışı, kimlik doğrulaması olmayan uzak bir saldırganın decoder durum belleğini bozmasına, bellek içeriği sızdırmasına, servisi çökertmesine veya potansiyel olarak kod çalıştırmasına yol açabiliyor. Zayıflık türleri: CWE-787 (sınır dışı yazma) ve CWE-252 (dönüş değerinin kontrol edilmemesi). Upstream puanı CVSS 4.0: 9.2.

Önemli bağlam:
  • The Hacker News'e göre açık, OpenAI'nin kırmızı takım kampanyası sırasında bulundu.
  • Imperva, resmi bir Node.js derlemesinde kod çalıştırmayı gösterdi. Diğer yazılımlarda bu henüz gösterilmedi ve gerçek dünyada saldırı raporu yok.
  • Brotli HTTP'de Content-Encoding: br olarak her yerde kullanıldığı için, sıkıştırılmış veriyi açan istemci ve sunucular saldırı yüzeyinde.

2. Düzeltilmiş Brotli sürümleri
NVD: etkilenen aralık 1.0.3 ile 1.2.0 arası. Güncel düzeltilmiş sürümler:
Kod:
Brotli 1.0.x -> 1.0.10 Brotli 1.1.x -> 1.1.1 Brotli 1.2.x -> 1.2.1

3. Bun
Bun güvenlik bildirimi (GHSA-663w-cv8g-jj2p):
  • Etkilenen: 1.0.21 ile 1.4.4 öncesi. Düzeltilmiş: 1.4.4 (Brotli 1.2.1 ile geliyor).
  • Tetikleyen API'ler: fetch (varsayılan olarak Accept-Encoding içinde br gönderir ve yanıtı otomatik açar), node:zlib içindeki brotliDecompress türevleri ve brotli formatlı DecompressionStream.
  • Yani bağlandığınız kötü niyetli bir sunucu veya şifresiz bağlantıda araya giren biri decoder'a veri gönderebilir.
  • bun build --compile ile üretilmiş tek dosyalık yürütülebilirler, yeniden derlenene kadar etkilenmiş kalır.
Kod:
bun --version bun upgrade bun build --compile ./src/index.ts --outfile mytool
Geçici çözüm olarak Bun, istek bazında fetch(url, { decompress: false }) kullanımını ve güvenilmeyen veriyi brotli API'lerine vermemeyi öneriyor.

4. Python
PyPA danışma kaydı (PYSEC-2026-4323) iki paketi kapsıyor:
  • Brotli (Google'ın CPython bağlaması): 1.2.0 dahil tüm sürümler etkileniyor, düzeltme 1.2.1.
  • brotlicffi: düzeltme 1.2.1.0 (21 Ekim 2026).
Kritik nokta: Bu paketlerden biri kuruluysa urllib3/requests, brotli ekstrası ile httpx ve aiohttp gibi yaygın HTTP istemcileri Brotli yanıtlarını otomatik açıyor. Yani sizin kodunuz brotli'yi hiç import etmese bile saldırgan kontrolündeki bir sunucudan gelen yanıt decoder'a ulaşabilir.
Kod:
pip show brotli brotlicffi 2>/dev/null | grep -E "Name|Version" pip install -U "brotli>=1.2.1" "brotlicffi>=1.2.1.0" pip-audit | grep -i brotli

5. Envoy ve Istio
Envoy bildirimi (GHSA-3wvj-j6qm-62mr, Critical 9.2):
Kod:
Etkilenen : v1.39.2, v1.38.5, v1.37.7, v1.36.11 Düzeltilmiş: v1.40.0, v1.39.3, v1.38.6, v1.37.8, v1.36.12
Sadece Brotli decompressor yapılandırılmış Envoy dağıtımları etkileniyor. The Hacker News, Istio için de yama yayımlandığını aktarıyor; Istio kullanıyorsanız kendi bildirimine bakın.
Kod:
envoy --version grep -rn "envoy.compression.brotli.decompressor" /etc/envoy/ 2>/dev/null

6. Sunucunuzda etkilenen kopyaları bulmak
Brotli birçok yazılımın içine gömülü geldiği için tek bir komut her şeyi bulmaz:
Kod:
dpkg -l | grep -i brotli # Debian/Ubuntu rpm -qa | grep -i brotli # RHEL/Fedora sudo lsof 2>/dev/null | grep -i libbrotlidec | awk '{print $1}' | sort -u node -v ; bun --version 2>/dev/null
Gömülü kopyalar (statik derlenmiş araçlar, konteyner imajları) için SBOM tabanlı tarama gerekir. Trivy veya Grype ile imajlarınızı tarayıp "brotli" geçen bileşenleri ayıklayabilirsiniz.

Sonuç
Bu açık, tedarik zincirinde "tek kütüphane, yüzlerce kopya" sorununun tipik örneği. Node.js'i güncellemek yetmiyor; Bun, Python ortamları, Envoy/Istio ve gömülü kopyaları da tek tek kapatmak gerekiyor. Siz ortamınızda Brotli'yi nerelerde buldunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   02-t02-brotli-bun-python-envoy.png (Dosya Boyutu: 123.75 KB / İndirme Sayısı: 1) ]]> <![CDATA[Japonya Dijital Ajansı İhlali: Site Tedarikçisi Üzerinden 13.000 Profil Risk Altında]]> https://www.turkteam.org/konu-japonya-dijital-ajansi-ihlali-site-tedarikcisi-uzerinden-13-000-profil-risk-altinda.html Sat, 24 Oct 2026 11:27:47 +0300 BilgeKagan]]> https://www.turkteam.org/konu-japonya-dijital-ajansi-ihlali-site-tedarikcisi-uzerinden-13-000-profil-risk-altinda.html [Resim: attachment.php?aid=401]
Selamlar,

Japan Times'ın 23 Ekim 2026 haberine göre Japonya Dijital Ajansı (Digital Agency), web sitesinin bir bölümünü yöneten tedarikçi Studio Co. üzerinden 13.000'den fazla kullanıcı profilinin etkilendiğini açıkladı. Veriler Ajans tarafından 2021-2023 arasında toplanmıştı. Siber güvenlik rehberliği yapan bir kamu kurumunun kendi tedarik zincirinden sızması, "biz rehber yazarız, bizim riskimiz yok" yanılgısına iyi bir karşı örnek.

Konuda anlatılacaklar
  1. Ne oldu?
  2. Zaman çizelgesi
  3. Etkilenen veri
  4. Tedarikçi riski dersleri

1. Ne oldu?
Studio Co., bulut ortamına yetkisiz erişimle verilerin dışarıdan alınabilir hale geldiğini 16 Ekim'de bildirdi. Dijital Bakan Toshiharu Furukawa 23 Ekim'deki basın toplantısında durumu doğruladı. Ajans, ikincil zarar (verinin kötüye kullanımı) teyit edilmediğini; buna rağmen Ajans adına gelen şüpheli e-posta/SMS'lere dikkat edilmesi gerektiğini söyledi.

2. Zaman çizelgesi
Kod:
30 Eyl - 1 Eki 2026 Yetkisiz erisim penceresi 13 Ekim Studio Co. erisimi dogruladi 16 Ekim Kamuoyu / Ajans bilgilendirmesi 23 Ekim Bakan aciklamasi (Japan Times)
Ajans, kendi soruşturma sürecinin gecikmeye yol açtığını belirtti. Bu, Eylül'de Government Solution Service altyapısında da isim/e-posta sızıntısı yaşayan aynı kurum için ikinci darbe.

3. Etkilenen veri
Profillerde ad ve e-posta var; bazılarında telefon ve teslimat adresi de bulunabiliyor. Kart veya kimlik numarası gibi daha hassas alanlar haberde belirtilmemiş.

4. Tedarikçi riski dersleri
  • Kamu ve kurum sitelerinde "küçük" içerik/ajans tedarikçileri de aynı envantere alınmalı.
  • Tedarikçi bulut hesaplarında MFA, ayrı kiracı, en az yetki ve erişim günlüğü şart.
  • Bildirim SLA'sı sözleşmede net olmalı (saat/gün cinsinden).
  • Kullanıcıya "resmi kurum adına gelen sahte ileti" uyarısı ihlal açıklamasının parçası olmalı.

Web sitenizin içerik ajansı veya hosting bayisi güvenlik denetiminize dahil mi?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   12-b02-japan-digital-agency.png (Dosya Boyutu: 117.94 KB / İndirme Sayısı: 1) ]]> [Resim: attachment.php?aid=401]
Selamlar,

Japan Times'ın 23 Ekim 2026 haberine göre Japonya Dijital Ajansı (Digital Agency), web sitesinin bir bölümünü yöneten tedarikçi Studio Co. üzerinden 13.000'den fazla kullanıcı profilinin etkilendiğini açıkladı. Veriler Ajans tarafından 2021-2023 arasında toplanmıştı. Siber güvenlik rehberliği yapan bir kamu kurumunun kendi tedarik zincirinden sızması, "biz rehber yazarız, bizim riskimiz yok" yanılgısına iyi bir karşı örnek.

Konuda anlatılacaklar
  1. Ne oldu?
  2. Zaman çizelgesi
  3. Etkilenen veri
  4. Tedarikçi riski dersleri

1. Ne oldu?
Studio Co., bulut ortamına yetkisiz erişimle verilerin dışarıdan alınabilir hale geldiğini 16 Ekim'de bildirdi. Dijital Bakan Toshiharu Furukawa 23 Ekim'deki basın toplantısında durumu doğruladı. Ajans, ikincil zarar (verinin kötüye kullanımı) teyit edilmediğini; buna rağmen Ajans adına gelen şüpheli e-posta/SMS'lere dikkat edilmesi gerektiğini söyledi.

2. Zaman çizelgesi
Kod:
30 Eyl - 1 Eki 2026 Yetkisiz erisim penceresi 13 Ekim Studio Co. erisimi dogruladi 16 Ekim Kamuoyu / Ajans bilgilendirmesi 23 Ekim Bakan aciklamasi (Japan Times)
Ajans, kendi soruşturma sürecinin gecikmeye yol açtığını belirtti. Bu, Eylül'de Government Solution Service altyapısında da isim/e-posta sızıntısı yaşayan aynı kurum için ikinci darbe.

3. Etkilenen veri
Profillerde ad ve e-posta var; bazılarında telefon ve teslimat adresi de bulunabiliyor. Kart veya kimlik numarası gibi daha hassas alanlar haberde belirtilmemiş.

4. Tedarikçi riski dersleri
  • Kamu ve kurum sitelerinde "küçük" içerik/ajans tedarikçileri de aynı envantere alınmalı.
  • Tedarikçi bulut hesaplarında MFA, ayrı kiracı, en az yetki ve erişim günlüğü şart.
  • Bildirim SLA'sı sözleşmede net olmalı (saat/gün cinsinden).
  • Kullanıcıya "resmi kurum adına gelen sahte ileti" uyarısı ihlal açıklamasının parçası olmalı.

Web sitenizin içerik ajansı veya hosting bayisi güvenlik denetiminize dahil mi?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   12-b02-japan-digital-agency.png (Dosya Boyutu: 117.94 KB / İndirme Sayısı: 1) ]]> <![CDATA[Crime Stoppers İhlali: 1,5 Milyon İpucu Sızdı, Toronto Programı Durduruldu]]> https://www.turkteam.org/konu-crime-stoppers-ihlali-1-5-milyon-ipucu-sizdi-toronto-programi-durduruldu.html Sat, 24 Oct 2026 11:26:31 +0300 BilgeKagan]]> https://www.turkteam.org/konu-crime-stoppers-ihlali-1-5-milyon-ipucu-sizdi-toronto-programi-durduruldu.html [Resim: attachment.php?aid=400]
Selamlar,

CBC'nin 21 Ekim 2026 tarihli özel araştırması, Kanada Crime Stoppers bölümlerine gönderilen 1,5 milyondan fazla ihbar kaydının Mart 2026'da P3 Global Intel (Navigate360) platformundan çalındığını ortaya koydu. Kayıtların yaklaşık yarısında kişisel bilgi var. Toronto Crime Stoppers 22 Ekim'de telefon, web ve uygulama üzerinden ihbar almayı hemen durdurduğunu açıkladı. Bu konu, teknik detaydan çok üçüncü taraf ve veri saklama derslerine odaklanıyor.

Konuda anlatılacaklar
  1. Ne sızdı, kim etkiledi?
  2. Toronto'nun resmi açıklaması
  3. Anonimlik vaadi neden çöktü?
  4. Kurumlar için dersler

1. Ne sızdı?
CBC analizine göre 1,6 milyona yakın Kanada bağlantılı kayıt tespit edildi; 850.000'den fazlasında adres, telefon, e-posta, plaka veya ödül banka bilgisi gibi tanımlayıcı unsurlar vardı. 4.300'den fazla ihbarda kişiler kendi adını yazmış. Hacktivist grup Internet Yiff Machine, P3'ün "anonim ve güvenli" iddiasını çürütmek istediğini söylemiş. Veri Distributed Denial of Secrets üzerinden araştırmacılara açılmış.

2. Toronto açıklaması
Global News'e göre Toronto Crime Stoppers başkanı Sean Sportun, 176.859 Toronto ihbarının etkilendiğini; Navigate360'ın önce "Toronto etkilenmedi", sonra 2022-2025 arası kayıtların etkilendiğini söylediğini belirtti. Kuruma 14.973 isimlik bir liste verilmiş ama isimlerin ihbarcı mı yoksa ihbarda geçen kişi mi olduğu belirtilmemiş. Tip Submit kapatıldı; polis ortaklığı geçici askıya alındı. Acil durumlar için 911, diğerleri için doğrudan polis kanalları öneriliyor.

3. Anonimlik vaadi neden çöktü?
  • İhbar metinlerinden kimlik bilgisi temizlenmeden saklanması.
  • Onlarca yıllık kapalı kayıtların tek platformda tutulması.
  • Üçüncü taraf güvencesine güvenilip bağımsız denetimin zayıf kalması.
Guelph Üniversitesi'nden Prof. Ali Dehghantanha'nın CBC'ye söylediği gibi: operasyonu dışarı verebilirsiniz, hesap verebilirliği veremezsiniz.

4. Kurumlar için dersler
  1. Hassas ihbar/şikayet sistemlerinde veri saklama süresini kısaltın; kapanan dosyayı çevrimiçi tutmayın.
  2. Üçüncü taraf sözleşmelerine denetim, ihlal bildirimi süresi ve veri yerelliği maddeleri koyun.
  3. "Anonim" iddiasını teknik olarak kanıtlayın (redaksiyon, alan ayrımı, erişim günlüğü).
  4. İhlal sonrası iletişim planında "kimi nasıl uyarırız, anonimliği bozmadan" senaryosu olsun.

Kurumunuzda üçüncü tarafa verilen hassas verinin saklama süresini kim denetliyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   11-b01-crime-stoppers-ihlal.png (Dosya Boyutu: 117.45 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=400]
Selamlar,

CBC'nin 21 Ekim 2026 tarihli özel araştırması, Kanada Crime Stoppers bölümlerine gönderilen 1,5 milyondan fazla ihbar kaydının Mart 2026'da P3 Global Intel (Navigate360) platformundan çalındığını ortaya koydu. Kayıtların yaklaşık yarısında kişisel bilgi var. Toronto Crime Stoppers 22 Ekim'de telefon, web ve uygulama üzerinden ihbar almayı hemen durdurduğunu açıkladı. Bu konu, teknik detaydan çok üçüncü taraf ve veri saklama derslerine odaklanıyor.

Konuda anlatılacaklar
  1. Ne sızdı, kim etkiledi?
  2. Toronto'nun resmi açıklaması
  3. Anonimlik vaadi neden çöktü?
  4. Kurumlar için dersler

1. Ne sızdı?
CBC analizine göre 1,6 milyona yakın Kanada bağlantılı kayıt tespit edildi; 850.000'den fazlasında adres, telefon, e-posta, plaka veya ödül banka bilgisi gibi tanımlayıcı unsurlar vardı. 4.300'den fazla ihbarda kişiler kendi adını yazmış. Hacktivist grup Internet Yiff Machine, P3'ün "anonim ve güvenli" iddiasını çürütmek istediğini söylemiş. Veri Distributed Denial of Secrets üzerinden araştırmacılara açılmış.

2. Toronto açıklaması
Global News'e göre Toronto Crime Stoppers başkanı Sean Sportun, 176.859 Toronto ihbarının etkilendiğini; Navigate360'ın önce "Toronto etkilenmedi", sonra 2022-2025 arası kayıtların etkilendiğini söylediğini belirtti. Kuruma 14.973 isimlik bir liste verilmiş ama isimlerin ihbarcı mı yoksa ihbarda geçen kişi mi olduğu belirtilmemiş. Tip Submit kapatıldı; polis ortaklığı geçici askıya alındı. Acil durumlar için 911, diğerleri için doğrudan polis kanalları öneriliyor.

3. Anonimlik vaadi neden çöktü?
  • İhbar metinlerinden kimlik bilgisi temizlenmeden saklanması.
  • Onlarca yıllık kapalı kayıtların tek platformda tutulması.
  • Üçüncü taraf güvencesine güvenilip bağımsız denetimin zayıf kalması.
Guelph Üniversitesi'nden Prof. Ali Dehghantanha'nın CBC'ye söylediği gibi: operasyonu dışarı verebilirsiniz, hesap verebilirliği veremezsiniz.

4. Kurumlar için dersler
  1. Hassas ihbar/şikayet sistemlerinde veri saklama süresini kısaltın; kapanan dosyayı çevrimiçi tutmayın.
  2. Üçüncü taraf sözleşmelerine denetim, ihlal bildirimi süresi ve veri yerelliği maddeleri koyun.
  3. "Anonim" iddiasını teknik olarak kanıtlayın (redaksiyon, alan ayrımı, erişim günlüğü).
  4. İhlal sonrası iletişim planında "kimi nasıl uyarırız, anonimliği bozmadan" senaryosu olsun.

Kurumunuzda üçüncü tarafa verilen hassas verinin saklama süresini kim denetliyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   11-b01-crime-stoppers-ihlal.png (Dosya Boyutu: 117.45 KB / İndirme Sayısı: 2) ]]> <![CDATA[Atlassian Ekim 2026 Bülteni: 75 Üçüncü Taraf Açığı, 6'sı Kritik]]> https://www.turkteam.org/konu-atlassian-ekim-2026-bulteni-75-ucuncu-taraf-acigi-6-si-kritik.html Sat, 24 Oct 2026 11:25:33 +0300 Tonyukuk]]> https://www.turkteam.org/konu-atlassian-ekim-2026-bulteni-75-ucuncu-taraf-acigi-6-si-kritik.html [Resim: attachment.php?aid=399]
Selamlar,

SecurityWeek'in 23 Ekim 2026 haberine göre Atlassian, Data Center ve Server ürünleri için Ekim güvenlik bültenini yayımladı. Listede 176 kayıt var; benzersiz CVE sayısı yaklaşık 75, bunların altı kritik. Hepsi üçüncü taraf bağımlılıklarda (Apache Tomcat, Netty, Bouncy Castle, Apache SSHD vb.). Kendi yazdığınız kod temiz olsa bile bağımlılık yüzünden risk taşıdığınızın güncel örneği.

Konuda anlatılacaklar
  1. Etkilenen ürünler
  2. Kritik CVE'ler
  3. Atlassian'ın risk notu
  4. Ne yapmalısınız?

1. Etkilenen ürünler
Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible, Jira Software, Jira Service Management.

2. Kritik CVE'ler (SecurityWeek özeti)
Kod:
CVE-2026-65637 / 65182 / 68525 Apache Tomcat (Confluence, Crowd) CVE-2026-58062 Bouncy Castle (Confluence, Crowd, Jira) CVE-2026-75595 Netty (Confluence, Jira) CVE-2026-77185 Apache SSHD (Fisheye/Crucible)
Diğer yüksek önemdekiler arasında DoS, kriptografik zayıflık, SSRF, yetkilendirme sorunları ve kod çalıştırma sınıfları var.

3. Atlassian ne diyor?
Şirket, bültendeki CVE'lerin Atlassian müşterileri için "kritik olmayan değerlendirilmiş risk" sunduğunu yazıyor ve aktif istismar bildirmedi. Yine de geçmişte (ör. CVE-2026-21589) PoC sonrası saatler içinde saldırı görüldüğü hatırlatılıyor.

4. Ne yapmalısınız?
  1. Self-hosted / Data Center envanterini çıkarın; en son sabit sürüm veya bültendeki düzeltilmiş sürüme geçin.
  2. İnternete açık Confluence/Jira örneklerini WAF + IP kısıtı arkasına alın.
  3. Bağımlılık taramasını (SCA) CI'ya ekleyin; "bizim kodumuz değil" bahanesi yama borcunu silmez.
  4. Yedek ve geri dönüş planını yükseltmeden önce doğrulayın.

Self-hosted Atlassian kullananlar: bültenleri kim takip ediyor, yama SLA'nız ne?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   10-t10-atlassian-75-ucuncu-taraf.png (Dosya Boyutu: 109.34 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=399]
Selamlar,

SecurityWeek'in 23 Ekim 2026 haberine göre Atlassian, Data Center ve Server ürünleri için Ekim güvenlik bültenini yayımladı. Listede 176 kayıt var; benzersiz CVE sayısı yaklaşık 75, bunların altı kritik. Hepsi üçüncü taraf bağımlılıklarda (Apache Tomcat, Netty, Bouncy Castle, Apache SSHD vb.). Kendi yazdığınız kod temiz olsa bile bağımlılık yüzünden risk taşıdığınızın güncel örneği.

Konuda anlatılacaklar
  1. Etkilenen ürünler
  2. Kritik CVE'ler
  3. Atlassian'ın risk notu
  4. Ne yapmalısınız?

1. Etkilenen ürünler
Bamboo, Bitbucket, Confluence, Crowd, Fisheye/Crucible, Jira Software, Jira Service Management.

2. Kritik CVE'ler (SecurityWeek özeti)
Kod:
CVE-2026-65637 / 65182 / 68525 Apache Tomcat (Confluence, Crowd) CVE-2026-58062 Bouncy Castle (Confluence, Crowd, Jira) CVE-2026-75595 Netty (Confluence, Jira) CVE-2026-77185 Apache SSHD (Fisheye/Crucible)
Diğer yüksek önemdekiler arasında DoS, kriptografik zayıflık, SSRF, yetkilendirme sorunları ve kod çalıştırma sınıfları var.

3. Atlassian ne diyor?
Şirket, bültendeki CVE'lerin Atlassian müşterileri için "kritik olmayan değerlendirilmiş risk" sunduğunu yazıyor ve aktif istismar bildirmedi. Yine de geçmişte (ör. CVE-2026-21589) PoC sonrası saatler içinde saldırı görüldüğü hatırlatılıyor.

4. Ne yapmalısınız?
  1. Self-hosted / Data Center envanterini çıkarın; en son sabit sürüm veya bültendeki düzeltilmiş sürüme geçin.
  2. İnternete açık Confluence/Jira örneklerini WAF + IP kısıtı arkasına alın.
  3. Bağımlılık taramasını (SCA) CI'ya ekleyin; "bizim kodumuz değil" bahanesi yama borcunu silmez.
  4. Yedek ve geri dönüş planını yükseltmeden önce doğrulayın.

Self-hosted Atlassian kullananlar: bültenleri kim takip ediyor, yama SLA'nız ne?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   10-t10-atlassian-75-ucuncu-taraf.png (Dosya Boyutu: 109.34 KB / İndirme Sayısı: 2) ]]> <![CDATA[Ruby Onigmo Regex Motorundaki Üç Hata: GitLab RCE CVE'lerinin Kök Nedeni]]> https://www.turkteam.org/konu-ruby-onigmo-regex-motorundaki-uc-hata-gitlab-rce-cve-lerinin-kok-nedeni.html Sat, 24 Oct 2026 11:21:09 +0300 Tonyukuk]]> https://www.turkteam.org/konu-ruby-onigmo-regex-motorundaki-uc-hata-gitlab-rce-cve-lerinin-kok-nedeni.html [Resim: attachment.php?aid=395]
Selamlar,

Dün GitLab'ın CVSS 10 kimlik doğrulamasız RCE açığını (CVE-2026-110264) konuşmuştuk. 23 Ekim'de Ruby projesi asıl kök nedeni açıkladı: Onigmo regex motorundaki üç bellek bozulması hatası. Ruby 4.0.9, 3.4.12 ve 3.3.13 bu hataları kapatıyor. GitLab sunucusu işletmeseniz bile kullanıcı girdilerinden regex derleyen her Ruby uygulaması için bu konu önemli.

Konuda anlatılacaklar
  1. Hangi GitLab CVE'leri hangi Ruby hatalarına dayanıyor?
  2. Kimler etkileniyor?
  3. Neden Regexp.timeout yetmiyor?
  4. Yükseltme ve geçici önlem
  5. Kendi kodunuzda kontrol

1. CVE eşlemesi
Ruby resmi duyurusuna göre:
Kod:
CVE-2026-89078 -> Cift free (alternation sonrasi parse hatasi) CVE-2026-93577 -> Derlenmis desen boyutu tasmasi CVE-2026-97229 -> Ayni tasma (CI/CD baglami) CVE-2026-110264 -> Cok sayida tekrar iceren desende ID tasmasi
Tam düzeltmeler: Ruby 4.0.9, 3.4.12, 3.3.13. Ruby kendi adına şimdilik ayrı CVE istemedi; takip için GitLab kimliklerini kullanın.

2. Kimler etkileniyor?
Yalnızca saldırganın kontrol ettiği bir dizgeden regex derleyen uygulamalar:
Kod:
Regexp.new(kullanici_girdisi) Regexp.compile(...) Regexp.union(...) /#{kullanici_girdisi}/
Geliştiricinin yazdığı sabit desenler etkilenmez. GitLab bunu CI yapılandırması gibi kullanıcı desenlerinde yapıyordu; benzer desen başka SaaS ürünlerinde de olabilir.

3. Regexp.timeout yetmiyor
Ruby açıkça yazıyor: Regexp.timeout bu hatalara karşı korumaz. Desen uzunluğunu sınırlamak da güvenilir değil; bazı hatalar kısa desenlerle tetiklenebiliyor. Tek sağlam yol: Ruby'yi yükseltmek veya güvenilmeyen girdiden regex derlememek.

4. Yükseltme
Kod:
ruby -v # Hedef: 4.0.9+ veya 3.4.12+ veya 3.3.13+ rbenv install 3.4.12 && rbenv local 3.4.12 # ornek # GitLab Omnibus: resmi yamali surume gecin
Ruby 3.2 ve daha eski dallar bu düzeltmeleri almayacak; yükseltme veya girdiyi sıkı doğrulama şart.

5. Kendi kodunuzda kontrol
Kod:
# projede Regexp.new / Regexp.compile arayin rg -n "Regexp\.(new|compile|union)" --type ruby
Bulduğunuz yerlerde girdinin saldırgan kontrolünde olup olmadığını gözden geçirin. Mümkünse beyaz liste, sabit desen veya güvenli bir eşleme tablosu kullanın.

Uygulamalarınızda kullanıcıdan regex alıyor musunuz? Nasıl sınırlıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   06-t06-ruby-onigmo-gitlab.png (Dosya Boyutu: 114.56 KB / İndirme Sayısı: 3) ]]> [Resim: attachment.php?aid=395]
Selamlar,

Dün GitLab'ın CVSS 10 kimlik doğrulamasız RCE açığını (CVE-2026-110264) konuşmuştuk. 23 Ekim'de Ruby projesi asıl kök nedeni açıkladı: Onigmo regex motorundaki üç bellek bozulması hatası. Ruby 4.0.9, 3.4.12 ve 3.3.13 bu hataları kapatıyor. GitLab sunucusu işletmeseniz bile kullanıcı girdilerinden regex derleyen her Ruby uygulaması için bu konu önemli.

Konuda anlatılacaklar
  1. Hangi GitLab CVE'leri hangi Ruby hatalarına dayanıyor?
  2. Kimler etkileniyor?
  3. Neden Regexp.timeout yetmiyor?
  4. Yükseltme ve geçici önlem
  5. Kendi kodunuzda kontrol

1. CVE eşlemesi
Ruby resmi duyurusuna göre:
Kod:
CVE-2026-89078 -> Cift free (alternation sonrasi parse hatasi) CVE-2026-93577 -> Derlenmis desen boyutu tasmasi CVE-2026-97229 -> Ayni tasma (CI/CD baglami) CVE-2026-110264 -> Cok sayida tekrar iceren desende ID tasmasi
Tam düzeltmeler: Ruby 4.0.9, 3.4.12, 3.3.13. Ruby kendi adına şimdilik ayrı CVE istemedi; takip için GitLab kimliklerini kullanın.

2. Kimler etkileniyor?
Yalnızca saldırganın kontrol ettiği bir dizgeden regex derleyen uygulamalar:
Kod:
Regexp.new(kullanici_girdisi) Regexp.compile(...) Regexp.union(...) /#{kullanici_girdisi}/
Geliştiricinin yazdığı sabit desenler etkilenmez. GitLab bunu CI yapılandırması gibi kullanıcı desenlerinde yapıyordu; benzer desen başka SaaS ürünlerinde de olabilir.

3. Regexp.timeout yetmiyor
Ruby açıkça yazıyor: Regexp.timeout bu hatalara karşı korumaz. Desen uzunluğunu sınırlamak da güvenilir değil; bazı hatalar kısa desenlerle tetiklenebiliyor. Tek sağlam yol: Ruby'yi yükseltmek veya güvenilmeyen girdiden regex derlememek.

4. Yükseltme
Kod:
ruby -v # Hedef: 4.0.9+ veya 3.4.12+ veya 3.3.13+ rbenv install 3.4.12 && rbenv local 3.4.12 # ornek # GitLab Omnibus: resmi yamali surume gecin
Ruby 3.2 ve daha eski dallar bu düzeltmeleri almayacak; yükseltme veya girdiyi sıkı doğrulama şart.

5. Kendi kodunuzda kontrol
Kod:
# projede Regexp.new / Regexp.compile arayin rg -n "Regexp\.(new|compile|union)" --type ruby
Bulduğunuz yerlerde girdinin saldırgan kontrolünde olup olmadığını gözden geçirin. Mümkünse beyaz liste, sabit desen veya güvenli bir eşleme tablosu kullanın.

Uygulamalarınızda kullanıcıdan regex alıyor musunuz? Nasıl sınırlıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   06-t06-ruby-onigmo-gitlab.png (Dosya Boyutu: 114.56 KB / İndirme Sayısı: 3) ]]> <![CDATA[CISA KEV'e İki Yeni Kayıt: Collabora CODE ve Arista VeloCloud Aktif İstismar]]> https://www.turkteam.org/konu-cisa-kev-e-iki-yeni-kayit-collabora-code-ve-arista-velocloud-aktif-istismar.html Sat, 24 Oct 2026 11:20:15 +0300 Tonyukuk]]> https://www.turkteam.org/konu-cisa-kev-e-iki-yeni-kayit-collabora-code-ve-arista-velocloud-aktif-istismar.html [Resim: attachment.php?aid=394]
Selamlar,

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), 24 Ekim 2026 Cuma günü Bilinen İstismar Edilen Zafiyetler (KEV) kataloğuna iki kritik açık ekledi: Collabora Online Built-in CODE Server (CVE-2026-110447) ve Arista VeloCloud Orchestrator (CVE-2026-114625). Federal sivil kurumlara yama veya azaltım için 26 Ekim 2026 son tarihi verildi. Dün Arista konusunu konuşmuştuk; bugünün yeni bilgisi CISA KEV kaydı ve Collabora tarafı.

Konuda anlatılacaklar
  1. CVE-2026-110447 (Collabora / Nextcloud)
  2. CVE-2026-114625 (Arista VCO) hatırlatması
  3. Neden KEV kaydı önemli?
  4. Pratik kontrol listesi

1. Collabora CODE: CVE-2026-110447
The Hacker News'e göre CVSS 9.2 olan bu komut enjeksiyonu, Nextcloud içindeki Collabora Online Built-in CODE Server (richdocumentscode) paketini etkiliyor. Yerel belge sunucusu çalışmıyorken proxy.php üzerinden uzaktan kod çalıştırma mümkün. Düzeltme Eylül 2026'da 26.4.303 sürümünde gelmiş. Aktörler Nextcloud sunucularına web shell bırakıp kimlik bilgisi depoları, parola yöneticisi artıkları ve kripto cüzdanları arıyor.

2. Arista VCO: CVE-2026-114625
CVSS 9.9 SQL enjeksiyonu; şirket içi (on-prem) VeloCloud Orchestrator'ı etkiliyor. Geçerli bir oturum + ağ erişimi gerekiyor; en düşük kiracı rolü bile "superuser operator" seviyesine çıkabiliyor. Düzeltilmiş sürümler: 5.2.3.18, 6.1.3.10, 6.4.2.12. Arista'nın paylaştığı saldırı kaynakları: 74.82.197[.]86 ve 38.54.50[.]151 (Japonya jeolokasyonu). Bu, Temmuz'dan bu yana VCO'da sömürülen üçüncü sıfırıncı gün.

3. KEV kaydı neden önemli?
CISA KEV, "aktif olarak istismar ediliyor" demenin resmi hali. ABD federal kurumları için bağlayıcı bir yama takvimi oluşturur; özel sektör için de önceliklendirme sinyali verir. "PoC yok, bekleyelim" demek artık savunulabilir değil.

4. Kontrol listesi
  1. Nextcloud kullanıyorsanız richdocumentscode / Collabora sürümünü 26.4.303+ yapın; proxy.php erişimini günlükleyin.
  2. On-prem VCO envanterini çıkarın; 5.2.3.18 / 6.1.3.10 / 6.4.2.12 altına düşenleri yükseltin.
  3. Yukarıdaki iki IP'yi engelleyin ve VCO erişim günlüklerinde arayın.
  4. VCO arayüzünü internete açmayın; yönetim ağına kısıtlayın.
  5. Web shell, beklenmeyen daemon ve yüksek istek oranı için izleme ekleyin.

Nextcloud veya VeloCloud kullananlar: yama süreciniz nasıl ilerliyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   05-t05-cisa-kev-collabora-arista.png (Dosya Boyutu: 121.5 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=394]
Selamlar,

ABD Siber Güvenlik ve Altyapı Güvenliği Ajansı (CISA), 24 Ekim 2026 Cuma günü Bilinen İstismar Edilen Zafiyetler (KEV) kataloğuna iki kritik açık ekledi: Collabora Online Built-in CODE Server (CVE-2026-110447) ve Arista VeloCloud Orchestrator (CVE-2026-114625). Federal sivil kurumlara yama veya azaltım için 26 Ekim 2026 son tarihi verildi. Dün Arista konusunu konuşmuştuk; bugünün yeni bilgisi CISA KEV kaydı ve Collabora tarafı.

Konuda anlatılacaklar
  1. CVE-2026-110447 (Collabora / Nextcloud)
  2. CVE-2026-114625 (Arista VCO) hatırlatması
  3. Neden KEV kaydı önemli?
  4. Pratik kontrol listesi

1. Collabora CODE: CVE-2026-110447
The Hacker News'e göre CVSS 9.2 olan bu komut enjeksiyonu, Nextcloud içindeki Collabora Online Built-in CODE Server (richdocumentscode) paketini etkiliyor. Yerel belge sunucusu çalışmıyorken proxy.php üzerinden uzaktan kod çalıştırma mümkün. Düzeltme Eylül 2026'da 26.4.303 sürümünde gelmiş. Aktörler Nextcloud sunucularına web shell bırakıp kimlik bilgisi depoları, parola yöneticisi artıkları ve kripto cüzdanları arıyor.

2. Arista VCO: CVE-2026-114625
CVSS 9.9 SQL enjeksiyonu; şirket içi (on-prem) VeloCloud Orchestrator'ı etkiliyor. Geçerli bir oturum + ağ erişimi gerekiyor; en düşük kiracı rolü bile "superuser operator" seviyesine çıkabiliyor. Düzeltilmiş sürümler: 5.2.3.18, 6.1.3.10, 6.4.2.12. Arista'nın paylaştığı saldırı kaynakları: 74.82.197[.]86 ve 38.54.50[.]151 (Japonya jeolokasyonu). Bu, Temmuz'dan bu yana VCO'da sömürülen üçüncü sıfırıncı gün.

3. KEV kaydı neden önemli?
CISA KEV, "aktif olarak istismar ediliyor" demenin resmi hali. ABD federal kurumları için bağlayıcı bir yama takvimi oluşturur; özel sektör için de önceliklendirme sinyali verir. "PoC yok, bekleyelim" demek artık savunulabilir değil.

4. Kontrol listesi
  1. Nextcloud kullanıyorsanız richdocumentscode / Collabora sürümünü 26.4.303+ yapın; proxy.php erişimini günlükleyin.
  2. On-prem VCO envanterini çıkarın; 5.2.3.18 / 6.1.3.10 / 6.4.2.12 altına düşenleri yükseltin.
  3. Yukarıdaki iki IP'yi engelleyin ve VCO erişim günlüklerinde arayın.
  4. VCO arayüzünü internete açmayın; yönetim ağına kısıtlayın.
  5. Web shell, beklenmeyen daemon ve yüksek istek oranı için izleme ekleyin.

Nextcloud veya VeloCloud kullananlar: yama süreciniz nasıl ilerliyor?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   05-t05-cisa-kev-collabora-arista.png (Dosya Boyutu: 121.5 KB / İndirme Sayısı: 2) ]]> <![CDATA[PHP'de Yeni Yamasız Açık CVE-2026-115560 ve PHP2Shell'i Kullanan Potassium Botneti]]> https://www.turkteam.org/konu-php-de-yeni-yamasiz-acik-cve-2026-115560-ve-php2shell-i-kullanan-potassium-botneti.html Sat, 24 Oct 2026 11:16:10 +0300 Tonyukuk]]> https://www.turkteam.org/konu-php-de-yeni-yamasiz-acik-cve-2026-115560-ve-php2shell-i-kullanan-potassium-botneti.html [Resim: attachment.php?aid=390]
Selamlar,

PHP2Shell dalgası bitmeden PHP ekibi 23 Ekim'de yeni bir bilgilendirme yayımladı: CVE-2026-115560 olarak izlenen ve henüz yaması olmayan bir uzaktan kod çalıştırma riski. Aynı günlerde bir Mirai türevi olan Potassium botnetinin PHP2Shell istismarına katıldığı ve x86-64 sunucularda ASLR'yi atlatan çalışan bir PoC yayımlandığı da raporlandı. Bu konuda üç gelişmeyi tek yerde topluyorum.

Konuda anlatılacaklar
  1. CVE-2026-115560 kimleri etkiliyor?
  2. Geçici önlem: tek satırlık ayar
  3. Potassium botneti ve IOC'ler
  4. ASLR atlatan PoC ne anlama geliyor?
  5. Ölçek: rakamlarla PHP2Shell
  6. Sunucu yöneticisi için kontrol listesi

1. CVE-2026-115560 kimleri etkiliyor?
The Hacker News ve BleepingComputer'ın aktardığı PHP duyurusuna göre açık herkesi değil, belirli bir kod desenini kullanan uygulamaları ilgilendiriyor:
  • Uygulama session.serialize_handler değerini önce php_binary veya php_serialize yapıyor,
  • ardından session_start() çağrılmadan önce ini_set() ile tekrar php işleyicisine dönüyor,
  • ve oturum yükleme ilerlemesi (session upload progress) açık.
Önemli nokta: PHP2Shell için çıkan 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri bu yeni açığı kapatmıyor. Düzeltme bir sonraki olağan sürümde gelecek. Duyuruda etkilenen sürüm aralığı ve CVSS puanı verilmedi; istismar edildiğine dair bir rapor da yok.

2. Geçici önlem
Yama gelene kadar PHP'nin önerdiği önlem, oturum yükleme ilerlemesini kapatmak:
Kod:
; php.ini session.upload_progress.enabled = 0
Ayarın gerçekten uygulandığını kontrol edin (FPM ve CLI farklı php.ini okuyabilir):
Kod:
php -i | grep -i upload_progress php-fpm8.3 -i 2>/dev/null | grep -i upload_progress grep -rn "serialize_handler" /var/www --include=*.php

3. Potassium botneti
SecurityWeek'e göre Sophos ve Arctic Wolf, PHP2Shell'i yayılmak için kullanan Potassium adlı bir Mirai türevi gözlemledi. Savunma tarafında işinize yarayacak göstergeler (The Hacker News / Sophos özeti):
Kod:
C2 IP : 134.199.154[.]64 C2 alan : thunder.godofthunder[.]st Port : TCP 50792 Kaynak IP : 85.11.167[.]243 , 217.60.242[.]76 , 45.198.224[.]169
Bu değerleri güvenlik duvarı ve DNS günlüklerinizde arayın. Göstergeler zamanla değişir.

4. ASLR atlatan PoC
SOCRadar, açık bir saldırgan sunucusunda PHP 8.4.26 mod_php hedefli aslr_exploit.py adlı bir betik buldu. VulnCheck'ten Spencer McIntyre da üretim ayarlarıyla çalışan x86-64 sistemlerde ASLR'yi atlatıp kod çalıştıran bir istismar geliştirdi. Pratik anlamı: "bellek rastgeleleştirmesi var, istismar zor olur" varsayımına güvenmeyin; yama tek gerçek çözüm.

5. Rakamlarla ölçek
  • Cloudflare: istismar denemeleri ilk 45 dakikada on binlerden 22 Ekim'e kadar milyonlara çıktı.
  • Censys: 23 Ekim itibarıyla 34,4 milyon PHP servisi savunmasız görünüyor.
  • Qualys: PHP çalıştıranların yaklaşık yüzde 71'i (yaklaşık 110 milyon) desteği bitmiş 5.4 ile 8.1 arası sürümlerde.
  • İngiltere'de 32 kamu servisi önlem amaçlı erişime kapatıldı; NCSC yaklaşık 50.000 uyarı gönderdi.
Doğrulanmış başarılı ele geçirme sayısı kaynaklarda henüz net verilmiş değil.

6. Kontrol listesi
  1. PHP2Shell yamasını uygulayın (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).
  2. session.upload_progress.enabled = 0 yapın ve her SAPI için doğrulayın.
  3. Desteği bitmiş PHP sürümlerini planlı şekilde güncel bir dala taşıyın.
  4. Web sunucusu ve DNS günlüklerinde yukarıdaki IOC'leri arayın.

Sunucularınızda session.upload_progress kapatınca bozulan bir özellik oldu mu?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   01-t01-php-cve-2026-115560-potassium.png (Dosya Boyutu: 120.57 KB / İndirme Sayısı: 2) ]]> [Resim: attachment.php?aid=390]
Selamlar,

PHP2Shell dalgası bitmeden PHP ekibi 23 Ekim'de yeni bir bilgilendirme yayımladı: CVE-2026-115560 olarak izlenen ve henüz yaması olmayan bir uzaktan kod çalıştırma riski. Aynı günlerde bir Mirai türevi olan Potassium botnetinin PHP2Shell istismarına katıldığı ve x86-64 sunucularda ASLR'yi atlatan çalışan bir PoC yayımlandığı da raporlandı. Bu konuda üç gelişmeyi tek yerde topluyorum.

Konuda anlatılacaklar
  1. CVE-2026-115560 kimleri etkiliyor?
  2. Geçici önlem: tek satırlık ayar
  3. Potassium botneti ve IOC'ler
  4. ASLR atlatan PoC ne anlama geliyor?
  5. Ölçek: rakamlarla PHP2Shell
  6. Sunucu yöneticisi için kontrol listesi

1. CVE-2026-115560 kimleri etkiliyor?
The Hacker News ve BleepingComputer'ın aktardığı PHP duyurusuna göre açık herkesi değil, belirli bir kod desenini kullanan uygulamaları ilgilendiriyor:
  • Uygulama session.serialize_handler değerini önce php_binary veya php_serialize yapıyor,
  • ardından session_start() çağrılmadan önce ini_set() ile tekrar php işleyicisine dönüyor,
  • ve oturum yükleme ilerlemesi (session upload progress) açık.
Önemli nokta: PHP2Shell için çıkan 8.5.12, 8.4.27, 8.3.36 ve 8.2.35 sürümleri bu yeni açığı kapatmıyor. Düzeltme bir sonraki olağan sürümde gelecek. Duyuruda etkilenen sürüm aralığı ve CVSS puanı verilmedi; istismar edildiğine dair bir rapor da yok.

2. Geçici önlem
Yama gelene kadar PHP'nin önerdiği önlem, oturum yükleme ilerlemesini kapatmak:
Kod:
; php.ini session.upload_progress.enabled = 0
Ayarın gerçekten uygulandığını kontrol edin (FPM ve CLI farklı php.ini okuyabilir):
Kod:
php -i | grep -i upload_progress php-fpm8.3 -i 2>/dev/null | grep -i upload_progress grep -rn "serialize_handler" /var/www --include=*.php

3. Potassium botneti
SecurityWeek'e göre Sophos ve Arctic Wolf, PHP2Shell'i yayılmak için kullanan Potassium adlı bir Mirai türevi gözlemledi. Savunma tarafında işinize yarayacak göstergeler (The Hacker News / Sophos özeti):
Kod:
C2 IP : 134.199.154[.]64 C2 alan : thunder.godofthunder[.]st Port : TCP 50792 Kaynak IP : 85.11.167[.]243 , 217.60.242[.]76 , 45.198.224[.]169
Bu değerleri güvenlik duvarı ve DNS günlüklerinizde arayın. Göstergeler zamanla değişir.

4. ASLR atlatan PoC
SOCRadar, açık bir saldırgan sunucusunda PHP 8.4.26 mod_php hedefli aslr_exploit.py adlı bir betik buldu. VulnCheck'ten Spencer McIntyre da üretim ayarlarıyla çalışan x86-64 sistemlerde ASLR'yi atlatıp kod çalıştıran bir istismar geliştirdi. Pratik anlamı: "bellek rastgeleleştirmesi var, istismar zor olur" varsayımına güvenmeyin; yama tek gerçek çözüm.

5. Rakamlarla ölçek
  • Cloudflare: istismar denemeleri ilk 45 dakikada on binlerden 22 Ekim'e kadar milyonlara çıktı.
  • Censys: 23 Ekim itibarıyla 34,4 milyon PHP servisi savunmasız görünüyor.
  • Qualys: PHP çalıştıranların yaklaşık yüzde 71'i (yaklaşık 110 milyon) desteği bitmiş 5.4 ile 8.1 arası sürümlerde.
  • İngiltere'de 32 kamu servisi önlem amaçlı erişime kapatıldı; NCSC yaklaşık 50.000 uyarı gönderdi.
Doğrulanmış başarılı ele geçirme sayısı kaynaklarda henüz net verilmiş değil.

6. Kontrol listesi
  1. PHP2Shell yamasını uygulayın (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).
  2. session.upload_progress.enabled = 0 yapın ve her SAPI için doğrulayın.
  3. Desteği bitmiş PHP sürümlerini planlı şekilde güncel bir dala taşıyın.
  4. Web sunucusu ve DNS günlüklerinde yukarıdaki IOC'leri arayın.

Sunucularınızda session.upload_progress kapatınca bozulan bir özellik oldu mu?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   01-t01-php-cve-2026-115560-potassium.png (Dosya Boyutu: 120.57 KB / İndirme Sayısı: 2) ]]> <![CDATA[Quest Diagnostics İhlali: Quanum Lab Portalında Hasta Kayıtlarına Erişildi]]> https://www.turkteam.org/konu-quest-diagnostics-ihlali-quanum-lab-portalinda-hasta-kayitlarina-erisildi.html Fri, 23 Oct 2026 11:28:05 +0300 Tonyukuk]]> https://www.turkteam.org/konu-quest-diagnostics-ihlali-quanum-lab-portalinda-hasta-kayitlarina-erisildi.html [Resim: attachment.php?aid=373]
Selamlar,

ABD'nin en büyük tıbbi test şirketlerinden Quest Diagnostics, 21 Ekim 2026'da Quanum Lab Services Manager (LSM) sistemine yetkisiz erişim olduğunu öğrendiğini açıkladı. Şirket bazı hasta kayıtlarına erişildiğine inanıyor ve korunan sağlık bilgisi (PHI) ile kişisel bilgilerin (PII) etkilendiğini doğruladı.

Konuda anlatılacaklar
  1. Quanum LSM nedir?
  2. Şirketin açıkladıkları
  3. Bilinmeyenler
  4. Sağlık verisi neden bu kadar değerli?
  5. Kurumlar için çıkarımlar

Quanum LSM nedir?
Bazı sağlık kuruluşlarının laboratuvar testi siparişi vermek, sonuçları almak ve sorgulamak için kullandığı web tabanlı portal. Yani doğrudan hasta adı, test türü ve sonuç bilgisini içeren bir sistem.

Şirketin açıkladıkları
AP News, Fox Business ve SecurityOnline'ın aktardığı bilgilere göre:
  • Quest, Quanum LSM erişimini durdurdu.
  • Önlem olarak Essential Insights ve LabHQ sistemlerine erişim de durduruldu; bunlarda veriye erişilmediği belirtiliyor.
  • Federal kolluk kuvvetleri bilgilendirildi, dış uzmanlar görevlendirildi.
  • Şirketin temel operasyonları önemli ölçüde etkilenmedi.
  • pwn.watch'a göre Quest, olayın PHP açıklarıyla ilgili olmadığını belirtti.

Bilinmeyenler
Etkilenen kişi sayısı ve hangi veri kategorilerinin etkilendiği henüz açıklanmadı; soruşturma sürüyor. Saldırının giriş noktası da paylaşılmadı. Bu tür olaylarda ilk açıklamadan sonra rakamların büyüdüğü sık görülür, takipte kalmakta fayda var.

Sağlık verisi neden değerli?
Kredi kartı iptal edilip yenilenebilir; test sonuçları, tanılar ve sağlık geçmişi değiştirilemez. Bu yüzden sağlık verisi hem şantaj hem hedefli dolandırıcılık için yüksek değerlidir. Etkilenen kişilere en sık gelen saldırı türü, "test sonucunuz hazır, görmek için giriş yapın" temalı oltalama ve sahte ödeme talepleridir.

Kurumlar için çıkarımlar
  • Müşteriye veya iş ortağına açık portallar (sipariş, sonuç, randevu) ana sistemler kadar sıkı izlenmeli: MFA, anormal sorgu hacmi alarmı, toplu dışa aktarma limitleri.
  • Olay anında ilgili diğer sistemleri önlem olarak durdurmak (Quest'in yaptığı gibi) yayılmayı sınırlar; bunun için önceden hazırlanmış bir izolasyon planı gerekir.
  • Türkiye'deki sağlık kuruluşları için de KVKK kapsamında özel nitelikli kişisel veri olan sağlık verisinde 72 saatlik bildirim yükümlülüğünü hatırlatmakta fayda var.

Sağlık sektöründe çalışanlar: sonuç portallarınızda hangi ek kontrolleri kullanıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   09-t09-quest-quanum-ihlal.png (Dosya Boyutu: 115.13 KB / İndirme Sayısı: 6) ]]> [Resim: attachment.php?aid=373]
Selamlar,

ABD'nin en büyük tıbbi test şirketlerinden Quest Diagnostics, 21 Ekim 2026'da Quanum Lab Services Manager (LSM) sistemine yetkisiz erişim olduğunu öğrendiğini açıkladı. Şirket bazı hasta kayıtlarına erişildiğine inanıyor ve korunan sağlık bilgisi (PHI) ile kişisel bilgilerin (PII) etkilendiğini doğruladı.

Konuda anlatılacaklar
  1. Quanum LSM nedir?
  2. Şirketin açıkladıkları
  3. Bilinmeyenler
  4. Sağlık verisi neden bu kadar değerli?
  5. Kurumlar için çıkarımlar

Quanum LSM nedir?
Bazı sağlık kuruluşlarının laboratuvar testi siparişi vermek, sonuçları almak ve sorgulamak için kullandığı web tabanlı portal. Yani doğrudan hasta adı, test türü ve sonuç bilgisini içeren bir sistem.

Şirketin açıkladıkları
AP News, Fox Business ve SecurityOnline'ın aktardığı bilgilere göre:
  • Quest, Quanum LSM erişimini durdurdu.
  • Önlem olarak Essential Insights ve LabHQ sistemlerine erişim de durduruldu; bunlarda veriye erişilmediği belirtiliyor.
  • Federal kolluk kuvvetleri bilgilendirildi, dış uzmanlar görevlendirildi.
  • Şirketin temel operasyonları önemli ölçüde etkilenmedi.
  • pwn.watch'a göre Quest, olayın PHP açıklarıyla ilgili olmadığını belirtti.

Bilinmeyenler
Etkilenen kişi sayısı ve hangi veri kategorilerinin etkilendiği henüz açıklanmadı; soruşturma sürüyor. Saldırının giriş noktası da paylaşılmadı. Bu tür olaylarda ilk açıklamadan sonra rakamların büyüdüğü sık görülür, takipte kalmakta fayda var.

Sağlık verisi neden değerli?
Kredi kartı iptal edilip yenilenebilir; test sonuçları, tanılar ve sağlık geçmişi değiştirilemez. Bu yüzden sağlık verisi hem şantaj hem hedefli dolandırıcılık için yüksek değerlidir. Etkilenen kişilere en sık gelen saldırı türü, "test sonucunuz hazır, görmek için giriş yapın" temalı oltalama ve sahte ödeme talepleridir.

Kurumlar için çıkarımlar
  • Müşteriye veya iş ortağına açık portallar (sipariş, sonuç, randevu) ana sistemler kadar sıkı izlenmeli: MFA, anormal sorgu hacmi alarmı, toplu dışa aktarma limitleri.
  • Olay anında ilgili diğer sistemleri önlem olarak durdurmak (Quest'in yaptığı gibi) yayılmayı sınırlar; bunun için önceden hazırlanmış bir izolasyon planı gerekir.
  • Türkiye'deki sağlık kuruluşları için de KVKK kapsamında özel nitelikli kişisel veri olan sağlık verisinde 72 saatlik bildirim yükümlülüğünü hatırlatmakta fayda var.

Sağlık sektöründe çalışanlar: sonuç portallarınızda hangi ek kontrolleri kullanıyorsunuz?

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   09-t09-quest-quanum-ihlal.png (Dosya Boyutu: 115.13 KB / İndirme Sayısı: 6) ]]> <![CDATA[Capcom ID Sızıntısı: 11,7 Milyon E-posta Adresi ve Son Giriş IP'leri Açığa Çıktı]]> https://www.turkteam.org/konu-capcom-id-sizintisi-11-7-milyon-e-posta-adresi-ve-son-giris-ip-leri-aciga-cikti.html Fri, 23 Oct 2026 11:27:07 +0300 Tonyukuk]]> https://www.turkteam.org/konu-capcom-id-sizintisi-11-7-milyon-e-posta-adresi-ve-son-giris-ip-leri-aciga-cikti.html [Resim: attachment.php?aid=372]
Selamlar,

Oyuncuları yakından ilgilendiren bir veri ihlali: Capcom, bazı oyunlarında çevrimiçi oynamak için gereken CAPCOM ID hesap sistemine üçüncü bir tarafın yetkisiz eriştiğini 22 Ekim 2026'da duyurdu. Dünya genelinde 11.774.247 kayıt etkilendi.

Konuda anlatılacaklar
  1. Hangi veriler açığa çıktı?
  2. Zaman çizelgesi
  3. Neler sızmadı?
  4. Neden "sadece e-posta" bile önemli?
  5. Oyuncular ne yapmalı?

Açığa çıkan veriler
Capcom'un resmi açıklamasına göre:
  • 11.774.247 kayıt: e-posta adresi, hesap oluşturma zamanı, son giriş zamanı, giriş sayısı ve son girişteki IP adresi.
  • 43 hesap: bunlara ek olarak doğum tarihi, cinsiyet, ülke/bölge ve takma ad.
  • 196 hesap: parolası izinsiz değiştirildi; bu hesapların parolaları Capcom tarafından sıfırlandı.

Zaman çizelgesi
  • 19 Ekim: Yetkisiz erişim tespit edildi.
  • 21 Ekim: Osaka Valiliği Polisi'ne ve Japonya Kişisel Bilgi Koruma Komisyonu'na (PPC) bildirildi.
  • 22 Ekim: Kamuya açıklama ve özür.

Neler sızmadı?
Capcom, müşterilerin belirlediği parolaların sızdığını doğrulamadığını ve kredi kartı verisinin etkilenmediğini belirtiyor. Yine de 196 hesapta parolanın izinsiz değiştirilmiş olması, saldırganın en azından bir kısım hesapta hesap üzerinde işlem yapabildiğini gösteriyor.

'Sadece e-posta' neden önemli?
E-posta + son giriş zamanı + IP birleşimi, ikna edici oltalama için ideal bir paket. Saldırgan şöyle bir mail atabilir: "Son girişiniz şu tarihte şu bölgeden yapıldı, onaylamıyorsanız tıklayın." Gerçek verilerle süslenmiş sahte bildirim, sıradan bir spamdan çok daha inandırıcıdır. pwn.watch da Capcom'u taklit eden oltalama beklendiği uyarısını yapıyor. Ayrıca son giriş IP'si kabaca konum bilgisi verir.

Oyuncular ne yapmalı?
  1. Capcom adına gelen e-postalardaki bağlantılara tıklamayın; siteye adres çubuğundan kendiniz girin.
  2. CAPCOM ID parolanızı başka yerde de kullandıysanız o hesaplarda da değiştirin.
  3. Bağlı platform hesaplarında (Steam, PlayStation, Xbox) iki adımlı doğrulamayı açın.
  4. "Ödül", "hesabınız kapatılacak", "ücretsiz DLC" temalı mesajlara özellikle şüpheyle yaklaşın.
E-posta adresiniz bir sızıntıda çıktığında adım adım ne yapılacağını anlatan ayrıntılı rehberi Virüs Temizleme ve Kişisel Güvenlik bölümünde paylaşıyoruz.

Capcom'dan bildirim maili aldınız mı? Gelen maillerin gerçek mi sahte mi olduğunu nasıl kontrol ettiğinizi yazın (kişisel bilgi paylaşmadan).

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   08-t08-capcom-id-sizinti.png (Dosya Boyutu: 125.27 KB / İndirme Sayısı: 4) ]]> [Resim: attachment.php?aid=372]
Selamlar,

Oyuncuları yakından ilgilendiren bir veri ihlali: Capcom, bazı oyunlarında çevrimiçi oynamak için gereken CAPCOM ID hesap sistemine üçüncü bir tarafın yetkisiz eriştiğini 22 Ekim 2026'da duyurdu. Dünya genelinde 11.774.247 kayıt etkilendi.

Konuda anlatılacaklar
  1. Hangi veriler açığa çıktı?
  2. Zaman çizelgesi
  3. Neler sızmadı?
  4. Neden "sadece e-posta" bile önemli?
  5. Oyuncular ne yapmalı?

Açığa çıkan veriler
Capcom'un resmi açıklamasına göre:
  • 11.774.247 kayıt: e-posta adresi, hesap oluşturma zamanı, son giriş zamanı, giriş sayısı ve son girişteki IP adresi.
  • 43 hesap: bunlara ek olarak doğum tarihi, cinsiyet, ülke/bölge ve takma ad.
  • 196 hesap: parolası izinsiz değiştirildi; bu hesapların parolaları Capcom tarafından sıfırlandı.

Zaman çizelgesi
  • 19 Ekim: Yetkisiz erişim tespit edildi.
  • 21 Ekim: Osaka Valiliği Polisi'ne ve Japonya Kişisel Bilgi Koruma Komisyonu'na (PPC) bildirildi.
  • 22 Ekim: Kamuya açıklama ve özür.

Neler sızmadı?
Capcom, müşterilerin belirlediği parolaların sızdığını doğrulamadığını ve kredi kartı verisinin etkilenmediğini belirtiyor. Yine de 196 hesapta parolanın izinsiz değiştirilmiş olması, saldırganın en azından bir kısım hesapta hesap üzerinde işlem yapabildiğini gösteriyor.

'Sadece e-posta' neden önemli?
E-posta + son giriş zamanı + IP birleşimi, ikna edici oltalama için ideal bir paket. Saldırgan şöyle bir mail atabilir: "Son girişiniz şu tarihte şu bölgeden yapıldı, onaylamıyorsanız tıklayın." Gerçek verilerle süslenmiş sahte bildirim, sıradan bir spamdan çok daha inandırıcıdır. pwn.watch da Capcom'u taklit eden oltalama beklendiği uyarısını yapıyor. Ayrıca son giriş IP'si kabaca konum bilgisi verir.

Oyuncular ne yapmalı?
  1. Capcom adına gelen e-postalardaki bağlantılara tıklamayın; siteye adres çubuğundan kendiniz girin.
  2. CAPCOM ID parolanızı başka yerde de kullandıysanız o hesaplarda da değiştirin.
  3. Bağlı platform hesaplarında (Steam, PlayStation, Xbox) iki adımlı doğrulamayı açın.
  4. "Ödül", "hesabınız kapatılacak", "ücretsiz DLC" temalı mesajlara özellikle şüpheyle yaklaşın.
E-posta adresiniz bir sızıntıda çıktığında adım adım ne yapılacağını anlatan ayrıntılı rehberi Virüs Temizleme ve Kişisel Güvenlik bölümünde paylaşıyoruz.

Capcom'dan bildirim maili aldınız mı? Gelen maillerin gerçek mi sahte mi olduğunu nasıl kontrol ettiğinizi yazın (kişisel bilgi paylaşmadan).

Yasal uyarı
Bu yazı bilgilendirme ve savunma amaçlıdır. Anlatılan kontrolleri yalnızca kendi sistemlerinizde veya yazılı izinle yapın. İzinsiz erişim, tarama ve sömürü girişimleri TCK 243-245 kapsamında suçtur. TurkTeam white-hat bir topluluktur; çalıntı veri, hesap, combo/log paylaşımı ve hack hizmeti talepleri forum kurallarına aykırıdır.

Kaynaklar

.png   08-t08-capcom-id-sizinti.png (Dosya Boyutu: 125.27 KB / İndirme Sayısı: 4) ]]>