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

페이지 정보

profile_image
작성자
댓글 0건 조회 19회 작성일 24-06-02 10:33

본문

2000x2000.8.jpgNow we have discovered two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities were remotely exploitable over PHP’s unserialize operate. We were also awarded with $2,000 by the Internet Bug Bounty committee (c.f. Many thanks go out to cutz for co-authoring this text. Pornhub’s bug bounty program and its comparatively excessive rewards on Hackerone caught our attention. That’s why we've got taken the attitude of a complicated attacker with the full intent to get as deep as possible into the system, specializing in one principal objective: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we shortly detected the utilization of unserialize on the website. In all instances a parameter named "cookie" acquired unserialized from Post knowledge and afterwards reflected by way of Set-Cookie headers. Standard exploitation strategies require so known as Property-Oriented-Programming (POP) that contain abusing already present lessons with particularly defined "magic methods" in order to trigger undesirable and malicious code paths.



sense8_204_unit_04032_r2.jpgUnfortunately, it was difficult for us to collect any information about Pornhub’s used frameworks and PHP objects usually. Multiple courses from common frameworks have been tested - all without success. The core unserializer alone is comparatively complicated as it involves greater than 1200 lines of code in PHP 5.6. Further, many internal PHP courses have their very own unserialize methods. By supporting buildings like objects, arrays, integers, strings and even references it is not any shock that PHP’s observe document reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such type for xhamster newer PHP versions like PHP 5.6 or PHP 7, especially as a result of unserialize already bought loads of consideration in the past (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 safety fixes its vulnerability potential should 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 result in unexpected conduct. This habits was not reproducible when tested towards Pornhub’s server though. Thus, we assumed a PHP 5 version. However, working the fuzzer towards a newer version of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after putting increasingly more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the problem safety related? If that's the case can we only exploit it regionally or additionally remotely? To additional complicate this case the fuzzer did generate non-printable data blobs with sizes of greater than 200 KB. A tremendous amount of time was obligatory to investigate potential issues. After all, we could extract a concise proof of concept of a working reminiscence corruption bug - a so referred to as use-after-free vulnerability! Upon additional investigation we discovered that the root trigger may very well be found in PHP’s garbage assortment algorithm, a part of PHP that is completely unrelated to unserialize.



However, the interaction of both parts occurred only after unserialize had completed its job. Consequently, it was not well fitted to remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and numerous arduous work a similar use-after-free vulnerability was discovered 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 jot down separate articles. You can read more details in Dario’s fuzzing unserialize write-up. In addition, we've got written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly tough to use. In particular, it concerned multiple exploitation phases. 1. The stack and heap (which additionally include any potential person-enter) as well as any other writable segments are flagged non-executable (c.f. 2. Even in case you are able to control the instruction pointer that you must know what you need to execute i.e. you have to have a legitimate handle of an executable reminiscence segment.

댓글목록

등록된 댓글이 없습니다.

회원로그인

회원가입