Kako hakeri preuzimaju web-mjesta s SQL injekcijom i DDoS-om

Čak i ako ste samo labavo pratili događaje hakerskih grupa Anonymous i LulzSec, vjerojatno ste čuli da su web stranice i usluge hakirane, kao što su zloglasni Sony hakeri. Jeste li se ikada zapitali kako to rade?

Postoje brojni alati i tehnike koje ove grupe koriste, i dok vam ne pokušavamo dati priručnik da to učinite sami, korisno je razumjeti što se događa. Dva od napada koje dosljedno čujete o njima jesu “(Distributed) Denial of Service” (DDoS) i “SQL Injections” (SQLI). Evo kako oni rade.

Slika po xkcd

Napad na uskraćivanje usluge

Što je?

"Uskraćivanje usluge" (ponekad nazvano "distribuirano uskraćivanje usluga" ili DDoS) napad nastaje kada sustav, u ovom slučaju web-poslužitelj, prima toliko zahtjeva u jednom trenutku da su resursi poslužitelja preopterećeni sustav jednostavno zaključava i zatvara se. Cilj i rezultat uspješnog DDoS napada jesu web lokacije na ciljnom poslužitelju koje nisu dostupne za legitimne zahtjeve za promet.

Kako radi?

Logistika DDoS napada najbolje se može objasniti primjerom.

Zamislite da se milijun ljudi (napadači) spoji s ciljem ometanja poslovanja tvrtke X tako što će skinuti svoj pozivni centar. Napadači koordiniraju tako da će u utorak u 9 sati svi nazvati telefonski broj tvrtke X. Najvjerojatnije telefonski sustav tvrtke X neće moći obraditi milijun poziva odjednom, tako da će sve dolazne linije biti povezane s napadačima. Rezultat toga je da legitimni pozivi kupaca (tj. Oni koji nisu napadači) ne prolaze jer telefonski sustav povezuje pozive napadača. Dakle, u suštini tvrtka X potencijalno gubi posao zbog legitimnih zahtjeva koji nisu u mogućnosti proći.

DDoS napad na web poslužitelju radi točno na isti način. Budući da praktički ne postoji način da se sazna koji promet dolazi iz legitimnih zahtjeva nasuprot napadača dok web-poslužitelj ne obradi zahtjev, ova vrsta napada obično je vrlo učinkovita.

Izvršavanje napada

Zbog "brutalne sile" prirode DDoS napada, morate imati puno računala koja su koordinirana za napad istovremeno. Ponovni pregled našeg primjera za pozivni centar, to bi zahtijevalo od svih napadača da obojicu pozovu u 9 sati ujutro i da u tom trenutku nazovu. Iako će ovo načelo sigurno djelovati kada je u pitanju napad na web-poslužitelj, postaje znatno lakše kada se koriste zombi računala, umjesto stvarnih računala s ljudskim poslom..

Kao što vjerojatno znate, postoji mnogo varijanti zlonamjernih programa i trojanaca koji, jednom na vašem sustavu, leže uspavani i povremeno "telefoniraju kući" za upute. Jedna od tih uputa mogla bi biti, primjerice, slanje ponovljenih zahtjeva web-poslužitelju tvrtke X u 9 sati ujutro. Dakle, jednim ažuriranjem na matičnoj lokaciji dotičnog zlonamjernog softvera jedan napadač može odmah koordinirati stotine tisuća kompromitiranih računala da bi izveli masivan DDoS napad.

Ljepota upotrebe zombi računala nije samo u njegovoj učinkovitosti, već iu njegovoj anonimnosti jer napadač zapravo ne mora uopće koristiti svoje računalo da bi izvršio napad.

SQL napad ubrizgavanjem

Što je?

