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

페이지 정보

profile_image
작성자
댓글 0건 조회 40회 작성일 24-05-31 04:36

본문

2000x2000.8.jpgWe've discovered two use-after-free vulnerabilities in PHP’s garbage collection algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. 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 text. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why we've taken the attitude of an advanced attacker with the total intent to get as deep as attainable into the system, specializing in one most important goal: 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" bought unserialized from Post knowledge and afterwards mirrored through Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that contain abusing already present lessons with specifically outlined "magic methods" with a view to set off unwanted and malicious code paths.



sense8_204_unit_04032_r2.jpgUnfortunately, it was difficult for us to gather any information about Pornhub’s used frameworks and PHP objects typically. Multiple courses from widespread frameworks have been examined - all without success. The core unserializer alone is comparatively complex because it entails more than 1200 traces of code in PHP 5.6. Further, many inside PHP courses have their own unserialize methods. By supporting buildings like objects, xhamster arrays, integers, strings or even references it isn't any surprise that PHP’s track record reveals a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no identified vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, especially because unserialize already got a whole lot of attention previously (e.g. phpcodz). Hence, auditing it can be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot consideration and so many security fixes its vulnerability potential should have been drained out and it needs to be secure, shouldn’t it? To find a solution Dario implemented a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.



Running the fuzzer with PHP 7 instantly result in unexpected conduct. This behavior was not reproducible when tested towards Pornhub’s server though. Thus, we assumed a PHP 5 model. However, operating the fuzzer against a newer model of PHP 5 simply generated more than 1 TB of logs without any success. Eventually, after putting increasingly effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions needed to be answered: is the difficulty safety related? If that's the case can we only exploit it domestically or additionally remotely? To additional complicate this example the fuzzer did generate non-printable information blobs with sizes of greater than 200 KB. An amazing amount of time was needed to investigate potential points. In any case, we may extract a concise proof of concept of a working reminiscence corruption bug - a so called use-after-free vulnerability! Upon additional investigation we found that the root trigger could possibly be found in PHP’s garbage assortment algorithm, a element of PHP that is completely unrelated to unserialize.



However, the interaction of both elements occurred solely after unserialize had completed its job. Consequently, it was not properly suited for remote exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and numerous hard work an analogous use-after-free vulnerability was found that gave the impression to be promising for remote exploitation. The high sophistication of the found PHP bugs and their discovery made it obligatory to write separate articles. You can learn extra particulars in Dario’s fuzzing unserialize write-up. As well as, we have now 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. In particular, it concerned a number of exploitation phases. 1. The stack and heap (which additionally embrace any potential person-input) as well as some other writable segments are flagged non-executable (c.f. 2. Even in case you are in a position to control the instruction pointer it's essential to know what you want to execute i.e. it's essential to have a legitimate deal with of an executable reminiscence phase.

댓글목록

등록된 댓글이 없습니다.

회원로그인

회원가입