Fölsun beiðna frá vefþjóni

Suma vefi fýsir að sækja vefslóðir fyrir hönd notandans. Kerfi sem annast myndaforskoðun, PDF-vinnslu eða innflutning gagna geta tekið við slóð, varpað af stað eigin HTTP-beiðni og skilað afrakstrinum til baka. Við slíkar kringumstæður er það ekki lengur vafrinn okkar sem tengist áfangastaðnum, heldur sjálfur vefþjónninn.

Gefist notandanum tækifæri til að stýra áfangastaðnum, getur hann í ákveðnum kerfum knúið þjóninn til þess að biðja um efni sem einungis er aðgengilegt innan ramma sama æfingakerfis. Það kallast SSRF, server-side request forgery, eða fölsun beiðna frá vefþjóni.

Í verkefninu Myndasóknarinn hefur verið komið fyrir einni tilbúinni innri leið. Sú athöfn okkar að senda beina beiðni á leiðina mætir jafnan höfnun, en verkefnið ljóstrar hins vegar upp um sérstaka labbslóð sem sækibiðlara þjónsins er heimilt að nýta. Með því að bera svörin saman komumst við hjá því að þurfa að leita uppi vistföng eða kanna aðrar þjónustur.

Tvær beiðnir, tveir sendendur

Venjulegt flæði lítur svona út:

vafrinn okkar
    │
    │ 1. biður /fetch að sækja slóð
    ▼
vefþjónn verkefnisins
    │
    │ 2. sendir nýja HTTP-beiðni
    ▼
innri labbþjónusta

Hin fyrri beiðni á uppruna sinn hjá okkur, en sú síðari berst hins vegar frá vefþjóninum og skartar því hans eigin netauðkenni. Fyrir vikið gæti innri þjónustan litið á sendandann öðrum augum en þegar við eigum í hlut og köllum hana beint.

Kóðinn á bak við slíkt flæði gæti í grófum dráttum verið:

target = request.args["url"]
result = lab_http_client.get(target)
return result.body

Notandinn velur target, en HTTP-biðlarinn keyrir hjá þjóninum. Öryggismörkin eru:

notandastýrð vefslóð → HTTP-biðlari þjónsins → net þjónsins

Þess ber að gæta að notkun JavaScript í vafra á fetch()-fallinu telst engan veginn til SSRF-veikleika, enda er það vafrinn sjálfur sem þá sendir beiðnina. Við leitum öllu heldur að því augnabliki þegar bakendinn, sjálfvirkur róbot eða tiltekið bakgrunnsverk tekur sig til og sækir slóðina.

Netútsýni þjónsins

Vefþjónn kann að búa yfir aðgangi að innri þjónustum (e. internal services) sem eiga einvörðungu að vera á færi annarra hluta sama forrits eða æfinganets. Góð dæmi um slíkt eru margvísleg stjórnendaviðmót, mælingaþjónustur eða önnur forrit sem deila sama gámi eða klasa.

Lykkjuvistfang (e. loopback address) vísar aftur á sama netnafnrými. localhost er algengt heiti fyrir slíka tengingu. Hið nákvæma form framsetningarinnar skiptir ekki höfuðmáli í þessum kafla; verkefnið Myndasóknarinn dregur fram fullbúna innri slóð svo nemandanum sé gert kleift að sniðganga það að smíða hana eða giska á hana.

Hugmyndin er að þjónninn geti séð:

innri beiðni frá eigin tengli

þar sem opinbera ingressið sér:

ytri beiðni frá keppanda

Sú iðja að treysta blindandi á þennan mun einan sér getur auðveldað boðið veikleikum heim. Prófunin í gagnaglímunni dregur áhrifin fram í dagsljósið með tveimur tilbúnum svörum.

Skýjalýsigögn sem áhrifadæmi

Skýjaumhverfi eiga það til að framreiða svokölluð skýjalýsigögn (e. cloud metadata) handa vinnslueiningum sínum. Þar kann að vera að finna upplýsingar um sjálfa vélina og, ef svo ber undir í viðkomandi umhverfi og stillingum, jafnvel tímabundin aðgangsgögn.

Þetta varpar ljósi á það hvers vegna SSRF-veikleiki kann að hafa víðtækari afleiðingar en það eitt að sækja almenna mynd. Við prófum þó aldrei raunverulegar lýsigagnaþjónustur í þessari leið og birtum engin vistföng þeirra. Ef slíkt efni er námsmarkmið þarf verkefnið að líkja eftir þjónustunni innan lokaðs gervinets.

Hvað sér notandinn?

SSRF-verkefni geta gefið mismiklar upplýsingar.

