OWASP Metodologija | Etiško Įsilaužimo Technologijos II -oji dalis

Tomas Savenas
savenas.lt
Published in
9 min readAug 13, 2020

--

OWASP tai yra bendruomenė, kurianti laisvai prieinamus straipsnius, metodikas, dokumentus, įrankius ir technologijas web aplikacijų saugumo srityje. Maždaug kas 3–4 metus yra išleidžiamas dokumentas pažeidžiamumu pažinimo OWASP Top 10, kuris yra skirtas web aplikacijų kūrėjams ir vystytojams. Bendruomenės nariai kruopščiai analizuoja saugumo pažeidimus, žurnalinius įrašus, ir kitus šaltinius, tam, kad suklasifikuotų eilės tvarka, pagal dažniausiai pasitaikančius ir turinčius didžiausią poveikį pažeidžiamumus. Taip pat pateikiamos prevencijos priemones, būdai sumažinti rizikas.

Kadangi naudojamos programavimo technologijos keičiasi, galu gale ir programuotojų įpročiai, tai dokumentą reikia atnaujinti. Atsižvelgiant į rekomendacijos programuotojai turėtų pritaikyti saugumo rekomendacijas kad sumažintų rizikas [9]

JAV ir Europoje organizuojamos metinės konferencijos AppSec. Susirenka daug saugumo specialistų web aplikacijų kūrėjų, teikiami pranešimai, OWASP bendruomenės nariams dalyvio mokestis yra mažesnis, nariu galima tapti užsiregistravus jų svetainėje. Taip pat vietiniai susitikimai “OWASP Chapters”, Lietuvoje kartą arba kelis kartus per metus yra organizuojami. Susitikimo metu yra skaitomi pranešimai apie saugumo spragas ir panašias temas su web aplikacijomis dalinamasi patirtimi, po susitikimo pasiliekama atsigerti gėrimo neformaliai pašnekėti. Apie artėjanti renginį galima rasti FaceBook grupėje.

Šiame aprašyme mes toliau nagrinėsime detaliau su pavyzdžiais kiekvieną iš dešimties spragų. Praktinė dalį galima atlikti TryHackMe kambaryje OWASP Top 10.

Prieš pradedant nagrinėti reikėtų pasitikslinti kelias savokas kurias naudosime šiame aprašyme: Ar kiekviena interneto svetainė yra web aplikaciją?

Ko gero vieno teisingo atsakymo nėra, tačiau Web aplikaciją tai internetu perduodamas dinamiškai sugeneruojamas turinys, naudojamos įvairios programavimo technologijos, apjungiamos kitos išorinės sistemos, duomenų struktūros. Paprastai turi autentifikacijos mechanizmus sesijos išlaikymo mechanizmas.

Kai tuo tarpu web svetainė tai įprastas statinis turinys, kuriame išdėstyti yra naudojama HTML struktūra.

OWASP Top 10 [2017]

[A1] Injekcijos

Tai yra labiausiai paplitusi, bei pavojingiausia spraga, kai kenkėjiškas kodas nėra validuojamas kliento pusėje, o įvestas turinys gali būti interpretuojama kaip komandos ir parametrai serverio pusėje.

Injekcijos yra skirstomos į komandų ir SQL. Priklausomai nuo naudojamos technologijos injekcijų esmė tą pati tik skiriasi sintaksė ir tolimesnis naudojamas, bei rezultatas.

Sėkmingai atlikus SQLi, rezultatas yra manipuliavimas duomenų bazių paslauga ir/arba pačiais duomenimis.

Sėkmingai atlikus komandų injekcija, rezultatas gali būti visos operacinės sistemos kontekste įskaitant visus duomenys joje esančius.

Priemonė prieš injekcijos — įvestų duomenų validaciją ir sanitizacija leidžiant priimti tik tokį duomenų tipą su kuriuo funkcijai ir reikia dirbti, bet ne interpretuojant kitaip. Daugiau pasiskaityti [10]

SQLi

SQLi skirstomos į kelis tipus [11] pagrindinės yra:

Error-Based SQLi — kai gaunamas HTTP atsakymas kartu su SQL klaida, toliau reikia suformuoti sinktase taip, kad gautume duomenų bazės įrašus.

Time-Based Blind SQLi, panašiai kaip ir klaidos tipu, tačiau rezultatas nėra matomas kartu su HTTP atsakymų, viskas remiasi SQL užlaikymo funkcija (skirtingai nuo duomenų bazės: sleep, WAIT FOR TIME)

