Kuidas häkkerid võtavad üle SQL-i ja DDoS-i veebisaite

Isegi kui olete alles lõdvalt järginud häkkerite gruppide anonüümseid ja LulzSeci sündmusi, olete ilmselt kuulnud veebilehtede ja teenuste häkkimise kohta, nagu kurikuulus Sony hacks. Kas olete kunagi mõelnud, kuidas nad seda teevad?

Neil rühmadel on mitmeid tööriistu ja tehnikaid ning kuigi me ei püüa teile seda teha, siis on kasulik mõista, mis toimub. Kaks neist rünnakutest, mida te nende kohta järjekindlalt kuulete, on „(Distributed) Denial of Service” (DDoS) ja „SQL Injection” (SQLI). Siin on, kuidas nad töötavad.

Pilt kasutajalt xkcd

Teenuse rünnaku eitamine

Mis see on?

„Teenuse keelamine” (mõnikord nimetatakse „hajutatud teenusetõendamise” või „DDoS”) rünnakuks, kui süsteem, antud juhul veebiserver, saab nii palju päringuid korraga, et serveri ressursid on ülekoormatud, siis süsteem lihtsalt lukustub ja lülitub välja. Eduka DDoS-i rünnaku eesmärk ja tulemus on sihitud serveri veebisaidid, mis pole õigustatud liiklusnõuetele kättesaadavad.

Kuidas see töötab?

DDoS-i rünnaku logistikat saab kõige paremini selgitada näitega.

Kujutage ette, et miljon inimest (ründajad) saavad kokku eesmärgiga takistada ettevõtte X äritegevust, võttes oma kõnekeskuse maha. Ründajad kooskõlastavad nii, et teisipäeval kell 9 helistavad nad kõik ettevõtte X telefoninumbrile. Tõenäoliselt ei suuda ettevõtte X telefonisüsteem korraga käsitleda miljoneid kõnesid, nii et kõik sissetulevad liinid on ründajate poolt seotud. Tulemuseks on see, et seaduslikud kliendikõned (st need, kes ei ole ründajad) ei läbi, sest telefonisüsteem on seotud ründajate kõnedega. Seega võib ettevõtte X olemuslikult kaotada äri, kuna õigustatud taotlused ei suuda läbida.

DDoS-i rünnak veebiserverile toimib täpselt samamoodi. Kuna praktiliselt ei ole mingit võimalust teada saada, milline liiklus pärineb õigustatud päringutest ja ründajatest, kuni veebiserver taotluse töötlemisel on seda tüüpi rünnak tavaliselt väga tõhus.

Rünnaku teostamine

DDoS-i rünnaku „jõulise jõu” olemuse tõttu peate kõikidel arvutitel ründamiseks koordineeritult olema. Vaadates meie kõnekeskuse näidet, nõuaks see, et kõik ründajad teaksid nii, et nad helistaksid kell 9.00 ja tegelikult sel ajal helistaksid. Kuigi see põhimõte toimib kindlasti veebiserveri ründamisel, muutub see oluliselt lihtsamaks, kui kasutatakse tegelike mehitatud arvutite asemel zombie arvutit..

Nagu te ilmselt teate, on palju pahavara ja troojalaste variante, mis kord oma süsteemis seisavad seisva ja juhuslikult "telefoni koju". Üks nendest juhistest võiks olla näiteks korduvate päringute saatmine ettevõtte X veebiserverisse kell 9.00. Nii et ühe vastase pahavara kodu asukohale ühe värskendusega saab üks ründaja koheselt koordineerida sadu tuhandeid ohustatud arvuteid, et teha massiivne DDoS-rünnak.

Zombie arvutite kasutamise ilu ei ole mitte ainult selle tõhusus, vaid ka anonüümsus, kuna ründaja ei pea tegelikult rünnaku teostamiseks oma arvutit üldse kasutama..

SQL sissepritse rünnak

Mis see on?

„SQL-i süstimine” (SQLI) on rünnak, mis kasutab ära halva veebiarendustehnoloogia ja tavaliselt koos vigase andmebaasi turvalisusega. Eduka rünnaku tulemus võib ulatuda kasutajakonto kujundamisest kuni vastava andmebaasi või serveri täieliku kompromissini. Erinevalt DDoS-rünnakust on SQLI rünnak täielikult ja kergesti välditav, kui veebirakendus on asjakohaselt programmeeritud.

