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

We now have discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize perform. We have 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 relatively high rewards on Hackerone caught our attention. That’s why we've taken the angle of a sophisticated attacker with the complete intent to get as deep as attainable into the system, focusing on one important objective: 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 instances a parameter named "cookie" received unserialized from Post knowledge and afterwards reflected by way of Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that involve abusing already current courses with specifically defined "magic methods" as a way to trigger unwanted and malicious code paths.

Unfortunately, it was tough for us to collect any information about Pornhub’s used frameworks and xhamster PHP objects normally. Multiple lessons from common frameworks have been examined - all with out success. The core unserializer alone is comparatively complex as it entails more than 1200 strains of code in PHP 5.6. Further, many internal PHP lessons have their own unserialize methods. By supporting buildings like objects, arrays, integers, strings or even references it is no surprise that PHP’s track document reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already received plenty of consideration prior to now (e.g. phpcodz). Hence, auditing it can be compared to 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 secure, shouldn’t it? To search out an answer Dario applied a fuzzer crafted particularly for fuzzing serialized strings which were handed to unserialize.

Running the fuzzer with PHP 7 immediately lead to unexpected conduct. This conduct was not reproducible when tested against Pornhub’s server though. Thus, we assumed a PHP 5 model. However, working the fuzzer against a newer version of PHP 5 just generated more than 1 TB of logs with none success. Eventually, after putting an increasing number of effort into fuzzing we’ve stumbled upon unexpected behavior again. Several questions needed to be answered: is the issue security related? If so can we only exploit it regionally or also remotely? To further complicate this example the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An incredible amount of time was crucial to analyze potential points. In spite of everything, we might extract a concise proof of idea of a working memory corruption bug - a so referred to as use-after-free vulnerability! Upon additional investigation we found that the basis trigger might be present in PHP’s rubbish assortment algorithm, a component of PHP that is completely unrelated to unserialize.

However, the interplay of both components occurred solely after unserialize had completed its job. Consequently, it was not effectively fitted to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and plenty of arduous work the same use-after-free vulnerability was found that seemed to be promising for remote exploitation. The high sophistication of the found PHP bugs and their discovery made it needed to put in writing separate articles. You may read 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 troublesome to exploit. Particularly, it involved multiple exploitation phases. 1. The stack and heap (which additionally embody any potential consumer-input) as well as another writable segments are flagged non-executable (c.f. 2. Even if you're in a position to regulate the instruction pointer it is advisable to know what you want to execute i.e. it's essential have a valid deal with of an executable reminiscence segment.