Nytro

Dar tu cum ai fost pacalit sa iti faci cont aici?

A vrut sa scrie Ursus.

Nu prea exista o "generatie noua"

PKfail The Binarly REsearch team discovered a key leak incident from American Megatrends stemming back to 2018. PKfail involves multiple devices and product lines and enables attackers to gain secure boot access similar to BlackLotus. Check for PKfail Now Read report Check for PKfail PKfail: Untrusted Platform Keys Undermine Secure Boot on UEFI Ecosystem ‍ July 25, 2024 The Binarly REsearch Team The Binarly REsearch team today discloses a key leak incident from American Megatrends stemming back to 2018. PKfail involves multiple devices and product lines and enables attackers to gain secure boot access similar to BlackLotus. July 24, 2024 [BRLY-2024-005] Usage of default test keys leads to complete Secure Boot bypass The Binarly REsearch Team has found that hundreds of devices use an insecure Platform Key (PK) which represents the root of trust for UEFI Secure Boot. Affected Devices Sursa: https://www.binarly.io/pkfail

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

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/

Am inteles nivelul tau. Succes in ceea ce faci, o sa ai nevoie.

Vrei sa zici IMSI?

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

Sa ma bata mama, nici drogurile nu mai sunt ce au fost, nu mai bagati toate mizeriile.

Search: https://bf.based.re/

Serverul se zbate sub usage, m-au sunat de la OVH ca e DDOS 8696 www-data 20 0 343584 80060 55552 S 3.7 0.2 3:52.19 apache2 19910 mysql 20 0 4759768 1.1g 10920 S 3.0 3.7 96899:03 mysqld

The entire database for the notorious #BreachForums v1 #hacking #forum was released on #Telegram Tuesday night, exposing a treasure trove of data, including members' information, private messages, cryptocurrency addresses, and every post on the forum. Tweet: https://x.com/sky31337/status/1816105295396880658

O zi productiva pentru forum, una cu multe conturi noi inregistrate

I missed this shit ❤️

Opera rullez! Glumesc, foloseam cand eram mic pe telefon, se chema mini opera. A, si cand descarcam torrrente cu el ❤️

Nu vreau sa te sperii, dar sunt camere pe elicoptere cu care se pot da amenzi pentru trafic (am vazut asta pe un forum underground de hackeri: Digi24 ii zice). Dar nu inteleg de ce iti e frica, banuiesc ca la Urus ai numere de inmatriculare false. Si ca nu arunci cojile de seminte pe geam. Lasand caterinca la o parte, am cunoscut multi participanti la RoCSC si sunt in top in Romania in materie de technical skills. De hacking. Nu de scamatorii gen alba-neagra.

Cel putin noi nu stam zi de zi cu grija ca ne salta cineva. Ca sa nu mai zic de aplicatia Lidl, e top!

Unii baieti plecati de acolo au ajuns sa castige bani foarte frumosi. Legal. Conteaza asta, cat timp oricum legile nu se respecta?

Saptamana aceasta se desfasoara bootcamp-ul de pregatire si de desemnare al echipei Romaniei pentru participarea la ECSC: https://ecsc.eu/ Pe scurt, pentru cei care nu stiu despre ce e vorba: tineri cu varsta de pana la 25 de ani participa la concursuri de tip CTF in tara si la final se desemneaza o echipa a tarii care o v reprezenta la etapa finala: ECSC, un concurs pe tari la "security". E un fel de campionat european la fotbal, doar ca pe "security". Pentru cei cu varsta de pana in 25 de ani, dar nu numai, va recomand sa aruncati un ochi. E frumos sa fii un "Hagi" al Romaniei si sa reprezinti tara. Detalii: https://www.rocsc.ro/

Join the largest cybersecurity conference from CEE November 28th-29th Palace of the Parliament | Bucharest, Romania https://def.camp/

