TürkTeam Portal

Siber güvenlik topluluğunun nabzı

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

Duyurular
 Arista VeloCloud Orchestrator Sıfırıncı Gün Açığı CVE-2026-114625 Saldırılarda
Tonyukuk 10-23-2026, 08:15 AM · Siber Güvenlik Haberleri
0 14
[Resim: attachment.php?aid=365]

Selamlar,

SD-WAN yönetenler için acil bir uyarı: Arista Networks, şirket içi (on-prem) VeloCloud Orchestrator (VCO) kurulumlarını etkileyen ve aktif olarak istismar edilen kritik bir sıfırıncı gün açığını 22 Ekim 2026'da yamaladı. Açık CVE-2026-114625 olarak izleniyor; pwn.watch kaydına göre CVSS puanı 9.9.

Konuda anlatılacaklar
  1. VCO nedir, neden değerli bir hedef?
  2. Açığın etkisi
  3. Düzeltilmiş sürümler
  4. Yama öncesi alınabilecek önlemler
  5. Ele geçirme şüphesinde ne yapmalı?

VCO nedir?
VeloCloud Orchestrator, VeloCloud SD-WAN'larını ve bağlı edge cihazlarını yapılandırmak, izlemek ve yönetmek için kullanılan web tabanlı yönetim portalı. Yani tek bir panelden onlarca, bazen yüzlerce şubenin ağ yapılandırmasına dokunulabiliyor. Bu tür merkezi yönetim düzlemleri saldırganlar için yüksek değerli hedeflerdir.

Açığın etkisi
BleepingComputer'a göre açık düşük karmaşıklıkta bir SQL injection. Saldırganın VCO web arayüzüne erişimi ve geçerli, düşük yetkili bir oturumu olması gerekiyor; kullanıcı etkileşimi gerekmiyor. Arista'nın açıklamasına göre:
Alıntı:Etkilenen bir sistemde kimliği doğrulanmış herhangi bir kullanıcı operator yetkisi kazanabilir ve yerel 'superuser operator' kullanıcısı gibi davranabilir. Bu, uzaktan erişilmesi amaçlanmayan dahili işlevlere erişimi de kapsar.
Başarılı istismar, orkestratörün ve yönettiği verilerin gizliliğini, bütünlüğünü ve erişilebilirliğini tehlikeye atabiliyor.

Düzeltilmiş sürümler
Kod:
VCO On-Prem icin hedef surumler: 5.2.3.18 veya sonrasi 6.1.3.10 veya sonrasi 6.4.2.12 veya sonrasi Hosted (Arista barindirmali) VCO: zaten yamali

Yama yapılana kadar
Arista'nın önerileri:
  • VCO web arayüzüne erişimi yalnızca yönetim ağlarıyla sınırlayın (internete açık panel bırakmayın).
  • Bilinen kötü amaçlı IP'lerden gelen bağlantıları izleyin ve engelleyin. Arista saldırılarda 74.82.197[.]86 ve 38.54.50[.]151 adreslerinin görüldüğünü bildirdi.
  • Son yönetici etkinliklerini ve olağandışı yapılandırma değişikliklerini gözden geçirin.
  • Web erişim loglarında alışılmadık URL benzeri yol bileşenleri, kodlanmış (encoded) karakterler, yerel veya dahili servislere referanslar ve yüksek istek hızları arayın.

Kod:
# Ornek log taramasi (kendi VCO loglariniz icin uyarlayin) grep -E "74\.82\.197\.86|38\.54\.50\.151" /path/to/vco/access.log* grep -Ei "%27|%22|union|select|localhost|127\.0\.0\.1" /path/to/vco/access.log* | head

Ele geçirme şüphesinde
Arista, iyileştirmeden önce mümkünse VCO web erişim loglarını, backend uygulama loglarını, sistem loglarını, veritabanı loglarını ve ilgili dosya sistemi zaman damgalarını korumanızı öneriyor. Yani önce kanıtı koruyun, sonra yamalayın veya yeniden kurun; aksi halde olay müdahalesinde neyin değiştiğini kanıtlayamazsınız. Ardından Arista TAC ile iletişime geçin.

Neden önemli?
Yönetim düzlemi açıkları, saldırgana tek tek cihazlara uğraşmadan tüm ağı yeniden yapılandırma imkanı verir. Basit bir kural: yönetim panelleri internete değil, VPN veya ayrık yönetim ağına bakmalı; düşük yetkili hesaplar da düzenli denetlenmeli, çünkü bu açıkta saldırganın ihtiyacı olan tek şey herhangi bir geçerli oturum.

Kurumunuzda SD-WAN yönetim paneli internete açık mı, yoksa ayrı yönetim ağında mı? Mimariyi nasıl kurduğunuzu tartışalı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
   
 PHP2Shell'de Yeni Bulgu: Amazon'a Göre Saldırılar Yamadan 4 Gün Önce Başladı
Tonyukuk 10-23-2026, 08:14 AM · Siber Güvenlik Haberleri
0 9
[Resim: attachment.php?aid=364]

