Siber güvenlik topluluğunun nabzı

Selam arkadaşlar,

Kamu hizmetlerinin taşeron sistemlere ne kadar bağımlı hale geldiğini gösteren bir olay daha var. ABD federal yargısı adına iflas davalarındaki resmi bildirimleri üreten ve gönderen Bankruptcy Noticing Center (BNC) sistemi, 9 Ekim'den bu yana çalışmıyor. Sistemi yargı adına işleten savunma ve havacılık devi BAE Systems, kesintinin bir siber güvenlik olayından kaynaklandığını doğruladı. Olay ABD'de geçiyor ama tedarikçi riski açısından her ülkenin kamu kurumları için ders niteliğinde.

Konuda Anlatılacaklar

1. BNC nedir, ne iş yapar?
   
2. Ne oldu, hangi sistemler kapalı?
   
3. Açıklamaların seyri: "kesinti"den "siber olay"a
   
4. Mahkemeler ve taraflar nasıl etkileniyor?
   
5. Bilinmeyenler
   
6. Kurumlar için tedarikçi riski dersleri
   
7. Kaynaklar
   

BNC Nedir?

ABD'de bir iflas davası açıldığında alacaklılara, borçlulara ve diğer taraflara toplantı tarihleri, karar ve son başvuru tarihleri gibi resmi bildirimlerin gönderilmesi gerekiyor. Bu bildirimleri mahkemeler adına merkezi olarak üreten ve kağıt postayla ya da elektronik olarak dağıtan sistem BNC. CyberScoop'un aktardığına göre BNC'yi federal yargı adına BAE Systems işletiyor.

Kısacası BNC, iflas sisteminin "posta servisi". Davaların kendisi başka sistemlerde yürüyor; ama tarafların neyin ne zaman olduğundan haberdar olması büyük ölçüde bu altyapıya bağlı.

Ne Oldu?

ABD Mahkemeleri İdari Ofisi'nin (AO) 15 Ekim tarihli açıklamasına göre, BNC'yi işleten yüklenicinin sistemlerini etkileyen bir siber güvenlik olayı nedeniyle iflas mahkemelerinin bildirim işlemleri aksıyor. Çevrimdışı olan hizmetler:

• bnc.uscourts.gov
  
• bankruptcynotices.uscourts.gov
  
• notices.uscourts.gov
  
• National Creditor Registration Service (Ulusal Alacaklı Kayıt Hizmeti, NCRS)
  

Hem kağıt hem elektronik bildirim üretimi 9 Ekim'den beri durmuş durumda.



Açıklamaların Seyri

Olayın iletişim tarafı da dikkat çekici. CyberScoop'un aktardığına göre salı günü yayımlanan bildirimde durum "ülke çapında hizmet kesintisi" olarak tanımlanmıştı. Kesintinin bir siber güvenlik olayı olduğu ilk kez AO'nun 15 Ekim tarihli açıklamasında açıkça söylendi.

BAE Systems sözcüsü ise şirketin olayın "BNC sistemiyle sınırlı" olduğunu ve "başka hiçbir sistemin etkilenmediğini" belirttiğini aktardı. Bu açıklama önemli, çünkü BAE Systems yalnızca bir yazılım taşeronu değil; ABD hükümetiyle çok sayıda hassas sözleşmesi olan bir savunma şirketi. Şirketin diğer müşterilerine yönelik bir etki olup olmadığı sorusu doğal olarak akla geliyor; şirket ise şimdilik net şekilde "hayır" diyor.

Mahkemeler ve Taraflar Nasıl Etkileniyor?

AO'ya göre mahkemeler dava dilekçesi ve evrak kabul etmeye devam ediyor; yani dava açma ve dosyalama süreçleri işliyor. Sorun, bu işlemlerden doğan bildirimlerin taraflara ulaşmaması.

CyberScoop'a konuşan bir iflas mahkemesi yazı işleri müdürü Joe Falzone, tarafların bildirim adreslerini CM/ECF (mahkemelerin elektronik dosya sistemi) üzerinden arayabileceğini, ancak elektronik iflas bildirimi (EBN) veya NCRS ile kayıtlı adreslerin burada eksik olabileceğini söylüyor. Yani bildirim için alternatif yol var ama boşluksuz değil.

Pratikte bu şu anlama geliyor: Bir alacaklı, normalde e-postasına düşecek bir toplantı ya da son başvuru tarihini kaçırabilir. Bir haftayı aşan bir kesinti, hukuki sürelerin işlediği bir sistemde ciddi bir operasyonel sorun.

Bilinmeyenler

Şu an kamuoyuyla paylaşılmamış ya da belirsiz olan konular:

• Olayın türü ve nedeni (fidye yazılımı mı, başka bir saldırı mı?)
  
• Saldırganların herhangi bir veriye erişip erişmediği
  
• BNC'nin ne zaman yeniden hizmete gireceği
  
• Herhangi bir grubun sorumluluk üstlenip üstlenmediği
  

Bildirim sistemlerinin doğası gereği BNC'de taraf adları, adresler ve dava bilgileri gibi veriler bulunması beklenir. Ancak herhangi bir verinin etkilendiğine dair resmi bir açıklama yok; bu yüzden bunu bir veri ihlali olarak değil, şimdilik bir hizmet kesintisi yaratan siber olay olarak ele almak gerekiyor.

CyberScoop, federal yargının daha önce de hedef alındığını hatırlatıyor: 2025'te yargının dava dosyalama sistemine yönelik bir ihlal yaşanmıştı. Arka arkaya gelen bu olaylar, yargı altyapısının saldırganlar için cazip bir hedef olmaya devam ettiğini gösteriyor.



Kurumlar İçin Tedarikçi Riski Dersleri

Bu olay teknik ayrıntıları henüz bilinmese de kurumsal açıdan net dersler veriyor:

1. Kritik süreçlerin dış kaynak haritası çıkarılmalı. Kurumunuzun "postacısı" kim? Toplu e-posta, SMS, fatura, bildirim ve tebligat süreçlerinizi hangi tedarikçiler yürütüyor? Bu listenin güncel olmaması, olay anında ilk kaybedilen saatler demek.

2. Manuel yedek süreç (fallback) tanımlı olmalı. BNC durunca mahkemeler bildirimleri başka yoldan yapabilmek için CM/ECF'deki adreslere yöneliyor; ama bu adresler eksik. Ana sistem durduğunda devreye girecek, veri açısından da güncel tutulan bir alternatif kanal planlanmalı.

3. Sözleşmelerde olay bildirim yükümlülükleri net olmalı. Tedarikçinin bir olayı ne kadar sürede, hangi ayrıntıyla bildireceği sözleşmeye yazılmalı. "Hizmet kesintisi" ile "siber olay" arasındaki fark, müşteri kurumun kendi risk değerlendirmesi için kritik.

4. İletişim şeffaflığı güven inşa eder. Kesintinin ilk günlerinde nedenin belirsiz kalması anlaşılabilir; ama etkilenen taraflar ne kadar erken doğru bilgi alırsa, kendi önlemlerini (alternatif adres kontrolü, son tarih takibi) o kadar erken alabilir.

Kamu ya da özel, hangi sektörde olursanız olun soru aynı: Kurumunuzda kritik bildirim süreçlerinden biri bir hafta dursa ne yapardınız? Bu soruyu bugün masaya koymak, olay anında doğaçlama yapmaktan çok daha ucuz.

Gelişmeleri takip edip yeni bir açıklama gelirse konuyu güncellerim.

Kaynaklar

• United States Courts - Cybersecurity Incident Disrupting Bankruptcy Court Operations (15 Ekim 2026): https://www.uscourts.gov/data-news/judic...operations
  
• CyberScoop - BAE Systems cybersecurity incident disrupts US bankruptcy courts: https://cyberscoop.com/bae-systems-cyber...cy-courts/
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Selam TurkTeam,

Impacket, ağ protokolleriyle (SMB, MSRPC, NTLM, Kerberos ve daha fazlası) ham düzeyde çalışan Python sınıflarından oluşan bir kütüphanedir. Ama çoğu pentest'çi onu, bu sınıfların üzerine yazılmış hazır betikleriyle (secretsdump, psexec, smbclient, wmiexec...) tanır. Bu araçlar, özellikle Windows/Active Directory ortamlarında kimlik bilgisi toplama ve uzaktan komut çalıştırmanın İsviçre çakısıdır. Bu rehberde Impacket'i kurulumdan temel iş akışına, yalnızca kendi lab ortamınızda uygulamak üzere ele alıyoruz.

Konuda Anlatılacaklar

1. Impacket nedir, ne işe yarar
   
2. Kurulum ve Kali'deki betik isimleri
   
3. Kimlik doğrulama söz dizimi (parola ve pass-the-hash)
   
4. impacket-smbclient ile paylaşım erişimi
   
5. impacket-psexec / wmiexec ile uzaktan komut
   
6. impacket-secretsdump ile kimlik bilgisi dökümü
   
7. Sonuç, kaynakça ve yasal uyarı
   

1. Impacket Nedir?
Impacket (SecureAuth/Fortra tarafından sürdürülen açık kaynak proje), ağ protokollerini programatik olarak kullanmayı sağlayan bir Python kütüphanesidir. Pratikte onu güçlü kılan, bu kütüphaneyle yazılmış hazır örnek betiklerdir. Bu betikler bir Windows ağında kimlik doğrulama, dosya erişimi, uzaktan komut çalıştırma ve kimlik bilgisi (hash) çıkarma gibi işleri standartlaştırır. Mavi takım için de değerlidir: saldırganın hangi protokolleri nasıl kullandığını anlamak, tespit kuralı yazmanın temelidir.

2. Kurulum
Kali/Parrot üzerinde Impacket betikleri genellikle hazırdır veya tek paketle gelir:
Kali'de betikler impacket- önekiyle çağrılır (örn. impacket-secretsdump). Pip ile kurduğunuzda ise doğrudan secretsdump.py biçiminde olur. Kurulumu doğrulamak için:

3. Kimlik Doğrulama Söz Dizimi
Impacket betiklerinin çoğu ortak bir hedef biçimi kullanır: domain/kullanici:parola@hedef. Çalışma grubu ortamında domain yerine makine/boş bırakılır.

Parola ile:

Parola sormasını istemek (komut geçmişine yazmamak için):

Pass-the-hash (parola yerine NTLM hash): -hashes LMHASH:NTHASH biçiminde verilir; LM yoksa boş bırakılıp yalnızca NT kullanılır:
Bu, bir hash ele geçirildiğinde parolayı kırmaya gerek kalmadan kimlik doğrulamayı gösterir; neden hash korumasının kritik olduğunu anlatan iyi bir derstir.

4. impacket-smbclient ile Paylaşım Erişimi
Impacket'in kendi SMB istemcisi, etkileşimli ve betiklenebilir bir arayüz sunar:
Bağlandıktan sonra komutlarla paylaşımları gezebilirsiniz:
Bu araç özellikle yönetici kimliğiyle C$ gibi idari paylaşımlara erişimi ve dosya aktarımını kolaylaştırır.

