Web application penetration testing

Temu rezervirala: Petra Kuhar

Sadržaj 1 Uvod 2 OWASP Top 10 2.1 Injection 2.2 Broken Authentcation and Session Management 2.3 Cross-Site Scripting (XSS) 2.4 Insecure Direct Object Reference 2.5 Security Misconfiguration 2.6 Sensitive data exposure 2.7 Missing Function Level Access Control 2.8 Cross-Site Request Forgery (CSRF) 2.9 Using components with known vulnerabilities 2.10 Unvalidated redirects and forwards 3 ASVS 3.1 Razine provjere sigurnosti 4 Primjer 4.1 Zaobilaženje autentifikacije korištenjem SQL injectiona [9] 4.2 Zaštita od SQL injectiona [8] 5 Literatura

Uvod

Penetration test, kraće samo pen test, je napad na računalni sistem koji traži njegove sigurnosne propuste i pomoću njih dobiva pristup podacima i značajkama tog računala. To jest, simulacija napada na sustav da se utvrde njegovi sigurnosni propusti. Web application penetration test fokusira se samo na evaluaciju sigurnosti neke web aplikacije. Proces uključuje aktivnu analizu aplikacije gdje traži bilo koje slabosti, tehničke pogreške ili ranjivosti.[1][2]

Ranjivost je mana ili slaba točka u dizajnu sustava, implementaciji ili radu i upravljanju koja se može iskoristiti da bi se prekršile sigurnosne politike sustava.[2]

Prijetnja je potencijalni napad koji, iskoristivši ranjivost, može naštetiti imovini u aplikaciji (vrijedne resurse kao npr. baze podataka). Test je akcija koja može otkriti ranjivost u aplikaciji. [2]

Meta penetration testa može biti white box sustav (daje osnovne i sistemske informacije o sustavu) ili black box (daje samo osnovne ili nikakve informacije, osim naziva tvrtke). Penetration test može pomoći u određivanju da li je sustav ranjiv na napad, da li su njegove sigurnosne obrane dovoljne i koje su sigurnosne obrane, ako ih ima, bile probijene.[1]

Ciljevi penetration testa ovise o vrsti odobrenih aktivnosti za bilo koji angažman, gdje je glavni cilj pronalaženje ranjivosti u sustavu koje bi mogla iskoristiti treća strana. Na kraju se klijent informira o svim ranjivostima te se preporučaju strategije ublažavanja. [1]

OWASP Top 10

Open Web Application Security Project (OWASP) je zajednica koja se bavi open-source sigurnosnim aplikacijama. Njihov cilj je širenje svijesti o sigurnosti aplikacija, a najpoznatiji su po objavljivanju industrijskog standarda OWASP Top 10.

Svakih nekoliko godina OWASP izdaje OWASP top 10, popis 10 najkritičnijih aplikacijskih sigurnosnih rizika s kojima se programeri i organizacije suočavaju. Cilj im je pomoći programerima i sigurnosnim timovima da bi bilje osigurali aplikacije koje dizajniraju i implementiraju. Budući da se rizici za aplikacije stalno mijenjaju i razvijaju, lista se svaki put revidira i izmjenjuje, zajedno s tehnikama i najboljim praksama za izbjegavanje i popravljanje tih ranjivosti. Osim OWASP Top 10 za web aplikacije, OWASP je također stvorio slične liste za Internet of Things, kao i za mobilnu sigurnost. [3]

OWASP top 10 za 2013. godinu:

1. Injection
2. Broken Autentication and Session Management
3. Cross Site Scripting (XSS)
4. Insecure Direct Object References
5. Security Misconfiguration
6. Sensitive data exposure
7. Missing function level access control
8. Cross Site Request Forgery (CSRF)
9. Using components with known vulnerabilities
10. Unvalidated Redirects and Forwards

Injection

Injection se nalazi na samom vrhu OWASP-ovog popisa, te je kriv za veliku većinu javnih objavljivanja i proboja sigurnosti. Postoji nekoliko vrsta ranjivosti ubacivanjem, a neke od njih su:

1. SQL Injection
2. Code Injection
3. OS Commanding
4. XML Injection
5. SSI Injection
6. Buffer Overflow

Sve vrste injectiona omogućuju nesigurne ili manipulirane zahtjeve, naredbe ili upite koji se mogu izvršiti u web aplikaciji. SQL injection je bio najučestalija verzija injectiona u 2013. Ako u sustavu neke tvrtke postoje opasnosti od injection ranjivosti to također znači da postoje neki ozbiljni rizici: gubitak podataka ili njihova korupcija, krađa podatka, neovlašteni pristup, zabrana pristupa, i potpuni gubitak kontrole nad sustavom. [5]

Broken Authentcation and Session Management

Neispravna autentifikacija i upravljanje sesijom je ranjivost koja omogućuje da se zaobiđu metode autentifikacije koje se koriste da bi zaštitile sustav od neovlaštenog upada. Najčešće je to korisničko ime i lozinka. U prosjeku je 23%, svih aplikacija koje su testirane, ranjivo na ovu vrstu napada.

Načini na koje web aplikacije ne zaštite korisničke podatke koji se šalju:

• ne kriptirane veze - Sve informacije koje se šalju ili primaju između web aplikacije i korisnika mogu biti presretane bez korisnikovog znanja.
• predvidljive akreditacije za logiranje - koriste se korisnička imena i lozinke koje se lako mogu pogoditi ili koje se često koriste. Na primjer lozinka 123456.
• vrijednost sesije ne istekne ili se ne poništi nakon odjave - imamo iste mogućnosti rada na web aplikaciji kao kada smo logirani, a zapravo smo se odjavili.
• korisnički podaci za logiranje nisu zaštićeni nakon spremanja.
• ID sesije se jasno vidi u URL stranice - npr. http://bank.com/login.jsp?sessionid=abcde gdje je abcde ID sesije. [5]

Cross-Site Scripting (XSS)

U ovoj vrsti napada napadač može ubaciti nepouzdane isječke Javascripta direktno u web aplikaciju bez validacije. Zatim se taj dio Javascripta izvrši od strane osobe koja posjećuje web aplikaciju. Postoje 3 vrste XSS napada:

• Reflected XSS - napadač žrtvi pošalje link na napadnutu web aplikaciju putem emaila, društvenih mreža itd. Link sadrži skriptu koja se aktivira kada žrtva posjeti tu web aplikaciju.
• Stored XSS - Napadač može ubaciti perzistentnu skriptu u ciljanu web stranicu koja će se pokrenuti kada je netko posjeti.
• DOM Based XSS - Ovdje nije potreban HTTP zahtjev, nego se skripta ubacuje kao rezultat modificiranja DOM-a (Document Object Model) ciljane web stranice na strani klijentskog koda u žrtvinom browseru i zatim se izvršava.

U prosjeku je 17% testiranih aplikacija ranjivo na XSS. Rizici XSS-a su:

• Moguće je ugroziti ili preuzeti žrtvin račun u toj web aplikaciji
• Čitanje podataka sa ciljane web aplikacije
• Modifikacija sadržaja na toj web aplikaciji ili stranici
• Mogućnost preusmjeravanja žrtve na drugu malicioznu ili lažnu stranicu
• Mogućnost da će se neki malware programi instalirati na žrtvin sistem [5]

Insecure Direct Object Reference

Ova vrsta napada se odnosi kada unutarnji objekt koji je dio implementacije u web aplikaciji, kao na primjer neki podatak ili ključ baze podataka, se prikaže korisnicima makar oni nemaju pristup bazi podataka. U takvim slučajevima napadač može manipulirati taj prikaz da dođe do podataka do kojih inače ne bi imao pristup.

Primjer Kada se korisnik logira na web stranice svoje banke, preusmjeri se na sljedeći URL: https://bank/balance?acc=123 U ovom slučaju, 123 je ID računa tog korisnika te korisnik vidi stanje tog računa. Korisnik može promijeniti zadnji dio URL-a koji se odnosi na ID računa i tako je moguće vidjeti tuđi račun koji ima taj ID. [5]

