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

We've got found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize function. We had been also 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 relatively high rewards on Hackerone caught our consideration. That’s why we now have taken the angle of a sophisticated attacker with the total intent to get as deep as potential into the system, specializing in one major goal: gaining distant 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 usage of unserialize on the web site. In all circumstances a parameter named "cookie" bought unserialized from Post data and afterwards reflected via Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that involve abusing already current classes with particularly defined "magic methods" to be able to set off unwanted and malicious code paths.

Unfortunately, it was difficult for us to collect any information about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from common frameworks have been tested - all without success. The core unserializer alone is comparatively complicated as it includes greater than 1200 traces of code in PHP 5.6. Further, many inside PHP classes 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 record shows a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no recognized vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already got a whole lot of attention up to now (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after so much attention and so many security fixes its vulnerability potential should have been drained out and it must be safe, shouldn’t it? To search out a solution Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which have been passed to unserialize.

Running the fuzzer with PHP 7 instantly lead to unexpected behavior. This conduct was not reproducible when examined against Pornhub’s server though. Thus, we assumed a PHP 5 model. However, operating the fuzzer against a newer version of PHP 5 just generated more than 1 TB of logs with none success. Eventually, after placing an increasing number of effort into fuzzing we’ve stumbled upon unexpected habits once more. Several questions had to be answered: is the problem safety related? If that's the case can we only exploit it domestically or additionally remotely? To additional complicate this situation the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An amazing period of time was mandatory to analyze potential issues. In spite of everything, porn we might extract a concise proof of idea of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the basis trigger might be found in PHP’s garbage assortment algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interaction of each parts occurred solely after unserialize had completed its job. Consequently, it was not nicely suited to remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and loads of onerous work an analogous use-after-free vulnerability was discovered that seemed to be promising for remote exploitation. The high sophistication of the discovered PHP bugs and their discovery made it essential to put in writing separate articles. You possibly can learn extra details in Dario’s fuzzing unserialize write-up. In addition, we have now written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly difficult to take advantage of. In particular, it concerned a number of exploitation stages. 1. The stack and heap (which additionally embrace any potential consumer-enter) as well as every other writable segments are flagged non-executable (c.f. 2. Even in case you are able to regulate the instruction pointer you could know what you want to execute i.e. you want to have a valid tackle of an executable reminiscence segment.