5. impacket-psexec ve wmiexec ile Uzaktan Komut
psexec, hedefte geçici bir servis oluşturup SYSTEM yetkisiyle etkileşimli kabuk verir (yerel yönetici kimliği gerekir):
Başarılı olursa bir Windows komut istemi açılır; yetkiyi doğrulamak için:
psexec servis oluşturduğu için gürültülüdür ve EDR/log tarafında iz bırakır. Daha sessiz bir alternatif wmiexec'tir; WMI üzerinden komut çalıştırır:


6. impacket-secretsdump ile Kimlik Bilgisi Dökümü
secretsdump, Windows kimlik sırlarını (SAM yerel hash'leri, LSA sırları ve domain denetleyicisinde NTDS.dit) çıkarır. Uzaktan, yönetici kimliğiyle:
Çıktı, kullanıcıların NTLM hash'lerini "kullanici:rid:lmhash:nthash:::" biçiminde listeler. Bu hash'ler pass-the-hash için veya çevrimdışı kırma (John/Hashcat) için kullanılabilir. Çevrimdışı analiz için elinizde SAM ve SYSTEM kovanları varsa:
Domain denetleyicisinde DCSync yöntemiyle tüm domain hash'lerinin çekilebilmesi, neden "Domain Admin" yetkisinin tüm ağın anahtarı olduğunu çarpıcı biçimde gösterir.


7. Savunma Perspektifi
Impacket araçları, saldırganın yetkili bir kimlik ele geçirdikten sonra ne kadar hızlı yayılabileceğini gösterir. Savunma için önemli kontroller:

• En az ayrıcalık ve yerel yönetici ayrımı: LAPS ile her makineye benzersiz yerel yönetici parolası.
  
• Kimlik koruma: Credential Guard, LSASS koruması ve güçlü parola politikaları pass-the-hash etkisini sınırlar.
  
• Tespit: psexec'in servis oluşturması (Event ID 7045), anormal WMI/SMB kullanımı ve DCSync replikasyon istekleri SIEM'de izlenmelidir.
  
• Ağ segmentasyonu: İdari paylaşımlara (C$, ADMIN$) erişimi kısıtlamak yanal hareketi zorlaştırır.
  

7.1. Impacket'i Bir İş Akışında Düşünmek
Impacket betiklerini tek tek öğrenmek kolaydır; asıl beceri, onları bir saldırı zincirinin mantıklı adımlarına yerleştirmektir. Tipik bir iç ağ senaryosunda sıralama şöyle işler: önce keşif ve bir kimlik (kullanıcı adı + parola ya da hash) elde edersiniz; ardından impacket-smbclient ile bu kimliğin hangi paylaşımlara eriştiğini görürsünüz; yeterli yetki varsa impacket-psexec veya impacket-wmiexec ile uzaktan komut çalıştırıp dayanak noktası kurarsınız; en sonunda impacket-secretsdump ile daha fazla kimlik bilgisi toplar ve bir sonraki makineye yanal hareket edersiniz. Bu döngü (kimlik topla, erişimi genişlet, yeni kimlik topla) modern iç ağ testlerinin özüdür.

Bu araçların en öğretici yanı, parolanın kendisine değil, kimlik doğrulama malzemesine (hash, bilet) dayanmasıdır. Pass-the-hash ile bir NTLM hash'i, parola hiç bilinmeden kimlik doğrulamak için yeterlidir; bu da neden hash'lerin en az parolalar kadar hassas olduğunu gösterir. secretsdump bir makineden hash topladığında, aynı yerel yönetici parolasının birçok makinede tekrar kullanıldığı ortamlarda tek bir hash tüm ağı açabilir. İşte bu yüzden LAPS gibi makine başına benzersiz parola çözümleri kritik bir savunmadır.

Pratik bir uyarı: bu betikler varsayılan yapılandırmalarıyla gürültülüdür ve çoğu kurumsal EDR/SIEM bunları tanır. Bir denetimde amaç sessizce yıkmak değil, savunmanın bu hareketleri görüp göremediğini test etmektir. Bu yüzden her adımı kaydedin, hangi aracın hangi iz bıraktığını not edin ve raporunuzda hem bulduğunuz yanal hareket yollarını hem de tespit boşluklarını birlikte sunun. Böylece Impacket, yalnızca bir saldırı aracı değil, aynı zamanda savunmayı ölçen bir mihenk taşı hâline gelir.

Sonuç
Impacket, Windows/AD ortamlarında kimlik doğrulama, dosya erişimi, uzaktan komut ve kimlik bilgisi dökümünü tek tutarlı çatı altında toplar. secretsdump, psexec ve smbclient üçlüsünü anlamak, hem kırmızı takımda yanal hareketi hem de mavi takımda tespiti kavramak için temeldir. Tüm bu araçları yalnızca kendi lab'ınızda veya yazılı izinli testlerde kullanın.

Kaynakça

• Impacket Resmi Deposu - https://github.com/fortra/impacket
  
• Impacket Örnek Betik Belgeleri - https://github.com/fortra/impacket/tree/master/examples
  
• Kali Tools: impacket-scripts - https://www.kali.org/tools/impacket-scripts/
  
• MITRE ATT&CK - OS Credential Dumping (T1003) - https://attack.mitre.org/techniques/T1003/
  
• Microsoft: LAPS - https://learn.microsoft.com/windows-serv...s-overview
  

Yasal Uyarı

Alıntı:Impacket araçları yalnızca kendi sistemlerinizde veya yazılı izin aldığınız ağlarda kullanılmalıdır. İzinsiz kimlik bilgisi dökümü ve uzaktan komut çalıştırma Türk Ceza Kanunu 243-245. maddeleri kapsamında ağır suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Selam arkadaşlar,

Yapay zeka ajanı ve iş akışı geliştirmek için kullanılan açık kaynak platform Langflow'da geçen ay kapatılan kritik bir açık, şu anda internete açık sunuculara karşı aktif olarak kullanılıyor. CVE-2026-105740 numaralı açık, Langflow'un MCP (Model Context Protocol) sunucu yapılandırmasındaki "stdio" taşıma yönteminden kaynaklanıyor ve herhangi bir oturum açmış kullanıcının sunucuda işletim sistemi komutu çalıştırmasına izin veriyor. Exploit girişimlerini tespit eden Previdian'ın verileri, saldırganların bu açığı varsayılan ya da zayıf parolalarla birleştirdiğini gösteriyor.

Konuda Anlatılacaklar

1. Langflow nedir, neden hedefte?
   
2. Açığın teknik özeti
   
3. İkinci açık: CVE-2026-105697 ve neden 1.9.0 yetmiyor?
   
4. Sahada neler görülüyor?
   
5. Sunucunuzu nasıl kontrol edersiniz?
   
6. Yama, geçici önlem ve sıkılaştırma
   
7. Kaynaklar
   

Langflow Nedir, Neden Hedefte?

The Hacker News'in aktardığına göre Langflow, geliştiricilerin yapay zeka uygulamaları ve ajan tabanlı iş akışları kurmasını sağlayan açık kaynak bir platform. Langflow'un ana şirketi DataStax, Şubat 2025'te IBM tarafından satın alındı.

Bu tür platformlar saldırganlar için cazip; çünkü genellikle LLM sağlayıcılarının API anahtarlarını, veritabanı bağlantı bilgilerini ve bulut kimlik bilgilerini ortam değişkenlerinde tutuyorlar. Bir Langflow sunucusunu ele geçiren saldırgan, sadece o sunucuya değil, bağlı olduğu tüm servislere de uzanabiliyor.

Açığın Teknik Özeti

• CVE: CVE-2026-105740
  
• CVSS 3.1: 9.9 (Kritik), vektör AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
  
• Zafiyet türü: CWE-78, işletim sistemi komut enjeksiyonu
  
• Etkilenen: Langflow 1.10.3 öncesi (CVE-2026-105740 1.9.0 öncesini, kardeş kayıt CVE-2026-105697 ise 1.10.2 dahil tüm sürümleri etkiliyor)
  
• Danışma notu: GHSA-7w94-79vh-5mr2 (Eylül 2026); CVE kaydı 5 Ekim 2026'da yayımlandı
  

Langflow'un güvenlik bildirimindeki açıklama özetle şöyle: Oturum açmış herhangi bir Langflow kullanıcısı, "Stdio" taşıma yöntemiyle bir MCP sunucusu eklediğinde, kullanıcının girdiği "command" alanı hiçbir doğrulama, izin listesi ya da sandbox olmadan doğrudan bir bash kabuğuna aktarılıyor. Komut, MCP sunucu listesi her yüklendiğinde çalışıyor. Ayrıca "env" alanı üzerinden LD_PRELOAD veya PATH gibi ortam değişkenleri de enjekte edilebiliyor.

Bildirim, açığın sonuçlarını da sıralıyor:

• Tam sunucu ele geçirme: Langflow sürecinin yetkileriyle dosya okuma/yazma ve komut çalıştırma.
  
• Kalıcılık: Zararlı MCP yapılandırması kaydediliyor ve sunucu listesi her yüklendiğinde (başka kullanıcılar ya da yöneticiler MCP ayarları sayfasına girdiğinde bile) yeniden çalışıyor.
  
• Gizlilik: Akış düzenleyicide görünen özel bileşen kodlarının aksine MCP sunucu yapılandırmaları proje ayarlarında saklanıyor ve normal akış incelemesinde görünmüyor.
  
• Yanal hareket: İç ağa, bulut meta veri uç noktalarına ve ortam değişkenlerindeki veritabanı kimlik bilgilerine erişim.
  

Önemli bir not: Açığın yönetici yetkisi gerektirmemesi. Yönetici olmayan sıradan bir hesap da yeterli.



İkinci Açık: CVE-2026-105697 ve Neden 1.9.0 Yetmiyor?

Burada dikkat edilmesi gereken bir incelik var. Langflow'un 28 Eylül tarihli ikinci güvenlik bildirimi (GHSA-w794-rj3p-xv45), aynı MCP stdio mekanizmasındaki sorunun iki adımda kapatıldığını anlatıyor:

• 1.9.0: REST API'deki "MCP sunucusu ekle" yoluna bir komut izin listesi ve argüman/ortam değişkeni doğrulaması eklendi. Bu, CVE-2026-105740'ı kapatıyor.
  
• 1.9.0 - 1.10.2 arası: Komutun nihayet çalıştırıldığı noktada hâlâ doğrulama yoktu ve bash sarmalayıcısı kullanılıyordu. Bu yüzden API'den geçmeyen yapılandırmalar (örneğin bir akışın içine gömülü MCP Tools bileşeni değeri) hâlâ keyfi komut çalıştırabiliyordu.
  
• 1.10.3: Aynı politika API'de, akış çalıştırmada ve süreç başlatılmadan hemen önce uygulanıyor; kabuk kullanımı tamamen kaldırıldı. Sorun burada tamamen kapandı.
  

The Hacker News'e göre bu ikinci kritik açık CVE-2026-105697 (CVSS 9.9) olarak izleniyor ve 1.10.3'te düzeltildi. Kısacası: 1.9.0'a yükseltmek yeterli değil, hedef 1.10.3 veya üstü olmalı.

Bildirimdeki bir diğer kritik ayrıntı: Varsayılan LANGFLOW_AUTO_LOGIN=true ayarında, auto_login uç noktası kimlik bilgisi istemeden token veriyor. Yani varsayılan yapılandırmayla internete açık bir sunucuda bu açık hesap bile gerektirmeden kullanılabiliyor. Langflow, AUTO_LOGIN'in yalnızca geliştirme ortamı için olduğunu belirtiyor.

Sahada Neler Görülüyor?

The Hacker News'in 15 Ekim tarihli haberine göre Previdian'ın tuzak (honeypot) sensörleri, 19 Eylül 2026'dan bu yana 27 farklı IP adresinden 1.423 sömürü girişimi kaydetti; haberin güncellemesinde bu sayı 28 IP'den 1.706'ya çıktı. Previdian'ın 17 Ekim'de güncellenen sayfasında ise toplam 2.065 girişim, 28 benzersiz IP ve 16 ülke görünüyor. Girişimler 11 Ekim'den itibaren belirgin şekilde arttı; o gün 333 girişim kaydedildi.

Previdian'ın kurucusu Ryan Dewhurst'ün The Hacker News'e anlattığı bir saldırı sırası çok öğretici: Saldırganlar önce Langflow sürümünü kontrol etmiş, auto_login uç noktasını denemiş (tuzak sistemde kapalı olduğu için 403 almış), ardından yaygın bir kullanıcı adı ve parolayla başarıyla oturum açmış ve aldıkları token'ı hemen zafiyetli MCP yapılandırma uç noktasına karşı kullanmış.

Yakalanan yüklerden bazıları:

• LANGFLOW_SECRET_KEY ve LANGFLOW_SUPERUSER_PASSWORD dahil ortam değişkenlerini ve Langflow yapılandırmasını çekip dışarıya gönderme girişimleri
  
• Host dosya sistemine erişmeye çalışan Docker komutları
  
• id, whoami gibi basit komut çalıştırma denemeleri
  

The Hacker News'e göre aktivitenin önemli bir kısmı tek bir IP adresinden geliyor ve bu adres Flowise ile Langflow'daki başka açıkları da hedeflemiş. Bu da açıkta kalan yapay zeka platformlarını sistematik olarak tarayan bir aktöre işaret ediyor; amacı şimdilik belirsiz. Açık, Previdian'ın 17 Ekim tarihli sayfasına göre henüz CISA KEV kataloğunda değil.

Haberde paylaşılan göstergeler (log ve güvenlik duvarı aramaları için):

Sunucunuzu Nasıl Kontrol Edersiniz?

Kurulu sürümü kontrol edin (pip ile kurulduysa):

Docker ile çalıştırıyorsanız imaj etiketini kontrol edin:

AUTO_LOGIN ayarını kontrol edin:

Ters proxy veya erişim loglarında MCP sunucu uç noktasına yapılan istekleri ve auto_login denemelerini arayın (yolu kendi ortamınıza göre değiştirin):

Langflow arayüzünde Settings > MCP Servers bölümünü açıp sizin eklemediğiniz bir stdio sunucusu olup olmadığına bakın. Ancak dikkat: Zafiyetli sürümde bu sayfayı açmak, kaydedilmiş zararlı bir yapılandırmayı tetikleyebilir. Şüpheniz varsa önce yükseltin ya da sunucuyu ağdan izole edip yapılandırmayı veritabanından inceleyin.



Yama, Geçici Önlem ve Sıkılaştırma

1. Yükseltin: langflow 1.10.3, langflow-base 0.10.3 ve lfx 1.10.3 veya üstü.

2. Hemen yükseltemiyorsanız: Langflow'un önerdiği geçici önlemler:

• LANGFLOW_AUTO_LOGIN=false ayarlayın.
  
• Langflow'u güvenilmeyen ağlara doğrudan açmayın; VPN ya da kimlik doğrulamalı bir ters proxy arkasına alın.
  
• Langflow hesaplarını yalnızca güvendiğiniz kullanıcılara verin.
  

Previdian ayrıca güçlü ve benzersiz parolalar kullanılmasını, kimlik doğrulama loglarının ve MCP uç noktasına yapılan isteklerin gözden geçirilmesini öneriyor.

3. 1.10.3 sonrası sıkılaştırma: Bildirime göre izin listesi npx ve uvx'in varsayılan olarak herhangi bir paketi çalıştırmasına hâlâ izin veriyor. Çok kullanıcılı ortamlarda şu ayarlar öneriliyor:
1.11.1 ve sonrasında özel kod çalıştırmayı kısıtlayan ayarlar (LANGFLOW_ALLOW_CUSTOM_COMPONENTS=false gibi) MCP stdio sunucularını da yalnızca süper kullanıcılara sınırlıyor.

4. Ele geçirilme şüphesi varsa: Sunucuyu izole edin, logları ve veritabanını koruyun, ortam değişkenlerinde ve yapılandırmada bulunan tüm sırları (LLM API anahtarları, veritabanı parolaları, bulut kimlik bilgileri, LANGFLOW_SECRET_KEY) güvenilir bir ortamdan döndürün ve sunucuyu temiz bir imajdan yeniden kurun.

Yapay zeka platformları hızla üretime alınıyor ama güvenlik yapılandırması çoğu zaman geliştirme ortamındaki haliyle kalıyor. Varsayılan AUTO_LOGIN açık bir Langflow'un internete açılması, bu olayın özeti gibi. Sizin ortamınızda Langflow, Flowise ya da benzeri araçlar kimin sorumluluğunda ve nereden erişilebilir? Yorumlarda tartışalım.

Kaynaklar

• The Hacker News - Langflow's Critical Authenticated RCE Flaw Targeted in 1,423 Honeypot Exploit Attempts (15 Ekim 2026): https://thehackernews.com/2026/10/langfl...d-rce.html
  
• Previdian - CVE-2026-105740 Exploitation Observed: https://previdian.com/CVE-2026-105740
  
• Langflow GitHub Security Advisory - GHSA-w794-rj3p-xv45: https://github.com/langflow-ai/langflow/...-rj3p-xv45
  
• Langflow GitHub Security Advisory - GHSA-7w94-79vh-5mr2: https://github.com/langflow-ai/langflow/...-79vh-5mr2
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Selam arkadaşlar,

Bu hafta altyapı tarafında iki büyük yama paketi birden geldi. NGINX ekibi 14 Ekim'de nginx 1.30.6 (stable) ve 1.31.7 (mainline) sürümleriyle beş güvenlik açığını kapattı; aynı dönemde F5 ve Juniper Networks da kendi ürün ailelerinde kritik açıklar için güncelleme yayımladı. İnternete bakan sunucuların önemli bir kısmının önünde NGINX olduğunu düşünürsek, bu konuyu "sonra bakarım" listesine atmamak lazım.

Konuda Anlatılacaklar

1. NGINX'teki beş açık ve tetiklenme koşulları
   
2. Puanlama farkı: NGINX "orta" diyor, F5 "kritik"
   
3. Yapılandırmanız etkileniyor mu? Hızlı kontrol
   
4. Juniper'ın ekim paketi
   
5. Yama ve geçici önlem önerileri
   
6. Kaynaklar
   

NGINX'teki Beş Açık

Bu açıkların ortak noktası, çoğunun yalnızca belirli yapılandırmalarda tetiklenmesi. nginx.org güvenlik bildirimleri ve The Hacker News'in derlemesine göre:

1. CVE-2026-15176 - alias + rewrite + $request_filename
Bellek bozulması türünde bir açık. Bir location bloğunda alias, rewrite ve $request_filename değişkeninin birlikte kullanıldığı yapılandırmaları etkiliyor. Etkilenen sürümler 0.1.29 - 1.31.6; yani neredeyse projenin tüm geçmişi kapsamda. Açığı F5'in kendisi bulmuş.

2. CVE-2026-93479 - map içindeki regex yakalamaları
map bloğundaki düzenli ifade yakalamalarının root veya log_format içinde kullanılmasıyla tetikleniyor. Etkilenen sürümler 1.30.0 - 1.30.5 ve 1.31.2 - 1.31.6. The Hacker News'e göre hata, temmuzda yayımlanan CVE-2026-42533 düzeltmesine dayanıyor. Bulan isimler: Matt Suiche (Tolmo) ve Mateusz Gierblinski.

3. CVE-2026-95101 - HTTP/3 istek gövdesi enjeksiyonu
HTTP/3 etkinken ve proxy_request_buffering on (varsayılan değer) durumunda istek gövdesine veri enjeksiyonu yapılabiliyor. Etkilenen sürümler 1.25.0 - 1.31.6. Bulan: Hansol Lee (GOTROOT). F5'in geçici önerisi proxy_request_buffering değerini off yapmak.

4. CVE-2026-97629 - TLS oturum bileti anahtar rotasyonu
ssl_session_cache shared kullanılıp ssl_session_ticket_key tanımlanmadığında ortaya çıkan bir mantık hatası. Etkilenen sürümler 1.23.2 - 1.31.6. Kaynaklara göre bu hata, deterministik olmayan şekilde istemci sertifikası kontrolünün atlanmasına yol açabiliyor; mTLS ile korunan uç noktalar için ciddi bir durum. Bulan: PhiNode Labs.

5. CVE-2026-97205 - AIO + SSI use-after-free
aio etkinken SSI include virtual kullanımında, 256'da sıfıra dönen 8 bitlik bir sayaç nedeniyle use-after-free oluşuyor. Etkilenen sürümler 0.8.11 - 1.31.6.



Puanlama Farkı: "Orta" mı, "Kritik" mi?

İlginç bir ayrıntı: NGINX projesi beş düzeltmenin hepsini "orta" (medium) önem derecesiyle işaretlemiş. F5'in CVSS v4 puanları ise farklı bir tablo çiziyor: bellek bozulması türündeki açıklar 9.2, TLS açığı 8.3, HTTP/3 açığı 6.9.

SecurityWeek'in haberine göre F5 toplamda 11 NGINX sorununu düzeltti ve CVE-2026-15176, CVE-2026-93479 ile CVE-2026-97205'i kritik olarak sınıflandırdı. Bu üç açığın, ASLR devre dışıysa ya da atlatılabilirse uzaktan kod çalıştırmaya imkân verebileceği belirtiliyor. Aradaki fark büyük ölçüde şu: NGINX, açığın tetiklenmesi için gereken özel yapılandırmayı hesaba katarak "orta" diyor; F5'in puanı ise koşullar sağlandığında ortaya çıkan etkiyi yansıtıyor.

İyi haber: Beş açığın hiçbiri CISA KEV kataloğunda değil ve aktif sömürü raporu yok. Kötü haber: The Hacker News, VulnCheck'e dayanarak mayıstaki CVE-2026-42945'in yayımlanmasından birkaç gün sonra sömürülmeye başlandığını hatırlatıyor. Bu, NGINX'in 2026'daki sekizinci güvenlik sürümü; araştırmacıların bu koda yoğun ilgi gösterdiği açık.

Aynı dönemde njs 1.0.2 sürümü de CVE-2026-101025 ve CVE-2026-101019'u düzeltti; njs modülünü kullananlar onu da güncellemeli.

Yapılandırmanız Etkileniyor mu?

Önce sürümünüze bakın:

Sonra çalışan yapılandırmanın tamamını (include edilen dosyalar dahil) döküp riskli direktifleri arayın:





Bu aramalar size sadece incelemeniz gereken satırları gösterir; bir direktifin var olması tek başına zafiyetli olduğunuz anlamına gelmez. Örneğin ilk açık için alias, rewrite ve $request_filename'in aynı location bağlamında birlikte kullanılması gerekiyor.

Dağıtım paketlerini kullananlar için:
Dağıtımlar düzeltmeleri genellikle kendi sürüm numaralarına geri taşıdığı (backport) için paket sürümünü dağıtımın güvenlik bildirimiyle karşılaştırın.

Juniper'ın Ekim Paketi

SecurityWeek'e göre Juniper Networks, Junos OS ve Junos OS Evolved'da 150'den fazla açığı kapatan 17 güvenlik bildirimi yayımladı; buna Juniper Cloud-Native Router'daki (JCNR) dört hata da ekleniyor. Bunlardan yaklaşık iki düzinesi kritik olarak derecelendirilmiş ve root yetkisiyle kod çalıştırma ya da cihazın tamamen ele geçirilmesi gibi sonuçlara yol açabiliyor. Juniper'ın bu açıkların sömürüldüğüne dair bir bilgisi yok.

Not: Juniper bildirimlerini tek tek açıp her CVE'yi doğrulamadım; buradaki sayılar SecurityWeek'in özetine dayanıyor. Juniper cihazı yönetenlerin kendi model ve sürümleri için Juniper Support Portal'daki bildirimleri doğrudan kontrol etmesini öneririm.



Junos sürümünü kontrol etmek için:

Yama ve Geçici Önlemler

NGINX Open Source:

• Stable dalındaysanız 1.30.6'ya, mainline dalındaysanız 1.31.7'ye yükseltin.
  
• Yükseltme sonrası yapılandırmayı test edip yeniden yükleyin:
  

Hemen yükseltemiyorsanız (geçici):

• HTTP/3 kullanıyorsanız F5'in önerdiği gibi proxy_request_buffering off değerini değerlendirin ya da HTTP/3'ü geçici olarak kapatın.
  
• mTLS kullanan sunucularda ssl_session_ticket_key ile açık bir bilet anahtarı tanımlamak veya oturum biletlerini kapatmak (ssl_session_tickets off) TLS açığının tetiklenme koşulunu ortadan kaldırır. Bu öneriyi açığın tanımladığı koşuldan çıkarıyorum; uygulamadan önce F5 bildirimini kontrol edin.
  
• SSI kullanmıyorsanız kapalı olduğundan emin olun.
  

NGINX Plus ve F5 ürünleri: The Hacker News'e göre NGINX Plus ve NGINX içeren diğer F5 ürünlerinin kullanıcıları F5 bildirimlerine bakmalı; bazı ürünler için 15 Ekim itibarıyla henüz düzeltilmiş sürüm yoktu.

Juniper: Kendi platformunuz için ilgili bildirimdeki düzeltilmiş Junos sürümüne geçin, yönetim arayüzlerine erişimi güvenilir ağlarla sınırlayın.

Sizin ortamınızda HTTP/3 veya SSI kullanan NGINX var mı? Yoksa çoğunuz sade reverse proxy olarak mı kullanıyorsunuz? Yorumlarda kontrol sonuçlarınızı paylaşabilirsiniz.

Kaynaklar

• nginx.org - Security Advisories: https://nginx.org/en/security_advisories.html
  
• nginx.org - CHANGES: https://nginx.org/en/CHANGES
  
• The Hacker News - NGINX Fixes 5 Flaws: https://thehackernews.com/2026/10/nginx-...sible.html
  
• SecurityWeek - F5, Juniper Networks Patch Critical Vulnerabilities: https://www.securityweek.com/f5-juniper-...abilities/
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

[center][/center]

Selam millet, BlueTornado yazıyor.

Modern uygulamaların yüzeyi çoğu zaman HTML formlarından çok JSON API'lerdir. OWASP API Security Top 10, bu yüzeyi hedefleyen riskleri listeler. Bu rehberde 2023 sürümüne odaklanarak özellikle BOLA ve BFLA'yı, labda test yaklaşımını ve savunma kontrollerini anlatıyoruz. İcat istatistik veya uydurma CVE yok; resmi OWASP dokümanına bağlı kalıyoruz.

Konuda Anlatılacaklar

1. API güvenliği neden ayrı ele alınır?
   
2. OWASP API Top 10 2023 özeti
   
3. BOLA (object) ve BFLA (function) derinlemesine
   
4. Lab: basit API ile A/B hesap testi
   
5. Korunma: authn/authz, rate limit, şema
   
6. İleri seviye: GraphQL, mass assignment, envanter
   
7. Kaynakça ve yasal uyarı
   

1) API Güvenliği Nedir?
API'ler makine-okur, otomasyona açıktır, mobil/SPA/partner entegrasyonlarını besler. UI'da gizlenen bir düğme API'de hâlâ duruyor olabilir. Kimlik doğrulama (authentication) ile yetkilendirme (authorization) karıştırılmamalıdır: "Token var" yetki demek değildir.

