TürkTeam Portal

Siber güvenlik topluluğunun nabzı

Duyurular, öne çıkan konular ve topluluktan son haberler burada.

Forumlar Yeni Mesajlar Kurallar
Duyurular
 session.upload_progress.enabled=0: PHP Hosting'de Tek Satırlık Acil Önlem
KulTiginDün, 08:36 AM · Sunucu ve Hosting Güvenliği
0 16
[Resim: attachment.php?aid=416]

Selamlar,

PHP ekibi 23 Ekim'de yamasız CVE-2026-115560 için geçici önlem olarak session.upload_progress.enabled=0 önerdi. İlginç olan şu: aynı satır, 21 Ekim'deki PHP2Shell (CVE-2026-109619) azaltım listesinde de vardı. Yani Çarşamba günü uyguladıysanız Cuma günkü yeni uyarı için ekstra işiniz yok. Bu kısa rehber, paylaşımlı hosting ve VPS'te ayarı nasıl doğru uygulayacağınızı anlatıyor.

Konuda anlatılacaklar
  1. Bu ayar ne işe yarar?
  2. Nereye yazılır?
  3. SAPI bazında doğrulama
  4. Ne bozulabilir?
  5. Yama ile birlikte kontrol listesi

1. Bu ayar ne işe yarar?
session upload progress, yükleme sırasında ilerlemeyi oturum verisine yazan varsayılan bir özelliktir. PHP2Shell ve CVE-2026-115560 zincirlerinde istismar yüzeyi olarak geçtiği için kapatılması öneriliyor. Özellik kapalıyken yükleme ilerleme çubuğu kullanan nadir uygulamalar bozulabilir.

2. Nereye yazılır?
Kod:
; /etc/php/8.3/fpm/php.ini (ornek yol) ; /etc/php/8.3/apache2/php.ini session.upload_progress.enabled = 0
Kod:
# FPM havuzunu yeniden yukleyin systemctl reload php8.3-fpm # veya Apache mod_php systemctl reload apache2
Sadece CLI php.ini'sini değiştirmek web'i korumaz.

3. Doğrulama
Kod:
php -i | grep -i upload_progress # FPM icin php-fpm8.3 -i 2>/dev/null | grep -i upload_progress # veya kucuk bir info.php (sonra silin) # <?php phpinfo();
Beklenen: session.upload_progress.enabled => Off

4. Ne bozulabilir?
Kendi yazdığınız veya eski bir eklentinin "upload progress" API'sini kullanması. Çoğu modern CMS varsayılanında bu özellik kritik değildir. Bozulma görürseniz özelliği geçici açmak yerine uygulamayı güncellemek veya ilerlemeyi başka yöntemleizlemek daha doğru.

5. Kontrol listesi
  1. Tüm SAPI'lerde ayarı Off yapın.
  2. PHP2Shell yamasını uygulayın (8.5.12 / 8.4.27 / 8.3.36 / 8.2.35).
  3. Uzun ömürlü worker'ları yeniden başlatın.
  4. CVE-2026-115560 için olağan sürümü izleyin; çıkınca yama + ayarı gözden geçirin.
  5. serialize_handler'ı çalışma zamanında değiştiren kod var mı diye arayın.
Kod:
grep -rn "serialize_handler\|ini_set.*session" /var/www --include=*.php | head

Hosting panelinizde bu ayarı merkezi mi yönetiyorsunuz, yoksa hesap başına 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

Ek DosyalarEkran Görüntüleri
   
 Secure Boot DBX İptali Nasıl Açılır? BlackX Sonrası Windows Yönetici Rehberi
KulTiginDün, 08:35 AM · Windows ve Güvenlik
0 15
[Resim: attachment.php?aid=414]

Selamlar,

BlackX kampanyasının gösterdiği gibi, Secure Boot yamasını kurmak tek başına Baton Drop benzeri zincirleri durdurmayabiliyor. Microsoft KB5025885, iptallerin elle etkinleştirilmesi gerektiğini yıllardır yazıyor; Enforcement Phase hâlâ ileri bir tarihe bırakılmış durumda. Bu rehber, kurumsal Windows yöneticisi için sadeleştirilmiş bir yol haritası. Üretimde uygulamadan önce mutlaka pilot yapın; bazı adımlar geri alınamaz.

