How we Broke PHP, Hacked Pornhub and Earned $20,000 > 자유게시판

We have discovered two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. We had been additionally awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for co-authoring this text. Pornhub’s bug bounty program and its relatively excessive rewards on Hackerone caught our consideration. That’s why we have taken the angle of a sophisticated attacker with the full intent to get as deep as potential into the system, xnxx focusing on one most important objective: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we quickly detected the usage of unserialize on the web site. In all instances a parameter named "cookie" obtained unserialized from Post information and afterwards reflected via Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that involve abusing already existing courses with specifically outlined "magic methods" with the intention to set off undesirable and malicious code paths.



Unfortunately, it was difficult for us to gather any information about Pornhub’s used frameworks and PHP objects on the whole. Multiple courses from common frameworks have been examined - all without success. The core unserializer alone is relatively complex as it entails more than 1200 strains of code in PHP 5.6. Further, many internal PHP lessons have their very own unserialize methods. By supporting buildings like objects, arrays, integers, strings and even references it isn't any surprise that PHP’s observe report reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already bought a lot of consideration in the past (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many safety fixes its vulnerability potential ought to have been drained out and it needs to be safe, shouldn’t it? To seek out a solution Dario implemented a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.



Running the fuzzer with PHP 7 immediately lead to unexpected habits. This behavior was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 model. However, running the fuzzer in opposition to a newer model of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after putting increasingly more effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions needed to be answered: is the issue safety related? In that case can we solely exploit it locally or also remotely? To additional complicate this example the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. An incredible period of time was crucial to research potential issues. In any case, we could extract a concise proof of idea of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the basis trigger could be present in PHP’s rubbish collection algorithm, a component of PHP that is completely unrelated to unserialize.



However, the interplay of each parts occurred solely after unserialize had finished its job. Consequently, it was not well fitted to distant exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and a number of hard work the same use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it obligatory to write down separate articles. You possibly can learn more details in Dario’s fuzzing unserialize write-up. As well as, we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably tough to take advantage of. Particularly, it involved multiple exploitation phases. 1. The stack and heap (which additionally embody any potential person-input) as well as every other writable segments are flagged non-executable (c.f. 2. Even if you are ready to regulate the instruction pointer you could know what you want to execute i.e. it's essential to have a sound tackle of an executable memory section.