CVE-2025-30406: Hardcoded Secret'lar, Token Sahteciliği ve CentreStack Güven Çöküşü

Yönetici Özeti

CVE-2025-30406, tipik zafiyet açıklamalarından farklı bir yerde durdu; çünkü memory corruption veya input parsing hatası değildi. Temel bir güven tasarımı çöküşüydü. Zafiyet, CentreStack ve Triofox dağıtımlarında hardcoded cryptographic keys bulunmasından kaynaklanıyordu. Bu durum, gömülü secret materyalini elde eden saldırganların kimlik doğrulamayı atlayıp platformun meşru kabul edeceği sahte kimlik artefaktları oluşturmasına imkan tanıyordu.

Konunun CWE-798 kapsamında ele alınması gereken tam da bu nedendir. Dağıtım başına benzersiz ve sıkı biçimde kontrol edilmesi gereken bir secret statik, geniş çapta dağıtılmış ve analiz yoluyla kurtarılabilir hale geldiğinde sorun kod kalitesini aşar. Ürünün güveni nasıl modellediğine dair mimari bir kusur haline gelir.

Hardcoded Kriptografik Anahtarlar Neden Kategorik Olarak Tehlikelidir?

Güvenlik ekipleri hardcoded anahtarları zaman zaman zayıf parolalarla aynı sepete koyar; sonraki sprint'te düzeltilmesi gereken bir hijyen meselesi gibi. Bu çerçeveleme ciddiyeti kayda değer ölçüde küçümsüyor. Hardcoded bir secret, kimliği imzalamaktan veya doğrulamaktan sorumlu bir güven yolunun içinde yer aldığı anda felaket düzeyinde sonuçlara yol açar.

Uygulama bu gömülü anahtarı oturum token'larını imzalamak, ayrıcalıklı API isteklerini yetkilendirmek veya güven taşıyan veriyi öngörülebilir ve tekrarlanabilir biçimde korumak için kullanıyorsa, o anahtarın ele geçirilmesi saldırganın sistemle ilişkisini temelden dönüştürür. Saldırganın kriptografiyi kaba kuvvet veya kriptanalizle kırması artık gerekmez. Yalnızca satıcının güven varsayımlarını ödünç alması ve bunları kendi adına kullanması yeterlidir.

Token Sahteciliğine Giden Yol

CVE-2025-30406 ile ilişkili en ciddi senaryo, kimlik doğrulama token'larının, biletlerin veya diğer kimlik artefaktlarının fiilen statik ve kurtarılabilir olan bir secret ile imzalanması ya da mühürlenmesiydi. Saldırgan bu materyali uygulama binary'sinin tersine mühendisliği, yapılandırma dosyalarının incelenmesi veya standart bir dağıtım artefaktının analizi yoluyla elde ettiğinde, keyfi kimlik doğrulama token'ları üretme kapasitesi kazanır.

Bu noktada uygulama, saldırgan tarafından üretilen kimliği meşru kimlikten ayırt edemez hale gelir.

İşte kritik dönüm noktası budur. Saldırgan artık input işleme veya memory corruption'ı sömürmeye çalışmıyor; platformun kendi güven dilini tam imzalama yetkisiyle akıcı biçimde konuşuyordur.

Token Sahteciliğinin Ardından RCE Neden Doğal Olarak Gelir?

Saldırgan platformun kabul ettiği ayrıcalıklı veya yönetici düzeyinde token'lar üretmeye başladığında sunucu kompromesine giden yol dramatik biçimde kısalır. Ardından gelen adımlar teknik açıdan çoğu zaman sıradan niteliktedir:

güvenilir yönetici kimliği gerektiren ayrıcalıklı API uç noktalarına doğrudan erişim.

güvenilir oturumlar tarafından kullanılabilen dosya yükleme veya dosya yönetimi işlevselliğinin kötüye kullanımı.

yalnızca güvenilir kimlikle sınırlı yönetimsel eylemlerin—hesap oluşturma, yapılandırma değişikliği, ajan dağıtımı—gerçekleştirilmesi.

sahte kimlik bilgilerini kabul eden meşru yönetim yüzeyleri aracılığıyla web shell veya sunucu tarafı kalıcılık artefaktlarının kurulumu.

Zafiyet, tesadüfen bağlantılı iki ayrı olay—“hardcoded key” ve “RCE”—değildir. Hardcoded key güven çöküşünü yapısal olarak kaçınılmaz kılar; güven çöküşü ise her ayrıcalıklı sunucu eylemini saldırgana açan mekanizmadır.

Security Through Obscurity Neden Hiçbir Zaman Savunma Olmadı?

Hardcoded kriptografik materyal üretilen ürünlerde kalmaya devam eder; çünkü geliştirme ekipleri kurtarma engelinin ihmal edilebilecek kadar yüksek olduğunu varsayar. Bu, uygulama güvenliğindeki en kalıcı yanlış güvendir. Secret kaynak kodda, derlenmiş binary'de, kurulum paketinde, yapılandırma şablonunda veya herhangi bir standart dağıtım artefaktında mevcutsa, bunların herhangi birine erişimi olan motive bir saldırganın onu kurtarabildiği varsayılmalıdır.

