How we broke PHP, hacked Pornhub and earned $20k
evonide.com
evonide.com
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.I think a lot of people are reading this and think that this advice is too wide, and include so much in so few words.
It's the same caliber as "don't trust strangers" and "be responsible of your actions". There is undeniable truth in it, you cannot go wrong following it and it's difficult to argument against. But I think that's what makes it counter productive and basically devoid of meaning.
Effectively if the rule is as old as computing, but it still has to be voiced, it means it's not a simple rule to begin with.
As you put it "you must understand how it's used and filter, strip everything that is not needed away". This basically means every time you have user input, ideally you'd have to audit all the libraries and frameworks accessing the data to check how they use it, and filter accordingly. Pass a construct to a json library ? first check what the json library does with it, sanitize your input for everything that could be harmful to the library. This solution is voiced in one sentence, but would mean hours/days of library auditing in a real world scenario.
TL;DR: you can't cover for everything, you have to choose your battles. Knowing which libraries have known vulnerabilities is valuable info.
What if my language can't deal with strings properly? Maybe strpos has a buffer overflow on a carefully crafted input. Would I be wrong for using it?
Note that a cookie that you set, and are now getting back IS user-input, unless you do something to validate that it's actually the value you set. (HMAC is a good start)
If your language can't deal with strings properly, I strongly suggest you not expose it to strings provided by users. If you do expose it to strings from users, at least you should sandbox your application as much as possible.
Without meaning to be sarcastic (particularly because I found your post interesting), what lesson learned? A casual perusal of your post suggests the lesson "one can't craft SQL code to get by an AWK regex", but, of course, "what I can't do no-one can" is a bad lesson to learn in security.
Otherwise even your simple solution would be drawn in "can you support multi-byte characters ? Do you handle non unicode stuff ? What if it leaks in your layers if code before reaching your awk library ?" and other problems that abound in most mildy complex projects.
Hear hear! So true. The problem is that making complex things simple is extremely difficult.
E.g. you need to assume that every function you pass that data to will be subjected to malicious or accidentally broken input. I originally wrote "unless/until you have sanitised the content", but really, when building applications taking user data, just assume that you're dealing with malicious or accidentally broken input everywhere unless you have proven otherwise.
This goes from the trivial: Range check numbers; check length of strings, and verify any other constraints (encoding, character set limitations) that you may later depend on.
To the very complex: Going to re-use end-user HTML? May sound simple, but you basically need a HTML parser with explicit white-listing of tags and attributes, and if you allow CSS you need to parse and white-list CSS attributes too (biggest risks: chance of executing malicious JS in context of another logged in user, including in your admin interface; chance of causing unintended side-effects if you allow triggering HTTP requests - as a minimum, even assuming nobody any longer are stupid enough to trigger side-effects on GET requests and assuming that's all they are able to trigger, it has privacy impacts including the chance of leaking details about your admin systems or any third party systems you pass the HTML on to).
In general it means you have to understand all the ways the type of data you allow can go from being innocuous inert sequences of bytes to triggering effects that may be under the control of a potentially malicious user, and you have to assume that if you don't know, then format needs to be assumed to not be inert when passed to any given piece of code.
E.g. to take a much simpler example than HTML. Consider passing arbitrary XML to an XML parser in order to validate it against a schema to sanitise. Could be a smart thing to do. Except, even assuming the schema is strict enough, consider that a malicious XML document passed to a parser that's not explicitly configured not to, may be able to make HTTP requests with a source IP on your internal network (by specifying a suitable URL for the doctype).
Doesn't need to be malicious either - I've seen plenty of systems have throughput fall through the floor because someone didn't handle this case and suddenly got a bunch of XML documents with a doctype URL that took ages waiting for requests to a downed nameserver for some third-party domain to time out.
In this case you also better be sure you don't have any services that are "protected" only by being behind a firewall that allows side effects via GET requests (a there's a good reason to never allow side effects via GET requests and not allow unauthenticated services even behind your firewall, on the assumption that somewhere, sometime, you will slip in this area and allow a user-supplied URL to get retrieved from an internal IP due to the multitude of formats that can include URLs)
And yes, if there's a risk of strpos having a buffer overflow, you are now SOL if you haven't validated your input in a way that prevents it, and while that's an unlikely case, it is an important illustration of the overall point:
All third-party data is unsafe until proven safe in the context of the code it will be passed to.
As a wider point, you should consider not only your own immediate usage, but whether or not a given piece of data may ever be passed on to a third party API etc., as whether or not you consider their own security lapses to be their problem, it can also harm you.
As a corollary, you should assume any data coming coming from a trusted partner is as unsafe as data passed to you from a known hacker.
It's with data as with unprotected sex: when you take data from someone, you're exchanging data not just with them, but with everyone with access to their systems and anyone they exchange data with.
Don't assume they're being safe - it takes just a single slip-up in their data handling before what you might think are "safe" data fields provided by your partner are actually unvalidated content provided by a malicious user. You may think you know the source of the data when taking a feed from a trusted partner, but you don't - not really.
To the extent that you should not just treat individual fields as supplied by potential malicious users. You should treat their entire supplied data feed as supplied by a potentially malicious user. As for why, consider the equivalent of SQL injection applied to whatever format your partner is passing you. Or they may have been hacked.
The TL;DR boils down to pretty much the comment you replied to. Anything longer, including the above needs to come with a big, huge caveat: It's NOT complete.
You can write books about the ways data-validation can go wrong and things to look for, and what I've written above just scrapes the surface in a few very unsatisfactory ways (except, hopefully, by terrifying you). You need to always approach it assuming the worst.
It's with data as with unprotected sex: when you take data from someone, you're exchanging data not just with them, but with everyone with access to their systems and anyone they exchange data with.
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?
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.
I'm curious if Haskell's purity helps developers focus on this issue and therefore makes it easier to mitigate. Given that all user input/state already has to be handled carefully (for ex: with monads). It will be obvious in the codebase which parts need to be zero'd in on for possible attack vectors.
Perl and Ruby have included this as a 'tainted' flag, many functions cannot be called with a tainted string.
No, haskell's type system does, not its purity.
>Given that all user input/state already has to be handled carefully (for ex: with monads)
What? Monads are not some mythical beast, there is nothing "handled carefully" about it. A monad is just a general interface.
I was explaining what monads are. You have read some of the weird misconceptions about haskell and monads and are now repeating them.
I used monads only as an example (in brackets) but it's hardly the only form where purity creates clear divisions in the codebase. So, once again, the specific functionality of monads has nothing to do with it. I'm speaking about the coding style that Haskell promotes making detecting bugs easier during code reviews.
Having done security reviews of code I would have loved to have that type of distinction exist in a codebase compared to the usual OOP mess (with PHP or Ruby for example, which is typically the only paid work available in infosec) where state/user input is leaking all over the place. Compared to clearly defined paths containing IO - which are separated from pure functions which don't have unexpected side effects and require far less scrutiny.
I'm answering my own question here but I was hoping someone who has more experience than me at conducting security-centric code reviews would chime in to provide their perspective.
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..."
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.
Though I am not sure who the user is in this analogy.
Suppose you were handling snakes. Some snakes are not poisonous, and don't need to handled with the care you'd handle, say, a black mamba with. However, you are being advised to treat every snake you encounter as though it was the most poisonous snake known, and apply every care that you normally apply to snakes that you know are poisonous.
Will you handle the snakes? Yes, you're a snake handler, remember? But you handle all of them like they are deadly, even the ones you "know" to not be deadly.
User input ought to be treated with the same kind of respect, although in terms of user input the option of giving them a wide birth isn't always as practical.
https://paragonie.com/blog/2016/04/securely-implementing-de-...
It has to be done properly, of course -- for example, a poorly designed hash function could have characteristic collisions for many different seeds.
Most hash functions are engineered for speed and collision resistance, in that order. Trading collision resistance for speed is worthwhile for many workloads, since it barely affects the average case.
I disagree with that assessment. I think most hash functions are designed for speed and good distribution of outputs given normal inputs. But designing to resist collisions against someone trying to deliberately create them is a different thing entirely.
> Trading collision resistance for speed is worthwhile for many workloads, since it barely affects the average case.
I think that is far from established. SipHash is marketed under this premise, but from what I have heard it is significantly slower, particularly for short inputs.
A faster hash function can yield better overall performance than having fewer collisions. Here's some empirical evidence for this: https://www.strchr.com/hash_functions
The speed is correlated only weakly with the number of collisions-- and using the modern x86 CRC32 instruction yields the best results.
The Perl interpreter has been doing that for ages.
Python in 2012: http://bugs.python.org/issue13703
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...
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.
[1] https://www.reddit.com/r/PHP/comments/3j88v4/something_about...
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.
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.
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();
\');';
2. if i understand the exploit correctly they got remote code execution by finding the pointer to 'zend_eval_string' and then feeding the above code into it. doesn't that mean the use of 'eval' in the code that is being executed is unnecessary?
It's Perl: http://perldoc.perl.org/functions/my.html
This means that there is a conflict between performance and having a well structured object oriented framework.
Demand loaded classes and byte code help a lot with that: http://www.yiiframework.com/performance/
Best would be a model where a persistent process handles multiple requests concurrently, but that is not normal for PHP. So you need to make sure that all the libraries you are using are not leaking, have a nice db connection pool, and write a PHP framework that handles concurrency. Might as well use a better language at that point :-)
What do you need a 'well structured object oriented framework' for? You're going to build up a huge object graph in memory, to output some HTML, and then throw away all the objects at the end of the request. Nobody is going to see your beautiful object tree, so don't bother. A blog entry page should be super simple.
header, title, content, comments, recent comments, footer.
Header and footer are dead simple echos of the boilerplate, maybe replace in the html title or something. Read the title and content from disk[1]. Have another data file for all your articles for the index page.
I prefer not to have comments on my blog, but if you must, you can put them in a database; limit to something like 100 or 1000 comments per article (because really) and limit threading, and it's going to be pretty quick to query them (make sure your webserver is doing reads from a database in the same metro area, if not on the same box).
Recent comments is across all blog entries; I would probably add a index on the time in the comments table and just select 2 from there; you could union that into the earlier comments query if you don't want to make two round trips to the database.
You don't need to do this with concurrency, each page load has barely anything to wait for, so more threads doesn't help throughput. Run enough php workers (php-fpm, or apache children if you're using apache_mod_php) to keep your cpu busy, and you're golden.
[1] There's four articles on this blog -- it doesn't need a database. PS run php as a user that can't write anywhere on the disk, and push the blog entries and the summary datafile with another user.
Edit to add: If you skip comments (or outsource to disqus or some other comments w/ javascript platform), you can make the whole site just static html, and leave PHP at home. OTOH, these guys are running Wordpress, because they like frequent security updates?
PHP ships with an opcode cache built-in (and at least on every distro I've seen, enabled by default) since PHP 5.5 that keeps the compiled bytecode in shared memory
In my experience php is fast enough until you start generating lots of garbage. It seems it wasn't really designed to garbage collect at all, but to rely on the per-request cleanup.
We should really stop pretending that the garbage collector is the problem with langauges. The collector isn't the problem, your garbage is the problem.
[Not that I'm a proponent of PHP, though it does make popping shells far more fun.]
Now, the approach PHP takes is fine for the original vision of the language. It even works great.
But languages designed for long running processes often have some sort of mechanism for dealing with that situation explicitly. Like the `NSAutoreleasePool` in Objective C. In C++ you might build your own custom slab allocator.
I'd say the garbage collector is one of the problems with PHP. Then again, if you run into it, PHP might not be the right tool for that particular job.
From a legal perspective how do companies and hackerone create a binding exemption from laws used to prosecute hackers?
Are there any legal precedents for this?
Two words -- honor code. Rock the boat and you will find yourself in an unpleasant situation, so instead everybody does good work and nobody asks too many questions.
For both white hats and Pornhub, the legal/authorized bounty system is in their interest. White hats are making less money than some black hats, but they're not constantly terrified of being prosecuted under intense anti-hacking laws. Pornhub is spending a lot less than they would if they were hacked by black hats. Both parties win.
But meh, sometimes jokes fall flat.
> Dump the complete database of pornhub.com including all sensitive user information.
And of course leak the data to expose everyone that participates in this nasty business. It is such a sad thing that people are even proud to work at companies like this where humans are not worth more than a big dick or boobs.
And then you get around and say that child porn is so horrible. No, all porn is horrible and destroys our families and integrity. How can there be any dignity left if these things are held to be something good?