How I found a Remote Code Execution bug affecting Facebook's servers
ubercomp.com
ubercomp.com
Of course, everyone will be curious about the payout ;)
There are no legal entities that would buy the bug, the USG can access any data w/ a warrant (thats free) vs. "millions or billions". Any other law enforcement agency could do the same thing. There is really no value there to them. So it would have to be blackhats, and that means some idiotic Russians mass owning everyone with old Java bugs. Again - not worth much.
This sort of bug has very little value, except to facebook.
As I said in the post, I already had a strong suspicion that, once I could read files, escalating to RCE would be easy. But I decided not to do it without permission and they fixed the bug very quickly. As much as I'd loved to actually see the output of an ls or something like that, I think I made the right call.
https://www.facebook.com/BugBounty/posts/778897822124446?str...
Not being in the bug bounty business, I had expected a higher payment.
It is like the anecdote of Tesla and Ford and knowing where to put the X[0], you aren't paying for time or manual labour - bug value is derived from how much damage it can cause, what its worth to Facebook to not be exploited and what the exploit is worth to the bad guys on the black market.
Time is often used to measure compensation – lawyers are well known for being paid in hourly fees –, however, in the long run, only results counts. And concerning the market, for how much could this bug have been sold, for example to the NSA?
I however believe he could easily have sold it on the black market for more. (Not saying that one should do such a thing.)
https://mail.gnome.org/archives/xml/2012-October/msg00045.ht...
For the nokogiri users, there are a couple of proofs-of-concept in this ticket: https://github.com/sparklemotion/nokogiri/issues/693 - they should be patched with modern versions of nokogiri and libxml2, but if you're running older versions, you might want to verify their behavior before someone else does it for you.
Here's an issue with paying more: the security engineers employes are paid around 100 to 150K a year.
Imagine you'd get paid 100K for a big exploit. It wont be valuable to be a security engineer anymore (since you can't be paid additionally for finding the bugs), it's better to be unemployed and spend your time finding the bugs.
I think that's one of the main issue, at least until bugs are extremely, extremely rare (which really, they aren't - these news are really the tip of the iceberg).
http://h30499.www3.hp.com/t5/HP-Security-Research-Blog/Q2-20...
Disclaimer: I used to work on WebInspect's audit engines
XML is data. If your application needs to send a request for reading a file through XML this should really be explicit, not relying in a "permission happy" XML library, no?
So the attack looks like this: Server takes input from evil user, inserts it into an XML document in memory. The input is malicious, and contains not only XML data, but XML directives to include other documents, specifically /etc/passwd on the location machine. The XML document is processed, the contents of /etc/passwd are automatically read by the XML parser/processor. However the data is not in the correct format, and the XML parser/processor spits out a detailed error message, showing the data that could not be processed/parsed, which is the contents of /etc/passwd.
Make sense?
I'm thinking there should be a "root path" for the library to be able to access files. Sure, you want to include "base.xml" it's in a specific directory and the library is allowed to read only that, and no "../../../../etc/password" tricks.
>and due to a valid scenario he theorized involving an administrative feature we are scheduled to deprecate soon, we decided to re-classify the issue as a potential RCE bug.
I imagine it might be some feature that could maybe be triggered internally through a file:// or http://localhost/ URL, and in doing so gain access to an interface that can issue shell commands. That's pure speculation though, and I'm probably way off.
remote read access is much more limited than remote write access, but even write access will be limited by file permissions, and doesn't necessarily translate to code execution.
injecting some code into some of the web-app source that gets triggered by an additional request would probably be hte easiest way, but you might also look for system binaries that get called by cron or similar.
Sounds like he didn't use any of these, and it was actually some sort of local web-accessible (but externally firewalled) admin interface that a suitable request could exploit, and I'm very curious how that part of it would work (especially how you'd know/find out about it as an outsider)
They never protect the systems from within that well because generally it's more effort than it's worth (well, of course, the day a company becomes bankrupt because of an RCE, they'd wish they spent the time - as usual with security).
Of course, it doesn't mean it's always possible. It's just likely.
Random scenario, since /etc/passwd is available, it tells me the php config sucks. you could just write a php shell and run it on the web interface. Or have the code within requests and read the log file (again, its all about config. if php let you read the file and doesn't only execute for .php files, bang. or if you can write a .php, bang again.)
The point really is that I rarely see people caring about protecting anything or following best practices once someone found a bug that affects the system (such as fs access).
If you find this interesting and want to hire me to do a security
focused review or penetration testing in your own (or your
company's) code, don't hesitate to send me an email at
reginaldo@ubercomp.com.
First, web app vulns are usually specific to a single site. (Unless obviously you find an issue in a common underlining framework, say, a session fixation attack in how PHP or ASP.NET handles sessions).
Second, and much more importantly, the vast majority of site's don't have financially actionably information. Unless you handle banking/credit card info, I am limited in what I can do to extract value from the server (compared to a compromised client). There aren't that many vectors to extract value.
-Dump their list of usernames/passwords? Ok, maybe some of those will also be used on other banking or commerce sites, but I have challenges/risks actually getting money out. And if I want stolen credit card numbers I can just buy them in card forums.
-Serve sleazy advertising? Ok, possible, but ad's are a crappy business to be in and its definitely a high volume/long time approach (ask how well Huffpo pays its writers). You can try affiliate spamming/stuffing, but again, not huge value. Both ads and affiliate approaches are dependent on how much traffic the server you hacked gets. Low traffic, you make no money. The more traffic, the larger the site, the smarter/better equipped the IT/security team. How long do you really think an Alexa top 10 or top 100 site won't notice an IFRAME pointing to .ru or .cn?
-Mining cryptocurrency? Not financially viable
What usually happens when a server is compromised is that an exploit kit is installed and it's used to attack the visitors (specifically exploit a vulnerability in the client). And so we are back to attacking clients to extract value over attacking (most) websites. Why do this? Simple:
- There are orders of magnitude more desktops/browsers than web servers. - They are running tons of diverse plugins and software so the attack surface is much larger. - Most of that software will be out of date and have known vulnerabilities. - Very few of these clients are "managed" by a personal IT person like a web server. The user is far less likely to notice anything bad.
All of that mean I can reach more targets, compromise a larger number of them, and hold them for longer. Why is this better than pwning a server? Because lots of scenarios to extract value that don't work on a handful of web servers do work when I have thousands and thousands of compromised clients:
-Show them ads -Stuff affiliate links -Changing their DNS settings and MitM all their traffic (bank.com? Why that's right over here!) -Keylog them to actually steal financial data, credits cards, bank logins, etc -Use them to send spam -Use them as a botnet to DDoS people and get paid protection money -Mining? perhaps?
To put this in prospective, very smart hackers doing crazy stuff to break out of Chrome's sandbox and exploit clients are getting $50-$100k in public contests like Pwn2Own. Getting $35,000 for a RCE is pretty awesome
Getting drive-by traffic is one of the most expensive pieces of the puzzle for malware groups. Last time I checked the forums, a thousand visitors was selling for around a dollar, and that isn't even well qualified traffic.
Having access to Facebook and over a billion pageviews per hour would be worth millions to any group who is capable of handling that type of volume. If they were smart about it, they could probably get away with it for up to a day (the Yahoo malware was active for a day and they didn't obfuscate it much).
Back of the envelope value is around $1M per hour, and that doesn't include the premium for the higher quality of traffic, but does assume you find a way to inject across all the servers and somehow not display it to Facebook internal IPs.
A big group with some fresh browser 0day would have loved to get their hands on this.
A much more devious attack would be modifying some of the code to silently siphon off login credentials, and grabbing the user database. Then once they were satisfied with that they could go with the malware route.