¿Es posible que una vulnerabilidad en una aplicación sea explotada para atacar a otra aplicación en el mismo servidor?

Si la vulnerabilidad de Magento condujo a un shell, entonces ese shell podría usarse para obtener acceso de root mediante una vulnerabilidad de escalada de privilegios. Cuando eso sucede, el atacante tiene control completo sobre el sistema.

La respuesta corta es un calificado "Sí". Especialmente si los sistemas de software se ejecutan en el mismo espacio de sistema de archivos y espacio de memoria. Si un atacante obtiene root, el sistema es pwned. Dicho esto, hay un par de configuraciones que harían mucho más difícil el pwnage y el HIDS debería tener tiempo Para alertar sobre la actividad.

Lo más común es que cada aplicación se ejecute en su propio chroot jail . Debería ser posible bloquear las cosas con suficiente fuerza con algo como SELinux o RBAC en Windows o Solaris. No son herméticos, el intruso estaría haciendo tanto ruido tratando de averiguar cómo están configurados y cómo otorgarse los privilegios necesarios para continuar el ataque, de nuevo, para este momento, el HIDS habría dejado el juego.

Una configuración aún más segura es hacer que cada aplicación se ejecute en su propia máquina virtual. Si las máquinas virtuales se ejecutan en la parte superior de un sistema operativo, el atacante tendría que salir completamente de la máquina virtual en la que se estaba ejecutando la aplicación vulnerable y entrar en la otra. Suponiendo que las máquinas virtuales y la máquina host ejecutan cada una HIDS, las alarmas se apagarán antes de que se complete el ataque a la segunda máquina. Si se están ejecutando en el metal, creo que es seguro decir que quien atacaría ese sistema no tiene los recursos para completar el ataque.

En mi humilde opinión, hacer que cada aplicación se ejecute en su propia máquina virtual es una buena idea de todos modos. Debería hacer el trabajo y la implementación es, por lejos, lo más fácil de implementar y administrar. . .

Sí, normalmente funciona a la inversa. Wordpress tiene un complemento inseguro instalado que permite cargar y ejecutar un script php. Esto se puede usar para atacar el lado de Magento, como la descarga de las credenciales de la base de datos de Magento, la inyección de cuentas de administrador personalizadas en la base de datos de Magento, la instalación del módulo de administración de archivos de Magepleasure y los scripts de recolección de información de la tarjeta.

Por supuesto, esta es una calle de dos vías. Si Magento no está parcheado para el error de robo de tiendas, el atacante puede usar una transacción POST para inyectar directamente una cuenta de administrador en la base de datos de Magento sin tener las credenciales de Magento. Descargue Magento y luego instale el módulo de administración de archivos Magepleasure y, una vez más, haga lo que desee en la cuenta de usuario.

Depende totalmente de lo que el atacante quiera hacer, la infección en la computadora probablemente se logra mejor a través de un blog popular, aunque el último golpe en Magento estaba usando el error de robo de tiendas SUPEE-5344 previamente inyectado creado cuentas de administrador o las instalaciones de Magento aún no están parcheadas correctamente las diversas vulnerabilidades para inyectar el paquete de infección GuruIncSite en el pie de página de Magento. Magento es, por supuesto, de interés directo para el robo de información de clientes antiguos y de tarjetas de crédito.

Para reiterar, si un módulo de complemento para O Wordpress o Magento es vulnerable a un ataque, ambas aplicaciones pueden verse comprometidas.

O, si solo usas OpenSSL antes de Heartbleed, habrías sido vulnerable, es importante que todo el Stack esté asegurado, cualquier componente suelto puede darle a un hacker la base para atacar todo el sistema.

Referencia enlace

Creo que las mejores soluciones implican altos niveles de aislamiento (virtualización, espacios de memoria privada, máquinas separadas)