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

페이지 정보

profile_image
작성자 Terra
댓글 0건 조회 28회 작성일 24-06-01 23:02

본문

1HccP.jpgNow we have found two use-after-free vulnerabilities in PHP’s garbage assortment 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 go out to cutz for co-authoring this article. Pornhub’s bug bounty program and its relatively high rewards on Hackerone caught our attention. That’s why now we have taken the attitude of an advanced attacker with the full intent to get as deep as possible into the system, focusing on one principal goal: gaining distant code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is built upon: PHP. After analyzing the platform we rapidly detected the utilization of unserialize on the website. In all circumstances a parameter named "cookie" acquired unserialized from Post data and afterwards mirrored by way of Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that involve abusing already current lessons with particularly defined "magic methods" with the intention to trigger unwanted and malicious code paths.



2sSjaI7.jpgUnfortunately, it was troublesome for us to gather any information about Pornhub’s used frameworks and PHP objects usually. Multiple classes from widespread frameworks have been examined - all with out success. The core unserializer alone is relatively complex as it involves more than 1200 traces of code in PHP 5.6. Further, many inside PHP courses have their own unserialize methods. By supporting structures like objects, arrays, integers, strings or even references it is not any shock that PHP’s observe record shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no known vulnerabilities of such sort for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already bought a lot of consideration previously (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 security fixes its vulnerability potential should have been drained out and it should be secure, shouldn’t it? To find an answer Dario implemented a fuzzer crafted specifically for fuzzing serialized strings which had been handed to unserialize.

class=

Running the fuzzer with PHP 7 instantly result in unexpected conduct. This conduct was not reproducible when tested against Pornhub’s server although. Thus, we assumed a PHP 5 version. However, operating the fuzzer against a newer version of PHP 5 simply generated greater than 1 TB of logs with none success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected behavior once more. Several questions needed to be answered: is the problem security related? In that case can we only exploit it regionally or also remotely? To additional complicate this case the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. A tremendous period of time was needed to research potential points. In spite of everything, we might extract a concise proof of idea of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we found that the basis trigger might be present in PHP’s rubbish assortment algorithm, a element of PHP that is totally unrelated to unserialize.



However, the interplay of each elements occurred only after unserialize had finished its job. Consequently, it was not properly fitted to remote exploitation. After additional evaluation, gaining a deeper understanding for the problem’s root causes and a lot of laborious work the same use-after-free vulnerability was discovered that appeared to be promising for remote exploitation. The excessive sophistication of the found PHP bugs and their discovery made it necessary to put in writing separate articles. You possibly can read more particulars in Dario’s fuzzing unserialize write-up. As well as, we've written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly troublesome to use. Specifically, it involved a number of exploitation levels. 1. The stack and heap (which additionally embrace any potential user-input) as well as another writable segments are flagged non-executable (c.f. 2. Even if you're in a position to control the instruction pointer it's essential know what you wish to execute i.e. it's essential to have a sound tackle of an executable reminiscence phase.

댓글목록

등록된 댓글이 없습니다.