2) OWASP API Top 10 2023 Özeti
Resmi liste (kısa Türkçe karşılıklarıyla):

• API1:2023 Broken Object Level Authorization (BOLA)
  
• API2:2023 Broken Authentication
  
• API3:2023 Broken Object Property Level Authorization
  
• API4:2023 Unrestricted Resource Consumption
  
• API5:2023 Broken Function Level Authorization (BFLA)
  
• API6:2023 Unrestricted Access to Sensitive Business Flows
  
• API7:2023 Server Side Request Forgery
  
• API8:2023 Security Misconfiguration
  
• API9:2023 Improper Inventory Management
  
• API10:2023 Unsafe Consumption of APIs
  

Detay için OWASP API Security Project sayfasına bakın. Sürüm yılını raporlarınızda belirtin.

[center][/center]

3) BOLA Nedir?
Broken Object Level Authorization, web'deki IDOR'un API dilindeki adıdır. Kullanıcı, erişmemesi gereken nesneye kimlik (id) ile ulaşır.



4) BFLA Nedir?
Broken Function Level Authorization, işlev düzeyinde yetki eksikliğidir. Özellikle admin uçlarının gizlenerek "güvende" sanılması.



BOLA nesne sahipliğine, BFLA ise role/işleve bakar; ikisi birlikte test edilmelidir.