Konuda anlatılacaklar
  1. Riskleri bilerek başlayın
  2. Adım adım etkinleştirme
  3. Doğrulama
  4. Kurtarma medyası
  5. Bilinen sorunlar

1. Riskleri bilerek başlayın
  • DBX'e PCA 2011 eklendikten sonra eski imzalı boot manager'lar çalışmaz.
  • Eski kurtarma USB / PXE medyası önyüklemeyebilir.
  • Bazı üretici üretici yazılımları DB/DBX güncellemesini bozar; cihaz sınıfı başına test şart.
  • BitLocker kurtarma ekranına düşebilirsiniz; 48 haneli anahtarı önceden alın.
Kod:
manage-bde -protectors -get %systemdrive%

2. Adım adım (özet)
Önce son aylık güvenlik güncellemesini kurun. Ardından (Yönetici PowerShell/CMD):
Kod:
# 1) 2023 UEFI CA'yi DB'ye ekle reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x5944 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula (True donmeli) [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI db).bytes) -match 'Windows UEFI CA 2023' # 2) PCA 2011'i DBX'e ekle (iptal) reg add HKLM\SYSTEM\CurrentControlSet\Control\Secureboot /v AvailableUpdates /t REG_DWORD /d 0x80 /f Start-ScheduledTask -TaskName "\Microsoft\Windows\PI\Secure-Boot-Update" # Dogrula [System.Text.Encoding]::ASCII.GetString((Get-SecureBootUEFI dbx).bytes) -match 'Microsoft Windows Production PCA 2011'
SVN güncellemesi (0x200) isteğe bağlı dördüncü adımdır; medya yönetimini etkiler.

3. Doğrulama olayları
Olay Kimliği 1036 (DB), 1799 (boot manager), 1037 (DBX), 1042 (SVN). Servicing altındaki UEFICA2023Status değerinin Updated olması beklenir.

4. Kurtarma medyası
İptalden önce, DB güncellemesi uygulanmış bir makinede "Create a Recovery Drive" ile FAT32 USB oluşturun ve bcdboot /bootex adımlarını Microsoft makalesindeki gibi uygulayın. Eski medyayı envanterden çıkarın.

5. Bilinen sorunlar (makaleden)
HP Sure Start, bazı Arm64/Qualcomm, VMware Secure Boot VM'leri, Symantec Endpoint Encryption gibi durumlarda ek üretici adımları gerekebilir. Geniş yayından önce pilot şart.

Kaç makinenizde DBX iptali gerçekten etkin? Ölçümleyen var 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

Ek DosyalarEkran Görüntüleri
   
 pip-audit ile Python Ortamı Tarama: Pillow Haftasında Pratik Rehber
KulTiginDün, 08:34 AM · Araç Tanıtım ve Eğitimleri
0 14
[Resim: attachment.php?aid=412]

Selamlar,

Bu hafta Pillow (CVE-2026-112900) ve LiteLLM tedarik zinciri derken Python bağımlılık envanteri yeniden gündeme geldi. pip-audit, PyPI/OSV üzerinden bilinen açıklara karşı ortamınızı veya requirements dosyanızı tarayan resmiye yakın, bakımı süren bir araç. Bu rehber kurulumu, ilk taramayı ve CI'ya eklemeyi adım adım anlatıyor.

Konuda anlatılacaklar
  1. Kurulum
  2. Ortam ve requirements taraması
  3. Çıktı formatları
  4. --fix ve dikkat edilecekler
  5. CI örneği

1. Kurulum
Python 3.10+ gerekir:
Kod:
python3 -m pip install -U pip-audit pip-audit --version

2. İlk tarama
Kod:
# Aktif sanal ortam pip-audit # Yalnizca yerel (sistem paketlerini gizle) pip-audit --local # requirements dosyasi pip-audit -r requirements.txt # Proje dizini (pyproject.toml) pip-audit .

3. Çıktı formatları
Kod:
pip-audit -f columns pip-audit -f json -o audit.json pip-audit -f markdown pip-audit --desc --aliases
JSON çıktıyı SIEM veya ticket sistemine beslemek kolaydır.

