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
- Amazon tam olarak ne söyledi?
- Dataminr ve Patchstack'in farklı tonu
- Asya'dan gelen yeni resmi tepkiler
- "İfşa tarihi" varsayımı neden tehlikeli?
- 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ı.
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ı.
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.
# 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 -50Kısa kontrol listesi (güncellenmiş)
- PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 veya dağıtım backport'u kurulu mu?
- FPM havuzları, Apache ve uzun ömürlü worker'lar yeniden başlatıldı mı?
- 17 Ekim sonrası loglar incelendi mi?
- 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