Security Misconfiguration

Loše ili nepropisne postavke servera ili web aplikacija mogu dovesti do različitih propusta koje napadači lako mogu iskoristiti:

• Omogućen debugging
• Krive postavke dopuštenja pristupa dokumentima
• Korištenje zadanih računa ili lozinki
• Omogućen je pristup stranicama za postavke web aplikacije [5]

Sensitive data exposure

Pod osjetljive podatke spadaju:

• Bankarske informacije (broj računa, broj kreditnih kartica)
• Zdravstvene informacije
• Osobne informacije (datum rođenja, OIB)
• Informacije o korisničkim računima

Kod ovih vrsta napada rizici su financijski gubitci i krađa identiteta za korisnika te smanjenje povjerenja u tvrtku od strane klijenta. Napadači mogu prisluškivati vezu kada se šalju podaci te tako doći do podataka ako oni nisu kriptirani. Također mogu pristupiti ne kriptiranim podacima na bazi podataka. [5]

Missing Function Level Access Control

Ako je provjera autentikacije u osjetljivim rukovateljima zahtjeva nepotpuna ili nepostojeća dolazi do ovog problema - nedostaje funkcija kontrole razine pristupa. Primjer ove ranjivost bilo bi kada neovlašteni korisnik može doći do URL-a koji sadrži osjetljive informacije ili otkriva funkcionalnosti koje su namijenjene samo autoriziranim korisnicima. Još jedan česti primjer ove ranjivosti je kada se samo sakrije neka funkcionalnost od korisnika, ali i dalje dozvoljavati zahtjev za tom funkcionalnosti ako korisnik otkrije kako doći do nje.

Rizici rangiraju od nekih naizgled beskorisnih informacija do potpunih preuzimanja sustava. [5]

Cross-Site Request Forgery (CSRF)

Ranjivost koja omogućuje napadaču da izvrši neke aktivnosti na korisnikovom računu bez njegovog znanja. Najčešće mete ovih napada su cloud pohrane, društvene mreže, bankovne i online shopping web aplikacije. Otprilike je 23% testiranih web aplikacija ranjivo na ovu vrstu napada.

Ovisno o izvršenoj aktivnosti, CSRF napadi mogu imati ozbiljne posljedice za korisnike tih web aplikacija poput objavljivanja privatnih informacija s društvenih mreža ili gubitak novaca s bankovnih računa. Glavni problem je da korisnici ne znaju da se maliciozne stvari odvijaju na njihovim računima.

Primjer

Kada je logiran na korisničkim stranicama njihove banke, korisnik posjeti stranicu koja sadrži CSRF napad. Nakon posjeta, šalje se skriveni, automatski zahtjev za prijenosom novca s jednog računa na drugi. Korisnik ne primi nikakvu obavijest o navedenom izvršenju. Ovakvi napadi se događaju jer aplikacija za bankarenje dopušta zahtjeve sa drugih servera i ne postoji jedinstven token koji je vezan za korisničku sesiju koji će provjeriti zahtjev za prijenosom novca. [5]

Using components with known vulnerabilities

Web servisi često uključuju dijelove koji imaju poznatu sigurnosnu ranjivost. Tu ranjivost mogu sadržavati operacijski sustavi, web server, neki plugin koji su instalirani ili neki library koji se koristi.

Ovo je jedan od najčešćih ranjivosti jer ih je teško otkriti baš zbog toga jer mnogo toga može imati neku ranjivost sadržanu u sebi. Developeri se većinom fokusiraju na osiguravanje vlastitog koga i često zaboravljaju na kod kojeg su preuzeli od drugih.

Jedan od mnogih primjera ove ranjivosti je korištenje WordPress aplikacije sa pluginom Jetpack koji je na verziji starijoj od 4.0.3. koji je u sebi sadržavao XSS napad. Ovo je dobar primjer kako se ranjivosti mogu naći u popularnim pluginova i tako oštetiti veliki broj korisnika. [5]

Unvalidated redirects and forwards