Selamlar,

PHP2Shell (CVE-2026-109618 ve CVE-2026-109619) olayında tablo bir gün içinde değişti. Dün yamalı sürümleri ve kontrol listesini konuşmuştuk; bugünün yeni bilgisi zaman çizelgesiyle ilgili: Amazon Threat Intelligence, ilk istismar denemelerini yamalar yayınlanmadan dört gün önce, 17 Ekim Cumartesi günü gördüğünü açıkladı. Bu konu, yalnızca yeni gelişmeleri ve savunma tarafında ne anlama geldiğini özetliyor.

Konuda anlatılacaklar
  1. Amazon tam olarak ne söyledi?
  2. Dataminr ve Patchstack'in farklı tonu
  3. Asya'dan gelen yeni resmi tepkiler
  4. "İfşa tarihi" varsayımı neden tehlikeli?
  5. Log incelemesinde tarih aralığını nasıl seçmeli?

Amazon'un açıklaması
BleepingComputer'ın aktardığına göre AWS CISO'su CJ Moses şunları belirtti:
  • İlk deneme, ambargo sürerken ticari bir anonimleştirme ağına ait IP adresinden bir honeypot'a yapıldı. Saldırganın bilgiyi ifşadan önce nasıl edindiği bilinmiyor.
  • İfşadan saatler sonra, VPN IP'lerinden birden fazla PoC denendi. Payload ve altyapı farklılıkları birden fazla aktör olduğuna işaret ediyor.
  • Açıklar artık "yaygın biçimde istismar ediliyor"; ancak bu denemelerin kaçının gerçek sistemlerde başarılı olduğu belirsiz.
  • Kritik cümle: "Savunucular, kamuya açıklama tarihinin istismarın en erken tarihi olduğunu varsaymamalı."

PHP ekibi ise sürecin ifşadan iki gün öncesine kadar plana göre ilerlediğini, 20 Ekim'de CVE numaraları ve bazı kritik altyapı sağlayıcılarına verilen azaltım önerileri sızınca takvimi öne çektiğini; ifşa öncesi yayımlanan PoC'lerin ise çalışmadığını söylüyor.

Farklı tonlar: 'yaygın istismar' mı, 'sadece tarama' mı?
  • Dataminr TRACE: İfşadan bu yana gözlenen etkinliğin tarama, parmak izi çıkarma ve çalışmayan exploit denemeleriyle sınırlı olduğunu, bilinen bir başarılı ele geçirme olmadığını, ama çalışan PoC'lerin ortaya çıkmasının "an meselesi" olduğunu yazdı.
  • Patchstack: Barındırma ortaklarından birden fazla aktif istismar vakası bildirimi aldığını, yamadan hemen sonra kendi telemetrisinde ise yalnızca yoklama (probing) gördüğünü canlı zaman çizelgesinde paylaştı.
  • Cloudflare: Integrity360 ve ABC News'e göre denemeler ifşa öncesinde binlerden, ifşadan saatler sonra milyonlara çıktı.
Bu çelişki gibi görünse de aslında aynı şeyi söylüyor: tarama hacmi devasa, başarılı ele geçirme verisi henüz netleşmedi. Savunma açısından fark etmez; yama ve iz arama yine zorunlu.

Yeni resmi tepkiler
ABC News'in Reuters kaynaklı haberine göre:
  • Avustralya Sinyal Müdürlüğü (ASD) acil yama çağrısı yaptı.
  • Çin Sanayi Bakanlığı kurumlardan sistemlerini denetlemelerini, en güncel PHP sürümüne geçmelerini ve gerekirse hesap, parola ve anahtarları değiştirmelerini istedi.
  • Güney Kore özel sektör siber güvenlik alarm seviyesini yükseltti ve acil müdahale önlemlerini devreye aldı.
BleepingComputer'a göre VirusTotal internete açık 5,1 milyonun üzerinde PHP sunucusu izliyor.

Pratik sonuç: log aralığınızı 17 Ekim'den başlatın
Dün paylaştığımız iz arama adımlarını uygularken aralığı 21 Ekim'den değil, en az 17 Ekim 00:00 (UTC) tarihinden başlatın. Hatta sızıntının tam başlangıcı bilinmediği için log saklama süreniz elveriyorsa daha geriye gidin.
Kod:
# Ornek: Nginx/Apache erisim logunda 17 Ekim sonrasi multipart POST ve 5xx dalgalari zgrep -h "Oct/2026" /var/log/nginx/access.log* \ | awk '$4 >= "[17/Oct/2026" && $9 ~ /^5/' \ | awk '{print $1}' | sort | uniq -c | sort -rn | head # PHP-FPM / web dizinlerinde son 7 gunde degisen .php dosyalari find /var/www -name "*.php" -mtime -7 -printf "%TY-%Tm-%Td %TH:%TM %p\n" | sort | tail -50
Not: awk ile tarih karşılaştırması kaba bir filtredir; ciddi incelemede logları SIEM'e alıp zaman damgasına göre sorgulayın.