5) Lab: Mini API Testi
Kendi bilgisayarınızda iki kullanıcı oluşturabileceğiniz bir lab API'si kullanın (Juice Shop API, crAPI, veya kendi Flask iskeletiniz).



[center][/center]

6) Kavram Referansı ve Korunma

Object property level (API3): Kullanıcı nesneyi görebilir ama , alanlarını okuyamamalı / yazamamalıdır (mass assignment ile bağlantılı).


Resource consumption (API4): Rate limit, pagination tavanı, max page size, maliyetli aramalar için kota.


Inventory (API9): Eski unutulmuş, shadow API, document edilmemiş debug uçları. OpenAPI envanteri tutun; gateway'de yalnızca bilinen route'ları açın.


Authn (API2): Credential stuffing'e karşı rate limit + MFA; JWT için bir önceki konudaki kurallar.

7) Uygulamalı Kontrol Listesi

• Her endpoint için: kim çağırabilir, hangi nesneler?
  
• A/B hesap otomasyon testi CI'da
  
• Admin prefix'leri ayrı authz middleware
  
• Response'ta fazla alan sızıntısı var mı?
  
• Rate limit ve payload size limit
  
• WAF/gateway + uygulama içi kontrol (defense in depth)
  
• Log: authz deny olayları
  

[center][/center]

8) İleri Seviye
GraphQL: Tek endpoint; field-level authz, query depth/cost limit, introspection'ı production'da kapatma.

BFLA keşfi: OpenAPI / JS bundle içinde , , string araması (kendi uygulamanız).

Unsafe consumption (API10): Üçüncü parti API yanıtına güvenerek komut/SQL birleştirmeyin; şema doğrulayın.


9) Sonuç
API güvenliği, UI güvenlik varsayımlarını taşımaz. BOLA ve BFLA en sık atlanan yetki hatalarıdır; rate limit, şema ve envanter ile tamamlayın. OWASP API Top 10'u ekip içinde ortak dil yapın.



Ek: Partner API ve Versiyonlama Notları
Dışarıya açılan partner API'lerinde ek olarak:

• İstemci kimliği başına ayrı kimlik bilgisi ve scope
  
• IP allowlist (mümkünse) + mTLS (yüksek güvenlikli B2B)
  
• Değişiklik yönetimi: breaking change için yeni versiyon
  
• Eski versiyonun kapatılma tarihi (inventory ile bağlantılı)
  

[center][/center]

API Top 10 maddelerini sprint Definition of Done listesine tek satırlık kontroller olarak eklemek, "sonra bakarız" riskini azaltır.

Kaynakça

• OWASP API Security Top 10 2023
  
• API1 BOLA
  
• API5 BFLA
  
• OWASP REST Security Cheat Sheet
  
• CWE-285 Improper Authorization
  

Yasal Uyarı
API testleri yalnızca kendi sistemleriniz veya yazılı pentest yetkisi kapsamında yapılmalıdır. İzinsiz API tarama ve veri erişimi TCK 243-245 kapsamında suç olabilir. Eğitim amaçlıdır.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Merhaba TurkTeam,

Bir Linux sistemde "kim, ne zaman, hangi dosyaya dokundu veya hangi komutu çalıştırdı?" sorusunun kesin cevabını veren bileşen auditd'dir. Linux Audit alt sistemi, çekirdek düzeyinde olayları yakalayıp standart bir denetim kaydına yazar; bu da hem güvenlik izleme (mavi takım) hem de uyumluluk (PCI-DSS, CIS) için paha biçilmezdir. Bu rehberde auditd'yi kurulumdan kural yazımına ve log incelemeye kadar uygulamalı ele alıyoruz.

