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

페이지 정보

profile_image
작성자 Stewart Morales
댓글 0건 조회 47회 작성일 24-05-29 00:25

본문

2000x2000.8.jpgWe have now discovered two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize function. We were 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 high rewards on Hackerone caught our consideration. That’s why we have taken the angle of a complicated attacker with the total intent to get as deep as possible into the system, focusing on one primary 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 rapidly detected the usage of unserialize on the website. In all circumstances a parameter named "cookie" obtained unserialized from Post information and afterwards mirrored via Set-Cookie headers. Standard exploitation methods require so called Property-Oriented-Programming (POP) that contain abusing already existing classes with specifically defined "magic methods" with a view 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 in general. Multiple lessons from common frameworks have been tested - all with out success. The core unserializer alone is comparatively complex as it includes greater than 1200 traces of code in PHP 5.6. Further, many inside PHP lessons have their own unserialize strategies. By supporting structures like objects, xhamster arrays, integers, strings or even references it isn't any surprise that PHP’s monitor document reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already received numerous attention in the past (e.g. phpcodz). Hence, auditing it may be compared to squeezing an already tightly squeezed lemon. Finally, after so much attention and so many safety fixes its vulnerability potential should have been drained out and it must be safe, shouldn’t it? To find an answer Dario carried out a fuzzer crafted particularly for fuzzing serialized strings which were handed to unserialize.

image-asset.jpeg?format=2500w

Running the fuzzer with PHP 7 immediately result in unexpected conduct. This conduct was not reproducible when tested towards Pornhub’s server though. Thus, we assumed a PHP 5 model. However, working the fuzzer towards a newer model of PHP 5 simply generated greater than 1 TB of logs without any success. Eventually, after putting increasingly effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions needed to be answered: is the issue security associated? If so can we only exploit it domestically 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 amount of time was mandatory to research potential points. In spite of everything, we could extract a concise proof of concept of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the root trigger could be present in PHP’s garbage assortment algorithm, a element of PHP that is totally unrelated to unserialize.



However, the interplay of both components occurred solely after unserialize had completed its job. Consequently, it was not well suited to distant exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and quite a lot of arduous work an analogous use-after-free vulnerability was found that appeared to be promising for distant exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it obligatory to write separate articles. You can learn more details in Dario’s fuzzing unserialize write-up. As well as, we now have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly troublesome to exploit. Specifically, it involved multiple exploitation levels. 1. The stack and heap (which additionally include any potential person-input) in addition to another writable segments are flagged non-executable (c.f. 2. Even in case you are ready to manage the instruction pointer you want to know what you want to execute i.e. it is advisable to have a valid tackle of an executable reminiscence section.

댓글목록

등록된 댓글이 없습니다.