4. --fix ve sınırlar
Kod:
pip-audit --fix --dry-run # ne yapacagini gosterir pip-audit --fix # bilinen duzeltmesi olanlari yukseltmeye calisir
Önemli: pip-audit zararlı paketi tespit motoru değildir; bilinen CVE/advisory listesine bakar. "pip install etmeyeceğiniz şeyi pip-audit etmeyin" güvenlik modeli geçerlidir. Hash'li requirements ile --require-hashes tekrarlanabilir denetim sağlar.

5. CI örneği (GitHub Actions)
Kod:
jobs: pip-audit: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - uses: actions/setup-python@v5 with: python-version: "3.12" - run: pip install pip-audit - run: pip-audit -r requirements.txt
Resmi GitHub Action da var: pypa/gh-action-pip-audit. Pillow 13.0.0 gibi güvenlik sürümlerini kaçırmamak için bu taramayı PR kapısına koyun.

Python projelerinizde bağımlılık taramasını CI'da zorunlu tutuyor musunuz?

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

Ek DosyalarEkran Görüntüleri
   
 YZ Siber Güvenlik İşlerini de Kesiyor: Barracuda Raporundan Kariyer Dersleri
KulTiginDün, 08:33 AM · Kariyer ve İş İlanları
0 18
[Resim: attachment.php?aid=410]

Selamlar,

Barracuda'nın Cybersecurity Skills Gap Report bulgularını Help Net Security 23 Ekim 2026'da özetledi: kuruluşların yüzde 56'sı YZ kaynaklı iş gücü azaltımı yaşamış; bunun yarısı giriş seviyesi, yarısı daha üst roller. Aynı anda neredeyse herkes beceri açığı bildiriyor. Yani hem iş kesiliyor hem "doğru insan yok" deniyor. Kariyer planı yapanlar için ne anlama geldiğini konuşalım.

Konuda anlatılacaklar
  1. Rakamlar ne diyor?
  2. İşin içeriği nasıl değişiyor?
  3. Giriş seviyesi tuzağı
  4. Hangi beceriler öne çıkıyor?
  5. Pratik öneriler

1. Rakamlar
  • yüzde 56: YZ bağlantılı kadro azaltımı (junior/senior eşit bölünmüş).
  • En sık beceri açığı: YZ riskleri, ardından kimlik ve phishing.
  • yüzde 50: ek kaynak olmadan genişleyen dijital operasyona destek beklentisi.
  • yüzde 69: olay müdahalesinde YZ/otomasyon + insan karma modeli.

2. İşin içeriği
Rutin korelasyon ve ilk yanıt önerileri makinelere kayıyor. İnsana kalanlar: zor tespit edilen saldırıları araştırmak, YZ bulgularını doğrulamak, olayda karar vermek, iş riskini anlatmak. "Alert kapatan analist" rolü daralıyor; "kanıtı sorgulayan analist" büyüyor.

3. Giriş seviyesi tuzağı
Junior işleri kaldırmak, geleceğin olay liderlerini yetiştirecek stajyerlik alanını da kaldırır. Barracuda CIO'su Siroui Mushegian'ın vurgusu: ellerini kirletecekleri yeni gelişim yolları şart. SOC'ta "YZ çıktısını doğrulama" rotasyonu, lab + mentorluk, kontrollü shadowing buna örnek olabilir.

4. Öne çıkan beceriler
  • YZ okuryazarlığı (modelin neyi bilmediğini bilmek).
  • Kimlik ve phishing derinliği.
  • İletişim ve yönetişim.
  • İş etkisi diliyle risk anlatımı.

5. Pratik öneriler
  1. CV'nize yalnızca araç adı değil, "YZ önerisini reddedip gerekçelendirdiğim olay" örneği koyun.
  2. Kimlik (Entra/Okta), tespit mühendisliği ve IR runbook yazımına ağırlık verin.
  3. Lab ortamında otomasyon + insan onay kapısı tasarımı çalışın.
  4. Junior iseniz: CTF/lab kanıtı + staj; senior iseniz: mentorluk ve yönetişim becerisi.

Sizin ekibinizde YZ hangi görevleri aldı, hangi görevler bilerek insanda kaldı?

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

Ek DosyalarEkran Görüntüleri
   
 Help Desk'ten Parola Sıfırlatmak: 2026'nın En Etkili Sıfırıncı Günü
