Kako hakeri preuzimaju web stranice SQL injectionom i DDoS-om

Čak i ako ste samo labavo slijedili događaje hakerskih skupina Anonymous i LulzSec, vjerojatno ste čuli o web stranicama i uslugama koje su hakirani, poput zloglasnih Sony hackova. Jeste li se ikad zapitali kako to rade?

Postoji čitav niz alata i tehnika koje te skupine koriste, a dok ne pokušavamo dati vam priručnik da to učinite samima, korisno je razumjeti što se događa. Dva napada koji dosljedno čujete o njima pomoću su "(Distributed) Denial of Service"( DDoS) i "SQL Injections"( SQLI).Evo kako oni rade.

Slika od xkcd

Denial of Service Attack

Što je to?

"denial of service"( ponekad nazvan "distribuirani denial of service" ili DDoS) napada događa se kada sustav, u ovom slučaju web poslužitelj, prima toliko zahtjeva istodobno da su resursi poslužitelja preopterećeni sustav jednostavno zaključavagore i zatvori. Cilj i rezultat uspješnog napada na DDoS su web stranice na ciljnom poslužitelju nedostupne za legitimne zahtjeve za prometom.

Kako funkcionira?

Logistika napada DDoS može se najbolje objasniti primjerom.

Zamislite milijun ljudi( napadači) da se zajedno s ciljem ometanja poslovanja tvrtke X uzevši u obzir svoj pozivni centar. Napadači koordiniraju tako da u utorak, u 9 sati svi će nazvati telefonski broj tvrtke X.Najvjerojatnije, telefonski sustav tvrtke X neće moći riješiti milijune poziva odjednom, tako da će sve dolazne linije biti vezane od strane napadača. Rezultat toga je da legitimni korisnički pozivi( tj. Oni koji nisu napadači) ne prolaze jer je telefonski sustav vezan za rukovanje pozivima napadača. Dakle, u biti tvrtka X potencijalno gubi posao zbog legitimnih zahtjeva koji se ne mogu probiti.

DDoS napad na web poslužitelj funkcionira na isti način. Budući da praktički nema načina da saznate koji promet potječe iz legitimnih zahtjeva protiv napadača sve dok web poslužitelj ne obrađuje zahtjev, takva vrsta napada obično je vrlo učinkovita.

Izvršavanje napada

Zbog prirode "brutalnog sila" DDoS napada, morate imati puno računala koja su koordinirana za napad u isto vrijeme. Preusmjeravajući naš primjer pozivnog centra, to bi zahtijevalo da svi napadači oboje znaju nazvati u 9 ujutro i zapravo zvati u to vrijeme. Iako će ovo načelo zasigurno funkcionirati kada je u pitanju napadanje web poslužitelja, ona postaje znatno jednostavnija kada se upotrebljavaju zombi računala, umjesto stvarnih računalnih računala.

Kao što vjerojatno znate, postoje mnoge varijante zlonamjernih programa i trojanaca koji, jednom u vašem sustavu, leže u mirovanju i povremeno "telefoniraju kući" za upute. Jedna od ovih uputa mogla bi, primjerice, biti poslati ponovljene zahtjeve na web poslužitelj tvrtke X u 9 sati ujutro. Dakle, s jednim ažuriranjem na početnu lokaciju odgovarajućeg zlonamjernog softvera, jedan napadač može trenutačno koordinirati stotine tisuća ugroženih računala za obavljanje ogromnog DDoS napada.

Ljepota korištenja zombi računala nije samo u svojoj učinkovitosti, već iu anonimnosti jer napadač zapravo ne mora uopće koristiti računalo za izvršenje napada.

SQL Injection Attack

Što je to?

Napad "SQL injection"( SQLI) napada je iskorištavanje koje iskorištava prednosti loših tehnika razvoja web stranica i, u pravilu, u kombinaciji s neispravnom sigurnost baze podataka. Rezultat uspješnog napada može varirati od oponašanja korisničkih računa do kompletnog kompromisa odgovarajuće baze podataka ili poslužitelja. Za razliku od DDoS napada, SQLI napad je potpuno i lako spriječiti ako je web aplikacija prikladno programirana.

Izvođenje napada

