Leaderboard

If you wanna look mai de aproape: http://rgho.st/7bcYZLH4J

https://www.deepin.org/ Download Torrent : deepin-15.2-amd64.iso & deepin-15.2-i386.iso Eu sunt super multumit de el , il folosesc ca si Desktop and Gaming Steam !

Daca te crezi puternic printr-un grad pe forum, ai probleme la mansarda. Deal with it.

Tin de la inceput sa mentionez ca tutorialul este pentru aplicatii web. De-a lungul timpului am vazut numeroase persoane care, desi aveau cunostinte despre anumite vulnerabilitati web(de ce apar, cum se exploateaza, etc.), nu reuseau sa gaseasca mai nimic in aplicatii web reale. Acest lucru se datoreaza faptului ca au sarit peste o etapa esentiala a unui audit de securitate si anume, Information Gathering. Neavand o metodologie clara si un plan de atac bine stabilit, acestia nu erau in masura sa obtina date suficiente despre aplicatiile pe care le analizau iar ca urmare a acestui lucru nu reuseau sa identifice vulnerabilitatile. In acest tutorial vom discuta despre care sunt informatiile de care avem nevoie despre tinta si cum le putem afla astfel incat sa ne maximizam rezultatele. Asa cum spuneam la inceputul acestui tutorial, Information Gathering este etapa initiala a oricarui audit de securitate IT care poate face diferenta dintre succes si esec. Prin aceastea, pentesterul incearca sa obtina toate informatiile posibile despre tinta folosindu-se de diferite servicii (motoare de cautare, diferite utilitare, etc.). Intrucat nu exista un model standard, fiecare pentester este liber sa isi construiasca propria metodologie astfel incat rezultatele sa fie cat mai bune. In cele ce urmeaza voi prezenta modul in care obisnuiesc eu sa abordez o tinta atunci cand realizez un audit de securitate. 1.Motoarele de cautare Primul lucru pe care trebuie sa il faci este sa cauti informatii prin intermediul motoarelor de cautare folosindu-te de diferiti operatori de cautare. Astfel poti obtine subdomeniile, diferite fisiere, tehnologiile folosite de aplicatia web si chiar unele vulnerabilitati. Exemplu: diferite subdomenii ale yahoo.com Cei mai folositori operatori ai motorului de cautare Google sunt: site: - acest operator permite afisarea rezultatelor doar de pe un anumit domeniu si este extrem de folositor pentru descoperirea subdomeniilor. Exemplu: site:*.yahoo.com filetype: sau ext: limiteaza rezultatele afisand doar paginile care au o anumita extensie si pot fi folosite pentru a descoperi tehnologiile folosite in dezvoltarea aplicatiei web. Exemplu: site:*.yahoo.com ext:php – am limitat rezultatele cautarii la subdomeniile yahoo.com care au fisiere .php intext:<termen> limiteaza rezultatele afisand doar paginile in care se regaseste termenul specificat si poate fi folosit pentru a descoperi diferite vulnerabilitati. Exemplu: site:targetwebsite.com intext:”You have an error in your SQL syntax” site:targetwebsite.com intext:”Microsoft OLE DB Provider for SQL Server” site:targetwebsite.com intext:”Microsoft JET Database Engine” site:targetwebsite.com intext:”Type mismatch” site:targetwebsite.com intext:”Invalid SQL statement or JDBC” site:targetwebsite.com intext:”mysql_fetch_array()” site:targetwebsite.com intext:”mysql_” operatori logici: Google accepta anumiti operatori logici care de cele mai multe ori sunt foarte folositori. De exemplu, putem exclude din rezultate anumite subdomenii folosind operatorul - . Astfel, site:.yahoo.com -site:games.yahoo.com va returna subdomeniile yahoo.com, mai putin rezultatele care au legatura cu games.yahoo.com. Mai multe informatii despre operatorii de cautare pentru Google gasesti aici si aici. Pe langa motoarele de cautare obsnuite ca Google, Bing, Yahoo etc., foloseste si: Censys - Foarte folositor in descoperirea subdomeniilor Exemplu: https://www.censys.io/certificates?q=parsed.subject.organization%3A%22Yahoo%22 Shodan 2. Determinarea tehnologiilor folosite La acest pas va trebuie sa verifici daca: aplicatia web este protejata de vreun Web Application Firewall (WAF) Cel mai simplu mod prin care poti face acest lucru este folosind wafw00f: $ python watw00f2.py http://www.targetwebsite.com aplicatia web foloseste un Content Management System (CMS) open-source (Wordpress, Joomla, Drupal, etc.) Poti verifica acest lucru folosind whatweb, cms-explorer, CMSmap. $ whatweb -a 3 http://targetwebsite.com $ cms-explorer.pl -url http://targetwebsite.com/ -type wordpress Urmatorul pas consta in identificarea sistemului de operare, al tipului de WebServer (Apache, IIS) folosit de tinta si versiunea acestora. Daca versiunile celor doua sunt outdated, cel mai probabil exista cateva vulnerabilitati cunoscute (CVE) in acele produse. Poti descoperi acest lucru cu o simpla cautare pe http://cvedetails.com . Exemplu: Vulnerabilitatile cunoscute pentru Apache 2.3.1 Determinarea sistemului de operare se poate realiza foarte simplu folosind nmap. $ nmap -sV -O www.targetwebsite.com Metodele prin care poti identifica versiunea Webserver-ului sunt: Analizand output-ul cererilor HTTP care folosesc metoda HEAD, OPTIONS sau TRACE Raspunsul HTTP al unei cereri care foloseste una din metodele de mai sus va contine, de cele mai multe ori, si headerul Server. Analizand pagina de eroare 404 Folosind httprecon / httprint . Un alt aspect important il constituie tehnologia server-side folosita de tinta. Cel mai simplu mod in care aceasta poate fi descoperita este urmarind extensiile fisierelor. De exemplu, daca URL-ul tintei este http://targetwebsite.com/index.php , este clar ca aplicatia web a fost scrisa in limbajul PHP. Alte extensii specifice tehnologiilor server-side sunt: .py – Python .rb – Ruby .pl – Perl .php / .php3 / .php4 / .php5 / .phtml / .phps – PHP .asp – Active Server Pages (Microsoft IIS) .aspx – ASP+ (Microsoft .NET) .asmx – ASP.NET WebServer .cfm – ColdFusion .cfml – Cold Fusion Markup Language .do – Java Struts .action – Java Struts .jnpl – Java WebStart File .jsp – Java Server Page .nsf – Lotus Domino server In cazul in care extensiile nu sunt vizibile in URL, poti identifica tehnologia server-side folosita analizand cookie-ul pe care aplicatia web il seteaza. Exemplu: PHPSESSID=12355566788kk666l544 – PHP De asemenea, iti poti da seama daca o aplicatie web este scrisa in PHP si prin intermediul unui Easter Egg. Daca adaugi codul ?=PHPE9568F36-D428-11d2-A769-00AA001ACF42 la finalul unui URL iar in pagina apare o imagine amuzanta inseamna ca aplicatia respectiva a fost dezvoltata folosind PHP. Bineinteles, acest Easter Egg poate fi dezactivat din php.ini. Mai multe informatii gasesti aici. 3. Identificarea fisierelor aplicatiei web La acest pas nu trebuie decat sa accesezi cat mai multe pagini alte aplicatiei web, fara a face nimic altceva. Viziteaza fiecare pagina insa nu uita sa conectezi browserul la Burp Suite pentru a se crea site-map-ul aplicatiei web. Astfel vei avea o evidenta mult mai clara asupra fisierelor pe care urmeaza sa le testezi. Foloseste Burp Spider pe langa navigarea manuala pentru a descoperi cat mai multe fisiere. PS: verifica daca exista fisierul robots.txt Dupa ce consideri ca ai navigat suficient printre fisierele aplicatiei web, trebuie sa descoperi fisierele ascunse. Exista numeroase aplicatii care te pot ajuta: Dirbuster Functia Discover Content a aplicatiei BurpSuite Wfuzz Patator Burp Intruder Liste de cuvinte pentru scripturile de mai sus: fuzzdb gitDigger svnDigger SecLists Urmatorul pas este sa iei la rand fiecare fisier gasit si sa incerci sa intelegi cum functioneaza aplicatia web respectiva. Pentru a-ti fi mai usor sa iti dai seama unde ar putea exista o vulnerabilitate, pune-ti urmatoarele intrebari: 1. In fisierul pe care il testezi, continutul se modifica in mod dinamic in functie de anumite criterii (valoarea unui parametru din URL, cookie, user agent etc.) ? Mai exact, este posibil ca in acel fisier aplicatia web sa foloseasca informatii dintr-o baza de date? Daca da, testeaza in primul rand pentru vulnerabilitatile de tip injection (SQL, XPATH, LDAP, etc.) insa nu neglija celelalte tipuri de vulnerabilitati. S-ar putea sa ai surprize. 2. Poti controla in vreun fel continutul paginii? Ceilalti utilizatori pot vedea datele pe care le introduci tu? Daca da, testeaza in special pentru vulnerabilitati de tip Cross Site Scripting si Content Spoofing. 3. Aplicatia web poate interactiona cu alte fisiere? Daca da, testeaza in special pentru Local File Inclusion. 4. In fisierul respectiv exista functii care necesita nivel sporit de securitate (cum ar fi formular de schimbare al emailului/parolei etc.)? Daca da, testeaza in special pentru Cross Site Request Forgery. Nu uita sa testezi fiecare parametru al fiecarui fisier pe care l-ai descoperit.

Viata nu e corecta,cei puternici domina,cei slabi se supun,Deal with it.