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

We have now discovered two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize perform. We had been also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for xhamster co-authoring this article. Pornhub’s bug bounty program and its comparatively high rewards on Hackerone caught our consideration. That’s why we have now taken the angle of an advanced attacker with the complete intent to get as deep as possible into the system, specializing in one important purpose: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we shortly detected the utilization of unserialize on the website. In all instances a parameter named "cookie" got unserialized from Post information and afterwards reflected through Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that contain abusing already present classes with specifically defined "magic methods" with a view to set off undesirable and malicious code paths.

Unfortunately, it was tough for us to collect any information about Pornhub’s used frameworks and PHP objects generally. Multiple classes from widespread frameworks have been tested - all without success. The core unserializer alone is comparatively advanced as it includes more than 1200 strains of code in PHP 5.6. Further, many internal PHP lessons have their very own unserialize methods. By supporting buildings like objects, arrays, integers, strings and even references it is no surprise that PHP’s monitor report shows a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no known vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, especially because unserialize already got plenty of consideration up to now (e.g. phpcodz). Hence, auditing it can 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 seek out an answer Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which were passed to unserialize.

Running the fuzzer with PHP 7 instantly result in unexpected behavior. This conduct was not reproducible when tested towards Pornhub’s server though. Thus, we assumed a PHP 5 version. However, running the fuzzer in opposition to a newer model of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after placing an increasing number of effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the difficulty security related? In that case can we only exploit it locally or also remotely? To additional complicate this example the fuzzer did generate non-printable information blobs with sizes of greater than 200 KB. An incredible amount of time was mandatory to investigate potential points. In any case, we may extract a concise proof of idea of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we discovered that the foundation trigger could possibly be present in PHP’s garbage collection algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interplay of both components occurred solely after unserialize had completed its job. Consequently, it was not well suited to distant exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and a variety of hard work an analogous use-after-free vulnerability was discovered that seemed 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 may 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 use. Particularly, it involved multiple exploitation levels. 1. The stack and heap (which also embrace any potential user-enter) in addition to any other writable segments are flagged non-executable (c.f. 2. Even in case you are ready to control the instruction pointer you want to know what you wish to execute i.e. you might want to have a valid handle of an executable reminiscence segment.