Şiddetli vbulletin kusuru, saldırganlar tarafından uzaktan kod yürütülmesine izin verir

Dünyanın en popüler ticari forum platformlarından biri olan Vbulletin’de yeni keşfedilen bir güvenlik açığı, güvenlik için yöntem görünürlüğüne güvenmenin tehlikelerini vurguladı.

PHP 8.1 veya üstünde çalışan Vbulletin sürümlerini etkileyen kusur, saldırganların PHP’nin yansıma API davranışındaki ince ama önemli bir değişiklik sayesinde, saldırganların korunan yöntemleri kimlik doğrulaması olmadan uzaktan çağırmasına izin verdi.

Geleneksel olarak, PHP’nin yansıtma sınıfı sınıfı açık izin gerektirdi (aracılığıyla setAccessible(true)korumalı veya özel yöntemleri çağırmak için.

– Reklamcılık –

Ancak, PHP 8.1’den başlayarak, bu kısıtlama rahatlamıştı: ReflectionMethod::invoke() Artık varsayılan olarak korumalı ve özel yöntemleri çağırabilir.

Bu değişiklik, geliştirici kolaylığı için tasarlanmış olsa da, Ajax ve mobil uygulamayı yansıtmayı kullanarak dinamik olarak yönlendiren Vbulletin’in API mimarisi için felaket kanıtladı.

Savunmasız kod örneği

Savunmasız kodun basitleştirilmiş bir sürümü aşağıda gösterilmiştir:

phpclass ApiController
{
    protected function protectedMethod() {
        echo "This should be protected!";
    }

    public function handle($method) {
        if (!is_callable([$this, $method])) {
            die("Not callable!");
        }
        $refMethod = new ReflectionMethod($this, $method);
        $refMethod->invoke($this); // No visibility check!
    }
}

// Simulate a web request
$api = new ApiController();
$api->handle($_GET['method']); // /api.php?method=protectedMethod

PHP 8.1+ üzerinde erişiyor /api.php?method=protectedMethod Geliştiricinin niyetinin aksine, korunan yöntemi doğrudan yürütür.

Korumalı yöntemden uzaktan kod yürütmeye kadar

Vbulletin API gibi uç noktaları ortaya çıkarır. /ajax/api/[controller]/[method]Yansıma Kullanarak Denetleyici Yöntemlerine Yönlendirme Talepleri.

En önemlisi, erişim kontrolü küresel olarak değil, yöntem düzeyinde uygulanır.

Bir saldırgan korumalı bir yöntemi hedeflediğinde (örn. vB_Api_Ad::replaceAdTemplateYansıma tabanlı dağıtım görevlisi hala çağırabilir ve amaçlanan kısıtlamaları atlayabilir.

İstismardaki önemli teknik adımlar:

• Dinamik çağırma: API işleyicisi kullanır ReflectionMethod::invokeArgs() Yöntem görünürlüğü kontrol etmeden.
• Şablon enjeksiyonu: Savunmasız replaceAdTemplate Yöntem, daha sonra Vbulletin’in şablon motoru tarafından oluşturulan ve yürütülen keyfi şablon oluşturulmasına izin verir.
• Filtreleri atlamak: Alternatif PHP işlevi çağırma sözdizimi kullanarak şablon kodu hazırlayarak (örn., "var_dump"("test")Saldırganlar güvenlik kontrollerini atlayabilir ve keyfi PHP kodu yürütebilir.

Sömürü tablosu

Örnek kötü niyetli şablon:

xml

Bu şablon, oluşturulduğunda, saldırganın Post istekleri aracılığıyla kabuk komutlarını yürütmesine izin verir.

Yansıma bir güvenlik sınırı değildir

Bu olay PHP geliştiricileri için kritik bir dersin altını çiziyor: Yansıma asla erişim kontrolü için bir proxy olarak kullanılmamalıdır.

Koddaki yöntem görünürlüğü, özellikle dinamik yönlendirme ve yansıma söz konusu olduğunda bir güvenlik sınırı değildir.

Vbulletin istismar zinciri, küçük bir dil güncellemesinin güvensiz mimari varsayımlarla birleştirildiğinde nasıl büyük bir güvenlik etkileri olabileceğini gösterir.

Benzer kusurları önlemek için en iyi uygulamalar:

• Yöntemleri dinamik olarak çağırmadan önce her zaman açık erişim kontrol kontrollerini uygulayın.
• Özellikle API yönlendirme katmanlarında yansıma kullanımı için denetim çerçeveleri.
• Dil değişiklikleri yeni riskler getirebileceğinden, desteklenen tüm PHP sürümleri altında test kodu.

Vbulletin’in durumunun gösterdiği gibi, yazılım tasarımındaki esneklik asla sağlam güvenlik kontrolleri pahasına olmamalıdır.

Geliştiriciler, gelecekte benzer güvenlik açıklarından kaçınmak için yansıma ve dinamik gönderim kullanımlarını gözden geçirmeleri istenir.

Bu haberi ilginç bul! Anında güncellemeler almak için bizi Google News, LinkedIn ve X’te takip edin!