XenForo şu anda hâlâ en popüler forum yazılımlarından biri ama son dönemde çıkan birkaç küçük değişiklik, eski PHP zafiyetleriyle birleşince işleri bayağı karıştırıyor. Ben de son birkaç aydır kendi test ortamımda ve birkaç açık kaynaklı addon’u inceleyerek bu zinciri kurmaya çalıştım. Konu sadece “exploit yazmak” değil, aslında nasıl bir zafiyetin başka bir zafiyetle birleşip ciddi sonuçlar doğurabileceğini anlatmak.
Öncelikle XenForo’nun template rendering motorunda ufak bir değişiklik var. 2.2.12’den beri “phrase” sistemi biraz daha esnek hale getirilmiş. Bu esneklik normalde iyi bir şey ama addon’larda kullanılan bazı eski serialization yöntemleriyle çakışınca PHP Object Injection kapısı aralanıyor. Tabii tek başına bu injection RCE’ye gitmiyor, ekstra bir adım lazım.
İkinci parça ise self-hosted XenForo kurulumlarında sık karşılaşılan bir durum: sunucuda çalışan Redis instance’ının dışarıdan erişime açık olması. XenForo varsayılan olarak Redis’i cache backend olarak kullanabiliyor ve session verilerini burada tutuyor. Eğer Redis AUTH olmadan çalışıyorsa ve aynı sunucuda XenForo varsa, deserializasyonla elde ettiğin obje üzerinden Redis’e kötü niyetli veri yazmak mümkün hale geliyor.
Üçüncü halka ise biraz daha modern: XenForo’nun kullandığı AWS S3 entegrasyonu (attachment’lar için). Birçok yönetici “s3://” bucket’ını public koyuyor çünkü “zaten forumdan erişilsin” diyor. Ama bucket policy’lerde “s3:GetObject” izni wildcard verilmişse ve sen Redis üzerinden yazdığın session ile S3 API’sine istek atabiliyorsan, bucket içindeki tüm dosyaları indirebiliyorsun. Bu da bazen yedek veritabanı dökümlerini bile ele geçirmene yetiyor.
Bütün bu zinciri tek bir IP’den denemek yerine, önce forumun kendisinde bir XSS veya CSRF ile ufak bir JavaScript enjekte edip Redis bağlantı bilgisini çekmek daha temiz oluyor. Böylece saldırganın doğrudan sunucuya erişimi olmadan işler yürüyebiliyor. Tabii ki bu senaryo sadece yanlış yapılandırılmış ortamlarda geçerli ama maalesef hâlâ çok fazla XenForo kurulumunda bu tip konfigürasyonlar var.
Sonuç olarak, tek bir “büyük” sıfırıncı gün beklemek yerine, mevcut küçük zafiyetleri ve yanlış yapılandırmaları birleştirerek ciddi etki yaratmak mümkün. XenForo kullanan herkesin en azından Redis AUTH ve S3 bucket policy’lerini kontrol etmesini öneririm.
Öncelikle XenForo’nun template rendering motorunda ufak bir değişiklik var. 2.2.12’den beri “phrase” sistemi biraz daha esnek hale getirilmiş. Bu esneklik normalde iyi bir şey ama addon’larda kullanılan bazı eski serialization yöntemleriyle çakışınca PHP Object Injection kapısı aralanıyor. Tabii tek başına bu injection RCE’ye gitmiyor, ekstra bir adım lazım.
İkinci parça ise self-hosted XenForo kurulumlarında sık karşılaşılan bir durum: sunucuda çalışan Redis instance’ının dışarıdan erişime açık olması. XenForo varsayılan olarak Redis’i cache backend olarak kullanabiliyor ve session verilerini burada tutuyor. Eğer Redis AUTH olmadan çalışıyorsa ve aynı sunucuda XenForo varsa, deserializasyonla elde ettiğin obje üzerinden Redis’e kötü niyetli veri yazmak mümkün hale geliyor.
Üçüncü halka ise biraz daha modern: XenForo’nun kullandığı AWS S3 entegrasyonu (attachment’lar için). Birçok yönetici “s3://” bucket’ını public koyuyor çünkü “zaten forumdan erişilsin” diyor. Ama bucket policy’lerde “s3:GetObject” izni wildcard verilmişse ve sen Redis üzerinden yazdığın session ile S3 API’sine istek atabiliyorsan, bucket içindeki tüm dosyaları indirebiliyorsun. Bu da bazen yedek veritabanı dökümlerini bile ele geçirmene yetiyor.
Hidden content - for more
Konuyu Görebilmeniz için "Beğenmeniz ve Yorum yapmaniz" Gerekir.
Sonuç olarak, tek bir “büyük” sıfırıncı gün beklemek yerine, mevcut küçük zafiyetleri ve yanlış yapılandırmaları birleştirerek ciddi etki yaratmak mümkün. XenForo kullanan herkesin en azından Redis AUTH ve S3 bucket policy’lerini kontrol etmesini öneririm.
Bu içeriği görmek için giriş yapın.