Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

How we broke PHP, hacked Pornhub and earned $20k

evonide.com

Post reply on HN
Print view View original

51–60 of 107 posts

Re: How we broke PHP, hacked Pornhub and earned $20k

#51

Post by anglebracket »

tjallingt wrote: post #50

I have some questions about two things in the exploit code that puzzled me: my $php_code = 'eval(\' header("X-Accel-Buffering: no"); header("Content-Encoding: none"); header("Connection: close"); error_reporting(0); echo file_get_contents("/etc/passwd"); ob_end_flush(); ob_flush(); flush(); \');'; 1. they seem to be using php to code the exploit (solely based on the $ before the variable name) but i've never seen the…

>i've never seen the 'my' keyword before, what exactly is this language?

It's Perl: http://perldoc.perl.org/functions/my.html

Re: How we broke PHP, hacked Pornhub and earned $20k

#52

Post by Xeago »

tjallingt wrote: post #50

I have some questions about two things in the exploit code that puzzled me: my $php_code = 'eval(\' header("X-Accel-Buffering: no"); header("Content-Encoding: none"); header("Connection: close"); error_reporting(0); echo file_get_contents("/etc/passwd"); ob_end_flush(); ob_flush(); flush(); \');'; 1. they seem to be using php to code the exploit (solely based on the $ before the variable name) but i've never seen the…

Looks like perl, seeing the `my`.

Re: How we broke PHP, hacked Pornhub and earned $20k

#54

Post by qwertyuiop924 »

nickpsecurity wrote: post #38
justinlardinois wrote: post #32

Earlier quoted context omitted.

Hash functions designed for hash tables are generally not hard to find collisions for, so there's not much that can be done. You could shoehorn in a secure hash function, but that would hurt performance.

I was thinking more on lines of (a) does JSON handling need hash tables and (b) if do, do they have to be open addressing or something vulnerable to DOS? A No on either can lead to an implementation with better DOS resistance.

For B) All hash table implementations are vulnerable to this kind of attack. However, some kinds of chaining are less vulnerable. In particular, balanced binary tree chaining would make the worst-case lookup (and insertion?) time complexity O(log n), which is a significant improvement over probing or linked list chaining. The tricks mentioned in the other comments above also improve things, by making such an event less likely.

As for A), no. No, JSON handling doesn't need hashtables. Since your app will only look at certain values in the JSON, you can simply ignore all the other values, and dump the values in an object/struct of your choosing. It wouldn't even be all that hard to write, provided you know how to write a parser...

Re: How we broke PHP, hacked Pornhub and earned $20k

#55

Post by codedokode »

segmondy wrote: post #41
krapp wrote: post #8

The takeway: You should never use user input on unserialize. Assuming that using an up-to-date PHP version is enough to protect unserialize in such scenarios is a bad idea. Avoid it or use less complex serialization methods like JSON.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

> you should NEVER TRUST USER INPUT

That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all?

> strip everything that is not needed

That does not always work. What if I have a comment form that should accept any characters?

Re: How we broke PHP, hacked Pornhub and earned $20k

#56

Post by nickpsecurity »

qwertyuiop924 wrote: post #54
nickpsecurity wrote: post #38

Earlier quoted context omitted.

I was thinking more on lines of (a) does JSON handling need hash tables and (b) if do, do they have to be open addressing or something vulnerable to DOS? A No on either can lead to an implementation with better DOS resistance.

For B) All hash table implementations are vulnerable to this kind of attack. However, some kinds of chaining are less vulnerable. In particular, balanced binary tree chaining would make the worst-case lookup (and insertion?) time complexity O(log n), which is a significant improvement over probing or linked list chaining. The tricks mentioned in the other comments above also improve things, by making such an event le…

Since your app will only look at certain values in the JSON, you can simply ignore all the other values, and dump the values in an object/struct of your choosing. It wouldn't even be all that hard to write, provided you know how to write a parser..."

That's what I was thinking. Never seen verified parsers or generators requiring these things. So I figured it was an unnecessary requirement bringing in its own security issue.

Re: How we broke PHP, hacked Pornhub and earned $20k

#57

Post by hueving »

seanp2k2 wrote: post #37
Buge wrote: post #13

Earlier quoted context omitted.

In the US the law is against unauthorized access. If a company agrees to let people try to hack their stuff, then the access is authorized and legal.