Out-of-Band SQL Injection, panašiai Time Based, atsakymo nematome, tačiau galime suprasti apie teisingą arba neteisingą naudojimą iš išorinio šaltinio į kurį bus kreipiamasi.

Išvesties kodo pvz.:

String query = "SELECT * FROM accounts WHERE custID='" + request.getParameter("id") + "'";

Error Based SQLi Atakos pvz.:

http://example.com/app/accountView?id=' or '1'='1

Verta paminėti apie specialiuosius simbolius kai kurie simboliai gali sukelti klaidų vykdant užklausas. Dėl to siūloma naudoti tokias funkcijas kaip [12]:

mysql_real_escape_string()

Komandinės injekcijos

Taip pat kaip ir SQLi, taip ir komandų įterpimo yra aklosios ir išorinės (Blind Based, Out of Band injection)

Web aplikacija gali serverio pusėje įvykdyti sistemines komandas. Paimkime pavyzdį su PHP, naudojant system() funkcija, perduodami argumentai bus interpretuojami kaip operacinės sistemos komandos ir mums kartu su HTML atsakymų grąžins koks yra naudotojo id tas kuris leidžia web serverio aplikaciją. Paprastai tai būna Apache web serverio paslauga vardu www-data, pasitaiko ir root t.y. administratoriaus teisėmis veikiančios paslaugos.

<?php system('id');?>

Toliau mes galime suformuoti užklausą, kad gautume Reverse Shell t.y. atgalininiu ryšiu užmezgama komandų interpretatorių. Atsižvelgiant į serverį galima pasirinkti atitinkamą Reverse Shell metodą: [2]

[A2] Sugadinta Autentifikacija

HTTP protokolas yra vadinamas stateless, tai yra be būsenos saugojimo. Kiekviena užklausa tarp kliento-serverio veikia kaip atskiras mechanizmas ir nežino apie buvusi ar būsimą užklausą. Dėl turi būti prie užklausos pridėta “sesijos sausainiukas” tam, kad serveris žinoti, kas siunčia užklausą, nes pagal tai galima grąžinti turinį ir sekti sesiją.

Jeigu piktavalis aptiktų autentifikacijos mechanizmo spragą, tuomet tai leistų prieiti prie kitų naudotojų paskyrų.

Silpni sesijos sudarymo mechanizmai

Jeigu sesijos reikšmė sudaroma taip, kad iš rezultato galima nuspėti kokie komponentai buvo panaudoti. Taip pat web aplikacijos registracijos logika sugadinta ir galima užregistruoti dar kartą jau egzistuojanti naudotoją. Jeigu yra admin naudotojas, užregistravus su tarpeliu priekyje “ admin” aplikacija nuvalo nereikalingą tarpelį, nes nėra laikomas simbolis.

Silpni ir įprasti slaptažodžių: Gali būti pakankamai saugus slaptažodžių sesijos mechanizmas tačiau, slaptažodžio poliką leidžia sudaryti slaptažodį į kelių raidžių, be papildomų kitų simbolių, nereikalaują keisti.

Dar blogiau yra kai be silpnų slaptažodžių, aplikaciją leidžia spelioti ir nedraudžia po nesėkmingų bandymų.

Vienos dažniausių web aplikacijų spragų yra “Brutalios jėgos” slaptažodžiu speliojimas iš eilės, ar kai turi rinkinį ar duomenų bazę, o web aplikacija neriboja bandymų prisijungti.

Atakos prieš slaptažodžius

Piktavaliai įvairiasiausias ir kūriškais būdais medžioje prisijungimus, žinodami, kad žmones nesikeičia, ir naudoja tuos pačius slaptažodžius praktiškai visur, taip pat tą patį slaptažodį net neįtariant naudoja jo kolega. Galima būtų teigti, kad slaptažodžiai yra kolektyvinės pasąmonės dalis. Mes juos tuos pačius ir silpnus naudojame, nes jie įprasti patogus dėl to tampa populiarus. Skaičiu seka yra visur tą pati. Lietuvoje naudojamu top 100 slaptažodžių nedaug skiriasi.

Žodyno ataka;

Žodyno ataka;

Rainbow tables;

Rainbow tables;

Brute-force;

Slaptažodžių sudarymo ypatybės

Naudojama maišos funkcija, kuri yra fiksuoto ilgio, lengvai ir greitai apskaičiuojama, tolygiai paskirsto raktus po visą lentelę. Sunku apskaičiuoti į kitą pusę.

