Gelişmiş XXE güvenlik açıklarından yararlanmak için eksiksiz bir rehber

XML Dış Varlık (XXE) güvenlik açıkları, modern web uygulamalarında en çok gözden kaçan ama etkili güvenlik açıklarından biridir. Her ne kadar tespit edilmesi ve kullanımı daha zor olmalarına rağmen, etkileri şiddetli kalır, genellikle saldırganların dahili dosyaları okumasına, sadece dahili ağlara ulaşmasına ve ciddi durumlarda bile uzaktan kod yürütmesini yürütmesine izin verir!

Bu makalede, XXE güvenlik açıklarının ne olduğunu ve bunları nasıl tanımlayacağını ve kullanmayı öğreneceğiz. Ayrıca bazı gelişmiş vakaları da ele alacağız.

Hadi dalalım!

XML Harici Varlık (XXE) enjeksiyonları, saldırganların Parsers’ın yeteneklerinden yararlanmak amacıyla XML verilerini manipüle etmelerini sağlayan bir güvenlik açığı sınıfıdır. Bu genellikle saldırganın, keyfi ana bilgisayarlara giden HTTP bağlantıları (sunucu tarafı istek ambalyası), dahili dosyalar okuma veya şiddetli durumlarda bile uzaktan kod yürütme yoluyla makineye erişim elde etmek için savunmasız uygulama bileşenini teşvik edebilmesine neden olur.

Bunun yerine bir video izlemeyi mi tercih ediyorsunuz? İzle XXE güvenlik açıkları hakkında öğretim kılavuzu Kanalımızda!

XXE enjeksiyonlarının XML ayrıştırma sırasında yetersiz kullanıcı giriş validasyonundan kaynaklandığını bilerek, XXE güvenlik açıklarına göre yaygın olarak duyarlı birkaç uygulama bileşenini kolayca listeleyebiliriz.

• XML tabanlı web hizmetleri (verileri XML biçiminde kabul eden ve işleyen SOAP, REST ve RPC API’leri)

• XML formatında veri veren veya kabul eden herhangi bir içe aktarma/dışa aktarma özelliği

• RSS/ATOM besleme işlemcileri

• Belge Görüntüleyenler/Dönüştürücüler (DOCX, XLSX, vb. Gibi XML tabanlı belgelerde bulunan herhangi bir özellik)

• Dosya Yükleme XML (SVG görüntü işlemcileri gibi)

Bir kural, her zaman keyfi verileri XML formatında kabul eden ve işleyen herhangi bir potansiyel uygulama bileşenini aramaktır. Bazı dinlenme API’leri (kasıtsız olarak) verileri XML dahil birden çok formatta kabul edecek şekilde yapılandırılmıştır. Her zaman hata ödül hedefinizin ne kabul edebileceğini test etmeye değer.

Artık XXE güvenlik açıklarının ne olduğunu ve onları nerede bulacağımızı bildiğimize göre, onlardan yararlanabileceğimiz bazı yollardan geçelim.

Korunmasız bir bileşen aracılığıyla XXE güvenlik açıklarını anlamakla başlayalım. Aşağıdaki savunmasız kod snippet’ine bir göz atın:

Yukarıdaki snippet’i analiz ederek birkaç sorunu tespit edebiliriz:

• Yeterli kullanıcı giriş doğrulaması yok

• XML ayrıştırıcısı XML varlıklarını destekler (bkz. LIBXML_NOENT bayrak)

• XML ayrıştırıcısı, harici DTD’leri otomatik olarak yükleyecek şekilde yapılandırılmıştır (belge türü tanımları, bkz. LIBXML_DTDLOAD bayrak)

Bu 3 koşulun hepsi bir XXE saldırısını kolaylaştırmaya yardımcı olur. Aşağıda gösterildiği gibi kötü amaçlı bir yük göndererek, harici varlığımızda belirttiğimiz yerel bir dosyayı kolayca yükleyebiliriz (xxe):

]>

    
        &xxe;
        ...
    

XXE – SSRF

Benzer şekilde, yerel bir dosya bildirmek yerine, sunucu tarafı istek ambalge saldırıları yapmak ve yanıtı almak için keyfi bir ana bilgisayara URL ekleyebiliriz.

]>

    
        &ssrf;
        ...
    

Tabii ki, yukarıda açıklandığı gibi basit XXE enjeksiyon güvenlik açıklarına karşı savunmasız uygulama bileşenleri bulmak oldukça nadirdir. Özellikle web geliştiricileri arasındaki güvenlik farkındalığındaki artış ve XXE gibi tehlikeli enjeksiyon saldırılarını aktif olarak azaltmayı hedefleyen yeni yerel güvenlik özellikleri ile.

Öyleyse daha gelişmiş örneklere bir göz atalım.

