Hack in the Box attack – presenter threatened with arrows

Marco Slaviero, a presenter at Hack in the Box 2010 in Kuala Lumpur, Malaysia, had a narrow escape yesterday after a number of outsized presentation arrows ganged up and threatened to attack him during his talk.

Powerpoint was initially suspected, but rapid investigation showed that Slaviero was using rival presentation software Keynote on a Mac. Prompt use of the space bar extracted Slaviero from danger and restored calm to the audience.

Don’t believe me?

Then be glad you didn’t see and hear the rest of Marco’s talk, which measured and analysed the real-world use of memcached, an open-source, high-performance, distributed memory object caching system. You would have wished you could disbelieve that, too.

Memcached is a popular server-side tool most commonly used for saving recently-generated web pages (and, if you wish, some or all of the data used to generate those pages) in memory, load-balanced across a number of servers on your LAN.

If memcached pages are requested again within a reasonable time, memcached simply “regurgitates them, rather than regenerating them,” in Marco’s words. This can speed up web applications dramatically, since it avoids both disk access and repeated database queries by the web server.

Clearly, memcached is intended as an accelerational back-end for your web server. Ideally, it should be accessible from your web servers only, and should deliver results only to those web servers.

But Marco’s research suggested that many memcached implementations are publicly visible and dangerously insecure.

For example, he was quickly able to find about 1000 openly-accessible memcached servers in a scan of just 600,000 IP numbers. Many of these memcached instances could be openly instructed to reveal statistics about their cache performance, a dump of cached requests and the structure of their cached data, plus vast quantities of that cached data.

The data openly visible from the public internet included:

  • email addresses and other user-specific information,
  • plaintext web login credentials (usernames and passwords),
  • social networking information gleaned from sites like Facebook, and
  • undisguised password hashes.

Many of these publicly-visible caches were almost certainly also open to modification, potentially allowing hackers to compromise web pages without changing anything on the web server itself or its back-end databases, and without leaving tell-tale signs in any change control log.

What were these memcached users thinking?

There’s no point in securing your web servers and the data in your back-end database servers if you then openly publish data from those systems anyway, albeit unintentionally. That’s like locking the front door of your house but leaving all the ground floor windows invitingly open.

The good news is that since Marco did his survey, first presented at the Black Hat conference, the caches whose owners he was able to identify and inform have all fixed their insecurity.

Those of you who use memcached, or whose services providers use it, ought to review your setup at once. Make sure you haven’t locked the door but opened the windows.