KulTiginDün, 08:32 AM · Sosyal Mühendislik ve Farkındalık
0 19
[Resim: attachment.php?aid=408]

Selamlar,

Dark Reading'in 23 Ekim 2026 dosyası net söylüyor: saldırganlar artık her zaman zararlı yazılım yazmıyor; help desk'i arayıp kibarca erişim istiyor. 1Password'dan Dave Lewis bunu "2026'nın en etkili sıfırıncı günü" diye nitelendiriyor. TransUnion raporu da dolandırıcılığın çoğunun müşteri ilişkisi kurulduktan sonra gerçekleştiğini gösteriyor. Bu konu, insanları suçlamak yerine süreci nasıl sertleştireceğinize dair pratik notlar.

Konuda anlatılacaklar
  1. Saldırı neden işe yarıyor?
  2. YZ ve deepfake boyutu
  3. CRM / SaaS yan kapıları
  4. Help desk için süreç önerileri
  5. Kimlik ve veri hijyeni

1. Neden işe yarıyor?
On yıl boyunca insanlara "bağlantıya tıklama" diye eğitim verdik; saldırganlar tıklatmayı bırakıp telefonla MFA kodu veya parola sıfırlama istedi. Hız metrikleri (ortalama görüşme süresi) ajanları doğrulamayı kısaltmaya itiyor. AI ile kişiselleştirilmiş senaryo ve ses deepfake'i bu baskıyı artırıyor.

2. YZ boyutu
KnowBe4, AI marka taklitlerinde (ör. Claude adına sahte ödeme maili) Nisan'dan bu yana yüzde 228 artış izlediklerini söylüyor. Saldırganlar hem insanları hem de yanlış yapılandırılmış YZ ajanlarını hedefliyor. Sosyal mühendislik tekniği aynı; ölçek ve inandırıcılık değişti.

3. CRM yan kapıları
Lewis'in gözlemi: kimse CRM'yi "hack"lemiyor; unutulmuş bir satıcı anahtarı veya yıllar önce açılmış misafir hesabıyla giriş yapıyor. Bir ele geçirilen entegrasyon, klasik veri merkezi ihlaline göre çok daha fazla hedef demek. Tespit de zor çünkü SaaS günlükleri geleneksel altyapıdan farklı.

4. Help desk süreç önerileri
  • Parola/MFA sıfırlamada scriptli kimlik doğrulama.
  • Kayıtlardaki numaraya geri arama (callback).
  • Ayrıcalıklı veya MFA sıfırlamalarında yönetici onayı.
  • Kimlik hassas görüşmelerde ortalama süre metriklerini kaldırın veya ağırlığını düşürün.

5. Kimlik ve veri hijyeni
  1. Her OAuth uygulaması, entegrasyon, misafir/portal kullanıcısı ve API anahtarını envanterleyin.
  2. Sahipsiz olanları iptal edin; kalanları daraltın; üç ayda bir tekrarlayın.
  3. Müşteri kayıtlarında saklama süresi koyun; uykudaki hesapları silin.
  4. Üretim müşteri verisini sandbox'a kopyalamayın.
"Tutmadığınız veri çalınamaz."

Help desk'inizde parola sıfırlama için geri arama zorunlu 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

Ek DosyalarEkran Görüntüleri
   
 eMudhra Sonrası: Tarayıcı Güvende, Ya Java ve CI Trust Store'ları?
BilgeKaganDün, 08:31 AM · Kriptografi
0 17
[Resim: attachment.php?aid=407]

Selamlar,

eMudhra ara CA özel anahtarlarının zayıf olduğu skandalında tarayıcılar hızla tepki verdi. Sonatype'ın 23 Ekim 2026 yazısı ise asıl soruyu soruyor: kurumunuzdaki diğer araçlar hâlâ etkilenen zincirlere güveniyor mu? Java cacerts, Node, Python, Go, Git ve sistem demetleri ayrı ayrı güncellenmeden "tarayıcı düzeldi" demek yetmez.

Konuda anlatılacaklar
  1. Neden tek trust store yetmiyor?
  2. Sonatype Audit and Fix betiği
  3. Betiğin görmedikleri
  4. Pratik yol haritası