Ova vrsta ranjivosti javlja kada napadač može preusmjeriti korisnika na nepouzdanu web stranicu kada korisnik klikne na link na nekoj stranici kojoj vjeruje. Ova vrsta ranjivosti se također zove i Open Redirect.

Potencijalna opasnost od ove vrste ranjivosti nije toliko opasna. Najčešće se koristi za phishing napade ili neke druge koji također koriste Social Engineering, ali to smanjuje potencijalnu štetu napada. Također može biti dio lančanog napada gdje je ova vrsta samo jedna od ranjivosti koje se iskorištavaju. Ta vrsta napada je naprednije te se ne koristi često. [5]

ASVS

OWASP Application Security Verification Standard (ASVS) projekt pruža osnovu za testiranje web aplikacija i kontrole njihovih tehničkih sigurnosti, ali također pruža programerima i popis uvjeta za sigurniji razvoj aplikacija. Primarni cilj projekta je normalizacija raspona obuhvata i razine strogosti kod testiranja sigurnosti web aplikacija. Standard daje osnovu za testiranje tehničkih zaštita, ali i zaštita u okolini web aplikacija da bi se zaštitili protiv ranjivosti kao npr. Cross-side scripting (XSS) i SQL injection. Ovaj standard se može koristiti za uspostavljanje razine povjerenja u sigurnosti web aplikacija. [7]

Razine provjere sigurnosti

ASVS definira tri razine provjere sigurnosti, a svaka razina se produbljuje.

RAZINA 1: Oportunistička - namijenjena za sve softwere.

Aplikacija postiže razinu 1 ako se na odgovarajući način brani od ranjivosti u zaštiti koje je lako otkriti, a uključena je u OWASP top 10 i druge slične provjere. Obično je prikladna za aplikacije gdje je dovoljno nisko povjerenje u korištenju sigurnosnih kontrola, gdje treba pružiti brzu analizu poslovnih aplikacija. Može se osigurati automatskim alatima ili jednostavno ručno bez pristupa izvornom kodu. Razina 1 je minimum potreban za sve aplikacije. [7]

RAZINA 2: Standardna – Za programe koji sadrže osjetljive podatke koji se moraju zaštiti.

Aplikacija postiže razinu 2 ako se primjereno brani od većine rizika koji su povezani danas sa softwareom. Osigurava da su sigurnosne kontrole u redu, efektivne i koriste se unutar aplikacije. Prikladna je za aplikacije koje obrađuju značajne business-to-business transakcije, uključujući i one koje obrađuju zdravstvene informacije. Prijetnje aplikaciji razine 2 u pravilu će biti kvalificirani i motivirani napadači s naglaskom na specifične ciljeve koristeći alate i tehnike koje su vrlo učinkovite u otkrivanju i iskorištavanju slabosti aplikacija. [7]

RAZINA 3: Napredna – Za najkritičnije programe

Aplikacije koje obavljaju visokovrijedne transakcije, sadrže osjetljive medicinske podatke ili bilo koji program koji zahtijeva najvišu razinu povjerenja. Razina 3 je za aplikacije koje obavljaju kritične funkcije, gdje bi kvar mogao značajno utjecati na poslovanje organizacije. Aplikacija postiže razinu 3 ako se na odgovarajući način brani od naprednih sigurnosnih ranjivosti, a također pokazuje načela dobrog sigurnosnog dizajna. [7]

Primjer

Isprobala sam kako funkcionira SQL injection. Pošto sam tek početnik, odlučila sam se na Metasploitable 2 virtualnu mašinu. To je namjerno ranjiva verzija Ubuntu Linuxa koja je dizajnirana za testiranje sigurnosnih alata i demonstriranje čestih ranjivosti. Nakon što se konfigurira Metasploitable 2, možemo se logirati na taj server preko web browsera na 192.168.56.101. Ovdje nam se otvara par mogućnosti koje možemo koristiti poput TWiki, phpMyAdmin, Mutillidae, DVWA i WebDAV. U ovom projektu ću korisiti Mutillidae. [4]

Mutillidae je besplatna, open source web aplikacija koja dozvoljava penetration testing i hakiranje web aplikacije. Sadrži ranjivosti i napomene koje pomažu ih iskorištavati te tako pruža okolinu za web hakiranje koju je lako koristiti za svrhe učenja.