Rünnaku teostamine

Kui logite veebisaidile ja sisestate oma kasutajanime ja parooli, võib veebirakendus teie volituste testimiseks käivitada päringu nagu järgmine:

SELECT UserID kasutajatelt WHERE UserName = "myuser" JA Password = "mypass";

Märkus: SQL-päringu stringide väärtused peavad olema ühekordsetes hinnapakkumistes, mistõttu nad ilmuvad kasutaja sisestatud väärtuste ümber.

Seega peab sisestatud kasutajatunnuse (myuser) ja parooli (mypass) kombinatsioon vastama kasutajate tabeli tagantjärele tagastamisele. Kui vasteid ei ole, ei tagastata ühtegi UserID-i, nii et sisselogimise andmed on kehtetud. Kuigi konkreetne rakendamine võib erineda, on mehaanika üsna tavaline.

Nüüd vaatame nüüd malli autentimise päringu, mille abil saame asendada väärtused, mida kasutaja veebivormile sisestab:

SELECT UserID kasutajatelt WHERE UserName = "[user]" ja Password = "[pass]"

Esmapilgul võib see tunduda lihtne ja loogiline samm kasutajate valideerimiseks, kuid kui kasutaja poolt sisestatud väärtuste lihtne asendamine toimub selle malliga, on see SQLI rünnakule vastuvõtlik.

Oletame näiteks, et kasutaja nime väljale sisestatakse „myuser'-” ja paroolisse sisestatakse „valejuht”. Kasutades lihtsat asendust meie malli päringus, saame selle:

SELECT UserID kasutajatelt WHERE UserName = "myuser" - 'JA Password = "väärkäsk"

Selle väite võtmeks on kahe kriipsude kaasamine (-). See on SQL-avalduste märkuste algusmärk, nii et midagi, mis ilmub pärast kahte kriipsut (kaasa arvatud), ignoreeritakse. Sisuliselt teostab ülaltoodud päring andmebaasi järgmiselt:

SELECT UserID kasutajatelt WHERE UserName = "myuser"

Silmatorkav tegevusetus on parooli kontrollimise puudumine. Kahe kriipsu lisamisega kasutajaväljavaadetesse möödusime paroolikontrolli tingimustest täielikult ja saime sisselogimise „myuseriks” ilma vastava parooli teadmata. See toiming manipuleerides päringut tahtmatute tulemuste saamiseks on SQL-i süstimisrünnak.

Mis kahju saab teha?

SQL süstimise rünnaku põhjuseks on hooletu ja vastutustundetu rakenduste kodeerimine ja see on täielikult välditav (mida me katame hetkega), kuid kahjustuste ulatus sõltub andmebaasi seadistusest. Selleks, et veebirakendus suhtuks taustaprogrammi andmebaasiga, peab rakendus andma andmebaasi sisselogimise (märkus, see erineb kasutaja veebisaidile sisselogimisest). Sõltuvalt sellest, millised õigused veebirakendus nõuab, võib see vastavat andmebaasi kontot nõuda midagi lugemis- ja kirjutamisõigusest olemasolevates tabelites ainult täieliku andmebaasi juurdepääsu korral. Kui see praegu ei ole selge, peaks mõned näited aitama anda selgust.

Ülaltoodud näite põhjal näete seda näiteks sisestades, "sinu kasutaja" - "," admin "-" või mõni muu kasutaja nimi, saame koheselt sellele kasutajale sisse logida ilma parooli teadmata. Kui oleme süsteemis viibinud, ei tea me, et me ei ole tegelikult see kasutaja, seega on meil täielik juurdepääs sellele kontole. Andmebaasi õigused ei taga selle jaoks turvavõrku, sest tavaliselt peab veebisaidil olema vähemalt lugemis- ja kirjutusõigus oma vastavasse andmebaasi..

Oletame nüüd, et veebisait kontrollib täielikult oma vastavat andmebaasi, mis annab võimaluse kustutada kirjeid, lisada / eemaldada tabeleid, lisada uusi turvakontode jms. Oluline on märkida, et mõned veebirakendused vajavad seda tüüpi luba, nii et ei ole automaatselt halb, kui täielik kontroll on antud.