1. Neden tek trust store yetmiyor?
Bir makinede tarayıcı işletim sistemi deposunu kullanırken JDK kendi cacerts dosyasını, bazı CLI araçları gömülü kökleri kullanır. Birini güncellemek diğerlerini güncellemez. Filippo Valsorda'nın deyişiyle bu, Heartbleed'den büyük bir temizlik işi; IoT, Docker ve unutulmuş Linux kutuları uzun kuyruk oluşturur.

2. Sonatype betiği
Paul Horton'un açık kaynak eMudhra Audit and Fix betiği Unix benzeri makinelerde Java, Node.js, Python, Go, Git ve sistem demetlerini tarar. Desteklenen yerlerde etkilenen ara CA'lara zincirlenen test sunucularına HTTPS isteği atar; kontrol için GitHub'a da bakar. Varsayılan olarak hiçbir şeyi değiştirmez. --no-network yalnızca sürüm kontrolü yapar; --dry-run / --fix isteğe bağlıdır.

3. Betiğin görmedikleri
Uzak sunucular, konteyner imajları, CI ajanları, üretim hostları ve proje bağımlılıkları taranmaz. Geliştirici dizüstü bilgisayar sonucu kurumsal durum demek değildir.

4. Pratik yol haritası
  1. Önce OS ve tarayıcı güncellemelerini tamamlayın.
  2. Geliştirici iş istasyonlarında betiği çalıştırıp çıktıyı envantere işleyin.
  3. CI runner ve temel konteyner imajlarını ayrı süreçle yenileyin.
  4. Java uygulamalarında cacerts / özel trust store yollarını bulun.
  5. Tedarikçi yamasını tercihen kullanın; elle sertifika silmeyi test edin.

CI ajanlarınızın trust store durumunu kim izliyor?

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

Ek DosyalarEkran Görüntüleri
   
 x402 SDK Açığı: Kötü Amaçlı API'ler YZ Ajanlarının Token Bakiyesini Boşaltabilir
BilgeKaganDün, 08:30 AM · Yapay Zeka Güvenliği
0 24
[Resim: attachment.php?aid=405]

Selamlar,

V12'nin 22 Ekim 2026 bulgularına göre, YZ ajanlarının API çağrılarını kripto ile ödemesini sağlayan x402 SDK'larında kritik hatalar vardı. Varsayılan istemci 18 Ağustos 2026'ya kadar harcama limiti koymuyordu; kötü amaçlı bir API, ajanın desteklenen token bakiyesinin tamamını isteyebiliyordu. x402 Foundation (Coinbase'in Linux Foundation'a devrettiği proje) üç kritik hatayı Ağustos sürümlerinde kapatmış; ancak güvenlik danışması yayımlanmadığı için npm audit / PyPI uyarısı görünmüyor.

Konuda anlatılacaklar
  1. Üç kritik hata
  2. Kimler etkileniyordu?
  3. Hangi sürüme geçilmeli?
  4. Politika önerileri

1. Üç kritik hata
  • Harcama limiti yok: Varsayılan istemci listedeki ilk ödeme seçeneğini imzalıyordu; tutar sınırı yoktu.
  • Solana ödeme atlatma (yalnızca TypeScript): Facilitator, token transferi yerine approval talimatını geçerli ödeme sayabiliyordu.
  • SIWx oturum açma: Otomatik istemci, mesajdaki site ile gerçek 402 yanıtını veren siteyi karşılaştırmadan imza atıyordu; başka bir siteye giriş mümkün olabiliyordu.
Ne V12 ne Foundation kamuya açık istismar bildirmedi.

2. Kimler etkileniyordu?
Otomatik imzalayan ve uygulama katmanında harcama politikası koymayan ajanlar. Elle onaylayan veya kendi limitini yazan uygulamalar daha az risk altındaydı.

3. Hedef sürümler (23 Ekim itibarıyla)
Kod:
TypeScript @x402/core / fetch / axios / svm / extensions 2.28.0 Go v2.28.0 Python 2.25.0 Harcama fix @x402/fetch veya @x402/axios >= 2.23.0
Yeni varsayılan: ödeme başına en fazla 1 USD ve tanınan USD stablecoin'ler. spendControls: false tüm korumaları kapatır; üretimde kullanmayın.

