Leaderboard

Intrebarea aceasta mi-a fost adresata de multa lume, chestia este ca eu nici macar nu stiam despre spitale, am aflat-o abia dupa ce am ajuns la DIICOT (eu fiind deja retras de vreo 2 luni din gruparea respectiva din cauza lipsei de timp), ulterior am vazut si dovezile si intr-adevar baietii ramasi acolo planuiau sa blocheze sistemele informatice ale spitalelor din motive inexplicabile pentru mine, sunt multe chestii si decizii luate de ei in absenta mea pe care nu le am inteles iar aceasta ar fi unul dintre ele. Dupa ce am fost prins in Moldova, am mers la Procuratura pentru Combaterea Criminalității Organizate și Cauze Speciale din Chisinau, am stat acolo ceva timp, dupa care peste ceva luni am fost la DIICOT in Bucuresti, a fost o procedura lunga, plina de stres si emotii nasoale care au durat cam un an. Intr-un final am reusit sa scap cu niste lucru in folosul comunitatii din singurul motiv (cred eu) ca procurorii de la DIICOT au fost de treaba cu mine si pentru ca eram minor (mai aveam o luna pana la 18 ani). O experienta nasoala la acel moment insa extrem de buna pentru timpurile de acum / cele care vin, am capatat o gramada de oportunitati de lucru si am reusit sa mi schimb total mentalitatea in legatura cu `distrugerea` si facutul chestiilor ilegale, le poti face daca esti pasionat insa totul poate fi legal, fara vreun risc care ti-ar putea distruge viitorul. O lectie foarte importanta pentru mine pe care am invatat-o `the hard way` 😁.

Salut, sunt baiatul din Republica Moldova si o sa va raspund la cateva intrebari pe care le-ati avut la momentul dat. 1. Nu eu eram analfabetul(sunt din Brasov dar stau in RM) 2. Nu aveam vreun scop de a luat bani etc, eram doar niste copii prosti ce n-aveau ce face cu timpul lor si am platit destul pentru asta. 3. Nu am fost niciodata de acord cu mesajul insa unul din baieti a insistat pe subiect, puteti observa ca tot el e cel ce a scris tot pe deface. 4. Am fost prins deoarece unul dintre baieti (cel ce scria pe deface-uri) vorbea mereu in public si se lauda cu chestiile facute, de la el a dat politia de mine pentru ca avea numarul meu de telefon (eu prost) Deci da, cel putin eu eram un copil prost care nu avea ce face, fara intentii rele (credeam eu). Sper ca v-am lamurit in cazul in care INCA era curios cineva care a fost faza. Stay legal!

How an Akamai misconfiguration earned us USD 46.000 FRANCESCO MARIANI SEPTEMBER 17, 2022 A few months ago me and my friend Jacopo Tediosi made an interesting discovery about an Akamai misconfiguration that allowed us to earn more than 46,000 dollars. Our research highlighted how manipulating a particular HTTP header made it possible to change the way how proxies communicated with each other and how this allowed us to perform different request smuggling attacks or, in particular cases, allowed us to poison the cache with arbitrary content chosen by us. In this post we will go directly into detail without explaining how these vulnerabilities work in general, hoping that the reader knows what we are talking about. If not, there are so many resources online and even labs to practice with them. Now the question is: how were we able to reveal the misconfiguration? and how was it actually handled by major bug bounty platforms and private companies? Even today you can encounter this header in the response in several Server under the Akamai network. Probably many of you have already understood or had already tried to force the use of Content-Length instead of Transfer-Encoding. But let’s go one step at a time. Once we noticed this particular thing, any attempt to abuse the Connection header with Content-Length as a value to perform a Request Smuggling attack didn’t work. One curious thing we noticed was some unusual responses being provided by Akamai, such as [no URL]. Or, with www.example.com: if we use the same host, the server actually provided different responses, but as many will know it is difficult to determine if it was actually Request Smuggling, HTTP Pipelining, or a normal server behavior by setting the Connection header in keep-alive. Trying to redirect the requests with my co-worker we actually found that it worked. But currently, we only had one potential Denial of Service which is often rejected for lack of impact. Once this was done, we did some tests from a different network to verify that it was an open desync. Only later we discovered that by inserting other host within the Akamai network we were completely able to redirect each other and finally we had a complete request smuggling. This sounds good, but we had a problem. We don’t have a host within Akamai network. How can you prove that through the attack you can arbitrarily redirect users if you don’t have any logs to show? As we continued to try, and luckily for us, we were able to abuse this bug to arbitrarily cache content from other hosts. We also found that, in addition to the GET method, we could use the OPTIONS method to perform the desired attack, moreover, there were more chances that Akamai would not notice that the request was actually malicious. To poison the cache, it was necessary to send a first GET or OPTIONS request to a nonexistent path (also to avoid damage to the platform), preferably with static resource extensions (more likely to be taken from the cache), with the second request to arbitrary hosts. After a couple of requests, the content of the second host’s file was correctly cached due to its revalidation, like this: From then on it was possible to visit the URL /it/it/medusa.txt which returned the robots.txt of the second host. Obviously, the content we decided to cache was not malicious but we could cache many types of files such as html or js. Finally, we had a nice impact for the report. POC: OPTIONS /random.txt HTTP/1.1 Host: ORIGINAL-HOST Connection: Content-Length Content-Length: 42 GET /robots.txt HTTP/1.1 Host: ARBITRARY-AKAMAI-HOST x: 1 by sending the request twice it was possible to cache the contents of robots.txt of the second host. As soon as the discovery was made, we started responsible disclosure, reporting the vulnerability to Akamai. We have not received immediate confirmation from them. While we waited, we realized that not all Akamai hosts were vulnerable or some did not allow arbitrary content caching (they probably had no cache or particular cache key settings that did not allow the attack). We thought maybe it was some general misconfiguration and decided to report it in bug bounty platforms as well. Vulnerability management by bug bounty platforms: Our sincere admiration for the triagers of the Hackerone platform. After a very short time, they were able to replicate and understand the vulnerability by assigning the right severity. Unfortunately, in Bugcrowd many of the triagers were unable to replicate the vulnerability despite providing a oneliner with curls, video POC, screenshots, and more. Some just didn’t put the two blank lines in GET requests, others had wrong burp targets and we have also received duplicated (?). like: We were very disappointed with the Bugcrowd triagers. Microsoft: Microsoft replied very late, saying it was unable to replicate the vulnerability (Akamai had already introduced the security fix). Apple: Apple responded late, and was unable to replicate the vulnerability due to Akamai’s fix. They were very kind and we received thanks by email, but no bounty was paid (we didn’t want any). Intigriti: We only filed a bug, the triager was very nice and friendly, but he gave us a duplicated. THE FIX: Akamai took very little time to get the security fix after our report, now any attempt to use the Connection header in an inappropriate way is automatically blocked. Akamai has given us permission to make a public disclosure. Sursa: https://blog.hacktivesecurity.com/index.php/2022/09/17/http/

https://adevarul.ro/stiri-interne/evenimente/inchisoare-pe-viata-pentru-luptatorul-k1-care-a-2209265.html?

.