Acest document nu acoperă sintaxa de bază SQL sau injectarea SQL. Se presupune că cititorul are deja o înțelegere excelentă a subiectului. Acest document se va concentra pe tehnici avansate care pot fi utilizate în atacurile asupra aplicațiilor web folosind Microsoft SQL Server. Aceste tehnici demonstrează modul în care un atacator poate folosi injecții SQL pentru a extrage conținut din baza de date, ocolind paravanul de protecție și pătrundând în rețeaua internă. Acest document este conceput pentru a învăța profesioniștii în domeniul securității informațiilor despre efectele potențial periculoase ale injecțiilor SQL care pot apărea în organizația dvs.
introducere
SQL Injection Detection
Obținerea rezultatelor din SQL Injections
Îmbunătățirea privilegiilor
Încărcarea fișierelor
Intruziunea în rețeaua internă
Port scanare
recomandări
concluzie
Acest document nu acoperă sintaxa de bază SQL sau injectarea SQL. Se presupune că cititorul are deja o înțelegere excelentă a subiectului. Acest document se va concentra pe tehnici avansate care pot fi utilizate în atacurile asupra aplicațiilor web folosind Microsoft SQL Server. Aceste tehnici demonstrează modul în care un atacator poate folosi injecții SQL pentru a extrage conținut din baza de date, ocolind paravanul de protecție și pătrundând în rețeaua internă. Acest document este conceput pentru a învăța profesioniștii în domeniul securității informațiilor despre efectele potențial periculoase ale injecțiilor SQL care pot apărea în organizația dvs.
Aplicațiile Web devin din ce în ce mai sigure, deoarece numărul de notificări de atacuri, cum ar fi injecția SQL, crește. Cu toate acestea, în aplicațiile mari și complexe, o singură supraveghere poate fi rezultatul compromiterii întregului sistem. Mulți dezvoltatori de aplicații web și administratori pot avea un sentiment fals de securitate, deoarece folosesc proceduri stocate sau ascund mesajele de eroare returnate în fereastra browserului. Acest lucru dă motive să creadă că vulnerabilitatea nu poate fi utilizată.
Deși discutăm Microsoft SQL Server în acest document, acest lucru nu înseamnă că acest produs este mai puțin sigur decât alte platforme, cum ar fi Oracle sau IBM DB2. Injecția SQL nu este o vulnerabilitate specifică Microsoft SQL Server este, de asemenea, o problemă de bază de date în general. Poate că cea mai mare problemă cu Microsoft SQL Server este flexibilitatea. Această flexibilitate deschide noi oportunități pentru atacurile clasei SQL Injection. Scopul acestui document este de a arăta că, ori de câte ori un administrator sau un dezvoltator permite executarea unei interogări SQL arbitrare, sistemul atacat este deschis pentru captură completă. Acest lucru nu înseamnă că produsul Microsoft SQL Server este vulnerabil în ansamblu.
SQL Injection Detection
Când încercați să utilizați injecții SQL în aplicații, atacatorul are nevoie de o metodă pentru a determina dacă a fost introdusă o interogare SQL arbitrară. Există, de asemenea, o nevoie pentru o metodă de obținere a rezultatelor. Pentru aceasta, pot fi utilizate două funcții server SQL încorporate. Funcțiile OPENROWSET și OPENDATASOURCE pentru deschiderea unei surse de date la distanță. Aceste funcții sunt utilizate pentru a deschide o conexiune printr-un furnizor OLEDB. Funcția OPENROWSET va fi utilizată în toate exemplele, dar funcția OPENDATASOURCE poate fi utilizată cu aceleași rezultate.
Această expresie returnează toate rândurile tabelului1 din sursa de date la distanță:
Opțiuni:
(1) Numele furnizorului OLEDB
(2) Șir de conectare (poate fi în formatul cerut de OLEDB sau ODBC)
(3) expresia SQL
În procesul de injectare SQL, atacatorul poate determina dacă interogarea SQL a fost executată. Dacă interogarea SQL are succes, serverul atacat va încerca să stabilească o conexiune de ieșire cu computerul atacatorului la portul specificat. Această conexiune SQL exterioară va fi, în majoritatea cazurilor, blocată de paravanul de protecție, deoarece este utilizat portul 80.
Această tehnică permite atacatorului să afle dacă a fost executată interogarea SQL, chiar dacă mesajele de eroare și rezultatele interogării nu au fost afișate în fereastra browserului.
Obținerea rezultatelor din SQL Injections
Funcțiile OPENROWSET și OPENDATASOURCE sunt utilizate cel mai adesea pentru a extrage datele necesare. Ele pot fi, de asemenea, folosite pentru plasarea datelor pe un server SQL la distanță. Funcția OPENROWSET poate fi utilizată nu numai pentru a executa o interogare SELECT, dar și pentru a efectua INSERT și DELETE în sursele de date externe. Prelucrarea datelor de la o sursă la distanță nu este un caz general și funcționează numai dacă furnizorul OLEDB acceptă această caracteristică. Furnizorul SQLOLEDB are o astfel de funcționalitate.
Următoarea este un exemplu despre modul de plasare a datelor într-o sursă de date externă:
În acest exemplu, toate rândurile din tabela 2 a serverului SQL local vor fi adăugate la tabela table1 localizată pe serverul de la distanță. Pentru realizarea cu succes a interogării, este necesar ca ambele tabele să aibă o structură similară.
După cum am aflat în paragraful anterior, sursele de date la distanță pot fi redirecționate către orice server de atac al atacatorului.
Atacatorul poate modifica interogarea de mai sus pentru a se conecta la o sursă de date la distanță, cum ar fi o copie a Microsoft SQL Server care rulează pe aparatul atacatorului.
Pentru a introduce datele cu succes, atacatorul trebuie să creeze un tabel1 cu aceleași coloane și tipuri de date ca în tabelul2. Aceste informații pot fi determinate folosind același truc pentru tabelele de sistem. Acest lucru va funcționa, deoarece structura tabelelor de sistem este cunoscută în prealabil. Atacatorul ar trebui să înceapă prin crearea de tabele cu o structură identică cu tabelele de sistem sysdatabases, sysobjects și syscolumns. Apoi, pentru a extrage informațiile necesare, trebuie executate următoarele interogări SQL:
După recrearea tabelelor din baza de date, încărcarea datelor necesare de pe serverul SQL este trivială.
Folosind această metodă, un atacator poate extrage conținut din tabele, chiar dacă aplicația ascunde mesajele de eroare sau rezultatele unor cereri nevalide.
După ce a primit privilegiile corespunzătoare, atacatorul va putea încărca lista de conectări și parole:
Parola de primire a hash-urilor permite atacatorului să utilizeze un atac brutal pentru a găsi parole.
De asemenea, atacatorul va putea să execute comenzi pe serverul atacat și să primească rezultatele executării acestora:
Dacă paravanul de protecție este configurat să blocheze toate conexiunile de server SQL, atacatorul poate folosi una din metodele de ocolire a firewall-ului. Atacatorul poate folosi portul 80 pentru conexiunea HTTP la transmiterea datelor. Mai jos este un exemplu al acestei tehnici:
Dacă conexiunea de ieșire către portul 80 este blocată de paravanul de protecție, atunci atacatorul poate încerca să utilizeze celelalte numere de port până când află deblocatul.
Îmbunătățirea privilegiilor
Adesea, administratorul, în urma recomandărilor de securitate, configurează aplicațiile să ruleze ca utilizator neprivilat. După ce a găsit o vulnerabilitate într-o aplicație lansată de un utilizator nepotrivit, atacatorul încearcă să ridice privilegiile și să obțină drepturi administrative. Un atacator poate folosi alte vulnerabilități cunoscute și necunoscute, ceea ce duce la creșterea privilegiilor. Există câteva vulnerabilități proaspete detectate în serverul SQL, dacă atacatorul poate efectua interogări SQL arbitrare, atunci poate să ridice relativ ușor privilegii.
Încărcarea fișierelor
Odată ce atacatorul a primit privilegiile de server SQL necesare, el ar putea să încarce un fișier binar pe server. Deoarece acest lucru nu se poate face folosind un protocol precum SMB, porturile 137-139 sunt de obicei blocate de un firewall, atacatorul are nevoie de o altă metodă pentru a plasa fișierul binar în sistemul de fișiere al victimei. Acest lucru se poate face prin încărcarea unui fișier binar într-un tabel local pe gazda atacatorului și punerea fișierului pe gazda atacată utilizând o conexiune la serverul SQL.
Pentru a implementa acest lucru, atacatorul trebuie să creeze un tabel pe serverul local, după cum urmează.
După crearea tabelului pentru fișierul binar, încărcați-l după cum urmează:
Un fișier binar poate fi descărcat pe serverul victimă de pe serverul atacatorului utilizând următoarea interogare SQL executată pe serverul victimă:
Această solicitare va duce la o conexiune de ieșire la serverul atacatorului și va scrie rezultatul interogării într-un fișier. În acest caz, conexiunea are loc utilizând protocolul și portul implicit, această conexiune este probabil să fie blocată de paravanul de protecție. Pentru a ocoli firewall-ul, atacatorul poate încerca să folosească:
Prima interogare SQL configurează o conexiune la serverul hacker pentru a utiliza portul 80, cea de-a doua interogare SQL se conectează la serverul hacker utilizând portul 80 și încarcă fișierul binar.
Folosind această tehnică, scriptul se va conecta la un server și va descărca fișierul binar al atacatorului sau va copia și rula fișierul de pe serverul victimă.
Intruziunea în rețeaua internă
Serverele Microsoft SQL Server conectate și la distanță permit unui server să interacționeze transparent cu un alt server de baze de date la distanță. Serverele conectate vă permit să efectuați interogări distribuite și chiar să vă permiteți să gestionați servere de baze de date la distanță. Atacatorul poate profita de aceste oportunități pentru a accesa rețeaua internă.
Atacatorul ar trebui să înceapă prin colectarea informațiilor stocate în master.dbo.sysservers în tabelul de sistem, așa cum sa demonstrat aici:
Mai mult, atacatorul poate solicita informații de la serverul de la distanță conectat.
Dacă serverele nu sunt configurate pentru a accesa datele (nu sunt configurate pentru cereri arbitrare, sunt permise numai procedurile stocate), atacatorul poate încerca:
Folosind această tehnică, un atacator poate "sări" de la un server la altul, pătrunzând mai adânc în rețeaua internă prin servere conectate și la distanță:
Odată ce atacatorul a primit accesul necesar la serverul conectat sau la distanță, el sau ea ar putea încărca fișierul pe server folosind metodele menționate mai devreme.
Port scanare
După găsirea vulnerabile (web) aplicarea, atacatorul poate utiliza următoarea interogare SQL:
Dacă portul este deschis, timpul de răspuns poate fi mai mic decât setarea timeout-ului (în funcție de aplicația care utilizează acest port) și va fi returnat următorul mesaj de eroare:
Un alt efect posibil al unui astfel de scaner port este un atac DOS. Luați în considerare următorul exemplu:
recomandări
Principala recomandare este să vă asigurați că nu există vulnerabilități în SQL Injection. Aceasta este recomandarea cea mai importantă, deoarece, chiar dacă nu puteți face trucurile descrise în acest articol, ar putea exista o altă modalitate de a exploata vulnerabilitățile. Pentru a proteja împotriva injecțiilor SQL, se recomandă utilizarea interogărilor parametrice și filtrarea intrărilor de utilizator pentru caractere non-alfanumerice.
Metoda cea mai corectă este aderarea la standardele de programare sigure la scrierea aplicațiilor. Dacă codul aplicației este deja scris, trebuie să efectuați un audit pentru a detecta vulnerabilitățile. De asemenea, este recomandat să se adreseze unor mijloace de automatizare, care sunt concepute pentru a detecta aceste tipuri de probleme.
Chiar dacă simțiți că ați închis toate vulnerabilitățile cunoscute, o soluție bună este să dezactivați funcționalitatea serverului SQL neutilizat. Dar numai în cazul în care această funcționalitate nu este cu adevărat necesară pentru dvs. Din fericire, funcțiile pe care vrem să le blocăm nu sunt folosite des.
Trebuie să dezactivați cererile speciale prin OLEDB de la serverul SQL. Capacitatea acestor cereri DisallowAdhocAccess controlate prin stabilirea valorii în registru.
Dacă utilizați instanța implicită, setați valoarea DisallowAdhocAccess = 1 în fiecare switchwitch:
Urmați acești pași pentru a seta această valoare:
Dacă sunteți paranoic, puteți seta cheile de registry în modul read-only astfel încât acestea să nu poată fi editate.
Este, de asemenea, foarte important să se aplice patch-uri care elimină erorile în securitate, este necesar să o faceți în timp util.
Ultima precauție, configurați și testați paravanul de protecție, astfel încât acesta să blocheze traficul de ieșire inutil. Acest lucru va contribui nu numai la menținerea bazei de date, ci și la îmbunătățirea securității rețelei în ansamblu.
Ceea ce am demonstrat în acest document este o mică accesibilitate care poate fi utilizată pentru a obține un control complet asupra mai multor servere. SQL este un limbaj universal. Nu o persoană sănătoasă va permite să execute un cod C ++ arbitrar sau Visual Basic pe server. Același lucru se referă la SQL. Nici o persoană sănătoasă nu va efectua orbește ceea ce a intrat utilizatorul. Acest document arată de ce acest lucru nu ar trebui să se întâmple.
Microsoft SQL Server este un server de baze de date puternic, flexibil și accesibil, care servește drept bază pentru o varietate de aplicații. Pe baza acestui fapt, este important să înțelegem cum poate fi compromis un server SQL, și cu atât mai important este să înțelegem cum poate fi evitată aceasta. Serverul SQL este un instrument și dacă este utilizat în mod incorect sau neglijent, puteți periclita nu numai datele, ci și alte aplicații din rețea. Aceasta înseamnă că trebuie să luăm serios securitatea Microsoft SQL Server.
Articole similare
Trimiteți-le prietenilor: