Leaderboard

Inregistrarea streamului este mai jos. O sa explic ce s-a intamplat. Il citesc pe Vali Petcu (zoso.ro) de foarte multi ani de zile si atata timp cat am activat pe RST am avut o relatie (virtuala), buna cu el. Nu s-a schimbat acest lucru nici in ziua de azi, chiar daca nu am mai vorbit cu el de prin 2012. Si pe Cetin Ametcea (arhiblog.ro), il citesc la fel de des. Nu am nici o problema cu vreunul dintre ei si nici nu voi avea vreodata. Spun asta ca sa fie clar pentru toata lumea. Dupa ce am reaparut pe forumul RST in urma cu cateva zile am zis ca de dragul vremurilor trecute sa fac o ghidusie. Sa ii fac pe Vali si pe Cetin sa vorbeasca despre RST si in acelasi timp sa vad cati oameni pot aduce pe forum intr-o perioada scurta de timp. Targetul principal era Vali, pentru ca stiam ca sunt multi care nu il suporta si de-abia asteapta sa il atace public. Planul de bataie: da-le haterilor informatia de care au nevoie ca sa il atace pe Vali Petcu RST Forums trebuie sa fie in centrul scandalului Vali si cu Cetin trebuie sa raspunda la acuzatiile ca bazele lor de date au ajuns pe mainile hackerilor (Cetin a preferat sa il doara la banana dupa ce si-a dat seama ca e trolling) planteaza samanta indoielii in mintea celor care ar putea fi afectati de atac (comentatorii care isi folosesc mailurile personale pentru a comenta pe blogurile lor) Vali trebuie sa vorbeasca pe stream despre patanie pentru a clarifica situatia poate se gasea si un ziarist imbecil care sa scrie despre asta fara sa verifice Am scris rapid postarea cu "leakul" si am adaugat manual cu font rosu si centrat doua texte: - "trebuie sa fii utilizator inregistrat pentru a vedea linkul" - "trebuie sa scrii 'Thank you' in comentarii pentru a vedea linkul" Asa ii fortam pe curiosi sa se inregistreze si sa lase si un mesaj pe forum. Atat pentru a ii trolla si mai mult, dar si pentru a creste topicul in Google, prin faptul ca exista activitate la el. Vali si cu Cetin si-au facut amandoi cont pe RST si au incercat sa descarce arhiva (care nu a existat niciodata). Daca nu ma insala instinctul probabil ca si Vladuz a fost printre primii care a incercat sa descarce arhiva, dar, repet, ma bazez doar pe instinct cand spun asta, pentru ca am vazut un nickname foarte asemanator in comentariile de la acea postare. Moving forward, au aparut imediat idiotii utili care au imprastiat vestea pe Reddit, exact cum ma asteptam, pentru ca se stia ca nu il halesc redditorii. De acolo discutiile s-au mutat la Vali in comentarii, samanta indoielii a aparut in mintea comentatorilor lui Vali si au inceput sa il acuze pe nedrept ca nu si-a dat interesul sa ii avertizeze ca a fost spart blogul, iar din momentul acela Vali a "clacat" oarecum de nervi si a inceput distractia. Sar peste niste pasi intermediari care au aprins si mai tare discutiile din comentariile de la el de pe blog, i-am mai dat o mica panica, cred eu, cand am postat un comentariu cu mailul lui si cu numele lui, apoi am asteptat streamul urmator sa vad daca vorbeste despre intamplare. Streamul il aveti mai jos. Acum pentru Vali, pentru ca stiu ca va citi asta, o sa il lamuresc de unde aveam mailul cu care comenta pe blogul lui. Si cum o imagine face cat 1000 de cuvinte, iata aici sursa: https://ibb.co/HHbPgFK Mailul a aparut intr-un stream de-al lui vechi si am facut screenshot la momentul respectiv, just in case, ca poate va fi candva util. Aia e, defect profesional A fost fun, nu a implicat hacking ci doar metode simple, dar bine targetate, menite sa inflameze spiritele. Eu m-am distrat, Vali s-a enervat, dar sunt sigur ca apreciaza un trolling bun, chiar daca cel trollat nu a fost el in mod direct, ci haterii si comentatorii lui. In mare parte planul meu a fost indeplinit cu succes, cu toate ca regret ca nu am prins nici un ziarist babalau care sa scrie despre asta. Dar pe viitor poate rezolv si cu treaba asta daca o sa mai am timp si chef. Acestea fiind spuse va las sa urmariti bucata de stream in care Vali vorbeste despre RST si... multumesc Vali

Nicolae Guta - Smecherii si mafia Imi era dor sa citesc un topic cu asa interes la cafea. Am asa un feeling ca e un fight intre generatii dupa anumite comentarii. #şailaicădaimăZindăScai

Au trecut 15 ani de la postarea "Sfaturi de om batran pentru ai nostri hackeri tineri". Acum am 42 de ani, am trecut prin multe experiente mai mult sau mai putin placute, asa ca viziunea mea personala despre viata este, cumva, putin mai diferita. Sa facem un rezumat la ce am spus in urma cu 15 ani. In continuare sunt de aceasi parere. A fi "hacker" este un mindset. In opinia mea a fi "hacker" (blackhat), inseamna in primul rand a sta ascuns. Daca nu te ascunzi cum trebuie nu mai esti hacker, esti puscarias. Doza de dopamina de care ai parte atunci cand primesti laude pentru ce ai facut este o recompensa personala de scurta durata. Nu considera ca ai facut mare lucru. Intotdeauna vor fi alte persoane care vor face acelasi lucru mult mai bine si intr-un mod mult mai interesant decat ai facut-o tu. Nu ti-o lua in cap si nu dezvolta un complex de zeu. Eu am trecut prin asta. E neplacut si te transforma intr-o persoana greu de suportat. Hackingul e pielea pulii, mai ales cand iti chiorăie mațele de foame. Acum citesc si eu, dupa 15 ani de la prima postare, ce opinie aveam despre relationarea cu oamenii. Nu numai ca nu mi-am schimbat parerea, dar chiar am ajuns sa ii indrum si pe altii sa procedeze la fel. A fi o persoana de treaba inseamna pe termen lung a creea conexiuni si relatii de calitate. Pe langa treburile mele am un job stabil, bine platit, pe care l-am obtinut folosind acest principiu. O fosta "victima" a mea este acum angajatorul meu. Lucrez de peste 7 ani in compania detinuta de aceasta persoana, iar datorita faptului ca am fost mereu corect, muncitor si respectuos, aceasta persoana a fost mereu alaturi de mine in cele mai grele momente ale vietii mele si m-a ajutat extraordinar de mult atunci cand aveam nevoie de ajutor. Nu strica sa fii o persoana corecta si de treaba, pentru ca, in general, oamenii cu care interactionam sunt oameni buni. Nu mai fac parte din comunitatea de hacking de foarte multi ani, nu ma mai invart in aceleasi cercuri de oameni in care ma invarteam inainte, asa ca opinia mea actuala se bazeaza pe experientele mele din ultimii 10 ani. Cumva este greu sa prezint aceasta parte, pentru ca am ajuns la un nivel de maturitate si de skilluri in comunicare care rezolva de la sine toate aceste probleme. Ce am invatat: - transmiteti-i direct omului care este perceptia voastra despre ce s-a intamplat - aflati daca persoana respectiva a gresit intentionat, sau pur si simplu a fost o neintelegere - daca a fost o neintelegere aratati-va bunavointa si incercati sa dregeti situatia, chiar daca nu ati fost voi de vina. Neintelegerile sunt insotite de regrete. Daca persoana respectiva regreta cu adevarat ca a gresit, faceti tot posibilul sa ii aratati ca intelegeti prin ce trece si ca nu ii purtati pica. Chiar daca aceasta atitudine nu vă va aduce intotdeauna mari beneficii, va veti simti foarte bine in pielea voastra, si veti dezvolta o relatie OK cu acea persoana. - daca NU a fost o neintelegere puteti urma sfaturile mele anterioare. Regulile raman aceleasi. Nu tineti cont de varsta si de sex, nu trebuie sa aveti mustrari de constiinta, nu trebuie sa va fie frica si NU UITATI. Din pacate asta este viata si uneori este nevoie sa aratam de ce suntem in stare pentru a fi lasati in pace. Nu este nevoie sa mai repet. Odata ce o persoana capata statutul de "inamic" trebuie tratata ca atare. Acum nu mai vorbesc din pozitia de "hacker", ci vorbesc din pozitia de om. Doar sa aveti grija sa nu categorisiti o persoana care a facut o simpla greseala ca fiind "inamic". Nimic nou sub soare. Opinia mea este aceeasi. Voi sari peste anumite puncte pentru ca nu ma mai reprezinta. Nu mai sunt parte din comunitatea RST, deci nu se mai aplica unele situatii. Parerea mea este aceeasi. Hai sa o simplificam si sa dam un exemplu din viata de zi cu zi. Mergi pe strada. La un moment dat dai peste unul plin de muschi, agresiv, pus pe harta, care o cauta cu tine. Daca ai 60 de kg imbracat si zero experienta in lupta, trebuie sa fii cam retard sa ai impresia ca intr-o confruntare 1 la 1 ai avea sanse sa castigi lupta. La fel a fost, este, si va fi, pe internet. Trebuie sa stii care iti sunt limitele. Daca exista o sansa reala de a fi dominat de cineva pe internet sau in viata reala, evita acel confict. E ok. Nu este o rusine sa respecti niste limite pentru a te proteja. Viata e lunga, de ce sa ti-o complici cand poti evita complicatiile? Nu am stapanit niciodata si nici nu cred ca voi stapani vreodata un limbaj de programare. Dar cand a fost nevoie am stiut sa fac singur cateva scripturi sau sa rog / platesc pe cineva sa ma ajute sa fac niste scripturi / programe. In ziua de azi nu cred ca mai conteaza daca esti "hacker" sau nu. Toata lumea este orientata catre castiguri financiare, nu catre a castiga respect in anumite comunitati de baieti priceputi de pe internet. Nu este neaparat un lucru rau, pentru ca vremurile s-au schimbat, prioritatile s-au schimbat, oamenii s-au schimbat. Daca nu stii un limbaj de programare nu este o problema atata timp cat nu iti doresti sa detii, pe bune, statutul de "hacker". Daca esti orientat catre castiguri financiare invata sa ceri programatorului ce ai nevoie, invata sa faci un flow, invata sa comunici cat mai bine ce ai nevoie si mai ales, invata sa vanezi bug-uri pentru a iti perfectiona aplicatia, fie ca este un soft care ruleaza pe propriul pc/telefon, fie ca este o aplicatie web. -------------------- Acum na, nu stiu cine ma mai cunoaste pe aici, cui ii mai pasa de existenta mea si de viata mea. Dar pentru cei care ma cunosc si au cea mai mica curiozitate ce am mai facut de cand am disparut, o sa fac un rezumat al ultimilor 8 ani din viata mea. Nu pentru a imi alimenta egoul, ci pentru a lasa scris experientele prin care am trecut, pentru ca am trecut prin momente de cosmar pe care am reusit sa le depasesc cu brio. Am trecut prin probleme de sanatate mai mari de cat mi-as fi imaginat vreodata. Fibromyalgia mi-a rapit 3 ani din viata si m-a facut din om neom. Din cauza asta am trecut prin axietate si depresie in adevaratul sens al cuvantului. Datorita unui coleg de munca am aflat despre metoda Wim Hof si am reusit sa inving anxietatea, depresia si fibromyalgia, despre care se spune ca este imposibil de vindecat. Inca ii mai simt prezenta uneori, dar reusesc foarte rapid sa o elimin din minte si din organism. Am trecut prin viciul cocainei si al alcoolului. Cine ma cunoaste mai bine stie ca aveam de ani de zile o adictie pentru iarba. La iarba am renuntat la inceputul pandemiei si o consider istorie. A fost cel mai jegos si pervers drog. Mi-am futut rau de tot receptorii canabinoizi si de aici pana la fibromyalgie a fost doar un mic pas. Cand aud prajiti care lauda iarba si efectele ei incerc sa le deschid ochii, chiar daca sansele de a ii convinge sunt minime. Este greu sa te pui cu prostia din mintea oamenilor, mai ales cand acestia fac cherry picking care sa le valideze pozitiv consumul de iarba. Si eu am fost prost asa ca incerc sa nu ii judec pe altii. Dar intre noi fie vorba, fumatorii cronici de iarba sufera de un retard pe care este foarte greu sa il combati. Toti fumatorii cronici, absolut toti, au aceeasi retorica retarda. Iarba e buna, iarba vindeca cancerul, iarba nu da dependenta, iarba nu este gateway drug. Gresit! Iarba FUMATA cauzeaza cancer pulmonar, probleme cardiace, este gateway drug si duce inevitabil la anxietate si depresie. Prajitii sunt prosti rau de tot si nu au nici o directie coerenta in viata. Nici macar consumul de heroina nu mi-a futut sanatatea si creierul asa cum mi le-a futut iarba. Sfat: daca esti prost macar nu mai semnaliza si nu mai face reclama unui drog care fute vieti mai rau decat heroina. Heroina iti da macar un scop, acela de a face rost de urmatoarea doza. Iarba te face apatic, visator, anxios si pierde vara. Adica un ratat care nu realizeaza cat de ratat este. Cele mai proaste decizii luate in viata au fost luate in perioada cand fumam. Am pierdut ani de zile visand la ce voi face maine, fara a face cu adevarat ceva in sensul asta, pentru ca iarba asa cum te face sa visezi si sa iti faci planuri, tot la fel te face sa te si indoiesti de planurile facute. De cocaina nu m-am mai atins de aproape un an. Nu am pofta de ea, sau vreun gand sa ma mai apuc din nou sa o consum. Am fost in preajma ei de cateva ori in ultima perioada si nu mi-a trezit nici o emotie. Muie cox. Iarba a fost mult mai nasoala, dar si mizeria de cox strica sinusuri, neuroni, relatii si prietenii. Cu alcoolul inca mai este o vaga problema, dar am ajuns sa reduc portia de tarie de la minim 300ml pe zi, la 300ml o zi pe saptamana. Consider ca este o problema pentru ca vreau sa reduc consumul la 0. Am inceput sa meditez in 2019 si am continuat sa o fac pana in ziua de azi. Cea mai buna alegere. Am urmat cursurile lui Paul Olteanu (RECOMAND), am inceput sa citesc carti de dezvoltare personala, neurostiinta, sa urmez cursuri de bussiness si am studiat tehnici de terapie. In momentul de fata pe langa job-ul pe care il am in IT si ce mai fac eu pe langa (tot in domeniul IT), am inceput sa lucrez cu cupluri care au probleme in relatie si cu persoane care se confrunta cu atacuri de panica, PTSD si anxietate profunda. Sper ca in curand sa fac un switch major de cariera si sa ma ocup exclusiv cu terapia de cuplu, terapia persoanelor cu atacuri de panica, celor cu anxietate si a celor cu PTSD. Se pare ca skillul de a manipula oameni poate fi folosit si in scopuri bune, nu doar in scopuri rele. In caz ca va intrebati daca ma mai ocup de hacking: oarecum. La job ma folosesc de experienta pe care o am pentru a descoperi directii noi. Nu mai comit ilegalitati, dar experienta dobandita de-a lungul anilor a fost cea care mi-a asigurat un post cald intr-o companie superba pentru care lucrez de mai mult de 7 ani. Se pare ca oamenii care gandesc "outside of box" sunt o raritate vanata de recrutori. Asa ca pot spune, fara teama de a gresi cu ceva, ca toti anii in care m-am ocupat doar de hacking au meritat. Din toate punctele de vedere. Sunt bine. Cred ca mai bine decat oricand. Mintea la 40+ ani functioneaza altfel. Caut liniste si pace, imi vad de familie, job si planuri, iar asta mi-a usurat viata destul de mult. Nu va speriati de varsta asta. Este o perioada foarte frumoasa daca aveti langa voi persoane dragi si stabilitate emotionala. Cam atat momentan. Ne mai auzim peste 15 ani, daca mai exista forumul P.S.: @Nytro te pupa fratele tau si scuze ca am disparut ca magarul in ceata cu proiectul ala din pandemie. Au aparut niste probleme nasoale in viata mea la momentul respectiv. Sper sa ma revansez candva.