Kısa kontrol listesi (güncellenmiş)
  1. PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 veya dağıtım backport'u kurulu mu?
  2. FPM havuzları, Apache ve uzun ömürlü worker'lar yeniden başlatıldı mı?
  3. 17 Ekim sonrası loglar incelendi mi?
  4. Yamasız dönemde açık kalan sunucularda DB parolaları, API anahtarları ve oturumlar yenilendi mi?

Sizin loglarınızda 17-21 Ekim arasında anormal POST trafiği gördünüz mü? IP ve hassas veri paylaşmadan genel gözlemlerinizi yazabilirsiniz.

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
   
 Yama Hızı Artık CV Maddesi: PHP2Shell Haftasından Kariyer Dersleri
KulTigin 10-22-2026, 08:40 AM · Kariyer ve İş İlanları
0 34
[Resim: attachment.php?aid=363]

Selamlar,

Bu haftanın gündemi (PHP2Shell, GitLab CVSS 10, LiteLLM tedarik zinciri, SafePay uyarısı) yalnızca teknik değil; iş ilanlarında aranan yetkinlikleri de netleştiriyor. Bu yazıda "yama hızı", olay iletişimi ve tedarik zinciri hijyeninin kariyer açısından nasıl öne çıktığını konuşuyoruz.

Konuda anlatılacaklar
  1. İşverenlerin bu hafta sorduğu üç soru
  2. CV ve mülakatta nasıl anlatılır?
  3. Junior / mid / senior için farklı beklentiler
  4. Türkçe ekosistemde pratik öneriler

Bu haftanın üç sorusu
  • KEV / kritik yama SLA'nız ne? CISA'nın PHP uyarısı "hemen", SafePay uyarısı yıllardır açık olan uç cihaz CVE'lerini hatırlatıyor. "Planlandı" ile "uygulandı ve doğrulandı" arasındaki fark artık mülakat sorusu.
  • Tedarik zincirini nasıl kilitliyorsunuz? LiteLLM: hash'li pip, digest'li Docker, floating latest yasağı, token hijyeni.
  • Olay anında nasıl iletişim kuruyorsunuz? Zeabur'un şeffaf (ve geç gelen) raporları ile "her şey kontrol altında" belirsizliği arasındaki fark, güven ve kariyer itibarı demek.

CV'de nasıl yazılır?
Kötü: "Yamalama yaptım."
Daha iyi: "İnternete açık 40 PHP host'unda 8 saat içinde 8.3.36'ya geçiş; FPM restart doğrulaması; 12 uygulama secret rotasyonu; olay sonrası postmortem."

Somut rakam, kapsam ve doğrulama adımı olmadan yama deneyimi CV'de erir. Aynı şekilde "Docker kullandım" yerine "üretim imajları digest ile sabitlendi, latest namespace'te engellendi" yazın.

Seviyelere göre beklenti
  • Junior: Kendi labında php -v / docker inspect / gh auth status çalıştırabilmek; bir runbook'u takip edebilmek.
  • Mid: Envanter + yama + doğrulamayı bir servis ailesinde uçtan uca sahiplenmek; IOC'yi SIEM'e yüklemek.
  • Senior / lead: SLA tanımlamak, istisna sürecini yönetmek, yönetim dilinde risk anlatmak, tedarik zinciri politikasını yazmak.

Mülakat sorusu örnekleri
  • İnternete açık bir RCE için 4 saatlik pencereniz var; ilk 30 dakikada ne yaparsınız?
  • pip install X latest CI'da çalışmış; nasıl anlar, nasıl temizlersiniz?
  • Yama sonrası "sanırım düzeldi"yi kabul etmezsiniz - hangi pozitif/negatif kontrolleri koşarsınız?

Pratik öneri
Bu haftaki gerçek olaylardan birini seçin (PHP, GitLab, LiteLLM veya SafePay). Kendi labınızda veya iş yerinizde (izinli) bir kontrol listesi uygulayın. Sonucu 10 satırlık bir postmortem olarak yazın: kapsam, süre, engel, doğrulama, sonraki iyileştirme. Bu doküman, genel "güvenlikle ilgileniyorum" cümlesinden daha değerli bir portfolyo parçasıdır.

Sizce junior bir adayın CV'sinde yama hızını göstermek için en temiz kanıt nedir? Tartışalı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
   
 Yama Hızı Artık CV Maddesi: PHP2Shell Haftasından Kariyer Dersleri
KulTigin 10-22-2026, 08:38 AM · Kariyer ve İş İlanları
0 31
[Resim: attachment.php?aid=362]

Selamlar,

Bu haftanın gündemi (PHP2Shell, GitLab CVSS 10, LiteLLM tedarik zinciri, SafePay uyarısı) yalnızca teknik değil; iş ilanlarında aranan yetkinlikleri de netleştiriyor. Bu yazıda "yama hızı", olay iletişimi ve tedarik zinciri hijyeninin kariyer açısından nasıl öne çıktığını konuşuyoruz.