UÇ! Bu örnekte, tüm kullanıcı girişi veri nesnesini yansıtarak XXE saldırısını basitleştirdik. Gerçekçi senaryolarda, farklı parametreleri enjekte etmeyi ve yanıt değişikliklerini gözlemlemeyi denemeniz daha olasıdır.

Harici DTD’lerle XXE’den sömürülme

Bazı durumlarda, filtreleyen hedeflerle karşılaşacaksınız. file:// Protokol ve boş bir değerle değiştirin veya tamamen engelleyin. Bunu atlamak için, bir belge türü tanımı (DTD) olan XML içinde özel bir özellik kullanabiliriz.

DTD, esasen kötü amaçlı XML yapımızda kullandığımız varlıkları belirten bir dosyadır. Şimdi, yerel olarak ilan etmek yerine (tıpkı daha önce yaptığımız gibi) ve bir güvenlik filtresinin kaldırılması file:// Protokol. DTD’mizi harici bir dosyada bildirebilir ve filtrelemeyi tamamen atlayabiliriz.

Sunucumuzda barındırılan aşağıdaki Belge Türü Tanımı (DTD) dosyasını aldığımızı varsayalım:

">
%e;
%xxe;

XXE yükümüzü, savunmasız uygulamanın sunucumuza ulaşmasını sağlayacak, kötü niyetli DTD dosyamızı yükleyecek ve içeriğini yürütebilecek şekilde oluşturabiliriz:

 %xxe;]>

Bu yaklaşımı kullanarak, artık engellenenleri belirtmemiz gerekmiyor file:// Dahili dosyaların içeriğini açıklarken savunmasız sunucuya protokol!

Bir parametre varlığıyla kör XXE’den yararlanmak

Bazı geliştiriciler XXE saldırılarına karşı proaktif önlemler almaya ve varlıkları kullanıcı girişinden çıkarmaya çalışır. Bildiğimiz gibi, bir XML varlığı (bir değişkenin eşdeğeri) bildirilir ve aşağıdaki formatta kullanılır:

]>
&name;

Ampers ve sembolü filtreleme (&) genellikle mantıklı bir şey gibi görünüyor. Ancak, bunun yerine parametre varlıklarından yararlanarak bunu kolayca atlayabiliriz. Parametre varlıkları bir yüzde işareti ile tanımlanır (), referenced with the following syntax: %name;

Ve yalnızca DTD’nin kendisinde referans verilebilir, burada harici bir kaynak yüklemek için parametre varlığı kullanan bir XXE yükü örneği:

 %xxe;]>

Bu yaklaşımla, normal harici varlıkları engelleyen korumaları ve filtreleri atlamak için parametre varlıklarını kullanabiliriz.

Kaynak tükenmesi yoluyla xxe’den yararlanıyor (“milyar gülüyor”)

Daha önce de belirttiğimiz gibi, XML ayrıştırıcılarındaki güvenlik yanlış yapılandırmaları yeni saldırı vektörleri açabilir ve XXE güvenlik açıklarından yararlanmamıza izin verebilir. Bazı durumlarda, varlık genişleme sınırları belirlenmediğinde, bunu dış varlıkları katlanarak genişletmek için pratik olarak kullanabiliriz.

Daha iyi ‘milyar gülüşler’ saldırısı olarak bilinen üstel varlık genişlemesi, özyinelemeli varlık beyanlarından yararlanır, bu da yüksek hafıza tüketimi ve hatta sistem çökmesine neden olur:

  
  
  
  
]>
&e9;

Bu saldırı özellikle tehlikelidir, çünkü yükün kendisi oldukça küçüktür ve genişleme ayrıştırma sırasında gerçekleşir, ancak sunucu kaynaklarını tamamen ezebilir.

UÇ! Hizmet Reddetme (DOS) saldırılarını test ederken ve yalnızca izin verildiğinde her zaman program yönergelerine uyun!

UTF-7 kodlama yoluyla XXE’den sömürülme

Bunu fark etmiş olabilirsiniz, ancak tüm XXE yüklerimizde sadece yalnızca UTF-8 kodlamasını kullandık. Daha önce gördüğümüz gibi, bazı filtreleme kuralları esas olarak kötü niyetli anahtar kelimelerin ve sözdizimi sembollerinin soyulmasından oluşur.

Ancak, ayrıştırıcı birden çok karakter kodlamasını kabul edecek şekilde yapılandırılmışsa, esasen UTF-8 karakter seti yerine UTF-7’de kodlanan kötü amaçlı yükümüzü gönderebiliriz:

+ADw-+ACE-DOCTYPE+ACA-data+ACA-+AFs-+AAo-+ACA-+ACA-+ADw-+ACE-ENTITY+ACA-xxe+ACA-SYSTEM+ACA-+ACI-file:///etc/passwd+ACI-+AD4-+AAo-+AF0-+AD4-+AAo-+ADw-data+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ADw-post+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ADw-post+AF8-title+AD4-+ACY-xxe+ADs-+ADw-/post+AF8-title+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ACA-+ADw-post+AF8-desc+AD4-xyz+ADw-/post+AF8-desc+AD4-+AAo-+ACA-+ACA-+ACA-+ACA-+ADw-/post+AD4-+AAo-+ADw-/data+AD4-

