How we Broke PHP, Hacked Pornhub and Earned $20,000

How we Broke PHP, Hacked Pornhub and Earned $20,000

Dillon 2024.05.29 06:29 views : 6
pexels-photo-3356195.png?auto=compressu0026cs=tinysrgbu0026h=750u0026w=1260

1HccP.jpgWe have now found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were 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 article. Pornhub’s bug bounty program and its comparatively high rewards on Hackerone caught our consideration. That’s why we've taken the attitude of an advanced attacker with the full intent to get as deep as potential into the system, focusing on one main 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 usage of unserialize on the web site. In all cases a parameter named "cookie" bought unserialized from Post information and afterwards reflected by way of Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that contain abusing already current courses with specifically outlined "magic methods" in order to trigger undesirable and malicious code paths.



2000x2000.7.jpgUnfortunately, it was troublesome for us to gather any information about Pornhub’s used frameworks and PHP objects usually. Multiple courses from widespread frameworks have been examined - all with out success. The core unserializer alone is relatively advanced because it entails more than 1200 traces of code in PHP 5.6. Further, many inner PHP lessons have their very own unserialize strategies. By supporting structures like objects, arrays, integers, strings or even references it is not any shock that PHP’s observe report exhibits a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no known vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, particularly as a result of unserialize already acquired a variety of consideration prior to now (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after a lot consideration and so many security fixes its vulnerability potential should have been drained out and it ought to be secure, shouldn’t it? To find a solution Dario implemented 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 behavior was not reproducible when tested in opposition to Pornhub’s server though. Thus, we assumed a PHP 5 model. However, running the fuzzer against a newer model of PHP 5 simply generated greater than 1 TB of logs with none success. Eventually, after putting increasingly more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the issue safety associated? In that case can we only exploit it locally or additionally remotely? To further complicate this situation the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. An amazing amount of time was essential to analyze potential issues. In any case, we may extract a concise proof of idea of a working reminiscence corruption bug - a so called use-after-free vulnerability! Upon further investigation we discovered that the root cause may very well be present in PHP’s garbage collection algorithm, a element of PHP that is completely unrelated to unserialize.



However, the interplay of both components occurred only after unserialize had finished its job. Consequently, it was not nicely suited for remote exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and a number of onerous work the same use-after-free vulnerability was found that gave the impression to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it obligatory to write down separate articles. You can learn more particulars in Dario’s fuzzing unserialize write-up. In addition, we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly tough to use. Specifically, it concerned a number of exploitation phases. 1. The stack and heap (which additionally embody any potential person-input) in addition to every other writable segments are flagged non-executable (c.f. 2. Even if you're ready to manage the instruction pointer it's good to know what you wish to execute i.e. you'll want to have a valid handle of an executable reminiscence segment.

Comments