Konuda anlatılacaklar
  1. İşverenlerin bu hafta sorduğu üç soru
  2. CV ve mülakatta nasıl anlatılır?
  3. Junior / mid / senior için farklı beklentiler
  4. Türkçe ekosistemde pratik öneriler

Bu haftanın üç sorusu
  • KEV / kritik yama SLA'nız ne? CISA'nın PHP uyarısı "hemen", SafePay uyarısı yıllardır açık olan uç cihaz CVE'lerini hatırlatıyor. "Planlandı" ile "uygulandı ve doğrulandı" arasındaki fark artık mülakat sorusu.
  • Tedarik zincirini nasıl kilitliyorsunuz? LiteLLM: hash'li pip, digest'li Docker, floating latest yasağı, token hijyeni.
  • Olay anında nasıl iletişim kuruyorsunuz? Zeabur'un şeffaf (ve geç gelen) raporları ile "her şey kontrol altında" belirsizliği arasındaki fark, güven ve kariyer itibarı demek.

CV'de nasıl yazılır?
Kötü: "Yamalama yaptım."
Daha iyi: "İnternete açık 40 PHP host'unda 8 saat içinde 8.3.36'ya geçiş; FPM restart doğrulaması; 12 uygulama secret rotasyonu; olay sonrası postmortem."

Somut rakam, kapsam ve doğrulama adımı olmadan yama deneyimi CV'de erir. Aynı şekilde "Docker kullandım" yerine "üretim imajları digest ile sabitlendi, latest namespace'te engellendi" yazın.

Seviyelere göre beklenti
  • Junior: Kendi labında php -v / docker inspect / gh auth status çalıştırabilmek; bir runbook'u takip edebilmek.
  • Mid: Envanter + yama + doğrulamayı bir servis ailesinde uçtan uca sahiplenmek; IOC'yi SIEM'e yüklemek.
  • Senior / lead: SLA tanımlamak, istisna sürecini yönetmek, yönetim dilinde risk anlatmak, tedarik zinciri politikasını yazmak.

Mülakat sorusu örnekleri
  • İnternete açık bir RCE için 4 saatlik pencereniz var; ilk 30 dakikada ne yaparsınız?
  • pip install X latest CI'da çalışmış; nasıl anlar, nasıl temizlersiniz?
  • Yama sonrası "sanırım düzeldi"yi kabul etmezsiniz - hangi pozitif/negatif kontrolleri koşarsınız?

Pratik öneri
Bu haftaki gerçek olaylardan birini seçin (PHP, GitLab, LiteLLM veya SafePay). Kendi labınızda veya iş yerinizde (izinli) bir kontrol listesi uygulayın. Sonucu 10 satırlık bir postmortem olarak yazın: kapsam, süre, engel, doğrulama, sonraki iyileştirme. Bu doküman, genel "güvenlikle ilgileniyorum" cümlesinden daha değerli bir portfolyo parçasıdır.

Sizce junior bir adayın CV'sinde yama hızını göstermek için en temiz kanıt nedir? Tartışalı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
   
 PHP2Shell Sonrası Hosting Operasyonu: Envanter, Yama, Restart, Doğrulama
KulTigin 10-22-2026, 08:36 AM · Sunucu ve Hosting Güvenliği
0 31
[Resim: attachment.php?aid=361]

Selamlar,

PHP2Shell yamaları çıktı; ama birçok ekip "apt upgrade yaptık" deyip eski FPM süreçlerinin yaşamaya devam ettiğini günler sonra fark ediyor. Bu yazı hosting / SRE tarafı için operasyonel bir kontrol listesi: envanter, yama, restart, doğrulama.

Konuda anlatılacaklar
  1. CLI PHP ile web PHP neden farklı olabilir?
  2. Hangi süreçleri yeniden başlatmalısınız?
  3. Konteyner ve paylaşımlı hosting farkı
  4. Doğrulama komutları

Envanter
CISA'nın uyarısı: PHP çoğu zaman başka yazılımların bileşeni olarak gelir ve varlığı doğrudan görünmeyebilir. WordPress, Drupal, Joomla, Laravel, Magento, phpMyAdmin, matomo, çeşitli panel yazılımları...
Kod:
# Debian/Ubuntu dpkg -l 'php*' | awk '/^ii/ {print $2, $3}' # RHEL ailesi rpm -qa 'php*' # Calisan surecler ps aux | grep -E 'php-fpm|apache2|httpd|lsphp|frankenphp' | grep -v grep # Web'in gordugu surum (kendi sunucunuzda gecici phpinfo) # echo '<?php echo PHP_VERSION;' > /var/www/html/v.php # curl -sS http://127.0.0.1/v.php && rm /var/www/html/v.php

