2

To what extent a hacker can potentially cause harm to a server? Can you please give few examples?

Recently, there was a data breach in my website and I found out this interface was public-facing and was curious to see if this could have been used for data breach.

Screenshot

  • Is "memcache" and "memcached" the same product? – k1DBLITZ May 19 '15 at 17:29
2

To what extent a hacker can potentially cause harm to a server? Can you please give few examples?

A few examples are XSS and data ex-filtration.

For more information on the XSS scripting exploit, please review: http://niiconsulting.com/checkmate/2013/05/memcache-exploit/

For more information on the data ex-filtration, please review: http://blog.codesherpas.com/on_the_path/2010/08/securing-memcache-in-2-minutes.html

It seems there are two CVE's for MemCache, specifically:

CVE-2010-5276 - The Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal does not properly handle the $user object in memcache_admin, which might "lead to a role change not being recognized until the user logs in again."

CVE-2010-5275 - Cross-site scripting (XSS) vulnerability in memcache_admin in the Memcache module 5.x before 5.x-1.10 and 6.x before 6.x-1.6 for Drupal allows remote attackers to inject arbitrary web script or HTML via unspecified vectors. Keep in mind that there could be more vulnerabilities with MemCache that have not been publicly disclosed.

  • 1
    I was thinking of something more serious, that could be exploited remotely. Social engineering is least possible for our application to be victim of xss attack – ramailo sathi May 19 '15 at 14:38
  • The documentation I've read seems to indicate the application is susceptible to stored cross site scripting versus reflected - in which case social engineering isn't required. Also, please read the article over data ex-filtration. The person was able to extract cached data from mem cache. If any sensitive data was cached (userID's, passwords, connection strings, etc) it could have been compromised. – k1DBLITZ May 19 '15 at 17:34
1
  • First thing that comes to mind is Script injection (for Cross-site scripting(XSS) or phishing purposes)

  • Secondly all 'private' cached data is readable to the world. (this could mean e-mails / passwords / keys / etc... were / are accessible for anyone who wants them.)

  • 1
    It would be nice, If you answered it in context of memcache. – ramailo sathi May 18 '15 at 13:02
  • What do you mean with "in context of memcache" The context is Security here. not operation. – LvB May 18 '15 at 13:19
0

The way your application server is configured could one of the possible way an attacker can use their accessibility opportunities - this will be defined as the attack surface for the application.

As you decided to keep it memcache based context, I would deliver you the protections instead of measuring the attack surface since this depends on the interfaces that are exposed to the public facing front. If you are at debian, use this to configure IPSec.

iptables -A INPUT -s 1.1.1.1/32 -p tcp --destination-port 11211 -j ALLOW
iptables -A INPUT -s 0.0.0.0/0 -p tcp --destination-port 11211 -j DROP

Use the above to protect from compromises if at all an attacker tries to backconnect and then root. This depends again on the usability such as if your use case is served via blocking all other ports except the one which you use. If memcached rely on the same system which has accessibility and talk to your MySQL instances, you might need to worry if any of the interfaces have been exploited. If they both are on the same system - your webserver will communicate with memcached rather then the mysql server and hence any exploitibility likelihood to webserver will lead clear consequences to your web database as well.

I also encourage to look at this, which will further deliver you the attack surface study.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.