로고

완도명사십리오토캠핑장
로그인 회원가입
  • 자유게시판
  • 자유게시판

    자유게시판

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

    페이지 정보

    profile_image
    작성자 Giuseppe
    댓글 댓글 0건   조회Hit 38회   작성일Date 24-05-28 01:35

    본문

    360_F_314700448_Ckh3uDxLuKEwPNGHIKF1ZgRwuVStqSft.jpgNow we have discovered two use-after-free vulnerabilities in PHP’s rubbish assortment algorithm. Those vulnerabilities have been remotely exploitable over PHP’s unserialize operate. 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 comparatively high rewards on Hackerone caught our attention. That’s why we now have taken the attitude of a complicated attacker with the complete intent to get as deep as possible into the system, specializing in one principal goal: 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 website. In all cases a parameter named "cookie" acquired unserialized from Post knowledge and afterwards reflected by way of Set-Cookie headers. Standard exploitation methods require so known as Property-Oriented-Programming (POP) that contain abusing already present lessons with specifically outlined "magic methods" with a purpose to set off undesirable and malicious code paths.



    b9404ca05d4b26a9c18a3f4577b1b9da.10.jpgUnfortunately, it was troublesome for us to collect any information about Pornhub’s used frameworks and PHP objects normally. Multiple courses from widespread frameworks have been examined - all without success. The core unserializer alone is relatively complicated as it involves more than 1200 traces of code in PHP 5.6. Further, many internal PHP classes have their very own unserialize methods. By supporting constructions like objects, arrays, integers, strings and even references it is no surprise that PHP’s monitor report exhibits a tendency for bugs and memory corruption vulnerabilities. Sadly, there have been no known vulnerabilities of such sort for newer PHP variations like PHP 5.6 or PHP 7, particularly because unserialize already received numerous consideration up to now (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 ought to have been drained out and it should be secure, shouldn’t it? To search out an answer Dario implemented a fuzzer crafted specifically for fuzzing serialized strings which had been passed to unserialize.



    Running the fuzzer with PHP 7 immediately lead to unexpected behavior. This conduct was not reproducible when examined 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 an increasing number of effort into fuzzing we’ve stumbled upon unexpected habits again. Several questions needed to be answered: is the difficulty safety related? In that case can we only exploit it regionally or also remotely? To further complicate this situation the fuzzer did generate non-printable knowledge blobs with sizes of greater than 200 KB. An incredible amount of time was necessary to investigate potential points. After all, 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 could be found in PHP’s rubbish collection algorithm, a element of PHP that is totally unrelated to unserialize.



    However, the interplay of both elements occurred only after unserialize had finished its job. Consequently, it was not effectively fitted to remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and quite a lot of exhausting work an identical use-after-free vulnerability was found that seemed to be promising for distant exploitation. The high sophistication of the found PHP bugs and their discovery made it needed to jot down separate articles. You'll be able to read more details in Dario’s fuzzing unserialize write-up. As well as, we've got written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably troublesome to take advantage of. Particularly, xnxx it involved multiple exploitation stages. 1. The stack and heap (which also embody any potential user-enter) as well as any other writable segments are flagged non-executable (c.f. 2. Even if you are able to regulate the instruction pointer it is advisable to know what you need to execute i.e. you have to have a legitimate tackle of an executable memory phase.

    댓글목록

    등록된 댓글이 없습니다.