4. Politika önerileri
  • Ödeme başına ve kümülatif bütçe koyun.
  • İzinli token, ağ ve alıcı beyaz listesi tanımlayın.
  • SIWx mesajında site eşleşmesini doğrulayın.
  • Yalnızca npm audit'e güvenmeyin; sürümü sabitleyin ve changelog okuyun.

YZ ajanlarınıza otomatik ödeme yetkisi veriyor musunuz? Limit nasıl tanımlı?

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

Ek DosyalarEkran Görüntüleri
   
 GCP Dataflow Gölge Bağımlılık: Tahmin Edilebilir Bucket ile Kiracılar Arası RCE
BilgeKaganDün, 08:28 AM · Bulut Güvenliği
0 14
[Resim: attachment.php?aid=403]

Selamlar,

Varonis Threat Labs, Google Cloud Dataflow'ta kiracılar arası (cross-tenant) bir saldırı yolunu açıkladı: varsayılan staging bucket adının proje kimliği + bölgeden tahmin edilebilir olması. Saldırgan bu adı önceden kendi projesinde oluşturursa (bucket squatting), kurbanın ilk Dataflow işi kodunu saldırganın kovasına yükleyebiliyor. --save_main_session ile pickle edilen oturum değiştirilince Dataflow işçilerinde kod çalışıyor. Google sorunu küresel olarak kapatmış; yine de dersleri kalıcı.

Konuda anlatılacaklar
  1. Saldırı zinciri
  2. Kimler risk altındaydı?
  3. Google'ın üç katmanlı düzeltmesi
  4. Sizin yapmanız gerekenler

1. Saldırı zinciri
  1. Saldırgan dataflow-staging-<bolge>-<md5(proje_id)> adını önceden oluşturur, AllUsers yazma verir.
  2. Kurban, açık staging konumu vermeden Beam Python ile ilk işi çalıştırır; pickle oturumu bu kovaya iner.
  3. Saldırgan pickled_main_session dosyasını kendi zararlı pickle'ı ile değiştirir.
  4. İşçiler unpickle ederken kod, Dataflow servis hesabı yetkisiyle çalışır.
Varonis, kurban projesine hiç IAM izni gerekmediğini vurguluyor; proje ID'si çoğu zaman gizli değildir.

2. Kimler risk altındaydı?
  • Apache Beam Python SDK kullanan işler (Java SDK zaten sahiplik kontrolü yapıyordu).
  • Bölgede henüz varsayılan staging bucket'ı oluşmamış projeler.
  • --save_main_session açık, --staging_location verilmemiş işler.

3. Üç katmanlı düzeltme
  • Beam 2.75.0: istemci tarafı bucket sahiplik doğrulaması.
  • Dataflow kontrol düzlemi: varsayılan kova başka projeye aitse FAILED_PRECONDITION.
  • SHA-256 bütünlük: staging sonrası değiştirilen artefaktlar işçi tarafından reddedilir.
Eski/pinlanmış SDK'lar bile sunucu tarafı kontrol sayesinde korunuyor.

4. Sizin yapmanız gerekenler
Kod:
# Isinizde staging konumunu acikca verin --staging_location=gs://SIZIN-PROJE-staging/beam --temp_location=gs://SIZIN-PROJE-temp/beam
  • Staging kovalarını kod deposu gibi koruyun; yazma yetkisini sıkı tutun.
  • Pickle hâlâ pickle'dır: --save_main_session kullanımını gözden geçirin.
  • Servis hesabına Compute Engine varsayılanı yerine en az yetkili özel hesap verin.

Dataflow/Beam işlerinizde staging_location'ı açık mı veriyorsunuz, yoksa varsayılan 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

Ek DosyalarEkran Görüntüleri
   
 Japonya Dijital Ajansı İhlali: Site Tedarikçisi Üzerinden 13.000 Profil Risk Altında
BilgeKaganDün, 08:27 AM · Siber Güvenlik Haberleri
0 18
[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

Ek DosyalarEkran Görüntüleri
   
 Crime Stoppers İhlali: 1,5 Milyon İpucu Sızdı, Toronto Programı Durduruldu
BilgeKaganDün, 08:26 AM · Siber Güvenlik Haberleri
0 12
[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

Ek DosyalarEkran Görüntüleri