Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

You can do all sorts of nasty things to an exposed memcached. For example, if you know your target site is using Rails (and if you've done Rails for more than two days you can describe the big freaking footprints most sites leave), you can identify at least one controller using action caching (look for the CMS, it is an obvious choice), write arbitrary Javascript into a cached page, and then figure out how to get someone logged into an admin account to visit that page on their site. That shouldn't be too difficult ("Hey guys, you have a spelling mistake here, click this link to your own domain to see it.") You now have the admin's account.

Action caching will vault over every built-in security measure Rails has to prevent script injection.

That is probably game over for most Rails applications, and all you need is one blind cache write to make it happen, since Rails will almost certainly give you everything you need to know in the URL to the probably-cached page (controller name, action name, object ID).

Happily, this is pretty easy to defend against: follow the directions that come with your memcached config file, particularly the one which says:

# Specify which IP address to listen on... This parameter is one of the only security measures that memcached has, so make sure it's listening on a firewalled interface. -l 127.0.0.1 *

Nonstandard ports never hurt anybody, either.



Many sites also use memcache to cache page fragments that will be sent verbatim to clients with the rest of the webpage.

As Marco demonstrated in his slides one can easily inject into caches and if one can change the values of keys related to page fragments then it is a major security risk.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: