Hack in the Box attack - presenter threatened with arrows

Filed Under: Data loss, Privacy, Vulnerability

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.

, , , , , , , ,

You might like

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

About the author

Paul Ducklin is a passionate security proselytiser. (That's like an evangelist, but more so!) He lives and breathes computer security, and would be happy for you to do so, too. Paul won the inaugural AusCERT Director's Award for Individual Excellence in Computer Security in 2009. Follow him on Twitter: @duckblog