Konuda Anlatılacaklar

1. Linux Audit alt sistemi nedir, syslog'dan farkı
   
2. Kurulum ve servis yönetimi
   
3. Dosya izleme (watch) ve syscall kuralları
   
4. auditctl, ausearch ve aureport referansı
   
5. Uygulamalı: hassas dosya ve komut denetimi
   
6. Kalıcı kurallar ve ileri ipuçları
   
7. Sonuç, kaynakça ve yasal uyarı
   

1. Linux Audit Alt Sistemi Nedir?
Linux Audit, çekirdekteki olayları (dosya erişimleri, sistem çağrıları, kullanıcı oturumları, yetki değişiklikleri) yakalayan bir denetim çerçevesidir. Kullanıcı uzayındaki auditd servisi bu olayları toplayıp genelde /var/log/audit/audit.log dosyasına yazar. Sıradan syslog'dan farkı, çekirdek düzeyinde ve değiştirilmesi zor, ince ayarlı bir denetim izi sunmasıdır: Örneğin "bu dosya her değiştirildiğinde kaydet" veya "her execve sistem çağrısını kaydet" gibi kurallar yazabilirsiniz. Bu, bir olay sonrası adli incelemenin ve gerçek zamanlı tespitin temelini oluşturur.

2. Kurulum ve Servis Yönetimi
Çalışan kuralları ve durumu görmek için:

3. Dosya İzleme ve Syscall Kuralları
auditd iki temel kural türü kullanır: watch (dosya/dizin izleme) ve syscall (sistem çağrısı izleme).

Dosya izleme (-w): -p ile izin türleri (r okuma, w yazma, x çalıştırma, a öznitelik), -k ile arama anahtarı:
Bu kural, /etc/passwd her yazıldığında veya özniteliği değiştiğinde bir kayıt üretir ve "passwd_degisiklik" anahtarıyla etiketler.

Syscall kuralı (-a): mimari (-F arch), çağrı (-S) ve koşullarla:
Bu kural, 64-bit sistemde çalıştırılan her komutu (execve) kaydeder. "always,exit" çağrı tamamlandığında her zaman kaydet anlamına gelir.

Belirli kullanıcıyı hedefleme (-F auid):

4. auditctl, ausearch ve aureport Referansı
auditctl - kuralları canlı yönetir (yeniden başlatınca kaybolur, kalıcı için bkz. 6. bölüm):

ausearch - denetim kayıtlarında arama (anahtara, kullanıcıya, zamana göre):

aureport - özet raporlar:

5. Uygulamalı: Hassas Dosya ve Komut Denetimi
Adım 1 - /etc/shadow izleme kuralı ekleyin:

Adım 2 - Dosyaya dokunarak olay üretin (lab):

Adım 3 - İlgili kaydı arayın:
Dönen kayıt şuna benzer alanlar içerir; type=SYSCALL satırında syscall, başarı durumu (success=yes), komut (comm="touch"), çalıştıran kullanıcı (auid) ve anahtar (key="shadow_izleme") yer alır:
Bu çıktı, hangi kullanıcının hangi komutla dosyaya dokunduğunu net biçimde gösterir.

Adım 4 - Komut çalıştırma denetimi ve özet rapor:
aureport -x çalıştırılabilir dosya (executable) bazında özet verir; anormal bir ikili (örn. beklenmedik bir yoldan çalışan kabuk) hemen göze çarpar.



6. Kalıcı Kurallar ve İleri İpuçları
auditctl ile eklenen kurallar yeniden başlatmada kaybolur. Kalıcılık için kuralları /etc/audit/rules.d/ altında bir .rules dosyasına yazın:
Ardından kuralları derleyip yükleyin:

• Hazır kural setleri: CIS ve STIG uyumlu örnek kurallar için topluluk kural dosyalarını (ör. Neo23x0/auditd) başlangıç olarak inceleyebilirsiniz.
  
• Değişmezlik: rules dosyasının sonuna "-e 2" eklemek, kural setini sonraki yeniden başlatmaya kadar kilitler; saldırganın denetimi kapatmasını zorlaştırır.
  
• Performans: Her execve'yi kaydetmek yoğun sistemlerde çok log üretir; kapsamı anahtar dosyalar ve kritik çağrılarla sınırlayın.
  
• Merkezileştirme: audispd eklentileriyle kayıtları bir SIEM'e iletebilirsiniz; yerelde kalan log, saldırgan tarafından silinebilir.
  

6.1. auditd ve Olay İzlemeyi Birlikte Düşünmek
auditd tek başına bir "tespit" aracı değildir; o, güvenilir bir ham kayıt üretir. Asıl değer, bu kayıtların düzenli olarak incelenmesi ve bir uyarı mekanizmasına bağlanmasıyla ortaya çıkar. Pratikte çoğu kurum auditd kayıtlarını audispd eklentileri aracılığıyla merkezi bir toplama noktasına (SIEM) iletir; çünkü yerelde kalan bir log, makineyi ele geçiren bir saldırgan tarafından silinebilir veya değiştirilebilir. Kayıtları ulaşıldığı anda ağ üzerinden dışarı taşımak, delil bütünlüğünü korumanın en sağlam yoludur.

Kural tasarlarken "her şeyi kaydet" tuzağına düşmeyin. Çekirdek düzeyinde her sistem çağrısını yakalamak teknik olarak mümkündür, ama yoğun bir sunucuda bu, dakikalar içinde gigabaytlarca log ve ciddi bir performans maliyeti anlamına gelir. Bunun yerine tehdit modelinize odaklanın: hassas yapılandırma dosyaları (/etc/passwd, /etc/shadow, /etc/sudoers), yetki yükseltme ile ilişkili ikililer, kimlik doğrulama olayları ve kritik dizinlerdeki değişiklikler. Az ama anlamlı kurallar, çok ama gürültülü kurallardan her zaman daha kullanışlıdır.

Son olarak, auditd kayıtlarını okumayı öğrenmek bir beceridir. type=SYSCALL, type=PATH ve type=EXECVE gibi farklı kayıt tipleri aynı olayın farklı yönlerini anlatır; ausearch bunları olay kimliğiyle gruplar. Bir kaydı incelerken auid (asıl oturum açan kullanıcı) ile uid (etkin kullanıcı) ayrımına özellikle dikkat edin: bir saldırgan sudo ile yetki yükseltse bile auid, gerçekte kimin oturum açtığını ele verir. Bu küçük detay, adli incelemede failin kim olduğunu belirlemenin anahtarıdır.

Sonuç
auditd, Linux'ta denetim izinin altın standardıdır: ince ayarlı kurallarla kimin neyi ne zaman yaptığını güvenilir biçimde kaydeder. watch ve syscall kurallarını, ausearch/aureport ile inceleme alışkanlığını ve kalıcı kural yönetimini oturttuğunuzda, hem tespit hem de adli inceleme kapasiteniz ciddi biçimde artar. Kuralları kritik varlıklara odaklayın ve mümkünse kayıtları merkezi bir sisteme iletin.

Kaynakça

• Linux Audit Projesi (resmi) - https://github.com/linux-audit/audit-documentation
  
• auditctl(8) Man Sayfası - https://man7.org/linux/man-pages/man8/auditctl.8.html
  
• ausearch(8) ve aureport(8) man sayfaları - https://man7.org/linux/man-pages/man8/ausearch.8.html
  
• Red Hat: Linux Audit Sistemi - https://access.redhat.com/documentation
  
• CIS Benchmarks - https://www.cisecurity.org/cis-benchmarks
  

Yasal Uyarı

Alıntı:Denetim yapılandırması yalnızca kendi sistemlerinizde veya yönetim yetkiniz olan sistemlerde uygulanmalıdır. Başkasının sistemine izinsiz müdahale Türk Ceza Kanunu 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Selam arkadaşlar,

Kendi bulutunu kendisi barındıranların gözdesi Nextcloud tarafında can sıkıcı bir durum var. "Collabora Online - Built-in CODE Server" uygulamasındaki (paket adı richdocumentscode) bir komut enjeksiyonu açığı eylül ortasından beri aktif olarak sömürülüyor. Açığa resmi CVE numarası ancak 14 Ekim'de verildi: CVE-2026-110447. Yani saldırganlar yaklaşık bir ay boyunca, çoğu yöneticinin elinde aranabilir bir CVE bile yokken bu açığı kullandı.

Konuda Anlatılacaklar

1. Açık nedir ve kimleri etkiliyor?
   
2. Sahada neler görüldü?
   
3. Yama ile CVE arasındaki bir aylık boşluk
   
4. Sunucunuzu nasıl kontrol edersiniz?
   
5. Temizlik ve sıkılaştırma önerileri
   
6. Kaynaklar
   

Açık Nedir?

CVE kaydındaki tanım kısa ve net: Nextcloud uygulaması olan Collabora Online Built-in CODE Server'ın 26.4.303 öncesi sürümleri, proxy.php dosyasında bir işletim sistemi komut enjeksiyonu içeriyor. Kayıtta açığın Eylül ve Ekim 2026'da vahşi doğada sömürüldüğü de açıkça yazıyor. Zafiyet türü CWE-78, CVSS v4.0 puanı 9.2 (Kritik).

Önemli bir ön koşul var: istismar, gömülü CODE sunucusu çalışmıyorken mümkün oluyor. Bu da yeniden başlatma, güncelleme ya da çökme sonrası gibi durumlar demek. Kimlik doğrulama veya kullanıcı etkileşimi gerekmiyor. Nextcloud forumundaki ilk uyarıyı yazan kullanıcının ifadesiyle sorun Collabora'nın kendisinde değil, gömülü uygulamanın Collabora'yı başlatma biçiminde (PHP exec çağrısı).

Etkilenenler:

• richdocumentscode 26.4.302 ve öncesini kullanan Nextcloud kurulumları
  

Etkilenmeyenler:

• richdocumentscode kurulu olmadan sadece richdocuments kullananlar
  
• Collabora'yı Docker veya Linux dağıtım paketiyle (DEB/RPM) çalıştıranlar
  
• Ayrı kurulmuş, bağımsız Collabora Online sunucuları
  
• Barındırılan Collabora hizmetleri kullananlar
  

BleepingComputer'ın Collabora'ya dayanarak aktardığına göre Nextcloud All-in-One kurulumları da etkilenmiyor.



Sahada Neler Görüldü?

BleepingComputer'ın aktardığı yönetici raporlarına göre saldırılar en az 10 Eylül'e kadar uzanıyor. Saldırganlar proxy.php'ye zararlı istek göndererek komut çalıştırıyor, ardından PHP web shell'leri bırakıyor ve bu shell'ler üzerinden parola veritabanları, parola yöneticisi kalıntıları ve kripto para cüzdanları arıyor. Bazı kullanıcılar fidye yazılımı operatörlerinin de açığı kullandığını iddia etmiş; BleepingComputer bunu bağımsız olarak doğrulayamadığını belirtiyor, ben de doğrulanmış bilgi gibi sunmuyorum.