Kad god se prijavite na web stranicu i unesete svoje korisničko ime i lozinku, kako bi testirali vaše vjerodajnice, web aplikacija može pokrenuti upit kao što je sljedeći:

SELECT ID korisnika od korisnika WHERE UserName = 'myuser' i lozinka= 'mypass';

Napomena: vrijednosti niza u SQL upitu moraju biti zatvorene u pojedinačnim navodnicima, zbog čega se pojavljuju oko korisnika unesenih vrijednosti.

Dakle, kombinacija unesenog korisničkog imena( myuser) i zaporke( mikroprocesora) mora odgovarati unosu u tablici korisnika kako bi se ID korisnika vratio. Ako se ne podudara, ne vraća se UserID, tako da vjerodajnice za prijavu nisu važeće. Dok se određena implementacija može razlikovati, mehanika je prilično standardna.

Sada pogledaj upit za autentifikaciju predloška koji možemo zamijeniti vrijednosti koje korisnik ulazi na web obrazac:

SELECT ID korisnika od korisnika WHERE UserName = '[user]' I lozinka = '[pass]'

Na prvi pogled ovomože se činiti kao jednostavan i logičan korak za lako provjeravanje korisnika, no ako se na ovom predlošku izvrši jednostavna zamjena korisničkih unesenih vrijednosti, on je osjetljiv na SQLI napad.

Na primjer, pretpostavimo da je "myuser-" u polje korisničkog imena unesena i "wrongpass" unesena u lozinku. Koristeći jednostavnu zamjenu u našem upitu predloška, ​​dobit ćemo ovo:

SELECT ID korisnika od korisnika WHERE UserName = 'myuser' - 'I lozinka =' wrongpass '

Ključ ove izjave je uključivanje dviju crtica( -),Ovo je početni komentar token za SQL izjave, tako da će se sve što se pojavljuje nakon dvije crtice( uključivo) zanemariti. U osnovi, gore navedeni upit izvršava baza podataka kao:

ODABERITE ID korisnika od korisnika WHERE UserName = 'myuser'

Izvanredni propust ovdje je nedostatak provjere lozinke. Uključivanjem dvije crtice kao dijela korisničkog polja potpuno smo zaobišli stanje provjere zaporke i uspjeli smo se prijaviti kao "myuser" bez poznavanja odgovarajuće lozinke. Ovaj čin manipulacije upitom za izradu neželjenih rezultata je napad SQL injekcije.

Kakva šteta može biti?

SQL injection napad je uzrokovan nepažljivim i neodgovornim kodiranjem aplikacija i potpuno je moguće spriječiti( što ćemo pokriti u trenutku), no opseg štete koja se može učiniti ovisi o postavljanju baze podataka. Da bi web aplikacija mogla komunicirati s bazom podataka baze podataka, aplikacija mora dostaviti prijavu u bazu podataka( napominjemo, to se razlikuje od prijave korisnika na web stranicu).Ovisno o dozvolama koje web aplikacija zahtijeva, ovaj odgovarajući račun baze podataka može zahtijevati bilo što od dopuštenja za čitanje / pisanje u postojećim tablicama samo do potpunog pristupa bazi podataka. Ako ovo sada nije jasno, nekoliko primjera bi trebalo pomoći u pružanju neke jasnoće.

Na temelju gore navedenog primjera možete vidjeti da unosom, na primjer, "youruser" - "," admin "-" ili bilo kojim drugim korisničkim imenom, možemo se odmah prijaviti na stranicu kao taj korisnik bez poznavanja lozinke, Jednom kada smo u sustavu ne znamo da nismo zapravo taj korisnik pa imamo puni pristup odgovarajućem računu. Dozvole za baze podataka neće osigurati sigurnosnu mrežu, jer obično web stranica mora imati barem čitanje / pisanje pristupa svojoj bazi podataka.

Pretpostavimo da web stranica ima potpunu kontrolu nad svojim bazama podataka koja omogućuje brisanje zapisa, dodavanje / uklanjanje tablica, dodavanje novih sigurnosnih računa itd. Važno je napomenuti da neke web aplikacije trebaju takvu vrstu dozvola tako danije automatski loša stvar koja se daje potpuna kontrola.

