Şifre Bilmeden Giriş: MantisBT SOAP API Kimlik Doğrulama Atlatma

Bir sisteme girmek için şifre bilmek zorunda olmadığınızı düşünün — sadece hedefin kullanıcı adını bilmeniz yeterli. ⚠️ CVE-2026-30849, tam olarak bunu mümkün kılıyor: MantisBT’nin SOAP API’si, MySQL üzerinde çalışan kurulumlarda tip dönüşümü hatasından kaynaklanan bir kimlik doğrulama atlama (authentication bypass) zafiyeti içeriyor. CVSS puanı 9.8 olan bu açık, kurumsal hata takip sistemlerini sessizce ele geçirmeye kapı aralıyor — ve kaç kurumun hâlâ yamayı uygulamadığını sormak gerekiyor.

Zafiyet Nedir ve Neden Bu Kadar Tehlikeli?

MantisBT (Mantis Bug Tracker), açık kaynaklı bir hata ve sorun takip sistemidir. Yazılım geliştirme ekiplerinden IT operasyon birimlerine kadar geniş bir kullanıcı tabanına sahip olan MantisBT, kurumsal ortamlarda “hangi yazılım hatası kimin elinde, hangi aşamada” sorularını yanıtlar. Ve tam bu noktada sorun başlıyor: bu sisteme erişim, kurumun iç süreçlerine, açık hatalara, güvenlik raporlarına ve proje durumuna doğrudan pencere açar.

CVE-2026-30849, MantisBT’nin 2.28.1 öncesi sürümlerinde, MySQL ailesi veritabanlarıyla (MySQL, MariaDB) kullanılan SOAP API uç noktasında bulunuyor. Zafiyetin köküne indiğimizde, son derece “sıradan” görünen ama yıkıcı sonuçlar doğuran bir hata var: parola parametresi üzerinde hatalı tip denetimi (improper type checking).

MySQL, belirli koşullarda dize (string) değerleri otomatik olarak tamsayıya (integer) dönüştürür. Saldırgan, SOAP zarfına parola alanı yerine 0 (sıfır tamsayı) veya tamsayı olarak yorumlanabilecek özel biçimlendirilmiş bir değer yerleştirdiğinde, veritabanı katmanındaki bu örtük tip dönüşümü parola karşılaştırmasını atlatıyor. Sonuç: geçerli bir kullanıcı adı bilindiği sürece, gerçek parola hiç bilinmeden oturum açılabiliyor.

PostgreSQL veya Microsoft SQL Server kullanan kurulumlar bu zafiyetten etkilenmiyor, çünkü bu veritabanları örtük tip dönüşümü yapmıyor. Risk yalnızca MySQL ekosisteminde — ama bu ekosistem kurumsal dünyada son derece yaygın.

Saldırı Nasıl Çalışır? Teknik Açıdan Bakış

Saldırı adımları son derece basit ve tekrarlanabilir nitelikte. MITRE ATT&CK çerçevesinde bu saldırı T1078 — Valid Accounts (Geçerli Hesapların Kötüye Kullanımı) ve T1190 — Exploit Public-Facing Application (Kamuya Açık Uygulama İstismarı) teknikleriyle örtüşüyor.

Saldırganın ihtiyacı olan tek şey hedef kullanıcının kullanıcı adı. Bu bilgiye ulaşmak için çoğu zaman SOAP API’nin mc_account_get_user_by_name gibi kimlik doğrulama gerektirmeyen uç noktaları bile yeterli olabiliyor. Ardından aşağıdakine benzer şekilde biçimlendirilmiş zararlı bir SOAP isteği gönderiliyor:

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:xsd="http://www.w3.org/2001/XMLSchema"
               xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <soap:Body>
    <mc_login xmlns="http://futureware.biz/mantisconnect">
      <!-- Sadece kullanici adi biliniyor, parola alanina tamsayi 0 yerleştiriliyor -->
      <username xsi:type="xsd:string">hedef.kullanici</username>
      <password xsi:type="xsd:integer">0</password>
    </mc_login>
  </soap:Body>
</soap:Envelope>

MySQL, 0 tamsayısını parola hash değeriyle karşılaştırırken örtük dönüşüm nedeniyle koşulu doğru kabul ediyor ve oturum açılıyor. Kimlik doğrulama başarıyla atlatıldıktan sonra saldırgan, kurbanın hesabının sahip olduğu tüm SOAP API işlevlerine erişim kazanıyor: hata biletlerini okumak, değiştirmek, kapatmak; kullanıcı bilgilerini toplamak; proje yapılandırmalarına ulaşmak. Yönetici hesabı hedef alınmışsa bu, sistemin tam kontrolü anlamına geliyor.

