Bu Neden Önemli
E-ticaret platformları işletme operasyonlarının merkezinde yer alır. Bir yönetici hesabı, sahibinin rızası olmadan sessizce silinir veya değiştirilirse, sistemin bütünlüğü tehlikeye girer.
Bu makale, Bagisto tabanlı sistemlerde gözlemlenen ciddi bir güvenlik sorununu belgeler; meşru yönetici hesaplarının silindiği ve beklenmeyen bir default/admin kullanıcısı ile değiştirildiği durumları anlatır. Bu işlemler açık denetim izleri veya kullanıcı tarafından başlatılan eylemler olmaksızın gerçekleşmiştir.
Bu makalenin amacı farkındalık yaratmak ve sorumlu bir bildirimde bulunmaktır, spekülasyona girmek değildir.
🧩 Olay Ne Oldu
Bir üretim Bagisto kurulumunda aşağıdaki davranış gözlemlendi:
Meşru bir yönetici hesabı (örneğin, Admin ID = 1)
üzerine yazıldı ve silindi.
Kısa süre sonra, farklı bir yönetici hesabı ortaya çıktı, bu hesap:
farklı bir e-posta kullanıyordu
farklı bir kullanıcı adı vardı
ancak eşit veya daha yüksek yetkilere sahipti
Bu, sistem sahibinin herhangi bir niyetli eylemi olmaksızın gerçekleşti.
Hiçbir yönetici UI etkileşimi bu değişikliği tetiklemedi.
Standart Laravel veya Bagisto logları bunun neden olduğunu açıklamadı.
Pratikte:
Gerçek bir yönetici kayboldu ve başka bir yönetici onun yerine geçti.
🔍 Loglar Ne Gösterdi
- Veritabanı Düzeyinde Silme Onaylandı
ROW formatında etkinleştirilen MySQL ikili logları (binlog) kullanarak:
admins tablosunda bir DELETE işlemi kaydedildi.
İşlem onaylandı.
Bu, kaydın veritabanı seviyesinde fiziksel olarak silindiğini doğrular.
Bu bir:
soft delete
UI gizlemesi
izin değişikliği değil.
- Uygulama Logları Belirsizdi
Laravel ve Bagisto uygulama logları:
Bir yönetici silme eylemini kaydetmedi.
Yönetici hesabını, yolu veya sorumlu kontrolörü tanımlamadı.
- Hazırlanmış İfadeler Ağzı Kapatır
Bagisto hazırlanan ifadeler kullandığından, MySQL genel logları yalnızca şunları gösterir:
Prepare
Execute
?
Bu, sorgunun kökenini belirsiz kılar:
UI, arka plan işi, kurucu veya iç servis mantığı tarafından gelip gelmediğini.
🔐 Önemli: Bu Kötü Sunucu Güvenliğinden Kaynaklanmadı
Açıkça belirtmek gerekirse, ortam kilitlenmişti:
✅ MySQL Güvenliği
❌ Uzaktan MySQL erişimi yok
❌ Root MySQL kullanıcısı devre dışı
❌ MySQL yalnızca yerel olarak erişilebilir
❌ Paylaşılan kimlik bilgiler yok
❌ Dış veritabanı bağlantıları yok
✅ SSH Güvenliği
❌ Parola ile giriş devre dışı
✅ Sadece SSH anahtarı kimlik doğrulaması
❌ Yetkisiz SSH oturumları tespit edilmedi
✅ Altyapı Kontrolleri
Maruz kalmış yönetici araçları yok
Açık veritabanı portları yok
Sızdırılmış kimlik bilgileri yok
Bu, aşağıdakileri dışlar:
brute-force saldırıları
uzaktan MySQL tecavüzü
SSH kimlik bilgisi suiistimali
dış bir aktör tarafından doğrudan veritabanı manipülasyonu
🚨 En Endişe Verici Davranış: Yönetici Değişimi
En alarm verici davranış sadece silme değil, aynı zamanda değiştirme idi.
Gözlemlenen model:
Meşru yönetici hesabı var (ID ≈ 1)
O hesap siliniyor
Başka bir yönetici hesabı ortaya çıkıyor
Yeni hesap:
yönetici yetkilerine sahip
belirgin bir yaratım olayı yok
karşılık gelen bir UI eylemi yok
Zamanla, meşru yönetici tekrar değiştiriliyor.
Bu davranış, aşağıdakiler için normal değil:
Laravel
Bagisto
veya herhangi bir standart RBAC uygulaması
❓ Bu Neden Ciddi Bir Güvenlik Riski?
- Güven Modelini Bozar
Yönetici hesapları güvenin kökenidir.
Sessiz silme veya değiştirme, tüm erişim varsayımlarını geçersiz kılar.
- Gerçek Zamanlı Denetim Yapmak İmkansızdır
Olmadan:
yönetici etkinlik logları
değiştirilemez denetim izleri
veritabanı düzeyinde tetikleyiciler
…olay sonrası araştırmalar tahmin yürütmeye dönüşür.
- Potansiyel Suistimal Yolu
İster kasıtlı, ister kazara olsun, bu davranış,:
kötü amaçlı paketler
tehdit altında güncelleme mantığı
kurucu veya tohum kodu
belirlenmemiş iç süreçler
🚨 Bu Bir Arka Kapı mı?
Bu makale niyet iddiasında bulunmuyor.
Ancak, güvenlik mühendisliği bakış açısından, gözlemlenen davranış bir arka kapı benzeri zayıflığın özelliklerine benziyor:
Gizli yetki değişiklikleri
Kullanıcı etkileşimi yok
Açık bir denetim izi yok
Tekrarlanan yönetici değişiklikleri
Yetkili erişim dolaylı olarak verildi
En azından bu, araştırılmayı gerektiren kritik bir güvenlik açığıdır.
🛠️ Bagisto Kullanıcılarının Hemen Yapması Gerekenler
Bagisto’yu üretimde çalıştırıyorsanız:
admins tablosunu denetleyin
Silinmiş, değiştirilmiş veya yeniden oluşturulmuş hesaplar arayın
Veritabanı denetimini etkinleştirin
Yönetici tablolarındaki tüm DELETE, INSERT, UPDATE işlemlerini kaydedin
Yönetici erişiminde 2FA’yı zorunlu kılın
Sadece parolayla yönetici erişimi yetersizdir
MySQL ikili loglarını saklayın
Olayları araştırmak için yeterince uzun süre
Kurucuları, tohumları ve paketleri gözden geçirin
Özellikle yönetici kullanıcılarını etkileyen her şeyi.
📣 Bagisto Topluluğuna Bir Çağrı
Bagisto geniş çapta benimsenmiştir, bu yüzden güvenlik şeffaflığı kritik öneme sahiptir.
Topluluk şunları hak ediyor:
meselenin tanınması
yeniden üretilebilir bir araştırma
ve doğrulanmış bir azaltma veya düzeltme
Bu davranışı göz ardı etmek, gerçek işletmeleri tehlikeye atar.
✅ Son Düşünceler
Bu makale bir suçlama değildir.
Gerçek üretim davranışına dayanan teknik bir uyarıdır.
Ne zaman:
SSH sıkılaştırılmışsa
MySQL uzaktan erişilebilir değilse
root erişimi devre dışıysa
…ve yönetici hesapları hâlâ sessizce silinip değiştirilirse,
sorun uygulama katmanının içindedir.
Bagisto kullanıcıları sistemlerini şimdi doğrulamalıdır, zarar meydana gelmeden önce.
Kaynak: Orijinal Makale