İtalya'nın ulusal CSIRT'ünün bülteni (CSIRT Toscana tarafından yeniden yayımlandı) ülke içinde yaşanan bir vakayı anlatıyor: Saldırgan web sunucusu kullanıcısının yetkileriyle komut çalıştırmış, üç web shell kurmuş ve yerel bir veritabanına, servis e-posta kutusuna ait kimlik bilgileri ile uygulama anahtarlarını içeren bir yapılandırma dosyasını almış. Bültene göre bulgular, birden fazla aktör tarafından yürütülen ve hâlâ devam eden otomatik bir sömürü kampanyasıyla uyumlu.

Nextcloud forumunda 16 Ekim'de paylaşılan bir başka vakada ise Nextcloud'un bütünlük kontrolü, richdocumentscode dizininde Nx_33143.php adlı fazladan bir dosya yakalamış. Kullanıcının aktardığına göre dosya, GET parametresiyle gelen komutu çalıştıran tek satırlık basit bir arka kapı. Aynı başlıkta daha önceki raporlarda shx* ve shrf* ile başlayan dosya adlarından bahsedildiği de geçiyor; bu isimler forum kullanıcılarının paylaşımı, resmi bir IOC listesi değil.

Bir Aylık Boşluk: Yama Var, CVE Yok

Bu olayı ayrıca ilginç kılan şey zaman çizelgesi. BleepingComputer'ın derlediği tarihler:

• 9 Eylül: Düzeltme commit'lendi.
  
• 10 Eylül: Yöneticilerin raporladığı en erken saldırı izleri.
  
• 11 Eylül: richdocumentscode 26.4.303 yayımlandı.
  
• 3 Ekim: Nextcloud forumunda "hemen güncelleyin" uyarısı paylaşıldı.
  
• 14 Ekim: Güvenlik bildirimi, GitHub advisory ve CVE yayımlandı.
  

Nextcloud, gecikmeyi kullanıcılara güncelleme için zaman tanımakla ve yaygın sömürü görmemiş olmakla açıklamış. Collabora ise gecikmeyi büyük ölçüde GitHub'ın CVE işleme kuyruğundaki yoğunluğa, onu da artan yapay zeka kaynaklı güvenlik raporu hacmine bağlamış. BleepingComputer'ın aktardığı Second Security çalışması da bu tabloyu destekliyor: açık kaynak projelerde yamanın yayımlanmasıyla CVE'nin yayımlanması arasındaki medyan süre ocakta 5,1 gün iken ağustosta 39 güne çıkmış.

Bence buradan çıkarılacak ders şu: "CVE çıkınca bakarım" yaklaşımı artık yetmiyor. Kendi barındırdığınız uygulamaların sürüm notlarını ve topluluk forumlarını takip etmek, en az CVE beslemesi kadar önemli hale geldi.

Sunucunuzu Nasıl Kontrol Edersiniz?

Önce uygulamanın kurulu olup olmadığına ve sürümüne bakın (Nextcloud dizininde, web sunucusu kullanıcısıyla):

Nextcloud'un yerleşik bütünlük kontrolü, forumdaki vakada olduğu gibi fazladan dosyaları yakalayabiliyor:

Uygulama dizininde sizin kurmadığınız PHP dosyalarını listelemek için basit bir arama:
(Yolu kendi kurulumunuza göre değiştirin. Bu komut kesin sonuç vermez, sadece incelenecek adayları çıkarır.)

Web sunucusu ve ters proxy loglarında proxy.php isteklerini 10 Eylül'den bu yana gözden geçirin:

İtalyan CSIRT'ü de aynı yönde öneride bulunuyor: Nextcloud çekirdeğinin ve uygulamaların bütünlüğünü doğrulayın, yetkisiz dosya ve olası web shell'leri arayın, sonuçları web sunucusu, ters proxy ve güvenlik çözümlerinin loglarıyla ilişkilendirin.



Temizlik ve Sıkılaştırma

1. Güncelleyin ya da kaldırın. richdocumentscode'u 26.4.303 veya üstüne yükseltin. Kullanmıyorsanız tamamen kaldırın. Hem Collabora hem İtalyan CSIRT'ü uyarıyor: uygulamayı sadece devre dışı bırakmak yeterli değil.

2. Yama, temizlik değildir. Güncelleme açığı kapatır ama önceden bırakılmış bir web shell'i silmez. Zafiyetli sürümü çalıştırdığınız dönemde CODE sunucusu herhangi bir nedenle durduysa, iz aramadan "tamam" demeyin.

3. Bulgu varsa olay müdahalesi yapın. CSIRT'ün önerisi: etkilenen sistemi izole edin, temizlikten önce delilleri alıp saklayın, kontrolleri diğer instance'lara ve açığa çıkan kimlik bilgileriyle erişilebilen kaynaklara genişletin. Gerekirse sistemi güvenilir kaynaklardan yeniden kurun ve sadece doğrulanmış veriyi geri yükleyin.

4. Sırları döndürün. Web sunucusu kullanıcısının okuyabildiği her şeyi (veritabanı parolası, servis hesapları, uygulama anahtarları, e-posta hesapları) açığa çıkmış kabul edip güvenilir bir ortamdan değiştirin.

5. Desteklenmeyen Nextcloud sürümleri. CSIRT'e göre desteği bitmiş Nextcloud kurulumlarında ya platformu düzeltilmiş bileşenle uyumlu desteklenen bir sürüme yükseltin ya da richdocumentscode'u kaldırın.

Genel sıkılaştırma tarafında da en asgari maddeler: yönetim erişimini VPN arkasına almak, web sunucusu kullanıcısının yapılandırma dosyalarına erişimini kısıtlamak, logları merkezi bir yerde toplamak ve uygulama dosyalarında bütünlük izlemesi kurmak.

Ev labında ya da küçük ofiste Nextcloud çalıştıran çok arkadaşımız var. Gömülü CODE kullanıyor musunuz, yoksa Collabora'yı ayrı container'da mı çalıştırıyorsunuz? Bu olaydan sonra tercihiniz değişti mi, yorumlarda konuşalım.

Kaynaklar

• CVE.org - CVE-2026-110447: https://www.cve.org/CVERecord?id=CVE-2026-110447
  
• GitHub Advisory Database - GHSA-f97p-r72q-64h2: https://github.com/advisories/GHSA-f97p-r72q-64h2
  
• BleepingComputer - Hackers exploit Collabora RCE flaw to backdoor Nextcloud servers: https://www.bleepingcomputer.com/news/se...d-servers/
  
• Nextcloud Community - To Collabora Built-in User: Update ASAP: https://help.nextcloud.com/t/to-collabor...sap/250516
  
• CSIRT Toscana (CSIRT-ITA BL02/261016): https://csirt.regione.toscana.it/nextclo...csirt-ita/
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

[center][/center]

Selam TurkTeam, BlueTornado burada.

JWT (JSON Web Token), iddia (claim) taşımak için yaygın bir formattır; "otomatik olarak güvenli oturum çözümü" değildir. Yanlış kullanıldığında alg:none, zayıf imza, uzun ömürlü token, secret sızıntısı gibi hatalar ortaya çıkar. Bu rehberde JWT yapısı, klasik oturum çerezi ile farkı, yaygın hatalar ve savunmacı doğru kullanım anlatılır.

Konuda Anlatılacaklar

1. JWT nedir, ne işe yarar?
   
2. Oturum çerezi ile karşılaştırma
   
3. Lab: token üretme ve inceleme
   
4. Yaygın hatalar (alg, secret, saklama)
   
5. Doğru kullanım: imza, süre, yenileme, iptal
   
6. İleri seviye: JWE, key rotation, browser saklama
   
7. Kaynakça ve yasal uyarı
   

1) JWT Nedir?
JWT genellikle üç Base64URL parçasından oluşur: header.payload.signature

• Header: algoritma ve tip
  
• Payload: claim'ler (sub, exp, iss, aud, özel alanlar)
  
• Signature: bütünlük; gizli anahtar veya özel anahtar ile
  

Payload varsayılan olarak şifreli değildir; Base64 decode herkes yapar. Gizlilik için TLS şarttır; ek gizlilik gerekirse JWE düşünülür.

Alıntı:JWT'yi "encrypt" sanmak yaygın hatadır. İmza bütünlük sağlar; içeriği gizlemez.

2) Klasik Oturum ile Fark

• Sunucu oturumu: Çerezde rastgele session id; veri sunucuda. İptal kolay (store'dan sil).
  
• Stateless JWT: Veri token içinde; ölçeklenmesi kolay, iptal zor (blacklist/ kısa ömür gerekir).
  

İkisi de doğru tasarlanırsa güvenli olabilir. Çoğu web uygulaması için HttpOnly Secure SameSite çerez + sunucu oturumu hâlâ sağlam bir seçimdir. JWT özellikle API'ler, mikroservisler ve mobil istemcilerde tercih edilir.

3) Lab: Token İnceleme


[center][/center]

4) Yaygın Hatalar

alg:none veya algoritma karışıklığı:
Eski kütüphane hatalarında saldırgan 'ı none veya HS256'ya çevirip RSA public key ile imza atlatmayı denemişti. Güncel kütüphane + sabit algorithms kullanın.

Zayıf / sızmış secret:

exp yok veya çok uzun: Yıllarca geçerli access token çalınırsa uzun süre geçerlidir.

Hassas veri payload'da: TCKN, parola hash'i, kart numarası koymayın.

localStorage'da access token: XSS ile çalınır. Mümkünse Secure HttpOnly çerez; XSS'i de kapatın.

Imza doğrulamadan claim okumak:

[center][/center]

5) Doğru Kullanım Pratikleri

• Access token kısa ömürlü (dakikalar); refresh token uzun, sıkı saklı, rotate edilebilir
  
• Kod:

  iss
  ,
  Kod:

  aud
  ,
  Kod:

  exp
  ,
  Kod:

  nbf
  doğrulayın
  
• HS256 için güçlü secret; asimetrik için RS256/ES256 ve JWKS
  
• Rol/yetki değişince eski token'lara güvenmeyin (kısa TTL veya sürüm claim'i)
  
• Logout: refresh iptali + çerez silme; saf stateless'ta kısa TTL şart
  
• TLS zorunlu; token'ı URL query'de taşımayın (loglara düşer)
  

6) Oturum Çerezi Sertleştirme (JWT kullanmasanız bile)

• Session fixation: login sonrası id yenile
  
• Idle / absolute timeout
  
• Concurrent session politikası (isteğe bağlı)
  

7) İleri Seviye
JWKS ve key rotation: header ile anahtar seçimi; eski kid kısa süre doğrulanmaya devam edebilir.


JWE: Token içeriğini şifrelemek gerektiğinde. Karmaşıklık artar; çoğu API için TLS + minimal claim yeterlidir.