Kako bismo ilustrirali štetu koja se može učiniti u ovoj situaciji, upotrijebit ćemo primjer naveden u gore navedenom komiku unosom sljedećeg u polje korisničkog imena: "Robert"; DROP TABLE Users; - ".Nakon jednostavne zamjene, upit za provjeru autentičnosti postaje:

SELECT ID korisnika od korisnika WHERE UserName = 'Robert';DROP TABLE Korisnici; - 'AND Password =' ​​wrongpass '

Napomena: točka-zarez u SQL upitu koristi se za označavanje kraja određene izjave i početak nove izjave.

Koji se izvršava u bazi podataka kao:

ODABERITE ID korisnika od korisnika WHERE UserName = 'Robert'

DROP TABLE Korisnici

Dakle, kao takav, koristili smo SQLI napad za brisanje cijele tablice korisnika.

Naravno, puno je gore moguće jer, ovisno o dozvoljenim SQL dozvolama, napadač može promijeniti vrijednosti, tablice s izvatkom( ili cijelu bazu podataka) u tekstnu datoteku, stvoriti nove račune za prijavu ili čak oteti cjelokupnu instalaciju baze podataka.

Sprječavanje napada SQL injection

Kao što smo spomenuli nekoliko puta prije, napad SQL injekcije lako se može spriječiti. Jedno od kardinalnih pravila razvoja web-mjesta nikada niste nikada slijepo povjerenje korisničkog unosa kao što smo to učinili kada smo izvršili jednostavnu zamjenu u gornjem upitu predloška.

SQLI napad lako je prigušen onim što se zove sanitizing( ili bježi) svoje ulaze. Postupak sanitizacije je zapravo prilično trivijalan, budući da sve ono što u osnovi ne uspijeva riješiti bilo koji pojedinačni pojedinačni navodni citat( ') tako da se ne mogu koristiti za preuranjeno prekidanje niza unutar SQL izraza.

Na primjer, ako ste željeli potražiti "O'neil" u bazi podataka, ne biste mogli koristiti jednostavnu zamjenu jer će pojedinačni citat nakon O uzrokovati prebrzo završetak niza. Umjesto toga, očistite ga pomoću znaka za bijegu odgovarajuće baze podataka. Pretpostavimo da je tip bijega za inline pojedinačni citat prefacing svaki citat s \ simbol. Dakle, "O'neal" će se sanificirati kao "O \ 'neil".

Ovaj jednostavan čin sanitarne zaštite uglavnom sprječava SQLI napad. Da bismo ilustrirali, pregledajmo prethodne primjere i vidimo koji su dobiveni upiti kada se korisnički unos dezinficira.

prolaznik :

ODABIR ID korisnika od korisnika WHERE UserName = 'myuser \' - 'I lozinka =' wrongpass '

Budući da je jedini citat nakon što je myuser pobjegao( što znači da se smatra dijelom ciljavrijednost), baza podataka će doslovno tražiti UserName od "myuser" - ".Osim toga, budući da su crtice uključene unutar vrijednosti niza, a ne sama SQL izjava, oni će se smatrati dijelom ciljne vrijednosti umjesto da se tumače kao SQL komentar.

Robert ';DROP TABLE Korisnici - / krivulje :

ODABERITE ID korisnika od korisnika WHERE UserName = 'Robert \';DROP TABLE Korisnici; - 'AND Password =' ​​wrongpass '

Jednostavno izbjegavajući pojedinačni citat nakon Roberta, i točke i crtice sadržane su unutar UserName traga za pretraživanje tako da baza podataka doslovno traži "Robert"; DROP TABLE Users;- "umjesto izvršavanja brisanja tablice.

Sažetak

Dok se napadi na webu razvijaju i postaju sofisticiraniji ili se usredotočuju na drugu točku ulaza, važno je zapamtiti zaštitu od pokušaja i istinitih napada koji su bili inspiracija nekolicine slobodno dostupnih "hakerskih alata" osmišljenih za njihovo iskorištavanje,

Neke vrste napada, kao što je DDoS, ne mogu se lako izbjeći, dok drugi, kao što je SQLI, mogu. Međutim, šteta koja se može učiniti ovim vrstama napada može se odvijati bilo gdje od neugodnosti do katastrofalne, ovisno o predviđenim mjerama.