Pe vremea cand eram activi eram tineri si fara responsabilitati. Azi avem job-uri, familii si alte griji. Asteptarile noastre sunt de la cei tineri, sa se faca remarcati. Normal, nu sa se faca remarcati ca fiind arstati ci prezentand la o conferinta precum Defcon sau Blackhat, sau cel putin la Defcamp, la noi acasa. E interesanta povestea, ti-am zis punctul meu de vedere, ceea ce face acel prieten al tau e business si nu are nicio legatura cu hacking-ul. Are legatura cu anumite infractiuni care se fac cu acele cartele, da, dar nu e nimic "hacking" acolo. In schimb povestea e interesanta si se pot invata lucruri din ea: iei ceva ieftin, faci ceva cu el, vinzi mai scump = profit. Un fel de dropshipping. Referitor la forum, nu ne dorim sa atragem astfel de persoane. Sau sa le indrumam sa faca astfel de mizerii. Poate sunt cativa care au scapat, dar multi au ajuns prin puscarii. Poate nu stau toata viata in puscarii, dar nu cred ca merita nici macar un an de puscarie pentru niste bani. Cu cateva mii de euro salariu la o multinationala poti fi foarte fericit. Hacking pentru mine inseamna ceva cu totul diferit, si fata de ce intelegi tu, si fata de ce inteleg multi altii. Pentru mine "hacking" se refera la partea de "research". Sa descoperi ceva nou. Sa aduci ceva in lumea asta de care sa poata profita toata lumea. Sau care sa fie doar fun. Exemplu: Nu totul se rezuma la bani. Daca ar fi aici doar oameni ca tine, ca doar asteapta ceva la schimb, informatii sau tool-uri pe care sa le poata folosi (ceea ce noi numeam "leecheri") forumul ar fi pustiu. Oamenii pe care ii mentionezi tu nu au nimic de oferit. Ei vor doar sa faca bani, poate chiar sa profite de membrii forumului pentru asta. Asadar, noi asteptam in continuare aici oameni dornici sa invete ceva dar si sa contribuie. Acel "offer something back to the community", lucru demult uitat...

Suna mai mult a business decat a hackereala. Da, de acord, acele servicii sunt folosite pentru cine stie ce lucruri, dar la baza astea sunt niste afaceri. Nu e tocmai "furt", sau ceva care sa fie descris din start drept ilegal. Dar cred ca si in aceste cazuri e ca la startup-uri: foarte putini au succes. Multi incearca, dar putini reusesc. Existau si in trecut metode sa te poti ascunde, dar cunstiintele tuturor erau limitate. Era vremea la care se descopereau lucruri. In prezent exista multa informatie disponibila, dar, inca o data - ca si in business, ai nevoie de O IDEE ca sa faci bani. Asta poate functiona si legal. Normal, nu incurajez pe nimeni sa faca ceva ilegal, indiferent ce inseamna asta. Din punctul meu de vedere in ziua de azi o poti duce foarte bine pe calea legala. Nu cred ca "ai nevoie" de milioane de dolari ca sa o duci bine. Dar daca chiar ai nevoie si esti destept, o poti face si legal.

Din cate am vazut eu nu prea bubuie. Adica se fac aceleasi mizerii care se faceau acum X ani. Furt de carduri din diverse surse, instalat ransomware si cerut bani sau tot felul de alte porcarii. Mie mi se pare ca "lumea" intelege mai bine lucrurile astea si nu se mai arunca toti cu "Da bro, iti trimit avans 5000 de USD pentru Lamborghini ala de zici ca mi-l vinzi cu 25000", cum se facea in tineretea mea, fiind din Valcea. Eu nu mai urmaresc nimic, doar ce apare public, nu mai stiu de alte forumuri sau de grupuri, vad ce apare in presa. Si nu vad nimic impresionant. Bine, exista si cazurile speciale, cu baetii care descopera 0days si le vand pe bani frumosi. Acestia sunt hackeri. Nu cei care le folosesc. Tot pe vremea mea li se zicea script kiddies, tocmai pentru ca nu posedau cine stie ce cunostiinte tehnice. @sefu9581 - Sa inteleg ca ai facut milioane? Din partea mea, felicitari celor care se descurca, cat timp: 1. Nu fac lucruri nasoale, in sensul ia banii corporatiilor, dar nu ai oamenilor de rand. Si lucruri care sa afecteze vietile oamenilor simple (gen ransomware la spitale...) 2. Nu dau in romanii nostri, care oricum in general sunt mai amarati Problema pe partea asta blackhat, indiferent de cum o vede lumea, e partea de "liniste". Din moment ce Escobar a fost prins, ma astept sa poata fi prins oricine. Indiferent de ce metode foloseste. Eu sunt genul care prefera linistea in locul unor sume mai mari de bani, si nici nu pot sa ma plang de lipsa banilor, desi nu sunt ei milioane.

Genial! Toate datele sunt aflate pe baza multiplelor incercari? Daca o persoana nu reactioneaza in vreun fel (e.g. comment-uri), sunt sanse sa i se blocheze contul pe baza postarilor existente? Nu se ia in considerare faptul ca niste useri trimite sute de reporturi?