How we Broke PHP, Hacked Pornhub and Earned $20,000 > 자유게시판

• 목록
• 답변
• 글쓰기
• 게시판 리스트 옵션
  • 수정
  • 삭제

We have found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities had 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 go out 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 now we have taken the attitude of a complicated attacker with the complete intent to get as deep as doable into the system, focusing on one predominant purpose: 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 instances a parameter named "cookie" received unserialized from Post data and afterwards reflected through Set-Cookie headers. Standard exploitation techniques require so called Property-Oriented-Programming (POP) that contain abusing already present courses with particularly defined "magic methods" in an effort to trigger unwanted and malicious code paths.

Unfortunately, it was troublesome for us to gather any details about Pornhub’s used frameworks and PHP objects basically. Multiple courses from frequent frameworks have been tested - all with out success. The core unserializer alone is comparatively complicated as it involves greater than 1200 strains of code in PHP 5.6. Further, many inside PHP classes have their very own unserialize strategies. By supporting constructions like objects, arrays, integers, strings or even references it isn't any shock that PHP’s monitor document shows a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no known vulnerabilities of such type for newer PHP versions like PHP 5.6 or PHP 7, particularly because unserialize already obtained loads of attention previously (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after a lot attention and so many security fixes its vulnerability potential ought to have been drained out and it must be secure, shouldn’t it? To search out an answer Dario applied a fuzzer crafted specifically for fuzzing serialized strings which had been passed to unserialize.

Running the fuzzer with PHP 7 instantly lead to unexpected conduct. This habits was not reproducible when examined towards Pornhub’s server though. Thus, we assumed a PHP 5 version. However, operating the fuzzer in opposition to a newer version of PHP 5 simply generated more than 1 TB of logs without any success. Eventually, after putting more and more effort into fuzzing we’ve stumbled upon unexpected conduct once more. Several questions had to be answered: is the difficulty security associated? In that case can we solely exploit it regionally or additionally remotely? To further complicate this example the fuzzer did generate non-printable information blobs with sizes of more than 200 KB. An incredible amount of time was crucial to investigate potential points. After all, we may extract a concise proof of concept of a working reminiscence corruption bug - a so known as use-after-free vulnerability! Upon further investigation we discovered that the root cause might be found in PHP’s rubbish assortment algorithm, a part of PHP that is totally unrelated to unserialize.

However, the interplay of each elements occurred solely after unserialize had finished its job. Consequently, it was not effectively suited for remote exploitation. After additional analysis, gaining a deeper understanding for the problem’s root causes and a number of laborious work an analogous use-after-free vulnerability was found that gave the impression to be promising for distant exploitation. The excessive sophistication of the discovered PHP bugs and their discovery made it obligatory to write down separate articles. You possibly can learn more details in Dario’s fuzzing unserialize write-up. In addition, we've written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was significantly tough to use. In particular, it involved multiple exploitation stages. 1. The stack and heap (which additionally include any potential consumer-input) in addition to another writable segments are flagged non-executable (c.f. 2. Even if you're ready to regulate the instruction pointer you should know what you wish to execute i.e. you could have a legitimate tackle of an executable reminiscence section.