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

We have now found two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize function. We have 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 comparatively excessive rewards on Hackerone caught our attention. That’s why we now have taken the perspective of a sophisticated attacker with the complete intent to get as deep as attainable into the system, focusing on one principal purpose: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we shortly detected the utilization of unserialize on the website. In all instances a parameter named "cookie" acquired unserialized from Post data and afterwards reflected by way of Set-Cookie headers. Standard exploitation strategies require so referred to as Property-Oriented-Programming (POP) that involve abusing already present lessons with specifically defined "magic methods" so as to set off unwanted and malicious code paths.

Unfortunately, porn it was difficult for us to collect any details about Pornhub’s used frameworks and PHP objects on the whole. Multiple lessons from frequent frameworks have been tested - all without success. The core unserializer alone is comparatively complex because it includes greater than 1200 strains of code in PHP 5.6. Further, many inner PHP classes have their own unserialize methods. By supporting constructions like objects, arrays, integers, strings and even references it is not any surprise that PHP’s track report reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such kind for newer PHP versions like PHP 5.6 or PHP 7, particularly as a result of unserialize already obtained quite a lot of consideration prior to now (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many safety fixes its vulnerability potential should have been drained out and it ought to be safe, shouldn’t it? To search out an answer Dario applied a fuzzer crafted specifically for fuzzing serialized strings which were passed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected behavior. This habits was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer in opposition to a newer model of PHP 5 simply generated greater than 1 TB of logs with none success. Eventually, after placing increasingly effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the issue security associated? If that's the case can we solely exploit it locally or also remotely? To additional complicate this example the fuzzer did generate non-printable information blobs with sizes of greater than 200 KB. An incredible amount of time was needed to research potential issues. In spite of everything, we could extract a concise proof of idea of a working memory corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we found that the root trigger could possibly be found in PHP’s garbage assortment algorithm, a element of PHP that is completely unrelated to unserialize.

However, the interplay of both elements occurred solely after unserialize had completed its job. Consequently, it was not well suited for distant exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and plenty of exhausting work a similar use-after-free vulnerability was found that seemed to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and their discovery made it mandatory to jot down separate articles. You'll be able to read extra details in Dario’s fuzzing unserialize write-up. As well as, we've written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to take advantage of. Specifically, it concerned a number of exploitation phases. 1. The stack and heap (which also embody any potential user-input) in addition to every other writable segments are flagged non-executable (c.f. 2. Even if you are in a position to regulate the instruction pointer you'll want to know what you want to execute i.e. you'll want to have a sound deal with of an executable memory section.