Seega selleks, et illustreerida sellises olukorras tekitatavat kahju, kasutame ülalmainitud koomiksit, sisestades järgneva kasutaja nime väljale: "Robert"; DROP TABLE Kasutajad; - ". Pärast lihtsat asendamist muutub autentimisküsimus:

SELECT UserID kasutajatelt WHERE UserName = "Robert"; DROP TABLE Kasutajad; - 'JA salasõna = "valeülekanne"

Märkus: semikoolon on SQL-päringus, mida kasutatakse konkreetse avalduse lõppu ja uue avalduse alguseks..

Mis andmebaasi täidab:

SELECT UserID kasutajatelt WHERE UserName = "Robert"

DROP TABLE Kasutajad

Nii et just nagu oleme kasutanud SQLI rünnakut kogu kasutajate tabeli kustutamiseks.

Loomulikult võib palju hullem olla, sest sõltuvalt lubatud SQL-õigustest saab ründaja väärtusi, tabelite (või kogu andmebaasi) muuta tekstifailiks, luua uusi sisselogimiskontosid või isegi kaaperdada kogu andmebaasi installi.

SQL-injektsioonirünnaku ennetamine

Nagu me mitu korda varem mainisime, on SQL-i süstimisrünnak kergesti välditav. Üks veebiarenduse peamisi reegleid on see, et te ei usalda kunagi kunagi kasutaja sisendit, nagu me tegime, kui me tegime ülaltoodud päringu korral lihtsa asenduse.

SQLI rünnaku on kergesti takistanud teie sisendite desinfitseerimine (või põgenemine). Tühjendusprotsess on tegelikult üsna triviaalne, sest kõik see on sisuliselt ükskõik millise sisemise ühekordse tsiteeringu (') tähemärki asjakohane, nii et neid ei saa kasutada stringide enneaegseks lõpetamiseks SQL-i käsu sees.

Näiteks, kui soovisite andmebaasis „O'neil” otsida, ei saanud te lihtsat asendust kasutada, sest O-i järel olev tsitaat põhjustaks stringi enneaegse lõpetamise. Selle asemel desinfitseerige see vastava andmebaasi põgenemise märgi abil. Oletame, et inline ühe tsitaadi põgenemise märk on iga sümboliga tsiteeritud. Niisiis oleks „O'neal” desinfitseeritud kui „O“ \ t.

See lihtne sanitaaraktsioon takistab SQLI rünnakut. Et illustreerida, vaadake uuesti oma eelmised näited ja vaadake tulemuste päringuid, kui kasutaja sisend on desinfitseeritud.

myuser '-- / viga:

SELECT UserID kasutajatelt WHERE UserName = "myuser" - 'JA salasõna = "väärkäsk"

Kuna üksik tsitaat pärast myuser on põgenenud (see tähendab, et seda peetakse osaks sihtväärtusest), otsib andmebaas sõna otseses mõttes kasutaja nime "myuser" - ". Lisaks, kuna kriipsud on stringide väärtuses ja mitte SQL-is, peetakse neid SQL-kommentaarina tõlgendamise asemel sihtväärtuse osaks.

Robert '; DROP TABLE Kasutajad;-- / viga:

SELECT UserID kasutajatelt WHERE UserName = "Robert"; DROP TABLE Kasutajad; - 'JA salasõna = "valeülekanne"

Lihtsalt pääsedes ühest tsitaadist pärast Robertit, on nii semikoolon kui ka kriips kasutajanime otsingustringis, nii et andmebaas otsib sõna otseses mõttes "Robert"; DROP TABLE Kasutajad; - " tabeli kustutamise asemel.

Kokkuvõttes

Kuigi veebirünnakud arenevad ja muutuvad keerukamaks või keskenduvad teisele sisenemispunktile, on oluline meeles pidada, et kaitsta proovitud ja tõeliste rünnakute eest, mis on inspireerinud mitmeid vabalt kättesaadavaid „häkkeritööriistu”, mis on mõeldud nende kasutamiseks..

Teatud tüüpi rünnakuid, nagu DDoS, ei saa kergesti vältida, samas kui teised, näiteks SQLI, saavad seda teha. Samas võivad sellised rünnakud teha kahju, mis ulatub ebamugavustest katastroofilistele, sõltuvalt ettevaatusabinõudest.