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 have been remotely exploitable over PHP’s unserialize function. We were also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for co-authoring this article. Pornhub’s bug bounty program and its comparatively excessive rewards on Hackerone caught our attention. That’s why we've got taken the attitude of a sophisticated attacker with the complete intent to get as deep as potential into the system, focusing on one foremost aim: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we shortly detected the utilization of unserialize on the web site. In all instances a parameter named "cookie" obtained unserialized from Post knowledge and afterwards reflected through Set-Cookie headers. Standard exploitation strategies require so called Property-Oriented-Programming (POP) that involve abusing already present lessons with specifically outlined "magic methods" with a view to trigger unwanted and malicious code paths.

Unfortunately, it was difficult for us to assemble any details about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from common frameworks have been tested - all without success. The core unserializer alone is relatively complex because it entails greater than 1200 lines of code in PHP 5.6. Further, many inside PHP lessons have their own unserialize methods. By supporting buildings like objects, arrays, integers, strings and even references it is not any shock that PHP’s observe document shows a tendency for porn bugs and reminiscence corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already got a whole lot of attention prior to now (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many security fixes its vulnerability potential should have been drained out and it needs to be safe, shouldn’t it? To seek out a solution Dario applied a fuzzer crafted particularly for fuzzing serialized strings which had been handed to unserialize.

Running the fuzzer with PHP 7 instantly result in unexpected behavior. This conduct was not reproducible when tested in opposition to Pornhub’s server though. Thus, we assumed a PHP 5 model. However, running the fuzzer in opposition to a newer model of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after placing increasingly effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions had to be answered: is the issue security associated? If that's the case can we solely exploit it domestically or additionally remotely? To further complicate this situation the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. An incredible amount of time was vital to analyze potential points. In spite of everything, we might extract a concise proof of idea of a working reminiscence corruption bug - a so called use-after-free vulnerability! Upon additional investigation we discovered that the basis trigger could possibly be found in PHP’s garbage collection algorithm, a component of PHP that is totally unrelated to unserialize.

However, the interplay of each parts occurred only after unserialize had finished its job. Consequently, it was not well suited for remote exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and plenty of exhausting work an identical use-after-free vulnerability was found that seemed to be promising for distant exploitation. The excessive sophistication of the found PHP bugs and their discovery made it obligatory to jot down separate articles. You possibly can learn more particulars in Dario’s fuzzing unserialize write-up. As well as, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to exploit. Specifically, it involved multiple exploitation stages. 1. The stack and heap (which also embody any potential person-enter) in addition to another writable segments are flagged non-executable (c.f. 2. Even if you are ready to control the instruction pointer you could know what you want to execute i.e. you'll want to have a sound deal with of an executable reminiscence phase.