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

페이지 정보

profile_image
작성자
댓글 0건 조회 24회 작성일 24-05-23 16:28

본문

360_F_314700448_Ckh3uDxLuKEwPNGHIKF1ZgRwuVStqSft.jpgWe've discovered two use-after-free vulnerabilities in PHP’s rubbish 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 exit to cutz for co-authoring this text. Pornhub’s bug bounty program and its relatively excessive rewards on Hackerone caught our attention. That’s why now we have taken the angle of a complicated attacker with the complete intent to get as deep as possible into the system, specializing in one principal objective: gaining distant 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 utilization of unserialize on the website. In all cases a parameter named "cookie" bought unserialized from Post data and afterwards reflected through Set-Cookie headers. Standard exploitation methods require so called Property-Oriented-Programming (POP) that involve abusing already current lessons with particularly outlined "magic methods" with a view to set off undesirable and malicious code paths.



28ee47455632b9eb0611a355c04645d5.png?resize=400x0Unfortunately, it was difficult for us to collect any details about Pornhub’s used frameworks and PHP objects usually. Multiple courses from frequent frameworks have been examined - all without success. The core unserializer alone is comparatively advanced because it includes greater than 1200 strains of code in PHP 5.6. Further, many inside PHP classes have their own unserialize strategies. By supporting constructions like objects, arrays, integers, strings or even references it isn't any surprise that PHP’s observe document shows a tendency for bugs and memory corruption vulnerabilities. Sadly, there were no known vulnerabilities of such kind for newer PHP variations like PHP 5.6 or PHP 7, especially as a result of unserialize already acquired a variety of consideration previously (e.g. phpcodz). Hence, auditing it can be compared to squeezing an already tightly squeezed lemon. Finally, after a lot 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 seek out an answer Dario applied a fuzzer crafted particularly for fuzzing serialized strings which had been passed to unserialize.



Running the fuzzer with PHP 7 immediately lead to unexpected conduct. This behavior was not reproducible when examined towards Pornhub’s server though. Thus, we assumed a PHP 5 model. However, working the fuzzer against a newer model of PHP 5 just generated greater than 1 TB of logs without any success. Eventually, after placing more and more effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions needed to be answered: is the problem safety related? If that's the case can we solely exploit it regionally or additionally remotely? To further complicate this example the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An amazing amount of time was vital to investigate potential points. After all, we might extract a concise proof of concept of a working memory corruption bug - a so known as use-after-free vulnerability! Upon further investigation we discovered that the root trigger may very well be found in PHP’s rubbish collection algorithm, a component of PHP that is completely unrelated to unserialize.



However, the interaction of both components occurred only after unserialize had completed its job. Consequently, it was not properly suited for remote exploitation. After further analysis, gaining a deeper understanding for the problem’s root causes and a number of laborious work a similar use-after-free vulnerability was discovered that gave the impression to be promising for remote exploitation. The excessive sophistication of the found PHP bugs and their discovery made it essential to write separate articles. You may learn more particulars 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 considerably troublesome to use. In particular, it concerned a number of exploitation phases. 1. The stack and xnxx heap (which also embrace any potential user-input) as well as some other writable segments are flagged non-executable (c.f. 2. Even if you are ready to control the instruction pointer you should know what you need to execute i.e. you have to have a legitimate deal with of an executable reminiscence phase.

댓글목록

등록된 댓글이 없습니다.

회원로그인

회원가입