Šta su i kako se boriti protiv DDos napada?
Koje su etape od trenutka postavljanja Web stranice do konačnog pretvaranja računara u oružje za bombardovanje IT ciljeva širom sveta? Kako da vaš sajt ne postane meta ili izvor DDos napada? Sve počinje od validacije koda…
Priprema Web sajta za potrebe malog porodičnog biznisa ili Web prezentacije za ograničeni broj korisnika na Internetu ne zahteva mnogo tehničkog znanja. Kreirate index.html sa nekoliko .php upita za konekciju do baze podataka i sajt je gotov – možete ga, sa sve stranicom za ostavljanje kontakt e‑mail adrese, postaviti na kućnoj desktop mašini s Xampp ili Wamp aplikacijom. Ipak, ukoliko kod u .php upitu nije zaštićen validacijom upita, mogu se javiti brojni problemi koji imaju dalekosežne posledice. Jedan od njih jeste da takav kod od trenutka objave na javnim DNS serverima otvara vrata potencijalnim napadima preko Interneta i pretvara kućni računar u zombi kompjuter koji učestvuje u DDos napadima na sasvim drugom kraju sveta.
Distributed Denial of Service napad
DDos je skraćenica od Distributed Denial of Service (distribuirano odbijanje servisa) i to je napad koji pravi poplavu zahteva sa ciljem da se sistem obori jer ne može da odgovori na zahteve. Bilo koje slanje ping x.x.x.x komande ka drugom sistemu ispitivanje je da li je sistem online i spreman za komunikaciju. Ciljani sistem odgovara svakom pojedinačnom zahtevu „jesam online“ i time u slučaju bombardovanja zahtevima postaje opterećeniji, a u ekstremnim slučajevima sporiji za ostale servise koje obavlja, da bi na kraju bio oboren usled preopterećenosti. U praksi, najteže je razdvojiti validne od nevalidnih zahteva te tako ovi napadi postaju ustaljena praksa hakera da obore bilo koji javno publikovani sajt ili interni server.
Veliki DDos napadi svakodnevno između različitih IP adresa na mapi sveta koriste slične zombi računare bez adekvatne kodirane zaštite, firewall‑a ili IDS (Intrusion Detection System) / IPS (Intrusion Prevention System) uređaja, a taj dinamični saobraćaj može čak i online da se prati na adresi www.digitalattackmap.com. U izveštaju od 24. aprila 2017, Interpol je analizirao i identifikovao 270 sajtova u jugoistočnoj Aziji koji su, inficirani dodacima u kodu, korišćeni kao zombi računari, a među njima je čak i nekolicina državnih Web sajtova koji verovatno imaju lične podatke svojih građana.
Koje su etape od trenutka hostovanja Web stranice do konačnog pretvaranja računara u oružje za bombardovanje bilo kojih IT ciljeva na svetu, bilo ličnih ili dirigovanih i usmerenih ka većim kompanijama? Dakle, objavljeni sajt sa pogrešno kodiranom validacijom ulaza u PHP upitu otvara vrata nesrećama. Činjenica da takav sajt nema adekvatan firewall ili IDS/IPS uređaj u datoj fazi ne predstavlja ni olakšavajuću ni otežavajuću okolnost, jer je otvoren za komunikaciju s napadačem preko Web adrese u browser‑u.
Šta je validacija ulaza u kodu? Korisnik Web sajta ima svoje polje u koje može da unese nekakav tekst u vidu imena, prezimena ili e‑mail adrese. Upravo takva polja koja su otvorena za komunikaciju korisnika preko Interneta mogu biti prostor u kome uporni haker pokušava da vidi hoće li Web upit generisati nekakvu grešku ili neuobičajeno ponašanje. Tako se testira postoji li prostor za ubacivanje bilo kakvog dela koda pomoću SQL sintaksi. Zapravo, napadač komunicira preko browser‑a sa SQL serverom jer ne postoji validacija šta korisnik može uneti u konkretno tekstualno polje.
Pretraživačem do problema u kodu
Kako potencijalni napadači znaju da je baš taj računar podoban za instaliranje zombi programa? Jedan od načina jeste preko pretraživača i nečega što je osnova optimizacije pretraživača (Search Engine Optimisation), a to je alat za organsku pretragu imena spider ili crawler. To mu onda dođe da hakeri koriste pretraživače da bi došli do svojih ciljeva?
Dovoljno je u ovom slučaju staviti u pretraživač string ’php?id=’ i počinje dugo pretvaranje kućnog računara u zombi slugu DDos napada. Novokreirani sajt, nakon publikovanja preko javnog DNS servera, za 72 sata obiđe svet i vidljiv je kroz DNS servere i kod svih pretraživača koji su preko svojih crawler‑a otkrili sve što je napisano u kodu za dati Web sajt. Dovoljna je samo pretraga navedenog upita i pretraživač će izbaciti sajtove koji nemaju rešenu validaciju ulaza, čime se oni kandiduju za grupu potencijalno ranjivih. Od tog trenutka moguće su dve vrste napada: jedan je upitati SQL bazu podataka ko su ljubitelji sajta i koji su njihovi specifični podaci (korisnička imena, lozinke, e‑mail adrese) ili ubaciti direktan deo koda u operativni sistem i time pretvoriti kućni kompjuter u ratnika na frontu različitih sajbergrupa.
Guardian je pisao da je izvesni šesnaestogodišnjak Adam Mudd 2013. kreirao program koji je u isto vreme napao 1,7 miliona računara koristeći DDos napad. Adam je još živeo kod svojih roditelja i tom prilikom zaradio je oko 400.000 funti. Izjasnio se kao kriv za počinjeni kriminalni akt za čiju aplikaciju je registrovano 112.000 korisnika koji su hakovali više od 660.000 IP adresa, od kojih je desetina bila u Velikoj Britaniji, odakle je Adam. U izveštaju BBC‑ja, među napadnutim sajtovima su i RuneScape, Minecraft i Xbox live.
Nove generacije napada
Teško je uraditi zvaničnu analizu koliko je sajtova na domenu .rs koji nisu adekvatno zaštićeni kroz sanitaciju koda, s obzirom na fluktuacije i update‑ovanje Web sajtova, servera i baza podataka. U realnosti, zombi kompjuteri mogu obavljati svoje aktivnosti u zavisnosti od zombi programa i vremena koje prođe dok korisnik potpuno ne reinstalira svoj računar jer postaje mnogo sporiji ili dok ne otkrije da postoji program koji pokreće neuobičajene procese za rad operativnog sistema.
Validacija ulaza u Web programiranju nije najveći izvor za zombije i DDos napade. Validacija ulaza pogađa bilo koju C ili C++ aplikaciju na isti način ubacivanjem dela koda kroz nezaštićeni deo na kojem korisnik ima slobodu da unese nešto u prazan tekstualni aplikativni input (Unesite broj fakture, Unesite korisničko ime). Ukoliko polje nije zaštićeno merama sanitacije koda, kroz takav ulaz moguće je uspostaviti kontrolu nad operativnim sistemom računara i kontrolisati određene procese u tom istom računaru.
Nova generacija DDos napada zove se PDDos (Permanent Denial of Service) i pogodio je nedavno IoT (Internet of Things) uređaje. IoT uređaj je onaj koji je povezan na Internet i deo je velikog sistema. Najjednostavniji može biti temperaturni senzor koji šalje podatke nekom serveru u pravilnim ili nepravilnim vremenskim razmacima. Kako prenosi portal arstechnica.com, jedan takav napad bio je u aprilu 2017. inicirajući čak 1500 uređaja za 15 sati. Prema izveštaju istraživačke grupe Hajime, sličan napad pre dve nedelje inficirao je 10.000 uređaja sa istim aplikativnim propustom. U januaru ove godine čak dva miliona uređaja istog aplikativnog problema bilo je „oteto“.
Validacija ulaza i mere zaštite koda
Prva mera zaštite jeste testiranje svoje aplikacije u internoj mreži, bez izlaganja novokreiranog Web sajta Internet konekciji. Za proveru postojanja propusta u pisanju koda dostupni su različiti alati na Internetu. Za Windows računare, Olly Dbg je jedna od alatki koja ispituje validaciju koda u C i C++, a dostupna je i za Linux distribuciju. Microsoft Visual Studio alati takođe otkrivaju rupe na kodovima koji se tiču input validacija. Sanitacija PHP koda moguća je i kroz primere koji se mogu pronaći pretraživačem. Nakon uspešnih zakrpa svih validacija ulaza, potrebno je takođe proveriti da li su verzije SQL servera i Web servera zakrpljene poslednjim verzijama. Primer validacije ulaza u JavaScript‑u dat je na listingu 1.
Prva preporučena mera za sprečavanje napada jeste definisanje zabranjenih tekstualnih formata, kao što je string 1=1 ili <script> tag‑ova. Definisanje dozvoljenih tekstualnih formata ili white list validation predstavlja osnovu, ali nije dovoljno za tekstualne formate iako se i oni mogu kontrolisati u određenoj meri. Treći način jeste definisanje regularnih izraza (regular expressions), a više informacija o ovoj tehnici može se pronaći na adresi: www.regular‑expressions.info.
Validacija ulaza mora biti primenjena na svim ulaznim poljima; treba definisati tip karaktera, kao i minimalnu i maksimalnu dužinu stringa (na primer, 1‑15 karaktera). Validacija petocifrenog poštanskog broja bila bi u obliku, ^\d{5}(‑\d{4})?$. Ukoliko se input validation piše za JavaScript, napadač uvek može da ga zaobiđe tako što će deaktivirati JavaScript ili koristiti Web proxy. U tom slučaju treba s obe strane implementirati input validation.
Zaštićena infrastruktura
Validacija koda predstavlja jednu od mera odbrane protiv DDos napada. U praksi, prva odbrana su firewall i IPS/IDS uređaji koji mogu da identifikuju DDos napad i zabrane dolazni saobraćaj sa IP adresa za koje postoji osnovana sumnja da realizuju DDos napad. Takvi uređaji su nažalost skupi, pa fizička lica teško mogu da ih priušte. Kućni računar i Web prezentacija na njemu nemaju opciju da se zaštite fizičkim uređajima od DDos napada, a ako ne postoji dovoljan nivo tehničkog znanja za validaciju koda, rešenje predstavljaju gotove platforme, kao što je WordPress hostovan kod provajdera u gotovom obliku (wordpress.com). WordPress ima visok nivo zaštite od DDos napada kako u samom kodu, tako i u odbrani svoje farme portala od specijalizovanih uređaja, ukoliko se Web aplikacija hostuje na wordpress.com.
U kompanijskim uslovima situacija je komplikovanija zbog širokog spektra softvera za različite organizacione jedinice (HR, finansije, IT)… Da li je za renome jedne firme bitno koliko je njena softverska aplikacija u sklopu SaaS (Software as a Service) cloud‑a ranjiva na DDos? Da li klijent koji koristi datu softversku aplikaciju ima štete od toga što je zombi softver instaliran negde u tuđoj infrastrukturi? Odgovor je pozitivan čak i ako je softverska aplikacija instalirana daleko od matične infrastrukture. Efekti DDos‑a u ovom slučaju tiču se slabijih performansi same aplikacije, a to smanjuje efikasnost zaposlenih. Taj deo priče ne dotiče klijentsku stranu obaveza u SLA (Service Level Agreement), ali postoji obaveza klijenta da obavesti i ukaže na problem sa performansama u samoj aplikaciji, dok bi hosting kompanija, inače vlasnik softverskog paketa i infrastrukture, sama morala da reši taj problem. Bitno je i da za klijentsku kompaniju postoji proces validacije UAT (User Acceptance Test) kao faza pretpotpisivanja ugovora u kojoj je na klijentu da dati softver istraži, analizira i proceni da li je i dalje adekvatan za potpisivanje ugovora, koji su često u praksi dugoročni.
Ukoliko softverski paket bude instaliran na matičnoj infrastrukturi, u virtuelnom ili fizičkom obliku, UAT faza mora proći rigorozne testove verifikacije da ne postoje funkcionalni i bezbednosni problemi u samoj aplikaciji. Testovi kojima se verifikuje da ne postoji bezbednosni problem često se u praksi preskaču i ne uzimaju za ozbiljno jer se veruje da je kod testiran više puta, ne samo kod proizvođača softvera već i kod njegovih klijenata koji softver već koriste. Ponekad je zgodno napraviti istraživanje o samom softverskom proizvodu i da li na Internetu postoje zabeleženi problemi bilo koje vrste.
Često zanemareni problem
Validacija ulaza nije najveći problem u softverskim aplikacijama, ali predstavlja jedan od zanemarenih problema koji su i dalje prisutni u softverskom inženjeringu. Istraživanje može ukazati da se default korisnički nalozi same aplikacije moraju promeniti, što je takođe jedan od savremenih problema iz oblasti aplikacione bezbednosti.
Karika koja se može pokazati u budućnosti kao najslabija u ovom procesu jeste čovek i njegova sposobnost da uoči ili nađe bezbednosni problem. Zagovornici RBA (Robotic process Automation) tehnologija veruju da postoji veliki prostor za poboljšanje bezbednosti softverskih proizvoda zato što troškovi UAT često probiju postavljene budžete. Teoretski, ljudi bi pravili softverske pakete, ali roboti bi ih analizirali i odobravali za upotrebu. To je argument zagovornika RBA za brži razvoj robotičkih softvera, koji nas očekuju u budućnosti, a mi treba da je dočekamo pripremljeni.
Rade Nikolić
