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

We've found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize perform. 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 have now taken the angle of a complicated attacker with the full intent to get as deep as potential into the system, focusing on one main purpose: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we quickly detected the usage of unserialize on the web site. In all instances a parameter named "cookie" acquired unserialized from Post information and afterwards mirrored 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" in order to trigger unwanted and malicious code paths.

Unfortunately, it was difficult for us to assemble any information about Pornhub’s used frameworks and PHP objects in general. Multiple classes from widespread frameworks have been examined - all with out success. The core unserializer alone is comparatively advanced as it involves more than 1200 lines of code in PHP 5.6. Further, many internal PHP lessons have their own unserialize methods. By supporting structures like objects, arrays, integers, strings and even references it is no shock that PHP’s monitor file reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, particularly as a result of unserialize already got a number of consideration previously (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many safety fixes its vulnerability potential ought to have been drained out and it needs to be secure, shouldn’t it? To find a solution Dario carried out a fuzzer crafted specifically for fuzzing serialized strings which have been handed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected behavior. This behavior was not reproducible when examined in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer in opposition to a newer model of PHP 5 just generated greater than 1 TB of logs with none success. Eventually, after putting increasingly effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions had to be answered: is the difficulty security associated? If that's the case can we solely exploit it locally or also remotely? To additional complicate this situation the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. A tremendous amount of time was necessary to research potential issues. In spite of everything, we might extract a concise proof of idea of a working memory corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we discovered that the root cause may very well be present in PHP’s garbage assortment algorithm, a element of PHP that is totally unrelated to unserialize.

However, the interaction of each elements occurred solely after unserialize had completed its job. Consequently, it was not effectively fitted to distant exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and plenty of onerous work an identical use-after-free vulnerability was discovered that gave the impression to be promising for distant exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it obligatory to write separate articles. You possibly can read extra particulars in Dario’s fuzzing unserialize write-up. As well as, we've got written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to use. In particular, it involved multiple exploitation phases. 1. The stack and heap (which also embody any potential person-enter) in addition to some other writable segments are flagged non-executable (c.f. 2. Even if you are in a position to regulate the instruction pointer it's essential know what you wish to execute i.e. you might want to have a valid tackle of an executable reminiscence section.