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

We have found two use-after-free vulnerabilities in PHP’s rubbish 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 go out to cutz for co-authoring this text. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why we now have taken the perspective of a complicated attacker with the total intent to get as deep as doable into the system, focusing on one most important 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 usage of unserialize on the web site. In all circumstances a parameter named "cookie" bought unserialized from Post information and afterwards mirrored via Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that involve abusing already present courses with specifically outlined "magic methods" in an effort to trigger unwanted and porn malicious code paths.

Unfortunately, it was tough for us to assemble any information about Pornhub’s used frameworks and PHP objects on the whole. Multiple classes from common frameworks have been tested - all with out success. The core unserializer alone is comparatively advanced because it involves greater than 1200 traces of code in PHP 5.6. Further, many inner PHP classes have their very own unserialize methods. By supporting constructions like objects, arrays, integers, strings or even references it is not any surprise that PHP’s observe report reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no recognized vulnerabilities of such kind for newer PHP versions like PHP 5.6 or PHP 7, particularly as a result of unserialize already acquired quite a lot of consideration in the past (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many safety fixes its vulnerability potential should have been drained out and it needs to be secure, shouldn’t it? To find a solution Dario applied a fuzzer crafted particularly for fuzzing serialized strings which had been passed to unserialize.

Running the fuzzer with PHP 7 instantly lead to unexpected conduct. This habits was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 version. However, working the fuzzer against a newer model of PHP 5 just generated more than 1 TB of logs without any success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected habits once more. Several questions had to be answered: is the problem security associated? In that case can we only exploit it locally or also remotely? To further complicate this situation the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An incredible amount of time was obligatory to investigate potential issues. In spite of everything, we might extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the root trigger may very well be present in PHP’s garbage collection algorithm, a component of PHP that is completely unrelated to unserialize.

However, the interaction of both components occurred only after unserialize had finished its job. Consequently, it was not effectively suited for remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and a lot of arduous work an analogous use-after-free vulnerability was found that appeared 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 possibly can 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 troublesome to use. Specifically, it involved a number of exploitation phases. 1. The stack and heap (which additionally embody any potential person-input) in addition to some other writable segments are flagged non-executable (c.f. 2. Even if you are able to manage the instruction pointer you have to know what you need to execute i.e. you want to have a sound tackle of an executable memory section.