Majoritatea continului de pe forum a fost lame si a ramas lame, insa exista in Romania o comunitate plina de sperante ca intr-o zi fiecare dintre ei o reuseasca sa sparga NASA sau vor face milioane din hacking. Speranta si faptul ca unii din membri faceau chestii impresionate si ca unii mai dadeau lovitura erau motivele ce faceau utilizatorii sa intre pe rstforums.com si sa dea refresh in fiecare ora. Daca vreti sa reinviati forumul si sa recreati o comunitate de hackeri pasionati atunci trebuie ca cititorii/utilizatorii sa gaseasca continut fascicant care sa il faca sa invete cate una, alta. Cititorul dupa ce citeste trebuie sa zica: ba ce tare! Trebuie sa mai intru sa vad ce au mai facut aia. Nu va trebuie compuneri de 10 pagini sau tutoriale de pe net copy si paste pe care nu le citeste nici dracu. Postati anecodnote de hacking de la serviciu, povesti cu hackeri din romania prinsi, baieti saltati de bcco/diicot, povesti cu tovarasi care au facut milioane si s-au ars, despre cum functionau platformele de malware, spear phishing, cum trimiteau astia milioane de emailuri si aveau un exploit pt Windows ca sa descarce si sa instaleze un malware in calculatorul victimelor pt a obtine bank logs. Aia cu virusul Gozi au facut 10+ milioane de dolari. Cum credeti voi ca au procedat, cum credeti ca au fost saltati, cum functiona malware-ul, etc. Marea majoritate cititorilor cauta metode de a face bani si povesti cum au facut altii bani, scheme care au mers, cum au mers. Totul in secolul 21 s-a rezumat si se rezuma la bani. Daca pe forum o parte din admini spun ca e mai bine ca s-au lasat de hackareala si ca e super ca au devenit sclavi corporatisti, atunci toti care erau pasionati de hacking vor pleca. Va garantez eu ca exista o gramada de oameni ce ar citii asta si ar intra zi de zi sa vada ce s-a mai postat si sa puna intrebari. Un motiv de ce o parte buna (posibil 90%+) din utilizatori intrau pe rstcenter e ca ei erau membri si pe alte forumuri gen hackyard, r00tw0rm, securityoverride, l33ts, xhackery, hackpedia, blackhatworld, hackforums, trojanforge, etc. Astfel chiar daca continut pe rstcenter nu era wow, ei erau activi sau fascinati de ce postau pe alte comunitati. Forumurile nu au murit. Internautii tot intrau pe Breached, Raid, Dread, Antichat, XSS etc. in anii 2020