🛡️ Önemli bir not: SOAP API devre dışı bırakılmış olsa bile saldırgan hâlâ kullanıcı adı, gerçek isim ve e-posta adresi gibi hesap bilgilerini toplayabiliyor. Bu durum, SOAP API’yi kapatmanın tam bir çözüm olmadığını, yalnızca riski önemli ölçüde azalttığını gösteriyor.

Kimin İçin Kritik? Kurumsal Risk Değerlendirmesi

MantisBT’yi “küçük ekiplerin kullandığı açık kaynak bir araç” olarak görmek, bu zafiyetin ciddiyetini hafife almak olur. Gerçek şu ki MantisBT, özellikle savunma, finans ve kamu sektöründeki pek çok kurumda hâlâ aktif olarak kullanılıyor — çoğu zaman ITSM ya da yazılım geliştirme süreçlerinin tam kalbinde.

Bu zafiyetin kurumsal risk boyutuna bakıldığında şu tablo çıkıyor:

Bilgi ifşası: MantisBT’deki açık hatalar, güvenlik açıkları veya yamalar saldırgana kurumun iç zayıflıklarını anlatan bir harita sunar. Bir saldırgan sisteme girdikten sonra “hangi yazılımlarda hata var, hangi yamalar bekliyor” bilgisini doğrudan okuyabilir.
Kimlik bilgisi hasadı: API üzerinden elde edilen kullanıcı adı ve e-posta listeleri, hedefli oltalama (spear phishing) saldırıları için birinci sınıf hammaddedir.
Yetki yükseltme zinciri: MantisBT hesabının sahip olduğu diğer sistemlerle SSO veya aynı parola kullanımı varsa, bu erişim bir köprü taşına dönüşür.
İz bırakmama riski: Geçerli bir kullanıcı oturumu üzerinden yapılan işlemler, standart log analizinde “meşru aktivite” olarak görünebilir. Bu, tespit edilme süresini önemli ölçüde uzatır.

Wazuh ile Tespit: SOAP API Kötüye Kullanımını Nasıl Yakalarız?

Kurumda Wazuh kullanıyorsanız, bu zafiyeti birkaç katmanda tespit edebilirsiniz. 🔧 Temel yaklaşım şu: MantisBT SOAP isteklerini içeren web sunucusu günlüklerini (Apache/Nginx access log) Wazuh ajanı üzerinden toplamak ve anormal tip uyuşmazlığı içeren istekleri yakalamak.

Aşağıdaki Wazuh özel kuralı, SOAP isteğinde mc_login çağrısı tespit edildiğinde ve kısa sürede birden fazla kimlik doğrulama denemesi yapıldığında uyarı üretir. Bu kural, hem kaba kuvvet (brute-force) denemelerini hem de kullanıcı adı numaralandırma girişimlerini yakalamak için başlangıç noktası olarak kullanılabilir:

<!-- /var/ossec/etc/rules/mantisbt_soap.xml -->
<group name="mantisbt,soap,authentication,">

  <!-- Kural 1: SOAP mc_login isteği tespiti -->
  <rule id="100500" level="6">
    <if_sid>31100</if_sid>
    <url>/mantisbt/api/soap/mantisconnect.php</url>
    <match>mc_login</match>
    <description>MantisBT SOAP API uzerinden mc_login istegi tespit edildi</description>
    <group>authentication_attempt,</group>
  </rule>

  <!-- Kural 2: 60 saniye icinde 5+ SOAP login denemesi = brute-force uyarisi -->
  <rule id="100501" level="12" frequency="5" timeframe="60">
    <if_matched_sid>100500</if_matched_sid>
    <same_source_ip/>
    <description>MantisBT SOAP API: Ayni IP'den cok sayida login denemesi (muhtemel brute-force veya bypass girisimi)</description>
    <group>authentication_failures,brute_force,</group>
    <mitre>
      <id>T1078</id>
      <id>T1190</id>
    </mitre>
  </rule>

  <!-- Kural 3: Farkli kullanici adlariyla SOAP login - hesap numaralandirma -->
  <rule id="100502" level="10" frequency="5" timeframe="120">
    <if_matched_sid>100500</if_matched_sid>
    <same_source_ip/>
    <not_same_user/>
    <description>MantisBT SOAP API: Farkli kullanici adlariyla login denemesi (hesap numaralandirma)</description>
    <group>authentication_failed,enumeration,</group>
    <mitre>
      <id>T1078</id>
    </mitre>
  </rule>

</group>

Bu kuralların çalışması için Wazuh ajanının MantisBT’nin çalıştığı sunucudaki web sunucusu erişim günlüklerini okuyor olması gerekiyor. Aşağıdaki yapılandırmayı ossec.conf dosyanıza ekleyin:

<!-- ossec.conf - MantisBT web sunucusu log izleme -->
<localfile>
  <log_format>apache</log_format>
  <location>/var/log/apache2/mantisbt_access.log</location>
</localfile>

<!-- Nginx kullananlar icin -->
<localfile>
  <log_format>nginx</log_format>
  <location>/var/log/nginx/mantisbt_access.log</location>
</localfile>

Ek olarak, MantisBT’nin kendi uygulama günlükleri de değerli bir kaynak. mantis_log tablosunu veya dosya tabanlı günlük çıktısını Wazuh’a besleyebilirseniz, başarılı kimlik doğrulama sonrası yapılan API çağrılarını da izleyebilirsiniz. Bu katman, özellikle bypass girişiminin tespit edilmesinde kritik önem taşıyor.

Ne Yapmalısınız? Acil Aksiyon Listesi

🛡️ Hemen MantisBT 2.28.1 sürümüne geçin. Bu, zafiyeti kapatmanın tek kesin yolu. Yamanın uygulanması geciktirilmemelidir — CVSS 9.8 puanı, bu açığın aktif istismar için son derece çekici olduğunu gösteriyor.
⚠️ Güncelleme yapana kadar SOAP API’yi devre dışı bırakın. MantisBT yönetici panelinden veya sunucu yapılandırmasından SOAP API uç noktasına erişimi engellemek, riski önemli ölçüde düşürür. Ancak bu yeterli değil; hesap bilgileri SOAP API kapalıyken de toplanabiliyor.
🔧 SOAP API’ye erişimi ağ katmanında kısıtlayın. Eğer SOAP API kullanmak zorundaysanız, güvenlik duvarı veya web uygulaması güvenlik duvarı (WAF) kurallarıyla erişimi yalnızca bilinen ve güvenilir IP aralıklarıyla sınırlayın. Kamuya açık bir MantisBT kurulumunda SOAP API’nin internete tamamen açık olmaması gerekiyor.
📊 Geçmişe dönük günlük analizi yapın. Zafiyetin kamuoyuna duyurulduğu tarihten önce MantisBT SOAP API günlüklerinde anormal mc_login çağrıları olup olmadığını inceleyin. Başarılı kimlik doğrulamaları bile şüpheli olabilir — özellikle kullanıcının gerçekten oturum açmadığı bir zaman dilimine denk geliyorsa.
MantisBT’deki kullanıcı hesaplarını gözden geçirin. Aktif olmayan hesapları devre dışı bırakın. Saldırgan kullanıcı adı bilmeye ihtiyaç duyduğundan, gereksiz hesapların varlığı saldırı yüzeyini genişletiyor. Özellikle eski çalışanlara ait hesaplar öncelikli hedef.
MantisBT üzerindeki hassas içeriği değerlendirin. Sisteminizde güvenlik açıklarına, yamaya bekleyen zafiyetlere veya iç altyapı bilgilerine dair kayıtlar varsa, bu bilgilerin ele geçirilmesinin ne anlama geleceğini düşünün ve gerekiyorsa erişim yetkilerini daraltın.

Benim Gözlemim: “Küçük Araç” Yanılgısı

Bu zafiyet bana her defasında aynı dersi hatırlatıyor: kurumsal güvenlik programlarında “birincil sistemler” ve “ikincil araçlar” ayrımı yapmak tehlikeli bir alışkanlık. MantisBT gibi hata takip sistemleri, güvenlik tarama programlarına çoğu zaman dahil edilmiyor; yama yönetimi takibine alınmıyor; bazen yıllarca güncellenmeden çalışıyor. Oysa bu sistemler, kurumun iç akışına ve bazen en kritik güvenlik bilgilerine doğrudan erişim sunuyor.

SOAP protokolü bu bağlamda ayrı bir tartışma konusu. Modern REST ve GraphQL API’leri yaygınlaşırken pek çok kurumsal kurulumda SOAP hâlâ hayatta — ve çoğu zaman gözetim altında değil. Tip dönüşümü gibi “önemsiz” görünen programlama hataları, SOAP’ın katı XML şema yapısı içinde beklenmedik davranışlara yol açabiliyor. Bu zafiyet, tip güvenliğinin (type safety) ne kadar kritik olduğunun bir kez daha kanıtı.

Eğer ortamınızda MantisBT varsa ve MySQL ile çalışıyorsa, bu yazıyı okuduktan sonraki ilk işiniz versiyonu kontrol etmek olsun. Versiyon 2.28.1 değilse, aksiyon almanın zamanı şu an. 📊

Orijinal kaynak: https://nvd.nist.gov/vuln/detail/CVE-2026-30849

Securtr