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

페이지 정보

profile_image
작성자
댓글 0건 조회 30회 작성일 24-05-30 07:34

본문

1476741245_PEPPER-PORN_low-res-1200x628.jpgWe'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 were additionally 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 high rewards on Hackerone caught our consideration. That’s why we now have taken the angle of an advanced attacker with the complete intent to get as deep as potential into the system, focusing on one primary 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 shortly detected the usage of unserialize on the web site. In all circumstances a parameter named "cookie" bought unserialized from Post information and afterwards reflected through Set-Cookie headers. Standard exploitation strategies require so known as Property-Oriented-Programming (POP) that contain abusing already present courses with particularly outlined "magic methods" as a way to trigger undesirable and malicious code paths.



s-l1200.webpUnfortunately, it was tough for us to assemble any information about Pornhub’s used frameworks and PHP objects usually. Multiple lessons from widespread frameworks have been examined - all with out success. The core unserializer alone is comparatively advanced because it involves greater than 1200 lines of code in PHP 5.6. Further, many inner PHP lessons have their own unserialize strategies. By supporting constructions like objects, arrays, integers, strings or even references it is no shock that PHP’s monitor report reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly because unserialize already bought numerous consideration in the past (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, porn after so much consideration and so many safety fixes its vulnerability potential ought to have been drained out and it ought to be safe, shouldn’t it? To find an answer Dario implemented a fuzzer crafted particularly for fuzzing serialized strings which had been passed to unserialize.



Running the fuzzer with PHP 7 instantly lead to unexpected conduct. This habits was not reproducible when examined against Pornhub’s server though. Thus, we assumed a PHP 5 model. However, operating the fuzzer in opposition to a newer version of PHP 5 simply generated more than 1 TB of logs without any success. Eventually, after placing increasingly more effort into fuzzing we’ve stumbled upon unexpected conduct again. Several questions had to be answered: is the issue security associated? If that's the case can we only exploit it locally or additionally remotely? To further complicate this case the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An incredible amount of time was mandatory to research potential points. In any case, we could extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon additional investigation we discovered that the root cause might be found in PHP’s rubbish assortment algorithm, a component 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 additional evaluation, gaining a deeper understanding for the problem’s root causes and a number of arduous work the same use-after-free vulnerability was discovered that seemed to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and their discovery made it necessary to write down separate articles. You can learn more particulars 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 exploit. Particularly, it involved multiple exploitation stages. 1. The stack and heap (which also embrace any potential consumer-input) in addition to every other writable segments are flagged non-executable (c.f. 2. Even in case you are ready to manage the instruction pointer you have to know what you want to execute i.e. it is advisable have a legitimate deal with of an executable memory segment.

댓글목록

등록된 댓글이 없습니다.

회원로그인

회원가입