A vrut sa scrie Ursus.

Eu vorbesc de hacking, nu frauda, a nu se confunda, cred ca si Nytro tot la asta se refera.

WhatsApp for Windows lets Python, PHP scripts execute with no warning By Bill Toulas A security issue in the latest version of WhatsApp for Windows allows sending Python and PHP attachments that are executed without any warning when the recipient opens them. For the attack to be successful, Python needs to be installed, a prerequisite that may limit the targets to software developers, researchers, and power users. The problem is similar to the one affecting Telegram for Windows in April, which was initially rejected but fixed later, where attackers could bypass security warnings and perform remote code execution when sending a Python .pyzw file through the messaging client. WhatsApp blocks multiple file types considered to carry a risk to users but the company tells BleepingComputer that it does not plan to add Python scripts to the list. Further testing by BleepingComputer shows that PHP files (.php) are also not included in WhatsApp's blocklist. Python, PHP scripts not blocked Security researcher Saumyajeet Das found the vulnerability while experimenting with file types that could be attached to WhatsApp conversations to see if the application allows any of the risky ones. When sending a potentially dangerous file, such as .EXE, WhatsApp shows it and gives the recipient two options: Open or Save As. WhatsApp options for executable files source: BleepingComputer.com However, when trying to open the file, WhatsApp for Windows generates an error, leaving users only the option to save the file to disk and launch it from there. In BleepingComputer tests, this behavior was consistent with .EXE, .COM, .SCR, .BAT, and Perl file types using the WhatsApp client for Windows. Das found that WhatsApp also blocks the execution of .DLL, .HTA, and VBS. For all of them, an error occurred when trying to launch them directly from the app by clicking "Open." Executing them was possible only after saving to disk first. Launching .EXE from WhatsApp client fails source: BleepingComputer Talking to BleepingComputer, Das said that he found three file types that the WhatsApp client does not block from launching: .PYZ (Python ZIP app), .PYZW (PyInstaller program), and .EVTX (Windows event Log file). BleepingComputer's tests confirmed that WhatsApp does not block the execution of Python files and discovered that the same happens with PHP scripts. If all the resources are present, all the recipient needs to do is to click the "Open" button on the received file, and the script executes. Das reported the problem to Meta on June 3 and the company replied on July 15 saying that the issue had already been reported by another researcher and should have already been fixed. When the researcher contacted BleepingComputer, the bug was still present in the latest WhatsApp release for Windows, and we could reproduce it on Windows 11, v2.2428.10.0. "I have reported this issue to Meta through their bug bounty program, but unfortunately, they closed it as N/A. It's disappointing, as this is a straightforward flaw that could be easily mitigated," explained the researcher. BleepingComputer reached out to WhatsApp for clarification about the reason for dismissing the researcher's report, and a spokesperson explained that they didn't see it as a problem on their side, so there were no plans for a fix: "We've read what the researcher has proposed and appreciate their submission. Malware can take many different forms, including through downloadable files meant to trick a user." "It's why we warn users to never click on or open a file from somebody they don't know, regardless of how they received it — whether over WhatsApp or any other app." The company representative also explained that WhatsApp has a system in place to warn users when they're messaged by users not in their contact lists, or whom have phone numbers registered in a different country. Nevertheless, if a user's account is hijacked, the attacker can send to everyone in the contact list malicious scripts that are easier to execute straight from the messaging app. Furthermore, these types of attachments could be posted to public and private chat groups, which could be abused by threat actors to spread malicious files. Responding to WhatsApp rejecting the report, Das expressed disappointment with how the project handled the situation. "By simply adding the .pyz and .pyzw extensions to their blocklist, Meta can prevent potential exploitation through these Pythonic zip files," the researcher said. He added that by addressing the issue WhatsApp "would not only enhance the security of their users but also demonstrate their commitment to promptly resolving security concerns. BleepingComputer contacted WhatsApp to alert them that the PHP extension is also not blocked but has not received a response at this time. Sursa: https://www.bleepingcomputer.com/news/security/whatsapp-for-windows-lets-python-php-scripts-execute-with-no-warning/