Kolizija — situacija, kai į vieną vietą pretenduoja du arba daugiau raktų, vadinama kolizija.

Druska tai atsitiktinė bitų seka, maišos funkcijoje pridedama prie slaptažodžio.

Top 100 lietuviškų slaptažodžių

Ar mano slaptažodis nutekintas?

Galima įvesti email ir pasižiūrėti ar toks buvo nutekintas: https://haveibeenpwned.com/ nebūtinai emailo nuomenys visi žinomi.

Breach Compilation [3]

Atidenti jautrūs duomenys (Sensitive Data Exposure)

Tai gali sistemos naudotojų prisijungimo duomenys, kontaktinė, finansinė ar kitą informacija. Piktavaliai gali tiesiogiai prisijungti prie komunikacijos kanalo ir įsiterpti tarp web aplikacijos ir kliento naršyklės (Men in The Middle). Taip nutinka, kai yra naudojamas atviro teksto, neiššifruotas protokolas HTTP, arba silpni šifravimo mechanizmai. Taip pat per naudojamas tas pats šifravimo raktas. Dėl atidžios konfigūracijos ar aplikacijos dizaino, duomenys gali būti prieinami nebūnai tiesiogiai, bet dėl kito aplikacijos pažeidžiamumo, pvz.: jeigu turime duomenų bazės failą pačiame web aplikacijos kataloge, duomet dėl menkos spragos tokios kaip “Directory Path Traversal” galėtume nesunkiai nuskaityti esančius įrašus.

Prevencijos priemonės:

Implementuotas stiprus šifravimo mechanizmai, duomenų kontrolė, kiti reikalingi nustatymai web aplikacijos sukietinimui.

XXE (XML išorinių objektų) ataka

XML išorinių objektų injekcija (dar žinomas kaip XXE) yra pažeidžiamumas, leidžiantis užpuolikui trukdyti programai apdoroti XML duomenis. Jeigu yra galimybė įkelti XML failus, ar nusiųsti XML formato užklausą ir nėra validuojami įvedami duomenys, tuomet atsiranda galimybė peržiūrėti failus, manipuliuoti serverio pusės užklausomis. Kai kurias atvejais pasinaudodamas XXE pažeidžiamumu,galima atlikti serverio užklausų klastojimo (SSRF) atakas [6] arba sutrukdyti veikiančias paslaugas (DoS Billion Laughs attack) [7].

XXE atakos gali būti dvejopos: in-band ir out-of-band (OOB-XXE) kitaip dar blind XXE.

in-band kai atakos rezultatas gaunas iškarto kartu su HTTP atsakymu.

OOB- kai nėra matomas rezultatas grįžusiame HTTP užklausome, tačiau atakos rezultatas gali būti kitaip įvertintas.

XML tai duomenų struktūrų kalga panašiai kaip ir HTML, tik skirtumas labiau, HTML kaip atvaizduoti domentus, o XML kaip perduoti duomenys. XML struktūra yra stabili nekinta jeigu aplikacijos technologija pasikeičia.

XML turi prologą kuriame yra aprašoma versija ir simbolių kodavimas, tačiau jis nėra būtinas tik yra geroji praktika įtraukti į kiekvieną XML dokumentą.

DTD — dokumento tipo apibrėžimas, ji apibrėžia XML dokumento struktūrą ir elementus bei požymius. Failo note.dtm pavyzdys:

<!DOCTYPE note [ 
<!ELEMENT note (to,from,heading,body)>
<!ELEMENT to (#PCDATA)>
<!ELEMENT from (#PCDATA)>
<!ELEMENT heading (#PCDATA)>
<!ELEMENT body (#PCDATA)> ]>

#PCDATA tai yra analizuojamų simbolių duomenis.

Toliau matome pateikiama XML failo struktūrą kuris naudota note.dtd

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE note SYSTEM "note.dtd">
<note>
<to>falcon</to>
<from>feast</from>
<heading>hacking</heading>
<body>XXE attack</body>
</note>

Paiimkite pvz ir pakeiskime

<!DOCTYPE replace [<!ENTITY name "feast"> ]>
<userInfo>
<firstName>falcon</firstName>
<lastName>&name;</lastName>
</userInfo>

Dabar pabandykite nuskaityti iš failo:

<?xml version="1.0"?>
<!DOCTYPE root [<!ENTITY read SYSTEM 'file:///etc/passwd'>]>
<root>&read;</root>

Rezultatas:

Sugedusi Prieigos Teisių Kontrolė arba IDOR

„Broken Access Control“ yra pažeidžiamumo tipas, kuriame yra neskelbtinų duomenų, arba pažeidžiamumo tipas, leidžiantis patekti į vietą, kurios standartiniams vartotojams neleidžiama peržiūrėti. Prieigos valdymas, kartais vadinamas autorizacija, yra tai, kaip žiniatinklio programa suteikia prieigą prie turinio ir funkcijų vieniems, o ne kitiems vartotojams (pvz. Administratoriaus vartotojas gali pasiekti administratoriaus panelę, o įprastas vartotojas negali pasiekti administratoriaus skydelio). Šie patikrinimai atliekami po autentifikavimo ir nustato, ką „įgaliotiems“ vartotojams leidžiama daryti. Dėl sugadintos prieigos kontrolės užpuolikas gali prieiti prie duomenų ir atlikti kitų vartotojų, turinčių tokio paties lygio prieigą tame pačiame serveryje, veiksmus (sąvoka, paprastai vadinama horizontaliųjų privilegijų eskalacija), arba gali užpuolikui suteikti prieigą prie duomenų ir atlikti veiksmus, viršijančius jų serverius. lygmuo ir administratorius (sąvoka, paprastai žinoma kaip vertikaliųjų privilegijų eskalavimas). Jei tam tikra žiniatinklio programa yra pažeidžiama tokio pobūdžio pažeidžiamumo, tai gali ne tik sukelti slaptų duomenų atskleidimą, bet taip pat gali visiškai sukompromituoti tam tikrą serverį, nes daugumoje administratoriaus tinklalapių, tokių kaip administratoriaus skydai, yra būdas vykdyti kodą (sistemos komandos).

Paleiskime VM ir ir gaukite vėliavą per IDOR pažeidžiamumą. Prisijunkite su naudotojų noot ir test1234, savo aplinkoje nematysite nieko keisto, tačiau keičiant parametrą URL nuorodoje galima gauti kitą rezultatą. Mūsų naudotojas yra su id = 1, administratoriai dažnai būna id = 0, pamėginkime ir pažiūrėkime koks rezultatas bus.

Neteisinga Saugos Konfigūracija

Ji skiriasi nuo kitų OWASP Top 10 pažeidžiamumų, nes jie atsiranda tada, kai saugumas galėjo būti tinkamai sukonfigūruotas, bet nebuvo.

Apsaugos klaidos yra tokios:

Prastai sukonfigūruoti debesies paslaugų, tokių kaip S3 segmentai, leidimai

Įgalinę nereikalingas funkcijas, tokias kaip paslaugos, puslapiai, paskyros ar privilegijos

Numatytosios paskyros su ne pakeistais slaptažodžiais.

Palikta aplikacijos šablonas, su standartiniais prisijungimais arba žinomu pažeidžiamumu.

Klaidų pranešimai, kurie yra per daug išsamūs ir leidžia užpuolikui sužinoti daugiau apie sistemą

Nenaudojamos HTTP saugos antraštės arba neatskleidžiama per daug informacijos „Server: HTTP“ antraštėje [8].

Pensive Notes aplikacija yra atviro kodo projektas, ji galima rasti GitHub išeities kodą, tarp skaitant aprašymą README.md faile, matome paliktus prisijungimus.

Cross-site Scripting (XSS)

XSS — tai yra injekcijos rūšis ir paprastai vykdomas kliento pusėje, naršyklėse dažniausiai su tokiomis technologijomis kaip „Javascript“, rečiau su „VBScript“, „Flash“ ir CSS. Šios atakos vis rečiau pasitaikančios dėl to, kad pačios naršyklės geba aptikti ir riboti. Chrome ir kitos naršyklės susitvarko su dauguma XSS atakų.

Tačiau vis dar pasitaiko jei nėra validuojami ar nuvalomi naudotojo įvesti duomenys. Gali būti, kad web aplikacija naudotojo pusėje atlieka validacija, tačiau piktavalis gali apeiti kontrolės mechanizmą. Yra trys pagrindiniai XSS scenarijų tipai:

Išsaugotas XSS — pavojingiausias XSS tipas. Jeigu web aplikacija neatlieka nenuvalytą užklausą ir išsaugoti duomenų bazėje, kuri vėliau parodomą kitam naudotojui, ar administratoriui.

Atspindėtas XSS — Dažnai panaudojamas kartu su fišingo atakomis ar kitaip sukčiaujant, kai piktavalis priverčia savo auką paspausti nuorodą URL, kad įvykdytų jų kenkėjišką kodą aukos naršyklėje.

DOM XSS — Siekiama pakeisti HTML dokumento struktūrą, stilių ir turinį. Gali būti pavogta kliento sesija, apeiti kitas saugumo priemonės. Taip pat gali būti auka priversta paspausti nuorodą. Kenksmingas HTML kodas per parametrus įvykdomas kliento pusėje, DOM aplinkoje.

Kitos saugumo priemonės XSS saugumo antraštės, headers.

Nesaugus deserializavimas

Serializavimas — tai procesas, kurio metu sudėtingos duomenų struktūros, tokios kaip objektai ir jų laukai, paverčiamos „lygesniu“ formatu, kurį galima siųsti ir priimti kaip nuoseklų baitų srautą.
Deserializacija yra priešinga operacija, tai yrasrauto atkūrimas iki visiškai funkcionalaus originalaus.

Matėme, kad prieš naudodamiesi šiuo metodu buvo nulaužtos svetainės, kuriose veikia tam tikra sistema. Sistemų, turinčių šią ypatingą pažeidžiamumą, pavyzdžiai: Python, PHP, „Java“

Tačiau šiam iššūkiui mes gilinamės į deserializacijos slapukus. Slapukai, kuriuos mes jau minėjome anksčiau, suteikia vartotojui leidimą ribotam turiniui, kaip mes minėjome anksčiau. Tačiau atminkite, kad slapukais taip pat galima manipuliuoti, ir tai gali duoti užpuolikui įgyti administratoriaus teises, jei slapukai patikimi be patvirtinimo.

Paleiskite VM ir atsilaikysite gautu IP adresu.

[A9] Komponentų naudojimas su žinomai pažeidžiamumais

Procesas išvengti šios rizikos yra nuolaitinis sekimas ir kontroliavimas išorinių komponentų kurie yra naudojami kartu su web aplikacija [14]. Atrodo, kad viskas kaip ir aiškų turėtų būti, mes gal būt patikrinimo ir įvertinimo saugumą, tačiau, keičiantis ir bėgant laikui, mes netik turime stebėti savo aplikaciją, tačiau kaip ji saveikauja su kitais komponentais. Ypatingai reiktų atkreipti į dėmesį apie paskelbtus ir atrastus pažeidžiamumus tuose komponentuose kuriuos mes naudojame.

[A10] Nepakankamas žurnalizavimas ir stebėsena

Problema atsiranka tai piktavaliai supranta, kad aplikacijos stebėjimas yra silpnoji vieta, jie gali drąsiai ir aktyviau nagrinėti aplikaciją ir bandytą ją pažeisti. Pažeidimo atveju, bet to, kad bus padaryta žala, sunku bus atsekti kilmės šaltinį tam, kad būtų taikoma atsakomybė [15].

#1 test
#2 http://pentestmonkey.net/cheat-sheet/shells/reverse-shell-cheat-sheet
#3 https://gist.github.com/scottlinux/9a3b11257ac575e4f71de811322ce6b3
#4 https://medium.com/@musyokaian/os-command-injection-vulnerability-22cc70e0e6a6
#5 https://medium.com/@musyokaian/owasp-top-10-tryhackme-b7d02f29254b
#6 https://portswigger.net/web-security/xxe
#7 https://github.com/swisskyrepo/PayloadsAllTheThings/tree/master/XXE%20Injection
#8 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A6-Security_Misconfiguration
#9 https://sucuri.net/guides/owasp-top-10-security-vulnerabilities-2020
#10 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A1-Injection
#11 https://dzone.com/articles/sqli-part-3-in-band-and-inferential-sqli#:~:text=Error%2Dbased%20SQLi%20is%20an,to%20enumerate%20an%20entire%20database.
#12 https://www.php.net/manual/en/function.mysql-real-escape-string.php
#13
#14 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A9-Using_Components_with_Known_Vulnerabilities.html
#15 https://owasp.org/www-project-top-ten/OWASP_Top_Ten_2017/Top_10-2017_A10-Insufficient_Logging%252526Monitoring.html

--

--

Tomas Savenas
savenas.lt

Kibernetinio saugumo entuziastas; Aktyviausias Lietuvis TryHackMe platformoje; Inovacijų valdymo ir Antreprenerystės Magistrantas @ KTU