Zaobilaženje autentifikacije korištenjem SQL injectiona [9]

Nakon što otvorimo Mutilidae interface, u izborniku imamo funkcionalnost Login/Register. Ovdje imamo priliku isprobati jednostavan SQL injection. Naravno, ovo nije prava okolina za pen-testing jer nam se prikazuju greške i njihovi opisi. Nakon što u name upišemo ' kako bi zatvorili SQL upit, prikazuje nam se sljedeće:

U poruci o greški nam se prikazuje cijeli SQL upit, tako da lako možemo ga modificirati. U intput za ime accounta pišemo: ' or 1=1 --

Pomoću ' zatvaramo input za username, dodajemo or 1=1 koji će uvijek biti točan, te na kraju -- koji služi da komentiramo ostatak upita da se on ne izvrši. U ovom slučaju zakomentiramo dio " AND password="" . Sada smo se logirali u sustav kao administrator jer je on najvjerojatnije prvi račun na popisu u bazi podataka.

Sada želimo doći do specifičnog računa. Ako unesemo korisničko ime jeremy u name input, te opet ' u password input, pojavi nam se sljedeće:

To znači da moramo napisati pravi SQL upit koji će nas logirati kao jeremy. Ako u password input opet unesemo ' or 1=1 -- , sustav će nas logirati kao administratora (opet vraća prvi unos u bazi). Tako da moramo modificirati upit. Ako unesemo SQL upit ' or (1=1 and username = 'jeremy') -- , sustav nas logira kao korisnika jeremy.

Zaštita od SQL injectiona [8]

Osnovna zaštita uključuje:

1. Parametrizirane upite – korištenje pripremljenih upita sa vezivanjem varijabli. Ovaj način osigurava da napadač ne može promijeniti namjenu upita, čak i ako su SQL naredbe umetnute u upit.
2. Upotreba spremljenih upita – upiti se spremaju u bazi, te se pozivaju iz aplikacije što smanjuje mogućnost napada umetanjem SQL upita.
3. Validacija unesenih podataka – provjera unesenih podataka da li se poklapaju sa dopuštenim unosom prije nego što se pošalje u bazu.

Dodatne zaštite:

1. Izbjegavanje unosa podataka od strane korisnika – Ova tehnika bi se trebala koristiti kao zadnji izbor, ako ostale tehnike nisu dovoljna zaštita. Ako se primijene pravilne tehnike pomoću kojih korisnik neće morati unositi nikakve podatke, tada sustav neće moći zamijeniti programerov kod i onaj koji je unesen.
2. Pažljivo dati privilegije korisničkim računima.

Literatura

1. Penetration test, Wikipedia, dostupno 8.1.2017. na: https://en.wikipedia.org/wiki/Penetration_test
2. OWASP testing guide v3, 2008, dostupno 8.1.2017. na: https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
3. OWASP top 10, Checkmarx, dostupno 8.1.2017. na: https://www.checkmarx.com/glossary/owasp-top-10/
4. What is Mutillidae?, Irongeek, dostupno 8.1.2017. na: http://www.irongeek.com/i.php?page=mutillidae/mutillidae-deliberately-vulnerable-php-owasp-top-10
5. OWASP, Detectify blog, dostupno 8.1.2017. na: https://blog.detectify.com/category/vulnerability/owasp/
6. OWASP top 10, IBM, dostupno 8.1.2017. na: https://www.ibm.com/developerworks/library/se-owasptop10/
7. Application Security Verification Standard 3.0., dostupno 12.1.2017. na: https://www.owasp.org/images/6/67/OWASPApplicationSecurityVerificationStandard3.0.pdf
8. SQL injection pervention, dostupno 14.1.2015. na: https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet
9. How to bypass Authentication using SQL Injection, dostupno 8.1.2017. na: https://www.youtube.com/watch?v=0_AN5FKsxaw&index=4&list=PLZOToVAK85MqYHbkAVK-ViD-Xb7pF6RKq