Service-to-service: Kullanıcı JWT'sini körü körüne iletmeyin; audience daraltın, impersonation claim'lerini dikkatli tasarlayın.


[center][/center]

8) Sonuç
JWT güçlü bir formattır; güvenlik tasarımında detaylarda gizlidir. İmza algoritmasını sabitleyin, süreyi kısa tutun, saklamayı XSS'e karşı düşünün, claim'leri doğrulayın. Gerekmiyorsa sunucu oturumu ile de ilerleyebilirsiniz.



Ek: Tarayıcı Saklama Karar Ağacı

• Birinci taraf web uygulaması: mümkünse sunucu oturumu veya refresh'i HttpOnly çerezde tutun
  
• Access token bellekte (memory) kısa ömürlü tutulabilir; sayfa yenilenince refresh ile yenilenir
  
• localStorage/sessionStorage: XSS yüzeyi geniş; yalnızca risk kabulü ile
  
• Mobil uygulama: OS güvenli depolama (Keychain / Keystore)
  

Test kontrol listesi:

[center][/center]

Kaynakça

• RFC 7519 - JWT
  
• OWASP JWT Cheat Sheet
  
• OWASP Session Management Cheat Sheet
  
• JWT BCP tartışmaları / best practices (Auth0 özeti, RFC 8725 ile birlikte okuyun)
  
• RFC 8725 - JWT Best Current Practices
  
• PyJWT Documentation
  

Yasal Uyarı
Token üretme/kırma denemeleri yalnızca kendi labınızda veya yazılı yetki ile yapılmalıdır. Başkalarının oturum token'larını ele geçirmek veya kullanmak TCK 243-245 kapsamında suç olabilir. Eğitim amaçlıdır.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Selam arkadaşlar,

E-ticaret tarafında çalışan, müşterisinin mağazasını yöneten ya da kendi Magento kurulumunu ayakta tutan herkesin bu hafta takvimini boşaltması gereken bir haber var. Adobe, 13 Ekim'de yayımladığı APSB26-153 bülteniyle Magento Open Source ve Adobe Commerce'te CVSS 10.0 puanlı bir açığı kapattı. Sansec ekibi açığa BlockStrap adını verdi ve yamanın yayımlanmasından sonraki 24 saat içinde dört ayrı kod çalıştırma yolunu yeniden üretebildiklerini söylüyor. Henüz canlı mağazalarda sömürü görülmedi ama Sansec'in tahmini net: uzun sürmez.

Konuda Anlatılacaklar

1. BlockStrap nedir, neden bu kadar ciddi?
   
2. Etkilenen ürün ve sürümler
   
3. StyleSmuggler bağlantısı ve "iki ayrı yama" meselesi
   
4. Adobe'nin "öncelik 2" derecelendirmesi neden tartışılıyor?
   
5. Yamanın gerçekten uygulandığını nasıl doğrularsınız?
   
6. Open Source 2.4.6 ve Mage-OS kullananlar için notlar
   
7. Kaynaklar
   

BlockStrap Nedir?

Adobe bültenindeki teknik tanım şöyle: "Şablon motorunda kullanılan özel öğelerin hatalı nötralize edilmesi" (CWE-1336). Etkisi keyfi kod çalıştırma, kimlik doğrulama gerektirmiyor, CVSS vektörü AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Yani internetten erişilebilen, oturum açmayı gerektirmeyen ve sunucunun tamamen ele geçirilmesine kadar giden bir senaryo.

Sansec'in açıklamasına göre BlockStrap, Magento'nun e-posta şablon motorunda ikinci geçişte gerçekleşen bir direktif enjeksiyonu. Kabaca anlatmak gerekirse: Eylül ayındaki düzeltme güvenilir direktifleri imzalıyordu; ancak saldırganın kontrol ettiği veri bir alt şablonun içinde yer aldığında bu veri de imzalanıp kök seviyede yeniden taranabiliyor. Bu sırada içeri kaçırılan bir {{block}} direktifi Magento'nun render sürecinde çalışıyor. Sonuç, mağaza sunucusunda saldırganın istediği PHP kodunun çalışması.

Adobe'nin ekim yaması bu genel yeniden tarama mantığını kaldırıp yerine kayıtlı yer tutucular (registered placeholders) koyuyor. Mantıklı bir çözüm; sorunun kökü zaten "aynı içeriği ikinci kez yorumlamak".



Etkilenen Sürümler

Adobe bülteninde listelenen etkilenen sürümler (hepsi "2026-sep ve öncesi" seviyesinde):

• Adobe Commerce: 2.4.9, 2.4.8, 2.4.7, 2.4.6, 2.4.5, 2.4.4
  
• Adobe Commerce B2B: 1.5.3, 1.5.2, 1.4.2, 1.3.4, 1.3.3
  
• Magento Open Source: 2.4.9, 2.4.8, 2.4.7, 2.4.6
  

Düzeltilmiş sürümler 2.4.10-alpha1 ve her dal için "2026-oct" seviyesindeki güncellemeler; B2B için 1.5.4-alpha1 ve ilgili 2026-oct paketleri.

Aynı bültende başka kritik açıklar da var. Örneğin B2B modülünü etkileyen ve CVSS 9.8 alan CVE-2026-92909 (hatalı yetkilendirme, kimlik doğrulamasız kod çalıştırma) ile CVSS 9.3 alan iki stored XSS açığı (CVE-2026-91013 ve CVE-2026-100133). Kısacası bu bülten "sadece BlockStrap" diye geçiştirilecek bir güncelleme değil.

StyleSmuggler Bağlantısı: İki Ayrı Yama Gerekiyor

Konunun en çok gözden kaçacak kısmı burası. Eylül ayında Adobe, aynı e-posta şablon motorundaki StyleSmuggler açığı (CVE-2026-75650) için VULN-39341 numaralı bir hotfix yayımlamıştı. Sansec'e göre BlockStrap, o düzeltmenin bıraktığı boşluktan yararlanıyor.

Adobe bülteninde açıkça şu yazıyor: CVE-2026-75650 hotfix'i, bu bültendeki güncellemelere ek olarak uygulanmalı. Sansec de aynı şeyi vurguluyor; ekim yaması VULN-39341'i içermiyor ve Adobe'nin yama kayıt sistemi bunu ön koşul olarak listelemiyor. Yani:

Alıntı:Eylül hotfix'ini kurmadan sadece ekim yamasını uygularsanız StyleSmuggler açık kalır. Sadece eylül hotfix'iyle kalırsanız BlockStrap açık kalır. İkisi birden gerekli.

Bir de şu ayrıntı var: düz bir Composer kurulumu hâlâ zafiyetli temel sürümü getiriyor. "2026-oct" sürümüne geçmeniz ya da Adobe'nin izole yamasını uygulamanız gerekiyor.

"Öncelik 2" Tartışması

Adobe bu bülteni öncelik 2 olarak işaretledi; bu da "30 gün içinde yamayın" anlamına geliyor. Adobe'nin bültende belirttiği gibi, yayım anında vahşi doğada bilinen bir istismar yoktu. Sansec'in aktardığına göre Adobe, öncelik 1'i bilinen sömürü olan açıklara ayırıyor.

Sansec bu derecelendirmeye itiraz ediyor. Gerekçeleri iki cümlede özetlenebilir: Saldırı yolu karmaşık olsa da yamayı tersine mühendislikle çözüp çalışan istismara çevirmek artık yapay zeka destekli araçlarla kısa sürüyor. Üstelik benzer karmaşıklıktaki StyleSmuggler, öncelik 1 hotfix'ten toplu sömürüye üç günde geçmişti. Bence burada Sansec'e hak vermemek zor; CVSS 10 ve kimlik doğrulamasız bir RCE için 30 günlük pencere fazla rahat.

Yamanın Uygulandığını Doğrulama

Sansec'in paylaştığı kontroller oldukça pratik. Deploy süreci "hatasız tamamlandı" dese bile koda bakmanızı öneriyorlar, çünkü Composer yama eklentileri bir parçayı build'i bozmadan atlayabiliyor; patch ... || true gibi komutlar kullanan deploy betikleri de başarısız parçaları sessizce yutuyor.

Magento kök dizininde BlockStrap düzeltmesinin varlığını kontrol etmek için:
Çıktı 0 ise BlockStrap düzeltmesi yok demektir. Mage-OS kullanıyorsanız yol farklı:

StyleSmuggler hotfix'inin durumunu görmek için:

13 Ekim'de 2.4.8-p5 yamasını uygulayanlar için ek bir not: Sansec'e göre her iki 2.4.8-p5 yama sürümü de BlockStrap düzeltmesini içeriyor, ancak ilk sürüm aynı bültendeki CVE-2026-91013 için gereken bir değişikliği dışarıda bırakmış. Kontrol:
Sonuç 0 ise 248p5-2026-10-002-CE yamasını uygulamanız gerekiyor.

Yamadan sonra Magento kök dizininde 976bc24c... ile başlayan boş bir dosya görürseniz paniğe gerek yok. Sansec'e göre bu, yamanın yanlışlıkla oluşturduğu bir kilit dosyası; silebilir ya da .gitignore'a ekleyebilirsiniz.



Open Source 2.4.6 ve Mage-OS Kullananlar

Sansec'in açıklamasına göre Adobe'nin herkese açık ekim yamaları Magento Open Source 2.4.7-p10, 2.4.8-p5 ve 2.4.9 için var. 2.4.4-p18, 2.4.5-p17 ve 2.4.6-p15 yamaları Adobe Commerce lisansı gerektiriyor. Yani Open Source 2.4.6 veya daha eskisini kullanan mağazaların 2.4.7-p10 ya da üstüne yükseltme yapması gerekiyor. Adobe bu sürümlerin indirme bağlantılarını ka-49323 numaralı KB makalesinde listeliyor.

Mage-OS tarafında 3.5.0'a kadar olan sürümler etkileniyor; 14 Ekim'de yayımlanan Mage-OS 3.6.0 Adobe'nin düzeltmesini içeriyor. Düzeltme framework'ü ve dört modülü değiştirdiği için metapaketi güncellemek gerekiyor:

Bir de log incelerken yanılmayın: Sansec, registerUndefinedFilterCallback içeren Twig payload'larının BlockStrap olmadığını, Magento'nun Twig kullanmadığını not ediyor. bxss.me geri çağrısı içeren istekler de Acunetix tarayıcısından geliyor.

Ne Yapmalı? (Kısa Liste)

• APSB26-153 güncellemelerini ya da izole yamayı bugün uygulayın, 30 günü beklemeyin.
  
• Eylül VULN-39341 (CVE-2026-75650) hotfix'inin yerinde olduğunu ayrıca doğrulayın.
  
• Yukarıdaki grep kontrolleriyle yamanın gerçekten koda girdiğini teyit edin.
  
• Open Source 2.4.6 ve öncesindeyseniz 2.4.7-p10 veya üstüne yükseltme planını hemen başlatın.
  
