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

페이지 정보

profile_image
작성자 Barrett Stump
댓글 0건 조회 27회 작성일 24-05-30 15:15

본문

2000x2000.8.jpgWe have now discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize perform. We have 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 comparatively excessive rewards on Hackerone caught our consideration. That’s why now we have taken the angle of a sophisticated attacker with the full intent to get as deep as attainable into the system, focusing on one essential 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 rapidly detected the utilization of unserialize on the website. In all instances a parameter named "cookie" acquired unserialized from Post knowledge and afterwards reflected via Set-Cookie headers. Standard exploitation methods require so referred to as Property-Oriented-Programming (POP) that contain abusing already current classes with specifically defined "magic methods" in an effort to set off unwanted and malicious code paths.



414_1000.jpgUnfortunately, it was tough for us to assemble any details about Pornhub’s used frameworks and PHP objects in general. Multiple lessons from frequent frameworks have been examined - all with out success. The core unserializer alone is relatively advanced as it includes more than 1200 traces of code in PHP 5.6. Further, many internal PHP classes have their very own unserialize strategies. By supporting buildings like objects, arrays, integers, xhamster strings and even references it is not any shock that PHP’s monitor report shows a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, especially because unserialize already bought numerous consideration in the past (e.g. phpcodz). Hence, auditing it may 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 must be safe, shouldn’t it? To seek out a solution Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which had been handed to unserialize.



Running the fuzzer with PHP 7 instantly result in unexpected habits. This behavior was not reproducible when tested towards Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer against a newer model of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after putting increasingly effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the problem safety related? In that case can we solely exploit it locally or additionally remotely? To additional complicate this example the fuzzer did generate non-printable knowledge blobs with sizes of more than 200 KB. An incredible period of time was crucial to analyze potential issues. In spite of everything, we might extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon additional investigation we found that the root cause could possibly be present in PHP’s garbage assortment algorithm, a part of PHP that is completely unrelated to unserialize.



However, the interplay of both parts occurred solely after unserialize had finished its job. Consequently, it was not effectively fitted to remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and a number of onerous work an identical use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it needed to write separate articles. You may read more details in Dario’s fuzzing unserialize write-up. As well as, we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to take advantage of. Particularly, it concerned a number of exploitation phases. 1. The stack and heap (which additionally embrace any potential user-enter) in addition to any other writable segments are flagged non-executable (c.f. 2. Even if you are ready to regulate the instruction pointer you should know what you need to execute i.e. you must have a sound handle of an executable reminiscence phase.

blackbg.jpg

댓글목록

등록된 댓글이 없습니다.