Tersine mühendislik bu nedenle ürün güvenlik ekipleri için teorik bir araştırma meselesi değildir. Saldırganların gizli tasarım varsayımlarını—“kimse bu anahtarı bulamaz”—etkilenen sürümü kullanan her müşteri dağıtımına karşı işlevsel giriş noktalarına dönüştürdüğü pratik yöntemdir.

Ürün ve Güvenlik Ekipleri İçin Mimari Dersler

CVE-2025-30406'dan çıkan mimari dersler bu spesifik satıcı ve kod tabanının çok ötesine geçiyor:

kimlik doğrulama ve yetkilendirme güvenini tanımlayan secretlar dağıtım başına benzersiz olmalı, kurulum sırasında oluşturulmalı ve örnekler arasında hiçbir zaman paylaşılmamalıdır.

imzalama ve doğrulama anahtarları talep üzerine değiştirilebilir olmalı ve dağıtılan artefaktlara statik biçimde gömülmemelidir.

kimlik doğrulama artefaktı tasarımı imzalama secretının açığa çıktığı senaryoyu hesaba katmalı ve kapsam ile geçerlilik süresiyle patlama yarıçapını sınırlamalıdır.

SSDLC incelemeleri secret yerleştirme kararlarını uygulama düzeyinde hijyen kontrolü değil, mimari inceleme maddesi olarak ele almalıdır.

CVSS Vektörü, Saldırı Yüzeyi ve Etkilenen Sürümler

CVE-2025-30406, CVSS 3.1 puanlamasında 9.8 (Kritik) değeri aldı:

~~~

CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H

~~~

Saldırı yüzeyi (attack surface): Saldırganın yalnızca CentreStack veya Triofox web arayüzüne ağ erişimi gereklidir — geçerli kimlik bilgisi, önceden foothold veya fiziksel erişim aranmaz. İnternetten (veya yönetim düzlemine erişimli bir ağdan) ulaşılabilen her örnek kapsam dahilindedir. HTTP/HTTPS erişilebilirliği yeterlidir.

WAF bu saldırıyı engelleyebilir mi? Kısmen. Bir WAF, token yapısı anomalilerini inceleyebilir ve standart dışı claim'lerle gelen JWT imzalarını işaretleyebilir. Ancak saldırgan, sızdırılan anahtarı kullanarak kriptografik olarak geçerli tokenlar ürettiğinden, salt imza tabanlı tespit bunları yakalamaz. Olağandışı başlık kombinasyonlarını, beklenmedik admin uç nokta erişim kalıplarını veya oturum IP/UA'sıyla eşleşmeyen tokenları içeren istekleri işaretleyen WAF kuralları telafi edici kontrol olarak yardımcı olabilir — ancak yama ve anahtar rotasyonunun yerini alamaz.

| Ürün | Etkilenen Sürümler | Düzeltilmiş Sürüm |

|---|---|---|

| CentreStack | 16.1.10296.56315 ve öncesi | 16.4.10315.56368 (Nisan 2025) |

| Triofox | Satıcı duyurusuna göre etkilenen sürümler | Satıcı yaması Nisan 2025 |

Tespit Sinyalleri

~~~yaml

title: CentreStack Sahte Admin Token Erişimi (CVE-2025-30406)

status: experimental

description: Normal oturum kurulum akışını atlayan tokenlarla admin API uç noktası erişimini tespit eder

detection:

condition: selection and not filter

selection:

cs-uri-stem|contains:

'/admin/'.

'/api/admin'.

cs-method: 'POST'

filter:

c-ip|cidr: '10.0.0.0/8'

timeframe: 5m

condition: selection | count() by c-ip > 10

logsource:

category: webserver

product: iis

~~~

Anormal yönetimsel API aktivitesinin hemen ardından CentreStack'in web kök dizinlerinde web shell oluşturulmasını da izleyin.

MyVuln Yaklaşımı

MyVuln bu zafiyet kategorisini dar bir kriptografi dipnotu değil, sistemik çıkarımları olan kök neden zayıflık kalıbı olarak sınıflandırmalıdır. Güven açısından kritik akışlara secret gömen bir ürün hattı, bitişik bileşenlerde neredeyse kesinlikle daha geniş yapısal risk taşıyor. MyVuln'ün Secret Governance analizi bu tür açıkları CWE-798 etiketiyle otomatik olarak işaretler ve etkilenen yazılımı çalıştıran her kuruluşa uzanan daha geniş secret yönetişimi hataları, dağıtım mimarisi riski ve miras kalan üçüncü taraf ürün maruziyeti kalıbıyla ilişkilendirir. Dahası, WAF kural önerileri ve anahtar rotasyon rehberliğini de platformdan erişilebilir kılar. Bu sayede "hardcoded key var" tespitinden eyleme geçirilebilir düzeltme yoluna geçiş hızlanır.