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

We have now discovered two use-after-free vulnerabilities in PHP’s rubbish collection algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We were 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 relatively excessive rewards on Hackerone caught our consideration. That’s why now we have taken the attitude of a sophisticated attacker with the complete intent to get as deep as attainable into the system, focusing on one predominant purpose: gaining distant 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 cases a parameter named "cookie" obtained unserialized from Post data and afterwards mirrored by way of Set-Cookie headers. Standard exploitation techniques require so known as Property-Oriented-Programming (POP) that involve abusing already current lessons with specifically defined "magic methods" with the intention to set off unwanted and malicious code paths.

Unfortunately, porn it was tough for us to assemble any information about Pornhub’s used frameworks and PHP objects typically. Multiple courses from common frameworks have been tested - all without success. The core unserializer alone is comparatively complex because it entails greater than 1200 strains of code in PHP 5.6. Further, many internal PHP lessons have their very own unserialize strategies. By supporting structures like objects, arrays, integers, strings and even references it is no shock that PHP’s monitor document reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already acquired 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 so much attention and so many safety fixes its vulnerability potential should have been drained out and it should be secure, shouldn’t it? To find a solution Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which have been passed to unserialize.

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This behavior was not reproducible when examined towards Pornhub’s server though. Thus, we assumed a PHP 5 model. However, running the fuzzer against a newer version of PHP 5 just generated more than 1 TB of logs with none success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected habits once more. Several questions needed to be answered: is the issue security associated? If that's the case can we only exploit it locally or also remotely? To further complicate this example the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. A tremendous amount of time was necessary to investigate potential issues. In spite of everything, we may 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 foundation trigger might be present in PHP’s garbage assortment algorithm, a component of PHP that is completely unrelated to unserialize.

However, the interplay of each parts occurred solely after unserialize had completed its job. Consequently, it was not effectively fitted to remote exploitation. After additional evaluation, 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 gave the impression to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and their discovery made it obligatory to write down separate articles. You'll be able to read more 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 significantly difficult to exploit. Specifically, it concerned a number of exploitation levels. 1. The stack and heap (which also include any potential user-enter) in addition to another writable segments are flagged non-executable (c.f. 2. Even in case you are in a position to regulate the instruction pointer you might want to know what you wish to execute i.e. it's worthwhile to have a sound deal with of an executable memory phase.