Svarbirt SSRF (e. content-based SSRF) skilar innihaldi hins innri svars beint í HTTP-svari verkefnisins. Við slíkar kringumstæður reynist leikur einn að bera saman beina beiðni og þá sem miðlað er í gegnum þjóninn.

Hálfblind SSRF-tilfelli kunna á hinn bóginn einungis að sýna stöðukóða, stærð svarsins eða hreinlega almenna villu. Verkefnið þarf þá að gefa lítið, fast mengi samanburðartilvika svo engin upptalning sé nauðsynleg.

Í blindri SSRF (e. blind SSRF) sér notandinn ekki innra svarið. Afmörkuð gagnaglíma getur vissulega útvegað sérstakan móttakara og annál (e. log) sem staðfestir tilvist beiðni. Forðastu þó að nýta þér móttakara á vegum þriðja aðila eða reyna að snúa blindu tilviki upp í hreinræktaða netkönnun.

Myndasóknarinn birtir svarið beint. Ein miðluð beiðni nægir.

Slóðarþáttun

Vefslóðin sjálf er skipulagt gagnasnið sem samanstendur af skema, hýsi, tengi, slóð og fyrirspurn. Ekki má heldur gleyma að notandaupplýsingar og svokölluð brot (e. fragments) geta einnig verið þar á ferðinni. Forrit sem athugar hráan streng en annað bókasafn túlkar slóðina getur komist að annarri niðurstöðu um áfangastaðinn.

Slíkt ósamræmi gengur undir heitinu slóðarþáttunarvilla (e. URL parsing discrepancy). Í CTF er hún aðeins viðeigandi ef verkefnið sýnir tvö lög sem túlka sömu slóð á ólíkan hátt.

Í Python má skoða hluta slóðar með stöðluðum þáttara:

from urllib.parse import urlsplit

parsed = urlsplit(url)
print(parsed.scheme)
print(parsed.hostname)
print(parsed.port)
print(parsed.path)

Þetta dæmi dregur fram með hvaða hætti hugbúnaðarsmiður eða höfundur verkefnis greinir slóðina í skýra hluta, fremur en að láta sér nægja að bera saman óunninn texta. Í þessum kafla verður ekki lagður fram neinn listi yfir bragðvísa framsetningu til að blekkja slóðarsíur. Verkefnið okkar samþykkir aðeins nákvæma labbslóð sem það birtir sjálft.

Framsendingar og endanlegt mark

HTTP-biðlarar geta hæglega fylgt framsendingum eftir. Þegar svo ber undir er engan veginn víst að upphafsslóðin sé sú sama og slóðin sem endanlega verður fyrir valinu:

upphafsslóð → framsending → endanleg slóð

Í gagnaglímum getur þetta skipt sköpum, sér í lagi ef eitt kerfislag lætur sér nægja að rýna aðeins í fyrsta skref ferlisins. Verkefni sem ætlað er að kenna þá hugsun verður að útvega eigin framsendingarþjón innan lokaðs nets og skilgreina af nákvæmni hvaða slóðir séu í raun á dagskrá.

Myndasóknarinn fylgir ekki framsendingum. Ef svar sýnir 3xx á sækibiðlarinn að skila því sem niðurstöðu í stað þess að tengjast nýjum áfangastað. Framsendingar mæla því beinlínis gegn þessari tilgátu og eiga engan veginn að þjóna sem ætluð hjáleið í þessu verkefni.

DNS og breyting milli skrefa

Hýsisheiti er jafnan varpað yfir í IP-tölu. Ef forrit tekur upp á því að fletta nafninu upp við sjálfa athugunina, en annað kerfislag flettir því svo aftur upp þegar til tengingar kemur, getur lokaniðurstaðan fræðilega séð tekið breytingum. Þetta er kallað DNS-endurbinding (e. DNS rebinding).

Við förum aðeins yfir hugmyndina. Við rekum ekki DNS-þjón, gefum ekki leiðbeiningar um breytinguna og notum hana ekki í byrjendaverkefninu. Hinn hagnýti lærdómur er sá, að hið endanlega vistfang vegur jafnan þyngra á metunum en texti hýsisheitisins einn og sér.

Ef CTF fjallar sérstaklega um DNS-breytingu þarf það að útvega afmarkað lén, lokað net og stöðuga tilraunauppsetningu. Að öðrum kosti ber nemandanum að líta svo á að vel staðfest og föst tenging sé vísbending sem mælir gegn þeirri lausnarleið.

Skemu og leyfðir áfangastaðir

Bókasöfn sem annast gagnaöflun geta hæglega styðst við fleiri en eitt vefslóðarskema. Því er mikilvægt að átta sig á hvaða skemu verkefnið heimilar hverju sinni. Í þessari leið höldum við okkur við HTTP innan tilbúins labbs og prófum ekki skrár, aðrar samskiptareglur eða ytri þjónustur.