To what extent? What if you do something on accident that ends up messing up their stuff? Just the first example I can think of: you figure out a way to reboot an instance which lets you exploit a race condition in some auth code, and don't realize that the instance you're killing is critical for some other function (let's say billing) and you end up causing some real monetary damage, even though you had no idea. Are…

It's in the agreement with you and the company. Usually it says if you cause a side effect like that you are at fault.

Re: How we broke PHP, hacked Pornhub and earned $20k

#58

Post by chatmasta »

ndesaulniers wrote: post #24

> Using a locally compiled version of PHP we scanned for good candidates for stack pivoting gadgets Surprised that worked. Guess they got lucky and either got the comiler+optization flags the same as the PHP binary used, or the release process can create higly similar builds.

They mention that PH had a custom compiled PHP and that's why they couldn't get the address of the function they wanted to call for evaluating code.

My understanding is that ROP gadgets are a separate issue. Basically you want to find a function that compiles to assembly instructions resembling the ones you need to move the stack pointer to your desired location. Testing this locally shouldn't be a problem, because functions across builds will compile to the same assembly instructions (even if their headers have different load addresses).

Again, that's my understanding - I have a very vague grasp of this stuff.

Re: How we broke PHP, hacked Pornhub and earned $20k

#59

Post by blastrat »

codedokode wrote: post #55
segmondy wrote: post #41

Earlier quoted context omitted.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everything that is not needed That does not always work. What if I have a comment form that should accept any characters?

I'm not being a smartaleck, but "you shouldn't be writing code" with your attitude/approach. "NEVER trust user input" is an important security mantra to learn all on its own, like "wipe your butt/wash your hands" is in another context.

The guy is writing a valid point on Hacker(!) News. People writing comments on HN (especially to summarize a takeaway from a longer form article) are not required to accurately recapitulate entire dossiers of how to process input. It is completely valid to say "you should never trust user input". Somebody who is looking to make that "actionable" or "clear and pretty useful" can very very easily google the phrase and will turn up a lot of useful answers and information.

This is what is meant by the idea that the simplicity of the iPhone UI and/or automated IDEs has created a generation of helplessness and entitlement.

The good advice remains good advice: you should never trust user input. If you can't turn that into sound advice from Hacker News, your options become limited to, nobody should trust the code you write, you shouldn't write code, or you shouldn't read hacker news for advice.

But the idea that people need to write what you personally need to hear or they shouldn't write comments? that's nuts. Could I have written a more useful comment to you and to the community? I'll tell you this, I did think about it, and this my best shot at what I thought you and the community could benefit from!

There used to be a guy on usenet news who posted all sorts of stuff, and had the name of his company in his .sig line, and he included the phrase "these ARE the opinions of my company" instead of that boring old boilerplate "none of the opinions I express are..."

Re: How we broke PHP, hacked Pornhub and earned $20k

#60

Post by krapp »

codedokode wrote: post #55
segmondy wrote: post #41

Earlier quoted context omitted.

Actually, the takeaway is not that "you should never use user input on unserialize." It is, that you should NEVER TRUST USER INPUT. This rule is as old as computing itself and trust of user input has always been the beginning of a security vulnerability. You need user input, you will use user input, but you must understand how it's used and filter, strip everything that is not needed away.

> you should NEVER TRUST USER INPUT That is not clear at all and pretty useless. What does it mean? I should not accept any user input at all? > strip everything that is not needed That does not always work. What if I have a comment form that should accept any characters?

>What does it mean? I should not accept any user input at all?

No, it means you should never assume that user data is safe, or even sane. Assume, rather, that everything every user is sending you is malicious, all the time, and write your code accordingly.

>. What if I have a comment form that should accept any characters?

First, you probably shouldn't, because your database and HTML should be using explicit character encodings, so a comment form that accepts anything doesn't make a lot of sense. How are you expecting to deal with "any characters"? What happens when they paste in a binary blob, or javascript code?

Secondly, assuming you want to do that, you still shouldn't trust the data. Add it to the database using parameterized queries, escape it when rendering, never mix it in to javascript variables and never serialize it into a format designed to unserialize executable objects.

It's not an unreasonable burden to expect web developers to at least be aware and code defensively. Especially with PHP.

Post reply on HN