"SQL injection" (SQLI) napad je iskorištavanje koje iskorištava slabe tehnike web razvoja i, obično u kombinaciji s, neispravnom sigurnošću baze podataka. Rezultat uspješnog napada može varirati od oponašanja korisničkog računa do potpunog kompromisa odgovarajuće baze podataka ili poslužitelja. Za razliku od DDoS napada, SQLI napad je potpuno i lako moguće spriječiti ako je web aplikacija prikladno programirana.

Izvršavanje napada

Kad god se prijavite na web-lokaciju i unesete svoje korisničko ime i zaporku, da biste testirali svoje vjerodajnice, web-aplikacija može pokrenuti upit poput sljedeće:

SELECT UserID FROM Users GDJE je UserName = "myuser" AND Password = "mypass";

Napomena: vrijednosti niza u SQL upitu moraju biti zatvorene u jednostruke navodnike zbog čega se pojavljuju oko vrijednosti unesenih od strane korisnika.

Dakle, kombinacija unesenog korisničkog imena (myuser) i lozinke (mypass) mora odgovarati unosu u tablici Users kako bi se vratio korisnički ID. Ako nema podudaranja, ne vraća se korisnički ID pa su vjerodajnice za prijavu nevažeće. Iako se određena implementacija može razlikovati, mehanika je prilično standardna.

Pogledajmo sada upit za provjeru autentičnosti predloška koji možemo zamijeniti vrijednostima koje korisnik unese u web obrazac:

SELECT UserID FROM korisnici WHERE Korisničko ime = "[korisnik]" I Lozinka = "[proslijedi]"

Na prvi pogled ovo može izgledati kao jednostavan i logičan korak za lako provjeravanje korisnika, ali ako se na ovom predlošku izvodi jednostavna zamjena korisničkih vrijednosti, on je podložan SQLI napadu.

Na primjer, pretpostavimo da je "myuser'-" uneseno u polje za korisničko ime i da je "passwordpass" unesena u lozinku. Koristeći jednostavnu zamjenu u našem upitu predložaka, dobili bismo sljedeće:

SELECT UserID FROM Users WHERE Korisničko ime = "myuser" - 'AND Password = "pogreška"

Ključ ove izjave je uključivanje dviju crtica (-). Ovo je početni znak komentara za SQL izraze, tako da će se sve što se pojavi nakon dvije crtice (uključivo) zanemariti. U osnovi, gornji upit se izvršava u bazi podataka kao:

SELECT UserID FROM korisnici WHERE Korisničko ime = "myuser"

Izvanredan propust ovdje je nedostatak provjere zaporke. Uključivanjem dviju crtica kao dijela korisničkog polja, potpuno smo zaobišli uvjet provjere lozinke i mogli smo se prijaviti kao "myuser" bez poznavanja odgovarajuće lozinke. Ovaj čin manipuliranja upitom za stvaranje neželjenih rezultata je SQL injection napad.

Što se može oštetiti?

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

Na temelju gore navedenog primjera, to možete vidjeti unosom, na primjer, "youruser '-", "admin" - " ili bilo koje drugo korisničko ime, možemo se odmah prijaviti na web-lokaciju kao korisnik bez poznavanja zaporke. Jednom kada smo u sustavu ne znamo da zapravo nismo taj korisnik pa imamo puni pristup tom računu. Dopuštenja za baze podataka neće pružiti sigurnosnu mrežu za to, jer web-lokacija obično mora imati barem pristup za čitanje / pisanje u odgovarajuću bazu podataka.

Pretpostavimo da web stranica ima potpunu kontrolu nad svojom bazom podataka koja daje mogućnost brisanja zapisa, dodavanja / uklanjanja tablica, dodavanja novih sigurnosnih računa, itd. Važno je napomenuti da bi neke web aplikacije mogle trebati ovu vrstu dozvole, tako da nije automatski loša stvar koja daje potpunu kontrolu.

Kako bismo ilustrirali štetu koja se može učiniti u ovoj situaciji, koristit ćemo primjer iz gornjeg stripa unoseći sljedeće u polje korisničkog imena: "Robert"; Korisnici DROP TABLE; - ". Nakon jednostavne zamjene upit za autentifikaciju postaje:

SELECT UserID FROM Users GDJE je UserName = "Robert"; Korisnici korisnika DROP TABLE; - 'AND Password = "pogrešan pristup"

Napomena: točka sa zarezom u SQL upitu koristi se za označavanje kraja određene izjave i početak novog izraza.

Koja se baza podataka izvršava kao:

SELECT UserID FROM korisnici WHERE Korisničko ime = "Robert"

Korisnici DROP TABLE

Upravo tako, koristili smo SQLI napad za brisanje cijele tablice Users.

Naravno, mnogo gore može biti učinjeno jer, ovisno o dozvoljenim SQL dozvolama, napadač može mijenjati vrijednosti, tablice (ili cijelu bazu podataka) u tekstualnu datoteku, stvarati nove račune za prijavu ili čak otimati cijelu instalaciju baze podataka.

Sprečavanje SQL injekcijskog napada

Kao što smo već nekoliko puta spomenuli, SQL injekcijski napad se lako može spriječiti. Jedno od glavnih pravila web razvoja je da nikada ne povjerite slijepo korisničkom unosu kao što smo to učinili kada smo izvršili jednostavnu zamjenu u gore navedenom upitniku.

SQLI-jev napad lako se sprječava takozvanim sanitizingom (ili izbjegavanjem) vaših ulaza. Proces sanitizacije je zapravo prilično trivijalan, jer sve što u biti radi je rukovanje bilo kojim inline pojedinačnim znakovima (') na odgovarajući način, tako da se ne mogu koristiti za prijevremeno okončanje niza unutar SQL izraza.

Na primjer, ako ste željeli tražiti “O'neil” u bazi podataka, ne biste mogli koristiti jednostavnu zamjenu jer bi jedan citat nakon O uzrokovao prestanak prestanka niza. Umjesto toga, dezinficirajte ga pomoću znaka za bijeg odgovarajuće baze podataka. Pretpostavimo da je znak za bijeg za jedan inline pojedinačni citat predgovor svakog citata simbolom. Dakle, "O'neal" će biti sanitized kao "O \ t.

Ovaj jednostavan čin sanacije uglavnom sprečava SQLI napad. Da ilustriramo, vratimo se na prethodne primjere i vidimo rezultirajuće upite kada je unos korisnika dezinficiran.

myuser”-- / wrongpass:

SELECT UserID FROM Users GDJE je UserName = "myuser" - 'AND Password = "pogrešan pristup"

Budući da je jedan citat nakon što je myuser izbjegnut (što znači da se smatra dijelom ciljne vrijednosti), baza podataka će doslovno tražiti korisničko ime "Myuser '-". Osim toga, budući da su crtice uključene unutar vrijednosti niza, a ne samog SQL izraza, one će se smatrati dijelom ciljne vrijednosti, umjesto da se tumače kao SQL komentar.

Robert'; Korisnici DROP TABLE;-- / wrongpass:

SELECT UserID FROM Users GDJE je UserName = "Robert"; Korisnici korisnika DROP TABLE; - 'AND Password = "pogrešan pristup"

Jednostavnim bježanjem od jednog citata nakon Roberta, i zarez i crtice sadržani su u nizu za pretraživanje UserName tako da baza podataka doslovno traži "Robert"; Korisnici DROP TABLE; - " umjesto izvršavanja tablice brisanje.

U sažetku

Dok se web-napadi razvijaju i postaju sofisticiraniji ili se fokusiraju na različitu točku ulaska, važno je zapamtiti da štitite od pokušaja i istinitih napada koji su bili inspiracija nekoliko slobodno dostupnih "hakerskih alata" dizajniranih da ih iskorištavaju.

Određeni tipovi 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 napadima može se nigdje kretati od neugodnosti do katastrofalnih ovisnosti o poduzetim mjerama opreza.