Cum hackerii preia site-urile web cu injecție SQL și DDoS
Chiar dacă ați urmat numai evenimentele grupurilor de hackeri Anonymous și LulzSec, probabil că ați auzit despre site-uri web și despre serviciile care au fost hackate, cum ar fi hack-urile infamous Sony. Te-ai întrebat vreodată cum o fac??
Există o serie de instrumente și tehnici pe care aceste grupuri le folosesc și, deși nu încercăm să vă oferim un manual pentru a face acest lucru singur, este util să înțelegeți ce se întâmplă. Două dintre atacurile pe care le auzi în mod constant despre acestea sunt "Distribuit Denial of Service" (DDoS) și "SQL Injections" (SQLI). Iată cum funcționează.
Imagine de xkcd
Denegarea atacului de serviciu
Ce este?
O "negare a serviciului" (uneori numită "denial distribuit de serviciu" sau DDoS) apare atunci când un sistem, în acest caz un server web, primește atât de multe cereri la un moment dat că resursele serverului sunt supraîncărcate, și se închide. Scopul și rezultatul unui atac de succes DDoS este că site-urile web de pe serverul destinație nu sunt disponibile pentru a legitima cererile de trafic.
Cum functioneazã?
Logistica atacului DDoS poate fi cel mai bine explicată printr-un exemplu.
Imaginați-vă că un milion de persoane (atacatorii) se reunesc cu scopul de a împiedica afacerea Companiei X prin luarea în jos a centrului de apeluri. Atacatorii se coordonează astfel încât, marți, la ora 9 dimineața, toți să sune la numărul de telefon al companiei X. Cel mai probabil, sistemul de telefonie al Companiei X nu va putea gestiona simultan un milion de apeluri, astfel încât toate liniile de intrare să fie legate de atacatori. Rezultatul este că apelurile legitime ale clienților (adică cele care nu sunt atacatorii) nu au loc, deoarece sistemul telefonic este legat de manipularea apelurilor de la atacatori. Deci, în esență, compania X pierde potențial din cauza solicitărilor legitime în imposibilitatea de a trece prin.
Un atac DDoS pe un server web funcționează exact în același mod. Deoarece nu există practic nici o modalitate de a ști care este traficul provenit din cererile legitime împotriva atacatorilor până când serverul web procesează cererea, acest tip de atac este de obicei foarte eficient.
Executarea atacului
Datorită naturii "forței brute" a unui atac DDoS, trebuie să aveți o mulțime de computere toate coordonate pentru a ataca în același timp. Revizuirea exemplului nostru de call center ar necesita ca toți atacatorii să știe să sune la ora 9 dimineața și să sune de fapt la acel moment. În timp ce acest principiu va funcționa cu siguranță atunci când vine vorba de atacarea unui server web, devine mult mai ușor atunci când sunt folosite calculatoare zombie, în loc de computere reale cu echipaj.
După cum probabil știți, există o mulțime de variante de malware și troieni care, odată ce vă aflați în sistem, se află latente și uneori "telefon acasă" pentru instrucțiuni. Una dintre aceste instrucțiuni ar putea fi, de exemplu, de a trimite solicitări repetate la serverul Web al companiei X la ora 9:00. Prin urmare, printr-o singură actualizare a locației de acasă a malware-ului respectiv, un singur atacator poate coordona instantaneu sute de mii de computere compromise pentru a efectua un atac masiv DDoS.
Frumusețea utilizării computerelor zombie nu este numai în eficiența sa, ci și în anonimatul său, deoarece atacatorul nu trebuie să utilizeze deloc computerul pentru a executa atacul.
SQL Injection Attack
Ce este?
Un atac SQL "SQL Injection" (SQL injection) este un exploit care profită de tehnicile de dezvoltare web slabă și, în mod obișnuit, combinat cu securitatea bazelor de date defecte. Rezultatul unui atac de succes poate varia de la impersonarea unui cont de utilizator la un compromis complet al respectivei baze de date sau server. Spre deosebire de un atac DDoS, un atac SQLI este complet și ușor de prevenit dacă o aplicație web este programată corespunzător.
Executarea atacului
De fiecare dată când vă conectați la un site Web și introduceți numele de utilizator și parola, pentru a vă testa acreditările, aplicația web poate executa o interogare precum:
SELECT UserID FROM Utilizatori WHERE UserName = "myuser" ȘI Password = "mypass";
Notă: valorile șirului dintr-o interogare SQL trebuie să fie închise în citate unică, motiv pentru care apar în jurul valorilor introduse de utilizator.
Așadar, combinația dintre numele de utilizator introdus (myuser) și parola (mypass) trebuie să se potrivească cu o intrare din tabelul Users, pentru ca un ID de utilizator să fie returnat. Dacă nu există nici o potrivire, nici un ID de utilizator nu este returnat, astfel încât acreditările de autentificare să fie nevalide. În timp ce o anumită implementare poate diferi, mecanica este destul de standard.
Deci, haideți să examinăm o interogare de autentificare a șabloanelor pe care o putem înlocui cu valorile introduse de utilizator pe formularul web:
SELECT Nume utilizator FROM FROM WHERE UserName = "[utilizator]" și Password = "[pass]"
La prima vedere, acest lucru poate părea un pas simplu și logic pentru validarea ușoară a utilizatorilor, totuși dacă se face o substituire simplă a valorilor introduse de utilizator pe acest șablon, este susceptibilă la un atac SQLI.
De exemplu, să presupunem că "myuser'-" este introdus în câmpul cu numele de utilizator și că "password wrongpass" este introdus în parolă. Folosind o substituție simplă în interogarea noastră șablon, am obține acest lucru:
SELECT Nume utilizator FROM FROM WHERE UserName = "myuser" - "AND Password =" wrongpass "
O cheie la această afirmație este includerea celor două liniuțe (-). Acesta este jetonul de început pentru declarațiile SQL, astfel încât orice element care apare după cele două liniuțe (inclusiv) va fi ignorat. În esență, interogarea de mai sus este executată de către baza de date ca:
SELECT UserID FROM Utilizatori WHERE UserName = "myuser"
Omisiunea flagrantă aici este lipsa verificării parolei. Prin includerea celor două liniuțe ca parte a câmpului de utilizator, am depășit complet condiția de verificare a parolei și am putut să ne conectăm ca "myuser" fără a cunoaște parola respectivă. Acest act de manipulare a interogării pentru a produce rezultate neintenționate este un atac de injecție SQL.
Ce prejudiciu se poate face?
Un atac de injectare SQL este cauzat de codificarea aplicațiilor neglijente și iresponsabile și este complet prevenit (pe care îl vom acoperi într-o clipă), cu toate acestea gradul de deteriorare care se poate face depinde de configurarea bazei de date. Pentru ca o aplicație web să comunice cu baza de date backend, aplicația trebuie să furnizeze o autentificare în baza de date (notați, aceasta este diferită de autentificarea unui utilizator pe site-ul propriu-zis). În funcție de permisiunile pe care le cere aplicația web, respectivul cont de baze de date poate necesita orice permisiune de citire / scriere în tabelele existente, numai pentru a accesa baza de date completă. Dacă acest lucru nu este clar acum, câteva exemple ar trebui să ofere o anumită claritate.
Pe baza exemplului de mai sus, puteți vedea acest lucru introducând, de exemplu, "youruser" - "," admin "-" sau orice alt nume de utilizator, putem intra instantaneu pe site ca acel utilizator fără a cunoaște parola. Odată ce ne aflăm în sistem, nu știm că nu suntem acel utilizator, deci avem acces deplin la contul respectiv. Permisiunile bazei de date nu vor oferi o plasă de siguranță pentru aceasta deoarece, de obicei, un site web trebuie să aibă cel puțin acces la citire / scriere în baza de date respectivă.
Acum, să presupunem că site-ul Web deține un control deplin asupra bazei sale de date care oferă posibilitatea de a șterge înregistrări, de a adăuga / elimina tabele, de a adăuga noi conturi de securitate etc. Este important să rețineți că unele aplicații web ar putea avea nevoie de acest tip de permisiune nu este automat un lucru rău că se acordă control complet.
Deci, pentru a ilustra daunele care pot fi cauzate în această situație, vom folosi exemplul furnizat în comicul de mai sus introducând următoarele în câmpul cu numele de utilizator: "Robert"; "Utilizatori DROP TABLE" - ". După o înlocuire simplă, interogarea de autentificare devine:
SELECT Nume utilizator FROM FROM WHERE UserName = "Robert"; DROP TABLE Utilizatori - 'AND Password =' wrongpass '
Notă: punct și virgulă într-o interogare SQL este folosit pentru a indica sfârșitul unei instrucțiuni speciale și începutul unei declarații noi.
Ce se execută de către baza de date ca:
SELECT Nume utilizator FROM FROM WHERE UserName = "Robert"DROP TABLE Utilizatori
Prin urmare, am folosit un atac SQLI pentru a șterge întregul tabel Utilizatori.
Desigur, mult mai rău poate fi făcut ca, în funcție de permisiunile SQL permise, atacatorul poate schimba valori, tabele de dump (sau întreaga bază de date în sine) într-un fișier text, poate crea noi conturi de conectare sau poate chiar deturna întreaga instalare a bazei de date.
Prevenirea unui atac de injectare SQL
Așa cum am menționat mai demult, un atac de injecție SQL este ușor de prevenit. Una dintre regulile cardinale ale dezvoltării web este că niciodată nu crezi că ai încredere în utilizatori ca și când am efectuat o înlocuire simplă în interogarea noastră de șablon de mai sus.
Un atac SQLI este ușor împiedicat de ceea ce se numește dezinfecție (sau scaparea) intrărilor dvs. Procesul de dezintoxicare este de fapt destul de banal, deoarece tot ceea ce face în mod esențial este manipularea oricărui tip de caractere inline (') în mod corespunzător astfel încât să nu poată fi folosit pentru a termina prematur un șir în interiorul unei instrucțiuni SQL.
De exemplu, dacă ați fi vrut să căutați "O'neil" într-o bază de date, nu ați putut folosi o substituție simplă, deoarece citatul unic după O va determina încheierea prematură a șirului. În schimb, o dezinfectați utilizând caracterul de evacuare al bazei de date respective. Să presupunem că caracterul de evacuare pentru o cotație inline unică este precedată de fiecare citare cu un simbol. Deci, "O'neal" ar fi sanitizat ca "O \ 'neil".
Acest simplu act de salubritate previne destul de mult un atac SQLI. Pentru a ilustra, să revedem exemplele noastre anterioare și să vedem interogările care rezultă atunci când intrarea utilizatorului este dezinfectată.
myuser“-- / wrongpass:
SELECT Nume utilizator FROM FROM WHERE UserName = "myuser" - "AND Password =" wrongpass "
Deoarece citatul unic după ce myuser este scăpat (adică este considerat o parte a valorii țintă), baza de date va căuta literalmente numele UserName al "Myuser" -". În plus, deoarece liniuțele sunt incluse în valoarea șirului și nu în instrucțiunea SQL în sine, ele vor fi considerate parte din valoarea țintă în loc să fie interpretate ca un comentariu SQL.
Robert "; DROP TABLE Utilizatori;-- / wrongpass:
SELECT UserID FROM Utilizatori WHERE UserName = "Robert \"; DROP TABLE Utilizatori - 'AND Password =' wrongpass '
Prin simpla scăpare a cotei unice de la Robert, ambele punct și virgulă sunt cuprinse în șirul de căutare UserName, astfel că baza de date va căuta literalmente "Robert"; "Utilizatori DROP TABLE" - " în loc să executați ștergerea tabelului.
În concluzie
În timp ce atacurile web evoluează și devin mai sofisticate sau se concentrează pe un punct de intrare diferit, este important să ne amintim să protejăm împotriva atacurilor încercate și adevărate care au fost sursa de inspirație a mai multor "instrumente de hacker" disponibile în mod liber pentru a le exploata.
Anumite tipuri de atacuri, cum ar fi DDoS, nu pot fi ușor evitate în timp ce altele, cum ar fi SQLI, pot. Cu toate acestea, daunele care pot fi cauzate de aceste tipuri de atacuri pot varia de la un inconvenient la un dezastru, în funcție de precauțiile luate.
