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

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

Shawn 2024.05.28 15:34 views : 63

2000x2000.8.jpgWe have now discovered two use-after-free vulnerabilities in PHP’s rubbish collection algorithm. Those vulnerabilities have 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 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 we've got taken the angle of a complicated attacker with the complete intent to get as deep as possible into the system, specializing in one major 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 rapidly detected the utilization of unserialize on the web site. In all cases a parameter named "cookie" obtained unserialized from Post information and xhamster afterwards mirrored through Set-Cookie headers. Standard exploitation methods require so called Property-Oriented-Programming (POP) that involve abusing already present lessons with specifically outlined "magic methods" with a view to set off undesirable and malicious code paths.



sense8_204_unit_04032_r2.jpgUnfortunately, it was difficult for us to assemble any details about Pornhub’s used frameworks and PHP objects on the whole. Multiple lessons from common frameworks have been tested - all without success. The core unserializer alone is relatively complex as it involves greater than 1200 lines of code in PHP 5.6. Further, many internal PHP courses have their very own unserialize strategies. By supporting constructions like objects, arrays, integers, strings and even references it is not any surprise that PHP’s monitor file exhibits a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no recognized vulnerabilities of such sort for newer PHP versions like PHP 5.6 or PHP 7, especially as a result of unserialize already obtained plenty of attention prior to now (e.g. phpcodz). Hence, auditing it can be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many security fixes its vulnerability potential ought to have been drained out and it needs to be safe, shouldn’t it? To find a solution Dario applied a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.



Running the fuzzer with PHP 7 instantly lead to unexpected behavior. This conduct was not reproducible when tested in opposition to Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer towards a newer version of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after putting an increasing number of effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions needed to be answered: is the problem safety related? If so can we solely exploit it domestically or additionally remotely? To further complicate this case the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. A tremendous period of time was essential to research potential points. After all, 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 basis trigger may very well be present in PHP’s garbage collection algorithm, a element of PHP that is totally unrelated to unserialize.



However, the interplay of each elements occurred only after unserialize had completed its job. Consequently, it was not properly fitted to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and lots of exhausting work the same 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 necessary to jot down separate articles. You may read extra details in Dario’s fuzzing unserialize write-up. As well as, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly troublesome to exploit. Specifically, it involved a number of exploitation levels. 1. The stack and heap (which also embrace any potential person-enter) in addition to every other writable segments are flagged non-executable (c.f. 2. Even if you're ready to regulate the instruction pointer it's good to know what you want to execute i.e. you could have a sound handle of an executable reminiscence section.

Comments