from Hacker News

Multiple Vulnerabilities in Pocket

by ers35 on 8/18/15, 1:07 PM with 154 comments

by jerf on 8/18/15, 2:30 PM
A little tip for people trying to armor themselves against this problem: If your app reaches out to do network transactions, it really ought to block localhost. However, bear in mind that localhost isn't "127.0.0.1"... it's "127.0.0.0/8" (or "127.x.x.x" if you don't casually speak CIDR). Ping 127.2.88.33 on your console now... you'll see replies.
On the flip side, if you're doing a security test like this, I've gotten mileage out of convincing apps to access local resources with things like 127.88.23.245, precisely because the developer blocked 127.0.0.1 specifically and thought they were done.
You should also usually block all internal and external IPs for your entire network, but especially in the cloud this can begin to get tricky. Still, you should.
And don't forget IPv6.
by mike-cardwell on 8/18/15, 2:05 PM
http://help.getpocket.com/customer/portal/articles/1225832-p...
"Pocket does not provide monetary compensation for any identified or possible vulnerability."
Cheapskates. This could have cost them money if somebody abusive had discovered it first. He deserves a monetary award.
[edit] Should we be concerned about the massive number of people listed on that page who have found security problems with Pocket? I counted 153 separate people...
by skarap on 8/18/15, 5:10 PM
Yet another service discovered which was built/deployed with no regard for security whatsoever. I'm beginning to realize - this is the norm. Security is the least important thing for most of the IT companies.
I guess the DevOps trend (i.e. not hiring sysadmins) should take it's share of blame. Or maybe it's the other way around - you don't care for security, so there is no point in hiring security experts?
by BenjaminWill on 8/18/15, 4:17 PM
Oh Mozilla, why couldn't you resist the money. Your recent so called "services" are not welcome. You know it. But well, money makes the world go around.
How much did Telefonica pay you for the Hello integration?
But sure, our surfing history will be secure ...
https://blog.mozilla.org/advancingcontent/2015/05/21/providi...
Did you guys acutally read your PR-bullshit here?
But soon a new small, fast, free, secure open-source browser will arrive and Mozilla will be history. But your pocket full. Well done.
by cddotdotslash on 8/18/15, 2:04 PM
Really interesting write up! I'm surprised they are still running in EC2-Classic. However, even if they are, security groups should still be restrictive enough to prevent some of the things discussed. For example, bypassing the load balancer shouldn't be possible. A security group applied to the back end instances should only allow HTTP/S traffic from the load balancer group. SSH security groups should only allow inbound traffic from known IPs (like the office network), etc. Unfortunately, not enough people do this, and once you can query instance meta data or obtain an SSH key, it's game over.
by ddlatham on 8/18/15, 2:36 PM
If you were Pocket how would you handle the vulnerability created by having internal services hit user-supplied URLs?
Some ideas:
- Move the service doing the fetching to an untrusted network. At least it would be unable to access any internal services and any compromises there would be hopefully limited. You still have the problem that the local machines there could potentially be compromised.
- Validate / verify the URL to ensure it's not hitting anything internal. This sounds hard. Pre-resolve the name and check to see if the IP is in an internal range? Seems easy to get our of date as your network changes. Make sure to repeat for any redirects? Is there a better way to validate?
- Ensure that all internal services require authentication. This also sounds hard and easy to miss something.
by pdkl95 on 8/18/15, 3:46 PM
This is the problem with services that store user information: it is highly probably that vulnerabilities like these exist. Security is rarely given the time and attention it requires.
I'm not trying to single out Pocket; they are just the latest evidence that even in the few cases where "you can trust us with your data" is said honestly, it isn't a promise that can be kept in practice.
by falcolas on 8/18/15, 1:25 PM
One more vulnerability which is possible when you can request an instance's metadata: Any AMI roles which have been given to that instance (for example to enable S3 access or decrypt data using AWS' key service) would be visible.
These keys are rotated relatively frequently, but it opens up a whole new level of exploits against the company which runs those AWS servers.
by schmichael on 8/18/15, 4:54 PM
Is there a name for this sort of attack? We were just protecting against some similar attacks earlier this week, and it would have been nice to have a short name to refer to them as instead of "that attack vector where we make unrestricted HTTP requests based on user input".
by mrbig4545 on 8/18/15, 1:47 PM
running as root??? seriously?????
by billyhoffman on 8/18/15, 2:30 PM
I'm really not a fan of EC2 exposing instance meta data as a RESTful HTTP API running on Local-Link IP addresses. If its only supposed to be queried locally, why aren't these just environment variables? Perhaps they are dynamic and that won't work but come on!
At the very least, run it on localhost:10101 or something. Don't give us another range to have to filter!
by robn_fastmail on 8/19/15, 9:38 PM
If you want a laundry list of SSRF methods you should protect against, a great place to start is this slide deck from a talk at ONsec a couple of years ago:
http://www.slideshare.net/d0znpp/ssrf-attacks-and-sockets-sm...
Its thrilling and terrifying :)
by hundt on 8/18/15, 4:26 PM
Security researchers out there: on what side of "the line" do you view this kind of exploitation to be? It was not done for nefarious purposes, but it did involve intentionally accessing resources that were clearly not intended to be accessed, like /etc/passwd. Would you worry if you did this that the company might call the police instead of thanking you?
by halosghost on 8/18/15, 2:44 PM
The one thing I don't like about this article (and indeed, much of the discourse around the Pocket integration) is its characterization of the Pocket integration itself. It calls it an “opt-out non-removable [extension]”. The truth is that you can easily disable it just as you can easily disable many other things that Firefox includes by-default. In fact, if you use Classic Theme Restorer (I use it not because I dislike australis, but because I really do not want a navigation toolbar), it has an option baked in to disable Pocket along with webrtc, et al.
Admittedly, I suppose it would be nice if Firefox actually packaged Pocket as a real extension that could be removed from the Extensions menu, but they have already integrated several things without using that schema.
I still use firefox, just with more and more things disabled, because none of the other browsers out there even come close to having what I need in a GUI browser (though, I would note that I'm evermore tempted to abandon GUI browsing altogether).
Either way, the write-up is great, and everything in the article other than that one characterization (which rubbed me a bit the wrong way in the wake of all the fevered discussions around the Pocket Integration) was a truly enjoyable read. Not to mention, it's great that the Pocket devs fixed things quickly; that's always a plus!
by luxoria on 8/18/15, 4:12 PM
>Grab ssh private keys from autoprovisioned EC2 user’s home directory using 301 redirect to file URI (after all, we’re running as root, we can read them).
This is not a fair assumption to make. Maybe they are running a LSM like AppArmor.
by _navaneethan on 8/19/15, 6:48 AM
You should receive some gift from pocket team :)
by Iuz on 8/18/15, 5:43 PM
Is it ironic that I saved the article on pocket?
by dafrankenstein2 on 8/18/15, 5:57 PM
i prefer using offline bookmark..specially the bookmark manager of Opera browser is impressive. ============================================= and for online bookmarking there is 'raindrop.io'