Bu yaklaşım, özellikle XXE enjeksiyon saldırılarını önlemek için kara listeye alınan anahtar kelimelere dayalı filtreleyen sistemler gibi çeşitli giriş doğrulama kısıtlamalarını atlamamıza yardımcı olabilir.

UÇ! XML Prolog’u yükünüze eklemeyi ve kodlamayı “UTF-7” olarak ayarlamayı unutmayın!

Uzak Kod Yürütülmesine Artan XXE

Bazı durumlarda, sistem dosyalarını okumanın veya dahili ağlara ulaşmanın ötesine geçmek mümkündür. Örneğin, Beklenen PHP modülü etkin olduğunda, sistem komutlarını yürütmek için sarmalayı kullanabiliriz:

]>

    
        whoami: &exec;
        ...
    

Bu spesifik PHP modülü, geliştiricilerin PTY aracılığıyla işlemlerle etkileşime girmesini sağlar. İlk XXE güvenlik açığımızı artırmak için kullanabileceğimiz birkaç ambalaj var:

• PHP Filtre Sargısı

• PHP Arşiv Sarma (Phar)

• ZIP/Kavanoz Sargısı (Arşivlerde Dosyaları Okumak İçin Kullanılır)

• Veri

• Gopher

• FTP

• Dikt

Bazılarını ayrıntılı olarak keşfedelim.

PHP Filtre Sargısı

PHP filtre sargısı, geliştiricilerin verileri filtrelemesine, sterilize etmesine ve doğrulamasına yardımcı olmayı amaçlayan PHP filtre uzantısının bir parçasıdır. Bu sargıyı yerel dosyaları okumak için kullanabiliriz (PHP kaynak kodu gibi):

]>

    
        &xxe;
        ...
    

Bu PHP filtresi, PHP dosyamızın içeriğini Base64’te kodlayacak ve bize iade eder.

PHP Arşiv Sarma (Phar)

PHP Arşivi Sarma Uzantısının bir parçası olan Phar Stream Sargacı, geliştiricilerin bir Phar dosyasındaki dosyalara erişmesine izin vermek için kullanılır (bir PHP uygulaması veya tek bir dosyaya derlenen kütüphane). Bu sarmalayı, PHP dosyalarının içeriğini dahili bir Phar dosyasının içindeki açıklamak için kullanabiliriz:

]>

    
        &xxe;
        ...
    

Bu sargı ayrıca güvensiz firalizasyon güvenlik açıklarını tetiklemeye yardımcı olabilir.

UÇ! Bazı sargıların yerel olarak desteklenmediğini ve kullanılmadan önce uzantıların/modüllerin etkinleştirilmesini gerektireceğini unutmayın!

İkinci dereceden XXE enjeksiyonu

İkinci dereceden XXE enjeksiyonları, kötü amaçlı yükün ilk olarak saklandığı ve daha sonra alındığı, alındığı ve yürütüldüğü XXE saldırılarının daha karmaşık bir varyantıdır. İkinci dereceden güvenlik açıklarının, öngörülemeyen ve gecikmiş infaz nedeniyle tanımlanması ve sömürülmesi daha zor olduğu bilinmektedir.

Bu genellikle, örneğin, işlevlerin içe aktarılması için geçerlidir. Bu tür özellikler genellikle eşzamansız olarak çalıştırmak için geliştirilmiştir. İlk başta, kötü amaçlı giriş dosyanızı yükleyerek sağlarsınız. Ardından, bir arka plan çalışanı (savunmasız bileşen) yükünüzü ele almadan önce içe aktarma talebiniz sıraya girecektir.

İzlenmesi gereken bir kural, yalnızca giriş noktalarında değil, tüm Web uygulaması veya API boyunca tüm XML veri akışlarını izlemenizi sağlamaktır.

XXE güvenlik açıkları hala web uygulamalarında mevcuttur, ancak sertleşmiş güvenlik önlemleri ve geliştiriciler arasında artan güvenlik bilinci nedeniyle tespit edilmesi oldukça zordur. Özellikle bu makalede belirtilen tüm sömürü yöntemlerine karşı, hedeflerinizi potansiyel XXE güvenlik açıkları için test etmek her zaman iyi bir fikirdir.

Yani, XXE güvenlik açıkları hakkında yeni bir şey öğrendiniz… Şu anda, becerilerinizi test etme zamanı! Intigriti’deki 70+ genel böcek ödül programlarımıza göz atın, diğer birçok avcı zaten Intigriti’de SSRF güvenlik açıklarını buldu ve bildirdi ve kim bilir, belki bugün bizimle bir ödül kazanmanız için bir sonraki!

Bugün Intigriti’de hacklemeye başlayın