
BlackHat Write-up: go-derper and mining memcaches - pmjordan
http://www.sensepost.com/blog/4873.html
======
patio11
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.

~~~
gertburger
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.

