¿Cuál es el riesgo de tener memcache en la interfaz pública?

2

¿Hasta qué punto un hacker puede causar daño a un servidor? ¿Puedes dar algunos ejemplos?

Recientemente, hubo una violación de datos en mi sitio web y Descubrí que esta interfaz era pública y tenía curiosidad por ver si se podría haber utilizado para la violación de datos.

    
pregunta ramailo sathi 18.05.2015 - 11:54
fuente

3 respuestas

2
  

¿Hasta qué punto un hacker puede causar daño a un servidor? Poder   ¿Por favor da algunos ejemplos?

Algunos ejemplos son XSS y la filtración de datos.

Para obtener más información sobre el exploit de scripts XSS, revise: enlace

Para obtener más información sobre la extracción de datos, revise: enlace

Parece que hay dos CVE para MemCache, específicamente:

CVE-2010-5276 - El módulo Memcache 5.x antes de 5.x-1.10 y 6.x antes de 6.x-1.6 para Drupal no controla correctamente el objeto $ user en memcache_admin, lo que podría "conducir a que no se reconozca un cambio de rol hasta que el usuario inicie sesión. de nuevo. "

CVE-2010-5275 - Vulnerabilidad de los scripts entre sitios (XSS) en memcache_admin en el módulo Memcache 5.x antes de 5.x-1.10 y 6.x antes de 6.x-1.6 para Drupal permite a los atacantes remotos inyectar scripts web o HTML a través de vectores no especificados. Tenga en cuenta que podría haber más vulnerabilidades con MemCache que no se hayan divulgado públicamente.

    
respondido por el k1DBLITZ 18.05.2015 - 17:45
fuente
1
  • Lo primero que me viene a la mente es la inyección de secuencias de comandos (para fines de secuencias de comandos entre sitios (XSS) o con fines de suplantación de identidad)

  • En segundo lugar, todos los datos almacenados en caché 'privados' son legibles para el mundo. (Esto podría significar que los correos electrónicos / contraseñas / claves / etc ... están / son accesibles para cualquiera que los quiera).

respondido por el LvB 18.05.2015 - 12:08
fuente
0

La forma en que se configura su servidor de aplicaciones podría ser una de las posibles formas en las que un atacante puede usar sus oportunidades de accesibilidad. Esto se definirá como la superficie de ataque para la aplicación.

Como decidiste mantenerlo en el contexto basado en memcache , te entregaría las protecciones en lugar de medir la superficie de ataque , ya que esto depende de las interfaces que están expuesto al público frente a frente . Si está en Debian, use esto para configurar 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 lo anterior para protegerse de compromisos si, en todo caso, un atacante intenta volver a conectarse y luego rootear. Esto depende nuevamente de la facilidad de uso, por ejemplo, si su caso de uso se atiende mediante el bloqueo de todos los demás puertos, excepto el que utiliza. Si memcached se basa en el mismo sistema que tiene accesibilidad y habla con sus instancias de MySQL, es posible que deba preocuparse si alguna de las interfaces ha sido explotada. Si ambos están en el mismo sistema, su servidor web se comunicará con memcached en lugar del servidor mysql y, por lo tanto, cualquier posibilidad de aprovechamiento del servidor web también tendrá claras consecuencias para su base de datos web.

También me animo a mirar this , que te proporcionará el estudio Attack Surface

    
respondido por el Shritam Bhowmick 11.10.2015 - 22:05
fuente

Lea otras preguntas en las etiquetas