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

페이지 정보

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

본문

1HccP.jpgWe have found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize perform. We had been additionally 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 relatively excessive rewards on Hackerone caught our attention. That’s why we've got taken the perspective of an advanced attacker with the total intent to get as deep as doable into the system, focusing on one main aim: gaining distant 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 usage of unserialize on the web site. In all cases a parameter named "cookie" got unserialized from Post data and afterwards reflected through Set-Cookie headers. Standard exploitation techniques require so referred to as Property-Oriented-Programming (POP) that involve abusing already current classes with particularly outlined "magic methods" to be able to set off unwanted and malicious code paths.



NFVTZ.jpgUnfortunately, it was troublesome for us to collect any details about Pornhub’s used frameworks and PHP objects typically. Multiple lessons from frequent frameworks have been examined - all with out success. The core unserializer alone is comparatively advanced because it includes greater than 1200 lines of code in PHP 5.6. Further, many internal PHP classes have their very own unserialize strategies. By supporting constructions like objects, arrays, integers, strings and even references it is not any shock that PHP’s track report exhibits a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no known vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly because unserialize already received lots of attention previously (e.g. phpcodz). Hence, auditing it can be in comparison with squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many security fixes its vulnerability potential should have been drained out and it must be secure, shouldn’t it? To search out a solution Dario applied a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.



Running the fuzzer with PHP 7 immediately lead to unexpected behavior. This behavior 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 behavior again. Several questions needed to be answered: is the issue safety related? If that's the case can we solely exploit it locally or also remotely? To further complicate this example the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An incredible period of time was vital to investigate potential issues. After all, we might extract a concise proof of idea of a working reminiscence corruption bug - a so referred to as use-after-free vulnerability! Upon further investigation we found that the root cause could be present in PHP’s rubbish collection algorithm, a component of PHP that is totally unrelated to unserialize.



However, the interaction of both elements occurred solely after unserialize had finished its job. Consequently, it was not effectively suited for remote exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and a variety of hard work an analogous use-after-free vulnerability was found that appeared to be promising for remote exploitation. The high sophistication of the found PHP bugs and their discovery made it mandatory to put in writing separate articles. You possibly can read extra details 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 troublesome to use. In particular, it involved a number of exploitation phases. 1. The stack and heap (which also embody any potential user-input) in addition to any other writable segments are flagged non-executable (c.f. 2. Even if you're able to manage the instruction pointer you should know what you want to execute i.e. you'll want to have a legitimate deal with of an executable reminiscence segment.

k1xIe5DPpnk

댓글목록

등록된 댓글이 없습니다.

회원로그인

회원가입