July 4, 2023 API Hacking Techniques How to exploit an API using prototype pollution Introduction I read somewhere that NodeJS has now been downloaded over 1.5 BILLION times. It’s one of the most popular runtimes startups use to build their web apps and APIs. And big businesses use it too. Everyone from LinkedIn and NetFlix to NASA, Uber, and GoDaddy uses it to drive their software. So what? Why is this important? As a cross-platform JavaScript runtime environment that may be driving the APIs you are testing, understanding how to exploit it is essential. We’ve seen plenty of examples of exploiting JavaScript on the client side, but can this be done on the server side that NodeJS delivers? It ends up you can. It’s called server-side prototype pollution (SSPP). And prototype pollution can be a huge vulnerability you need to know how to detect and exploit. So let’s dive in and discuss what prototype pollution is, why it matters, and how you can weaponize it to exploit an API. What is prototype pollution? Prototype pollution is a type of attack vector in which an attacker can inject data into an object prototype. This attack occurs when the user input isn’t sanitized or filtered properly before being parsed by JavaScript. When this happens, malicious data is added to the global scope, which can be executable code that will run immediately and access privileged information. This type of attack is known as “polluting” the prototype chain, which can lead to a whole host of problems, including remote code execution (RCE). To get a more in-depth understanding, you can check out this article on MDN. Let’s look at an example of how this works. Consider this code: obj[a][b] = c; If an attacker can control a and c, then he can set the value of a to __proto__, and the property b will be defined for all existing objects of the application with the value of c. Can you think of some ways you can abuse this? I bet you can. Detecting Server Side Prototype Pollution So before I show you how to detect SSPP, I need to warn you about something. When testing client-side prototype pollution, you can easily reverse all your changes and return to a clean environment by simply refreshing the target web page. That’s more challenging when testing prototype pollution on the server side. Once you pollute a prototype on the server, this change will persist for the entire lifetime of the Node process, and you don’t have any way of resetting it. This means it can impact production workloads and can negatively impact the API you are testing. So please be aware and be careful. I will show you both some destructive and non-destructive ways to detect SSPP. Use good judgment when applying these techniques to a target. Test for polluted property reflection Look for API endpoints that reflect an object that is created or updated. You can usually find this where objects are created in a POST operation or are updated in a PUT operation. Consider this example: POST /api/user HTTP/1.1 Host: vuln-api.com ... { "user":"bob", "firstName":"Bob", "lastName":"Smith", "__proto__":{ "foo":"bar" } } If the target is vulnerable to SSPP, then you may see a new property called foo with the value of bar reflected in the response: HTTP/1.1 200 OK ... { "username":"bob", "firstName":"Bob", "lastName":"Smith", "foo":"bar" } If this works, it’s time to start looking for places in the API where this can be abused. Suppose you can start adding properties to objects through SSPP. In that case, you can significantly change the business logic code flow and behavior, leading to privileges escalation or remote code execution. Test for poisoned server configuration changes While polluting properties and looking for them in a reflected response works, it is a rather destructive methodology to active objects. And the reality is APIs don’t always reflect objects that are created or updated. This means we don’t always get to SEE that the objects have been modified in this way. There are other ways to cause prototype pollution that we can more easily monitor and detect. One such approach is to try to poison properties that match configuration options for the server and see if it alters its behavior. If it does, it strongly indicates that you’ve found a server-side prototype pollution vulnerability you can exploit. There are several techniques you can use for this. Gareth Heyes has published some excellent research on this already. We will look at a few methods that pollute how cache controls work in Express and how to override the spaces in JSON output. Testing for Cache-Control So if you read Gareth’s research, you will know that the Express developers were onto his shenanigans and started hardening their code to prevent prototype pollution abuse for crucial server configurations. But they haven’t gotten them all (yet). One of the best ways to see if you have found an entry point to poison configuration is to see if you can abuse the cache control in Express. Here is how it works. When you send a request with the “If-None-Match” header, you should expect to receive a 304 (not modified) response. However, if you found SSPP, you can attempt to pollute the Object prototype on the server by adding cache-control=”no-cache”. If it works, when you send the original request that returned a 304, you SHOULD now get a 200 back with that data and a corresponding ETag, demonstrating its vulnerable. Just remember you are affecting the caching for the entire API. If you are doing this on a production server, ensure you have approval and are in constant contact with the Ops group to schedule the testing and notify them when to revert the caching state by restarting the processes. Testing for JSON spaces override So Express offers a lot of configurable options in its server framework. One example of this is the fact you can configure how many spaces a JSON object will use to indent any data in the response. You can test this by attempting to pollute the Object prototype by adding “json spaces” and setting it to a larger number than average, like 10 or 15. If you are testing this with Burp Suite, remember to look at the Raw tab, as the Pretty tab will strip out the extra spaces as it tries to give you easy-to-read JSON output. This methodology has recently been fixed in Express 4.17.4. But for all those older Express instances out there, you can still abuse this. If you want to practice this, PortSwigger has a wicked lab for detecting server-side prototype pollution you can mess with. You can test other ways to detect SSP, like through status codes and character set output. Lots to be learned if you check out the SSPP tutorial on Web Security Academy. A simple vulnerable API in NodeJS example So I wanted to give you something to play with to see all this in action. I encourage you to jump into PortSwigger’s Web Security Academy project. But they don’t let you see the code causing these vulnerabilities. So I’ve written a purposely vulnerable API in NodeJS to walk you through this. I hinted at this when showcasing the prototype pollution for cache control earlier in this article. But I will walk you through an example and demonstrate how you can control code flow in a vulnerable API that ultimately lets you execute a dangerous sink, giving you remote code execution on the API server. DO NOT RUN THIS ON A MACHINE CONNECTED TO THE INTERNET. YOU’VE BEEN WARNED. The vulnerable API code OK, so here is the raw code for our vulnerable API: A vulnerable NodeJS/Express API - app.js 'use strict'; const express = require('express'); const bodyParser = require('body-parser') // App const app = express(); app.use(bodyParser.json()) const config = { //allowEval: false } global.users = { "admin": {firstName: "The", lastName: "Admin"}, "bob": {firstName: "Bob", lastName: "Smith"}, } var findUserByUsername = function (username, callback) { if (!users[username]) return callback(new Error( 'No user matching ' + username ) ); return callback(null, users[username]); } function addUser( user ) { Object.assign(users, user); } function updateUser(username, prop, value){ users[username][prop] = value; } app.get("/api/users", (req, res) => { return res.status(200).send(users); }); app.get("/api/users/:username", (req, res) => { var username = req.params.username; findUserByUsername(username, function(error, user) { if (error) return res.status(404).send('User not found'); return res.status(200).send(user); }); }); app.post("/api/users", (req, res) => { var user = JSON.parse(JSON.stringify(req.body)); addUser(user); return res.status(200).send(user); }); app.put("/api/users/:username", (req, res) => { var username = req.params.username; var user = JSON.parse(JSON.stringify(req.body)); for(var attr in user){ updateUser(username, attr, user[attr]); } findUserByUsername(username, function(error, user) { if (error) return res.status(404).send('User not found'); return res.status(200).send(user); }); }) app.post("/api/eval", (req, res) => { var body = JSON.parse(JSON.stringify(req.body)); if (!config.allowEval){ console.log('allowEval not set!'); return res.status(403).send(); } console.log("allowEval IS set. RCE on its way..."); eval(body.code) return res.status(200).send(); }); app.listen(3000, '0.0.0.0'); console.log("Vulnerable API running..."); The things I want you to zoom into are the following: There is a dangerous sink in the POST endpoint for /api/eval (around line 69). It is protected by a simple variable in the config object called allowEval. It’s not set by default, which means this endpoint will never successfully run the dangerous eval() operation. We want to abuse the server and find a way to get here. The PUT endpoint for /api/users is vulnerable to server-side prototype pollution, following the pattern we discussed earlier where obj[a][b] = c, which we can see in the updateUser() function on line 34. OK, so with that outlined, let’s go about exploiting this API and get it to run our own malicious code to send us a remote shell from the API server. Exploring the API So if we examine the code closely, we can see that when updating a user Express will iterate over each property sent to the endpoint and update the object based on the username. If we wanted to update the “admin” user, we could send a payload that looks something like this: PUT /api/user/admin HTTP/1.1 Host: vuln-api.com ... { "firstName":"Bob", "lastName":"The Builder" } So on the first iteration, we would see an update look something like this: users["admin"]["firstName"] = "Bob"; You can see where this is going. This is a classic prototype pollution construct. We control the username, the property, and the value. So let’s leverage this to change the code flow of the API and get us to our dangerous sink. Exploiting the API So let’s first check to see if the /api/eval endpoint is indeed protected from our use: Sure enough, we get a 403, as expected. But look closely at the code for the endpoint. It’s simply checking the config object to see if allowEval is present. It’s not even checking if it’s true or false… it’s just checking if it’s there. Knowing we have a potential SSPP vulnerability in the PUT method for /api/users, let’s see if we can abuse that. Remember when I said this?: If an attacker can control a and c, then he can set the value of a to __proto__, and the property b will be defined for all existing objects of the application with the value of c. So, to cause prototype pollution on the server, we need to reconstruct that as: users["__proto__"]["allowEval"] = true; And that is pretty easy here. We need to change the endpoint URL path and include a JSON payload with that property. It looks something like this in Burp: Alright. Everything is staged. We can now execute the dangerous sink and run code on the API server. Let me first start a netcat listener so I can catch a reverse shell: netcat -lvp 4242 And now, with the allowEval variable polluted in the config object, we can change the code flow and run our malicious code on the /api/eval endpoint. In this case, I will get NodeJS to load a child process and exec a reverse shell: Back on your netcat listener, you should have a shell on the API server: Pwnage via prototype pollution. How sweet it is. Conclusion Now that you know what server-side prototype pollution is and how to exploit it, you should be aware of this vulnerability class in the wild. It can be challenging to detect, as it relies on the code flow of a server framework running JavaScript to achieve its malicious goals. But with enough practice and exploration into different endpoints and payloads, anything is possible. If you find an API running NodeJS during your recon, it’s worth exploring this. If you aren’t sure how to tell if an API is running NodeJS, check out my article on detecting an API’s programming language. So the next time you audit or pentest an API, make sure to look for prototype pollution potentials and see if you can manipulate code flow in your favor! Have fun. Like what you’re reading? Then join the API Hacker Inner Circle. It’s a FREE weekly newsletter designed for developers, testers, and hackers that keeps you up to date with the community and my work. Hope to see you there! Sursa: https://danaepp.com/how-to-exploit-an-api-using-prototype-pollution

Legenda criminalitatii cibernetice, IMEI-u nu e ciclu la femei.

Exista, doar ca nu ca si o comunitate din ro, conceptul asta s-a cam dus pe la noi, cum a spus cineva mai sus, marea majoritate o ard prin corporatii, bounty, sau pe alte forumuri.