Yama hedefleri
Kod:
8.5.12 | 8.4.27 | 8.3.36 | 8.2.35
EOL dallar (8.1 ve öncesi) için resmi sürüm yok; dağıtım backport'u veya kaynak backport. Changelog'da CVE-2026-109618 ve CVE-2026-109619 arayın; sürüm numarası yanıltıcı olabilir.

Restart listesi
Carthage / PHP ekibinin vurgusu: paket güncellendi diye iş bitmez.
  • Apache (mod_php) veya PHP-FPM havuzları
  • LiteSpeed / lsphp
  • FrankenPHP
  • Uzun ömürlü worker'lar: kuyruk işçileri, Laravel Octane, Swoole, RoadRunner
  • Konteyner: yeniden başlatma değil, yamalı base ile rebuild + redeploy

Kod:
# Ornek (Debian, PHP 8.3 FPM + Apache) sudo apt-get update sudo apt-get install --only-upgrade php8.3-fpm php8.3-cli libapache2-mod-php8.3 sudo systemctl restart php8.3-fpm apache2 # Supervisor altindaki worker'lar sudo supervisorctl restart all # Surum dogrulama php -v curl -sS http://127.0.0.1/v.php

Paylaşımlı hosting
Müşteri olarak WordPress çekirdeğini veya eklentiyi güncellemek PHP runtime'ını güncellemez. Barındırma firmanızdan yazılı teyit isteyin: "Sitemizi sunan PHP sürümü 21 Ekim 2026 PHP2Shell düzeltmesini içeriyor mu?" Teyit gelene kadar WAF ve geçici php.ini kısıtları (session.upload_progress.enabled=0 vb.) riski azaltır ama güvenli yapmaz.

Yama sonrası kısa av
  • Upload / cache dizinlerinde tanınmayan .php
  • Yeni yönetici kullanıcıları
  • Bellek limiti / 500 hata dalgalarıyla biten multipart POST'lar
  • İnternete açık kalmışsa: DB parolası, API anahtarı, salt rotasyonu

Kaç sunucuda CLI ile web PHP sürümü farklı çıktı? Deneyiminizi yazın.

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
   
 Güvenli Olmayan Deserialization: pickle, YAML ve Java için OWASP Özeti
KulTigin 10-22-2026, 08:35 AM · Web Uygulama Güvenliği
0 34
[Resim: attachment.php?aid=360]

Selamlar,

CISA'nın SafePay uyarısında Veeam Backup & Replication için adı geçen CVE-2024-40711, CWE-502: Deserialization of Untrusted Data sınıfında. Yani sorun yeni değil; fidye grupları hâlâ bu sınıftan besleniyor. Bu yazıda OWASP Deserialization Cheat Sheet'in pratik kısımlarını Python, Java ve genel prensipler üzerinden özetliyorum.

Konuda anlatılacaklar
  1. Serialization / deserialization nedir?
  2. Python: pickle ve YAML
  3. Java: ObjectInputStream ve filtreler
  4. Genel kural: güvenilmeyen veriyi native formatta açmayın

Kısa tanım
Serialization bir nesneyi saklanabilir / gönderilebilir bir formata çevirmektir; deserialization tersidir. JSON ve XML gibi saf veri formatları görece güvenlidir. Birçok dilin yerel (native) formatı ise özelleştirme özellikleri sunar; bu özellikler güvenilmeyen veride RCE, DoS veya erişim kontrolü atlatmaya dönüşebilir.

Python
OWASP'ın net uyarısı:
  • pickle.load / pickle.loads: Güvenilmeyen veriyi asla unpickle etmeyin; keyfi kod çalıştırabilir.
  • PyYAML: Güvenilmeyen YAML için yaml.safe_load() kullanın; yaml.unsafe_load veya Loader=yaml.Loader / UnsafeLoader kullanmayın.
  • jsonpickle.decode: Güvenilmeyen girdiyle kullanmayın.

Kod:
# Kendi labiniz - guvenli YAML import yaml metin = "liste: [1, 2, 3]" veri = yaml.safe_load(metin) print(veri) # pickle: yalnizca tamamen guvendiginiz, sizin urettiginiz baytlar

Java
  • ObjectInputStream.readObject / readUnshared, XStream.fromXML, XMLDecoder gibi API'leri güvenilmeyen girdiyle kullanmayın.
  • Serialization filter'ları uygulama özel sınıf allow-list'i ve kaynak limitleriyle yapılandırın.
  • resolveClass() override'ı tek başına yeterli değildir; grafik derinliği, referans sayısı, dizi uzunluğu ve akış boyutu da sınırlanmalıdır.
  • Hex'te AC ED 00 05 veya Base64'te rO0 ile başlayan trafik Java serialization işareti olabilir.

Genel prensipler
  1. Mümkünse native format yerine JSON/XML gibi saf veri formatı kullanın.
  2. Akışın nesne tipini belirlemesine izin vermeyin.
  3. İmzalı (imzası doğrulanmış) veriyi deserialize edin.
  4. Hassas alanları transient yapın; asla deserialize edilmemesi gereken sınıflarda readObject her zaman istisna fırlatsın.

SafePay bağlamında ders basit: yedekleme ürünlerindeki yıllardır bilinen deserialization RCE'leri hâlâ aktif sömürü vektörü. Envanterinizde Veeam, eski Java serileştirme uçları ve pickle kullanan dahili API'ler varsa bunları "teknik borç" değil "açık kapı" olarak işaretleyin.

Kod tabanınızda pickle veya yaml.load (safe olmayan) kalan yer var mı? Grep sonucunuzu (dosya yolu yeter) paylaşın.

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
   
 ReDoS Nedir? Evil Regex, Backtracking ve GitLab Regex Açıkları Bağlamı
KulTigin 10-22-2026, 08:34 AM · Web Uygulama Güvenliği
0 36
[Resim: attachment.php?aid=359]

Selamlar,

GitLab'ın bu ay üst üste iki CVSS 10 regex derleyici açığı yayınlaması (CVE-2026-97229 ve CVE-2026-110264) birçok ekibi aynı soruya getirdi: düzenli ifadeler neden bu kadar tehlikeli olabiliyor? GitLab açıkları bellek taşması sınıfındaydı; ama aynı ailede daha yaygın görülen bir kardeş var: ReDoS (Regular Expression Denial of Service). Bu yazıda OWASP'ın ReDoS sayfasına dayanarak evil regex kavramını ve kendi kodunuzda nasıl tarayacağınızı anlatıyorum.

Konuda anlatılacaklar
  1. Naif regex motoru ve backtracking
  2. Evil regex nedir?
  3. Saldırı senaryoları
  4. Lab ve savunma

Naif algoritma
OWASP'a göre birçok regex motoru NFA (Nondeterministic Finite Automaton) kurar ve eşleşme bulunana kadar olası yolları tek tek dener. Girdi eşleşmezse motor önceki konumlara dönüp (backtracking) başka yolları dener. Kötü yazılmış bir desende yol sayısı girdi uzunluğuyla üstel büyür; örneğin ^(a+)+$ deseni için aaaaX 16 yol, on altı a içeren girdi 65536 yol üretebilir.

Evil regex
OWASP, şu özelliklere sahip desenleri "evil" sayar:
  • Tekrar içeren gruplama
  • Tekrarlanan grubun içinde: tekrar veya örtüşen alternasyon
Örnekler: (a+)+$ , ([a-zA-Z]+)*$ , (a|aa)+$ , (a|a?)+$
Bu desenler aaaaaaaaaaaaaaaaaaaaaaaa! gibi bir girdide motoru uzun süre meşgul edebilir.

Saldırı senaryoları
  • Web uygulamasında kullanıcı girdisinin evil bir regex ile doğrulanması (e-posta, sınıf adı vb.)
  • Regex'in kendisinin kullanıcı girdisinden etkilenmesi (regex injection) - OWASP örneğinde kullanıcı adı regex olarak derleniyor
  • WAF / tarayıcı / veritabanı katmanındaki regex'lerin hedef alınması
GitLab açıkları ReDoS değil, derleyici tamsayı taşması yoluyla RCE idi; ama ortak ders aynı: kullanıcı kontrolündeki veya karmaşık regex'leri güven sınırı olarak görmeyin.

Lab
Kod:
# Python - kendi labiniz (kisa timeout ile) import re, time pat = re.compile(r"(a+)+$") s = "a" * 28 + "!" t0 = time.time() try: pat.search(s) finally: print("sure_s:", round(time.time() - t0, 3))
Girdi uzunluğunu artırdıkça sürenin hızla büyüdüğünü görürsünüz. Üretimde böyle bir deseni kullanıcı girdisine uygulamayın.

Savunma
  • Kullanıcı girdisini regex'e gömmeyin; sabit bir desen kullanın.
  • Mümkünse doğrulamayı regex yerine parser / allow-list ile yapın.
  • Backtracking'siz motorlar veya atomic grouping / possessive quantifier kullanın (dile göre).
  • Regex çalıştırırken zaman ve bellek limiti koyun.
  • Bağımlılıklarınızda ve WAF kurallarınızda evil regex tarayıcıları (ör. rxxr2, regexploit) çalıştırın.

Kod tabanınızda kullanıcı girdisinden derlenen regex var mı? Son denetimde ne 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

Ek DosyalarEkran Görüntüleri
   
 gh auth status: GitHub CLI Token'larınızı Düzenli Kontrol Etmek
KulTigin 10-22-2026, 08:33 AM · Script ve Otomasyon
0 41
[Resim: attachment.php?aid=357]

Selamlar,

LiteLLM tedarik zinciri saldırısında saldırganın elinde üç geliştiriciye ait GitHub CLI OAuth token'ı vardı. Bunlardan biri organizasyon sahibi yetkisindeydi; branch koruması bu token ile aşıldı. Bu yazıda GitHub CLI'nin resmi gh auth status komutunu kullanarak kendi makinelerinizdeki token durumunu nasıl kontrol edeceğinizi anlatıyorum.

Konuda anlatılacaklar
  1. gh auth status ne gösterir?
  2. JSON çıktısı ve otomasyon
  3. Token hijyeni için pratik kurallar
  4. Sızma şüphesinde yapılacaklar

gh auth status
Resmi kılavuza göre komut, bilinen her GitHub host'unda aktif hesabı ve kimlik doğrulama durumunu gösterir. Her hesap için durum test edilir; sorunlar çıktıya eklenir. Süresi dolmuş veya dolmak üzere olan ve yenilenebilen token'lar, --no-refresh verilmedikçe otomatik yenilenir. Herhangi bir hesapta kimlik doğrulama sorunu varsa komut çıkış kodu 1 ile biter (JSON modu hariç).

Kod:
# Tum host ve hesaplar gh auth status # Yalnizca aktif hesap gh auth status --active # Belirli host gh auth status --hostname github.com # JSON (otomasyon icin); token'i da eklemek icin --show-token gh auth status --json hosts # DIKKAT: --show-token token'i duz metin basar; ekran paylasiminda kullanmayin

Ne aramalısınız?
  • Beklemediğiniz ekstra hesaplar veya host'lar
  • Organizasyon sahibi / admin yetkili hesapların geliştirici laptop'larında uzun süre durması
  • CI dışında kişisel makinelerde duran yüksek yetkili token'lar
  • Eski, kullanılmayan host girişleri

Pratik hijyen kuralları
  1. Yüksek yetkili (org owner) hesaplarla günlük geliştirme yapmayın; ayrı bir "günlük" hesap kullanın.
  2. gh auth logout ile kullanılmayan girişleri kapatın; github.com/settings/applications üzerinden yetkilendirilmiş OAuth uygulamalarını gözden geçirin.
  3. Token'ların YZ asistanı yanıtlarına veya loglara düşebileceğini varsayın (LiteLLM'in olay sonrası değerlendirmesi tam da bunu işaret ediyor). Loglarda Authorization / gho_ / ghp_ araması yapın.
  4. CI için fine-grained veya environment-scoped token kullanın; laptop OAuth token'ını CI'ya taşımayın.

Kod:
# Basit periyodik kontrol (kendi makineniz) gh auth status --active 2>&1 | tee ~/gh-auth-check-$(date +%F).log # Beklenmeyen hesap varsa alarm (ornek) gh auth status --json hosts --jq '.hosts[].accounts[].username' | grep -vE '^(sizin_beklenen_kullanici)$' && echo "beklenmeyen hesap" || true

Organizasyonunuzda org owner hesabıyla günlük commit atan var mı? Ayrı günlük hesap politikası uyguluyor 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
   
 CyberChef Sıfırdan: SOC ve CTF için Tarayıcıda İsviçre Çakısı
0 32
[Resim: attachment.php?aid=356]

Selamlar,

Base64, hex, gzip, XOR, JWT parçalama, timestamp çevirme... SOC analisti veya CTF oyuncusu bu işlemleri günde onlarca kez yapar. GCHQ'nun açık kaynak aracı CyberChef bunları sürükle-bırak bir "tarif" (recipe) olarak tarayıcıda birleştirmenizi sağlar. Önemli güvenlik özelliği: işlemlerin hiçbiri CyberChef sunucusuna gitmez; her şey sizin tarayıcınızda, sizin bilgisayarınızda çalışır.

Konuda anlatılacaklar
  1. Arayüzün dört ana alanı
  2. Yerel kurulum: Docker ile
  3. İlk tarifler: Base64, hex+gzip, Magic
  4. SOC / CTF kullanım senaryoları

Arayüz
README'ye göre dört ana alan:
  1. Input (sağ üst): metin veya dosya
  2. Output (sağ alt): sonuç
  3. Operations (sol): kategorili işlem listesi / arama
  4. Recipe (orta): sürüklediğiniz işlemler ve parametreleri