Leyfilisti í CTF getur afmarkað:

• skema,
• hýsi,
• tengi,
• og eftir atvikum slóð.

Ef þjónninn tekur þátt í því að þátta slóðina af nákvæmni, ber alla þessa þætti saman við hinn afmarkaða labblista, slekkur á framsendingum og lokar fyrir aðra útleið, má telja víst að almennar SSRF-hjáleiðir séu ekki rökrétt næsta skref. Myndasóknarinn opnar aðeins eina innri leið viljandi til að sýna grunnflæðið.

Göngudæmi: Myndasóknarinn

Byrjaðu á beinni beiðni á flaggleiðina í gegnum opinbera verkefnisslóð:

BASE_URL='https://slod-verkefnisins.example'

curl -i "$BASE_URL/internal/flag"

Skráðu höfnunina hjá þér sem grunnlínu. Síðan verkefnisins mun síðan opinbera fullbúna innri labbslóð; komdu henni fyrir í breytu algjörlega óbreyttri:

INTERNAL_URL='<innri labbslóð sem verkefnið birtir>'

Fáðu þjóninn nú til þess að sækja einmitt þessa tilteknu slóð:

curl -i -G "$BASE_URL/fetch" \
  --data-urlencode "url=$INTERNAL_URL"

Nú eru tvö skref:

þú → /fetch → innri labbleið

Ef síðara svarið færir þér fánann, er ljóst að þjóninum tókst að varpa beiðninni af stað úr öðru netsamhengi. Vertu þess þó minnug(ur) að þessi kafli sýnir hvorki raunverulegt innra vistfang né sjálfan fánann.

Nái beiðnin ákveðnum tímamörkum gæti verið að þjónustan sé hreinlega rangt stillt og geti ekki svarað eigin innri beiðni. Slíkt telst til útfærsluvillu í verkefninu sjálfu, en er alls engin hvatning til þess að prófa önnur tengi eða hýsa.

Vísbendingar gegn veikleikum og falskar niðurstöður

Endurvarpi vefurinn slóðinni án þess að nokkur sækibiðlari komi þar við sögu, er engan veginn um SSRF að ræða. Afhentur kóði sem velur efni úr föstu korti eftir auðkenni, án netbeiðni, mælir einnig gegn tilgátunni.

Gættu þess að líta ekki á CORS-villu í vafra sem sönnun fyrir SSRF-veikleika. CORS-reglur ráða því einungis hvort JavaScript-kóða sé heimilt að lesa svar á milli ólíkra uppruna, á meðan SSRF snýst alfarið um þær beiðnir sem bakendinn sjálfur sendir frá sér. Gefðu þér tíma til að komast til botns í því hvaða ferli það var sem raunverulega stofnaði til tengingarinnar.

Almenn villa er heldur engin trygging fyrir því að innri þjónusta hafi svarað kallinu. Miklu sterkari sönnunargögn felast í þekktu gervimerki, fána úr tilbúinni innri leið eða hreinlega skráningu í annál frá móttakara á vegum verkefnisins.

Nákvæm þáttun vefslóða, staðfesting á endanlegum áfangastað, lokað fyrir framsendingar og heft útleið – allt eru þetta skýrar vísbendingar sem mæla gegn raunhæfni hvers kyns hjáleiða. Í gagnaglímum fyrir byrjendur ber okkur því að styðjast við hina ætluðu labbslóð, eða snúa okkur að annarri tilgátu, fremur en að þreyta okkur á sífellt óvenjulegri framsetningu á vistföngum.

Samantekt

SSRF verður þegar notandastýrð slóð lætur vefþjón senda beiðni. Hin síðari beiðni á rætur sínar í öðru netsamhengi og kann í ákveðnum kerfum að ná til tilbúinnar innri þjónustu, sem ytri beiðnum er að öllu jöfnu varnað aðgangs að.

Við greinum beiðni vafrans frá beiðni þjónsins og skoðum skema, hýsi, tengi og endanlegt mark. Slóðarþáttun, framsendingar og DNS-breyting geta skipt máli á hugmyndastigi, en þessi byrjendakafli kennir ekki hjáleiðalista. Hitt raunverulega og lifandi verkefni útvegar eina nákvæma og lokaða labbslóð, og útheimtir ekkert meira en einfaldan samanburð á tveimur svörum.

Í eftirfarandi kafla munum við rýna í XML-þáttara sem búa yfir þeim eiginleika að geta sótt svokallaðar ytri einindir. Þar geta bæði skráarlestur og beiðnir frá þjóninum sprottið beint upp úr sjálfu gagnasniðinu, fremur en úr hversdagslegum url-reit.