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

프로젝트 :

업체명 : KV

담당자명 : Lucio Keighley

연락처 : JT

이메일 : lucio_keighley@yahoo.com

We have now found two use-after-free vulnerabilities in PHP’s garbage assortment algorithm. Those vulnerabilities had been remotely exploitable over PHP’s unserialize perform. We were also 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 comparatively high rewards on Hackerone caught our attention. That’s why we now have taken the attitude of an advanced attacker with the full intent to get as deep as possible into the system, focusing on one major purpose: gaining remote code execution capabilities. Thus, we left no stone unturned and attacked what Pornhub is constructed upon: PHP. After analyzing the platform we quickly detected the usage of unserialize on the web site. In all circumstances a parameter named "cookie" bought unserialized from Post data and afterwards mirrored via Set-Cookie headers. Standard exploitation strategies require so known as Property-Oriented-Programming (POP) that contain abusing already existing classes with particularly outlined "magic methods" with a purpose to set off undesirable and malicious code paths.

Unfortunately, it was tough for us to gather any details 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 advanced as it involves more than 1200 lines of code in PHP 5.6. Further, many inside PHP lessons have their very own unserialize methods. By supporting structures like objects, arrays, integers, strings or even references it is not any surprise that PHP’s monitor file reveals a tendency for bugs and reminiscence corruption vulnerabilities. Sadly, there were no identified vulnerabilities of such type for newer PHP variations like PHP 5.6 or PHP 7, particularly as a result of unserialize already got a lot of consideration previously (e.g. phpcodz). Hence, auditing it may be in comparison with squeezing an already tightly squeezed lemon. Finally, after so much consideration and so many safety fixes its vulnerability potential ought to have been drained out and it needs to 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.

Running the fuzzer with PHP 7 immediately result in unexpected behavior. This conduct was not reproducible when examined in opposition to 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 greater than 1 TB of logs without any success. Eventually, after placing an increasing number of effort into fuzzing we’ve stumbled upon unexpected behavior again. Several questions had to be answered: is the difficulty security related? If that's the case can we solely exploit it regionally or additionally remotely? To further complicate this situation the fuzzer did generate non-printable data blobs with sizes of more than 200 KB. An incredible period of time was vital to research potential points. In any case, we might extract a concise proof of concept of a working memory corruption bug - a so called use-after-free vulnerability! Upon further investigation we discovered that the foundation cause could possibly be found in PHP’s garbage collection algorithm, xhamster a component of PHP that is completely unrelated to unserialize.

However, the interplay of each components occurred only after unserialize had completed its job. Consequently, it was not properly fitted to distant exploitation. After further evaluation, gaining a deeper understanding for the problem’s root causes and a number of laborious work the same use-after-free vulnerability was discovered that seemed to be promising for distant exploitation. The high sophistication of the discovered PHP bugs and their discovery made it mandatory to put in writing separate articles. You'll be able to read more details in Dario’s fuzzing unserialize write-up. In addition, we have written an article about Breaking PHP’s Garbage Collection and Unserialize. Even this promising use-after-free vulnerability was considerably difficult to take advantage of. Particularly, it involved multiple exploitation phases. 1. The stack and heap (which additionally embody any potential user-input) in addition to another writable segments are flagged non-executable (c.f. 2. Even in case you are ready to regulate the instruction pointer you have to know what you need to execute i.e. it is advisable to have a valid address of an executable reminiscence phase.