Auto Bake açıksa input veya tarif değişince çıktı hemen üretilir. Breakpoint koyup adım adım ilerleyebilir, tarifleri yerel depolamaya kaydedebilir, URL hash ile paylaşabilirsiniz (#recipe=...&input=...).

Yerel kurulum (Docker)
Hassas veriyi genel web sitesine yapıştırmak istemiyorsanız yerelde çalıştırın:
Kod:
# Onceden derlenmis imaj docker run --rm -it -p 8080:8080 ghcr.io/gchq/cyberchef:latest # Tarayicida: http://localhost:8080
Kaynaktan build için Node.js v24 gerekir; Docker yolu toolchain istemez. README, CyberChef'in tamamen istemci tarafında çalıştığını ve tam bir kopyasının indirilip kapalı ağda / VM'de kullanılabileceğini özellikle vurgular.

İlk tarifler
  • From Base64: Operations'tan sürükleyin, input'a kodlanmış metni yapıştırın.
  • From Hex -> Gunzip: Hexdump'lanmış sıkıştırılmış veriyi açmak için iki işlemli tarif.
  • Magic: CyberChef, verinin hangi kodlamalar altında olabileceğini otomatik tahmin etmeye çalışır; Output'taki sihir ikonuna tıklayınca uygun işlemi önerir.

SOC / CTF senaryoları
  • Oltalama ekindeki PowerShell'in -EncodedCommand parametresini UTF-16LE Base64'ten çözmek
  • DNS veya HTTP üzerinden exfil edilen hex parçalarını birleştirip Gunzip etmek
  • JWT'nin header/payload kısmını (imza doğrulaması olmadan) okumak - yalnızca inceleme
  • Timestamp yığınını insan okur tarihe çevirmek
  • Basit XOR / tekrarlayan anahtar denemeleri (CTF crypto)

Kod:
# Derin baglanti ornegi (URL hash) # https://gchq.github.io/CyberChef/#recipe=From_Base64('A-Za-z0-9%2B/%3D',true)&input=SGVsbG8=
Hassas müşteri verisini genel instance'a yapıştırmayın; Docker ile yerel kopya kullanın. CyberChef bir çözümleyici değildir; çıktıyı her zaman bağlamıyla doğrulayın.

En sık kullandığınız CyberChef tarifi nedir? URL'sini (hassas veri olmadan) paylaşın.

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
   
 Docker İmajını Digest ile Sabitlemek: latest Tuzağından Kurtulmak
0 43
[Resim: attachment.php?aid=354]

Selamlar,

LiteLLM olayında yalnızca PyPI wheel'leri değil, Docker Hub ve GHCR'daki latest, main-latest ve main-stable etiketleri de zararlı imaja işaret etti. Etiket hareketli bir işaretçidir; digest ise içeriğin parmak izidir. Bu yazıda Docker'ın resmi pull belgelerine göre imajı digest ile sabitlemenin nasıl yapıldığını anlatıyorum.

Konuda anlatılacaklar
  1. Etiket ile digest farkı
  2. Digest nasıl öğrenilir, nasıl çekilir?
  3. Dockerfile'da FROM ...@sha256:...
  4. Üretim politikası önerileri

Etiket ile digest
docker pull debian dediğinizde Engine varsayılan olarak :latest etiketini kullanır. Aynı imaj daha sonra güvenlik güncellemesiyle yeniden yayınlandığında aynı etiket yeni bir içeriğe bakabilir - bu bazen istediğiniz şeydir (yama almak), bazen istemediğiniz (saldırganın latest'i zehirlemesi).

Digest, imaj yapılandırması ve katmanlarını kapsayan bir SHA256 özetidir. Docker belgelerinin dediği gibi: digest ile çekmek, o imajın tam olarak o sürümünü "pin"ler ve her zaman aynı içeriği garantiler.

Lab: digest öğrenip sabitlemek
Kod:
# Once etiketi cekin; Docker pull bitince digest'i yazar docker pull debian:bookworm # Yerel imajin RepoDigests degerini okuyun docker image inspect debian:bookworm --format '{{json .RepoDigests}}' # Digest ile cekme ornegi (asagidaki hash ornektir; kendi ciktinizi kullanin) # docker pull debian@sha256:<sizin_digest>
Dockerfile'da:
Kod:
# ORNEK - hash'i kendi dogrulanmis degerinizle degistirin FROM debian@sha256:3f1d6c17773a45c97bd8f158d665c9709d7b29ed7917ac934086ad96f92e4510
Belgelerin uyarısı: Digest ile sabitlemek, imajın güvenlik güncellemelerini otomatik almamanız anlamına gelir. Yamalı bir sürüme geçmek için digest'i bilinçli olarak değiştirirsiniz. Bu bir özelliktir: değişiklik denetimli olur.

LiteLLM bağlamı
LiteLLM, etkilenen Docker imaj index'ini açıkça yayınladı: sha256:1bbcb1443bc962e45f5aad53fe3d2c30600e0379715fb6c664cdd3ac126c339e. Çalışan konteynerlerinizin gerçekte hangi digest'i koşturduğunu bilmiyorsanız, "biz latest kullanmıyoruz, v1.107.0 kullanıyoruz" demek yetmeyebilir; çünkü o etiket o aralıkta zehirli index'e bakıyordu.

Kod:
# Calisan konteynerin gercek digest'i docker inspect --format '{{index .RepoDigests 0}}' <konteyner> # veya docker image inspect <image_id> --format '{{join .RepoDigests "\n"}}'

Üretim politikası
  • CI'da imajı etiket + digest ile kaydedin; deploy yalnızca digest kullansın.
  • latest / main-stable gibi hareketli etiketleri üretim namespace'inde yasaklayın.
  • İmzalı imajlar (cosign / Docker Content Trust) ile digest doğrulamasını birleştirin.
  • Bağımlılık güncellemelerini (renovate/dependabot) digest değişikliği olarak PR'layın; insan gözü görsün.

Sizin Kubernetes manifest'lerinizde digest var mı, yoksa hâlâ tag 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