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

We have now discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We had been additionally awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks exit to cutz for co-authoring this article. Pornhub’s bug bounty program and its comparatively high rewards on Hackerone caught our consideration. That’s why we now have taken the attitude of a complicated attacker with the complete intent to get as deep as potential into the system, specializing in one important purpose: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we rapidly detected the utilization of unserialize on the website. In all circumstances a parameter named "cookie" got unserialized from Post knowledge and afterwards reflected via Set-Cookie headers. Standard exploitation methods require so called Property-Oriented-Programming (POP) that involve abusing already current classes with particularly defined "magic methods" with a view to trigger undesirable and malicious code paths.

Unfortunately, it was troublesome for us to gather any details about Pornhub’s used frameworks and PHP objects normally. Multiple lessons from widespread frameworks have been examined - all with out success. The core unserializer alone is comparatively advanced because it entails more than 1200 traces of code in PHP 5.6. Further, many inner PHP lessons have their very own unserialize methods. By supporting buildings like objects, arrays, integers, strings and even references it is not any shock that PHP’s track file reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already got a number of attention previously (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after a lot consideration and so many safety fixes its vulnerability potential ought to have been drained out and it must be secure, shouldn’t it? To find an answer Dario carried out a fuzzer crafted particularly for fuzzing serialized strings which were handed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This conduct was not reproducible when examined in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 version. However, running the fuzzer towards a newer version of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions had to be answered: is the problem security related? If so can we only exploit it locally or also remotely? To additional complicate this situation the fuzzer did generate non-printable information blobs with sizes of greater than 200 KB. An incredible period of time was crucial to investigate potential points. In any case, we might extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon additional investigation we found that the foundation cause could possibly be found in PHP’s garbage assortment algorithm, a part of PHP that is completely unrelated to unserialize.

However, the interaction of each elements occurred solely after unserialize had finished its job. Consequently, it was not effectively suited for xhamster distant exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and quite a lot of laborious work a similar use-after-free vulnerability was found that seemed to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it mandatory to write separate articles. You possibly can read more particulars in Dario’s fuzzing unserialize write-up. In addition, we have now written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly troublesome to use. Specifically, it concerned a number of exploitation stages. 1. The stack and heap (which additionally include any potential consumer-enter) in addition to every other writable segments are flagged non-executable (c.f. 2. Even if you're in a position to regulate the instruction pointer you have to know what you wish to execute i.e. it's essential to have a legitimate deal with of an executable reminiscence segment.