• Mağaza dizinlerinde son haftalarda değişmiş PHP dosyalarını ve beklenmedik admin hesaplarını gözden geçirin.
  

Sansec, toplu saldırı dalgası görmeleri halinde makalesini güncelleyeceğini söylüyor. Bu konuyu da gelişme olursa güncellemeye çalışacağım. Magento yöneten arkadaşlar, yamayı uygularken StyleSmuggler hotfix'iyle çakışma yaşadınız mı? Sansec, hotfix yerindeyken Preview.php ve AbstractTemplate.php için satır kayması uyarısı çıktığını ama parçaların yine de uygulandığını söylüyor; sizde durum nasıldı, yorumlarda yazarsanız başkalarına da yol gösterir.

Kaynaklar

• Adobe - Security update available for Adobe Commerce | APSB26-153: https://www.adobe.com/trust/security/pro...6-153.html
  
• Sansec - BlockStrap: Magento and Adobe Commerce RCE (CVE-2026-103849): https://sansec.io/research/blockstrap-magento-rce
  
• BleepingComputer - Critical BlockStrap flaw lets hackers run code on Magento servers: https://www.bleepingcomputer.com/news/se...o-servers/
  

Alıntı:Yasal Uyarı: Bu konu yalnızca bilgilendirme ve savunma amaçlıdır. Paylaşılan kontrol ve tespit adımlarını yalnızca sahibi olduğunuz veya yazılı izinle yönettiğiniz sistemlerde uygulayın. İzinsiz erişim, tarama ve sistemlere müdahale, 5237 sayılı Türk Ceza Kanunu'nun 243-245. maddeleri kapsamında suçtur.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri
   

Merhaba TurkTeam,

SQL Injection (SQLi), web uygulamalarının en eski ve en etkili zafiyetlerinden biridir. Elle sömürmek zahmetli olabilir; işte SQLmap tam burada devreye girer: SQL enjeksiyon açıklarını otomatik tespit eden ve sömüren güçlü, açık kaynaklı bir araçtır. Bu rehberde SQLmap'i, yasal ve güvenli bir lab olan DVWA (Damn Vulnerable Web Application) üzerinde adım adım kullanacağız. Her şey yalnızca kendi lab ortamınız içindir.

Konuda Anlatılacaklar

1. SQL Injection ve SQLmap nedir
   
2. Lab kurulumu: DVWA ve güvenlik seviyesi
   
3. Oturum/çerez ile kimlikli tarama mantığı
   
4. SQLmap temel parametre referansı
   
5. Uygulamalı: veritabanı, tablo ve veri çıkarımı
   
6. İleri seviye: risk/level, --os-shell, tamper
   
7. Sonuç, kaynakça ve yasal uyarı
   

1. SQLi ve SQLmap Nedir?
SQL Injection, kullanıcıdan gelen girdinin doğrudan bir SQL sorgusuna karıştırılmasıyla, saldırganın sorgunun mantığını değiştirebilmesidir. Sonuç; yetkisiz veri okuma, kimlik doğrulama atlatma, hatta bazı durumlarda sunucuda komut çalıştırmaya kadar gidebilir.

SQLmap, bu açıkları otomatik keşfeden ve sömüren bir araçtır. Boolean-based, error-based, time-based blind, UNION-based gibi birçok enjeksiyon tekniğini destekler; MySQL, PostgreSQL, MSSQL, Oracle gibi pek çok veritabanını tanır ve veri çıkarımını otomatikleştirir.

2. Lab Kurulumu: DVWA
DVWA, kasıtlı olarak zafiyetli bir PHP/MySQL uygulamasıdır ve öğrenmek için idealdir. En kolay yol Docker ile çalıştırmaktır:
Tarayıcıdan http://localhost adresine gidin, varsayılan admin/password ile giriş yapın ve "Create / Reset Database" butonuna basın. Ardından DVWA Security sayfasından güvenlik seviyesini önce Low yapın.

Hedefimiz "SQL Injection" sayfasıdır; URL şu kalıptadır:

3. Oturum/Çerez Mantığı
DVWA giriş gerektirir; SQLmap'in de aynı oturumu kullanması için çerezi vermeliyiz. Tarayıcının geliştirici araçlarından (Application > Cookies) PHPSESSID ve security çerezlerini kopyalayın. Bunları --cookie ile SQLmap'e aktaracağız.

4. SQLmap Parametre Referansı
-u - Hedef URL (enjekte edilecek parametreyi içerir):

--cookie - Kimlikli istek için oturum çerezi:

-p - Hangi parametrenin test edileceği:

--dbs - Erişilebilir veritabanlarını listele:

-D / --tables - Bir veritabanının tablolarını listele:

-T / --columns - Bir tablonun sütunlarını listele:

--dump - Verileri çıkar (döküm al):

--batch - Soruları varsayılanla otomatik yanıtla (etkileşimsiz):

5. Uygulamalı: Veritabanından Veri Çıkarma
Adım 1 - Enjeksiyon tespiti. Önce parametrenin zafiyetli olup olmadığını doğrulayalım:
SQLmap zafiyeti bulunca "parameter 'id' is vulnerable" ve kullanılan tekniği (örn. boolean-based blind, UNION query) ile birlikte arka plandaki veritabanını (örn. MySQL) raporlar.


Adım 2 - Veritabanlarını listeleme:
Çıktıda "dvwa", "information_schema" gibi veritabanları listelenir.

Adım 3 - dvwa veritabanının tabloları:
"users" ve "guestbook" tabloları görünür.

Adım 4 - users tablosunu dökme:
SQLmap kullanıcı kayıtlarını bir tabloda gösterir. Parola sütunu hash'li ise SQLmap hash'i tanıyıp sözlük saldırısı önerir; kabul ederseniz dahili wordlist ile kırmaya çalışır ve çözülen parolaları yanında gösterir.


6. İleri Seviye: Level, Risk, Shell ve Tamper
--level ve --risk: Daha fazla test vektörü ve daha agresif teknikler için (1-5 ve 1-3); yüksek değerler daha kapsamlı ama daha gürültülüdür:

Higher security seviyeleri: DVWA'da güvenlik "Medium" (POST + sayısal) veya "High" olduğunda, isteği -r ile bir dosyadan (Burp'tan kaydedilen ham istek) besleyebilir veya --data ile POST gövdesi verebilirsiniz:

--os-shell: Uygun koşullarda (dosya yazma yetkisi, yol bilgisi) işletim sistemi kabuğu dener. Bu, yüksek etkili bir adımdır ve yalnızca kendi lab'ınızda denenmelidir:

--tamper: Basit WAF/filtre atlatma için yük dönüştürme betikleri (yalnızca yetkili testlerde):

7. Savunma Tarafı
SQLmap'i öğrenmenin asıl amacı savunmayı güçlendirmektir. SQL Injection'a karşı temel önlemler:

• Parametreli sorgular / prepared statements: Girdiyi koddan ayırır; en etkili çözümdür.
  
• En az ayrıcalıklı DB kullanıcısı: Uygulama hesabı yalnızca ihtiyaç duyduğu tablolara erişsin.
  
• Girdi doğrulama ve çıktı kodlama: Beklenen tipi zorlayın.
  
• WAF: Ek katman olarak faydalıdır ama tek başına yeterli değildir.
  

7.1. SQLmap Çıktısını Doğru Okumak
SQLmap güçlü bir araç olsa da, çıktısını doğru yorumlamak aracı çalıştırmak kadar önemlidir. Araç bir parametreyi test ederken hangi tekniklerin işe yaradığını açıkça raporlar: boolean-based blind, error-based, time-based blind ve UNION query. Bu tekniklerin ne anlama geldiğini bilmek, bulgunun gerçekliğini ve etkisini değerlendirmenize yardımcı olur. Örneğin time-based blind, uygulamanın hata vermeden sessizce zafiyetli olduğunu gösterir ve genellikle en yavaş ama en güvenilir yöntemdir; UNION query ise veriyi tek istekte büyük miktarda çekebildiği için en hızlısıdır.

SQLmap sonuçlarını bir oturum dosyasında önbelleğe alır; aynı hedefi tekrar çalıştırdığınızda tespit aşamasını atlayıp doğrudan devam eder. Bu hız kazandırır, ancak hedef değiştiyse yanıltıcı olabilir; temiz bir test için --flush-session kullanarak önbelleği temizleyebilirsiniz. Ayrıca aracın ürettiği tüm istek ve yanıtları ve çıkarılan verileri bir çıktı dizininde saklar; raporlama yaparken bu çıktı dizini delil zincirinizin bir parçası olur.

Gerçek bir yetkili testte gürültü ve etki yönetimi kritiktir. Yüksek --level ve --risk değerleri çok daha fazla istek üretir ve üretim sistemlerinde performans sorunlarına yol açabilir; bu yüzden kapsamınızı ve müşterinizle anlaştığınız sınırları her zaman gözetin. --dump ile koca bir tabloyu çekmeden önce, gerçekten o veriye ihtiyacınız olup olmadığını düşünün; çoğu zaman zafiyetin varlığını ve birkaç örnek kaydı göstermek, tüm veritabanını indirmekten daha profesyonel ve daha az risklidir. Amaç, bulguyu kanıtlamak ve kapatılmasını sağlamaktır; veri hırsızlığı değil.

Sonuç
SQLmap, SQL Injection tespit ve sömürüsünü otomatikleştiren son derece güçlü bir araçtır; DVWA ise bunu güvenle öğrenmek için ideal bir sahadır. Önce Low seviyede temel akışı (tespit > dbs > tables > columns > dump) oturtun, ardından level/risk ve farklı güvenlik seviyeleriyle derinleşin. Unutmayın: amaç yıkmak değil, zafiyeti anlayıp parametreli sorgularla kapatmaktır.

Kaynakça

• SQLmap Resmi Sitesi ve Wiki - https://sqlmap.org
  
• SQLmap Kullanım Belgeleri - https://github.com/sqlmapproject/sqlmap/wiki/Usage
  
• DVWA Resmi Deposu - https://github.com/digininja/DVWA
  
• OWASP SQL Injection - https://owasp.org/www-community/attacks/SQL_Injection
  
• OWASP SQL Injection Prevention Cheat Sheet - https://cheatsheetseries.owasp.org/cheat...Sheet.html
  

Yasal Uyarı

Alıntı:SQLmap yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde kullanılmalıdır. İzinsiz SQL enjeksiyonu ve veri erişimi Türk Ceza Kanunu 243-245. maddeleri kapsamında ağır suçtur. DVWA'yı daima yerel/izole ortamda çalıştırın.

Yasal uyarı: Bu içerik eğitim amaçlıdır. Yalnızca kendi sistemlerinizde veya yazılı izin aldığınız hedeflerde uygulayın (TCK 243-245).

Ek Dosyalar

Ekran Görüntüleri