Cuando Apache o nginx sirve archivos estáticos, estos siguen enlaces simbólicos incluso en el caso de que un enlace apunte a un archivo propiedad de otro usuario del sistema (por ejemplo, uno correspondiente a otra suscripción). Esto permite a un atacante acceder a una suscripción para leer archivos de otra suscripción, incluyendo aquellos archivos que contienen contraseñas y parámetros de configuración de WordPress y otros CMSs.

Mitigación de la vulnerabilidad

Permisos del sistema de archivos

Si está usando WP Toolkit, la forma más fácil de mitigar la vulnerabilidad para sus instancias de WordPress es usar el Toolkit:

  1. Vaya a WP Toolkit.
  2. Seleccione todas las instancias de WordPress y haga clic en Comprobar seguridad.
  3. Verifique que se ha marcado «Permisos para archivos y directorios» como OK.
  4. En caso contrario, haga clic en Proteger.

Si no está usando WP Toolkit o si necesita proteger otros CMS que no sean WordPress, deberá corregir manualmente los permisos sobre todos los archivos que desee proteger denegando todos los permisos al grupo «Otros» ejecutando el siguiente comando:

chmod o-rwx <file_name>

Nota: No existe ninguna lista de archivos a proteger adecuada para todas las aplicaciones web o CMS. Los archivos exactos cuyos permisos deben cambiarse para proteger una aplicación web varían en función de la aplicación en cuestión.

Configuración de Apache

Este método de mitigación de la vulnerabilidad es apropiado para suscripciones que usen Apache como su servidor web (una suscripción usa Apache si el «modo proxy» está activado en Hosting y DNS > Configuración de Apache y nginx).

Nota: En Plesk Obsidian 18.0.30 y versiones posteriores, esta solución se aplica por defecto. En el caso de versiones anteriores de Plesk, siga las instrucciones que se detallan a continuación para mitigar la vulnerabilidad.

Para mitigar la vulnerabilidad, haga lo siguiente:

  1. Vaya a Planes de servicio > su plan > pestaña “Servidor web” (o su suscripción > Sitios web y dominios > Hosting y DNS > Configuración de Apache y nginx).
  2. Seleccione la casilla «Limitar la habilidad para seguir enlaces simbólicos».

Esta acción aplicada a un plan de servicio mitiga la vulnerabilidad para todas las suscripciones basadas en dicho plan de servicio (es decir, un atacante que obtenga acceso a una suscripción no podrá llevar a cabo ataques contra otras suscripciones). De aplicarse a una suscripción, solo se mitiga la vulnerabilidad para dicha suscripción.

Nota: Un sitio web que use enlaces simbólicos a sus propios archivos seguirá funcionando si no usa la opción “FollowSymLinks” en el archivo .htaccess, puesto que la opción “SymLinksIfOwnerMatch” viene activada por defecto. Si dicho sitio usa la opción “FollowSymLinks” en el archivo .htaccess, este dejará de funcionar.

Prudencia: De aplicar esta solución, seguirá siendo vulnerable a una condición “time-of-check to time-of-use” relacionada con la opción “SymLinksIfOwnerMatch” de Apache. Para mitigar dicha vulnerabilidad, puede aplicar este parche a Apache (este todavía no ha sido probado por Plesk, por lo que su aplicación queda bajo su propia responsabilidad) o bien usar una de las opciones de protección de enlaces simbólicos basadas en kernel descritas más adelante en este artículo.

Configuración de nginx

Este método de mitigación de la vulnerabilidad es apropiado para suscripciones que usen nginx para servidor archivos estáticos de forma directa (una suscripción usa nginx si el «modo proxy» está desactivado o si este está activado y «Servir archivos estáticos directamente a través de nginx» también está activado en Hosting y DNS > Configuración de Apache y nginx).

Para mitigar la vulnerabilidad, haga lo siguiente:

  1. Vaya a Planes de servicio > su plan > Servidor web (o su suscripción > Sitios web y dominios > Hosting y DNS > Configuración de Apache y nginx).
  2. Seleccione la casilla «Limitar la habilidad para seguir enlaces simbólicos».

Esta acción aplicada a un plan de servicio mitiga la vulnerabilidad para todas las suscripciones basadas en dicho plan de servicio (es decir, un atacante que obtenga acceso a una suscripción no podrá llevar a cabo ataques contra otras suscripciones). De aplicarse a una suscripción, solo se mitiga la vulnerabilidad para dicha suscripción.

Nota: Esta opción no es aplicable a equipos que ejecuten una versión 2.6.39 o anterior del kernel de Linux. Para mitigar la vulnerabilidad en este tipo de máquinas, le recomendamos actualizar el sistema operativo a la versión estable más reciente o usar uno de los kernels basados en el mecanismo de protección de enlaces simbólicos detallados a continuación.

SecureLinks en mod_hostinglimits para CloudLinux

En el caso de equipos que ejecuten CloudLinux, puede mitigar la vulnerabilidad activando el mecanismo de protección de coincidencia de propietario de enlace simbólico como parte del módulo HostingLimits para Apache. Si desea más información, consulte la documentación de CloudLinux.

KernelCare Symlink Protection patchset para CentOS 7 (disponible de forma gratuita)

En equipos que ejecuten CentOS 7, puede mitigar la vulnerabilidad instalando el Symlink Protection Patchset gratuito disponible a través de CloudLinux. Si desea más información, consulte la documentación de CloudLinux.

Grsecurity (un conjunto de parches para el kernel de Linux que enfatiza las mejoras de seguridad - requiere el pago de una suscripción)

Si ninguna de estas opciones puede aplicarse a su caso, puede instalar el conjunto de parches para la mejora de la seguridad grsecurity para el kernel de Linux kernel y configurar la prestación GRKERNSEC_SYMLINKOWN. Tenga en cuenta que el uso de grsecurity no es gratuito y requiere la compra de una suscripción anual.