El escáner externo de Stoïk Protect puede detectar vulnerabilidades durante su análisis semanal. Éstas se muestran en la pestaña "Infraestructura" de Stoïk Protect.
Para acceder al contenido relacionado con una vulnerabilidad específica – descripción, recursos afectados, cómo corregirla – haga clic en ella en la lista a continuación:
Nota: al tratarse de términos técnicos informáticos, estos se presentan en su mayoría en inglés. Sin embargo, si hay alguna incomprensión, recuerde que nuestros equipos están aquí para resolver todas sus dudas.
Password authentication enabled
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
Subdomain takeover (Toma de control de subdominio)
Una explotación eficaz de este tipo de vulnerabilidad permite a un adversario reclamar y tomar el control del subdominio de la víctima.
La toma de control de un subdominio es posible en diversas aplicaciones, como Github, Shopify, Netlify, Wix y AWS S3 bucket.
Desde un punto de vista técnico
Este ataque se basa en los siguientes elementos:
- El registro del subdominio en el servidor DNS externo de la víctima está configurado para apuntar a un recurso/servicio/punto de acceso externo que no existe o no está activo. La proliferación de productos XaaS (Anything as a Service) y servicios en la nube públicos abre la puerta a numerosas posibles tomas de control por fuentes ajenas que deben ser monitoreadas.
- El proveedor de servicios que aloja el recurso/servicio/punto de acceso externo no gestiona adecuadamente la verificación de la propiedad del subdominio.
Si la toma de control del subdominio tiene éxito, es posible llevar a cabo una gran variedad de ataques (difusión de contenido malicioso, phishing, robo de información de cookies de sesión de usuarios, información de claves de acceso, etc.). Esta vulnerabilidad puede ser explotada por una amplia gama de registros de recursos DNS, incluidos A, CNAME, MX, NS, TXT, etc.
En términos de gravedad del ataque, la toma de control de un subdominio NS tiene el impacto más alto (aunque sea una de las menos probable), ya que un ataque exitoso podría llevar al control total de toda la zona DNS y del dominio de la víctima.
Para este ejemplo, vamos a estudiar la toma de control de un dominio de Shopify, aunque este escenario puede aplicarse a otras aplicaciones.
Cuando accedemos al subdominio vulnerable, vemos lo siguiente:
Esto puede ser utilizado por un atacante para desplegar archivos maliciosos o crear ataques de phishing que resulten creíbles, utilizando dominios válidos.
Remediaciones
- A corto plazo, en caso de que el subdominio vulnerable no se utilice con fines comerciales, recomendamos eliminar el registro DNS.
- A medio plazo, la gestión de la infraestructura como código (IaC) debería ayudar a evitar situaciones donde el subdominio se elimina pero el registro DNS asociado sigue existiendo.
CVE-2021-22205
Esta vulnerabilidad fue publicada por GitLab. Se refiere a un problema de seguridad en la gestión de imágenes a través de su biblioteca interna ExifTool. El envío de imágenes maliciosas conduce a la ejecución remota de código en el servidor que aloja el GitLab vulnerable.
Desde un punto de vista técnico
Esta vulnerabilidad se debe al paso de imágenes proporcionadas por el usuario a la versión integrada de ExifTool del servicio. Un atacante podría ejecutar comandos de forma remota como usuario de GitLab, debido a la mala gestión de los archivos DjVu por parte de ExifTool.
Si se explota, esta vulnerabilidad puede afectar al servidor subyacente que aloja la aplicación GitLab.
Como la vulnerabilidad permite al atacante tomar el control del servidor, el impacto puede llevar a una propagación lateral sobre los activos conectados dependiendo de la configuración de seguridad.
Esta vulnerabilidad puede encontrarse de manera pública en Internet. Una búsqueda rápida del término "CVE-2021-22205" lleva a este repositorio público en Github.
A partir de ahí, solo se necesita usar la prueba de concepto y ejecutar comandos, como en el siguiente ejemplo que enumera el contenido del directorio del servidor:
Consecuencias
- Desde un punto de vista cibernético, esto puede tener un impacto directo en la confidencialidad, integridad, disponibilidad y trazabilidad de los activos almacenados en el servidor. Como la explotación de la vulnerabilidad no requiere autenticación en la plataforma o servidor, su impacto es crítico y permite al atacante acceder al shell.
- Desde un punto de vista organizativo, la explotación de la vulnerabilidad provoca pérdidas financieras directas al afectar la seguridad de los activos de la empresa y requiere una investigación posterior por expertos en seguridad para asegurarse de que la red subyacente no haya sido comprometida.
Remediación
- A corto plazo, se debe implementar inmediatamente una restricción de acceso para limitar el acceso al servidor GitLab solo a los desarrolladores conocidos. GitLab es un servicio interno y no debería ser accesible desde Internet. Esto se puede lograr limitando las funcionalidades del servidor, por ejemplo, configurando archivos .htaccess para servidores Apache o creando reglas de filtrado en caso de que un firewall proteja al servidor.
- A medio plazo, las acciones anteriores pierden eficacia y se vuelven más complejas. La única remediación posible es actualizar GitLab a la última versión disponible.
Password Authentication Enabled (Autenticación por Contraseña Habilitada)
SSH (Secure SHell) es un protocolo de red que permite a los administradores acceder de forma segura a un ordenador de manera remota. Existen 2 métodos de autenticación para conectarse al servidor a través de SSH:
- Uso de una clave criptográfica: no puede ser adivinada por un atacante, ya que el archivo es complejo y largo.
- Combinación usuario/contraseña: la autenticación por contraseña tiene más probabilidades de ser eludida por piratas informáticos a través de ataques de fuerza bruta.
Si un hacker malintencionado logra descubrir la combinación de contraseña/identificador, puede obtener derechos de administrador y acceder a los datos en el servidor. Así, podría hacer que estos datos sean inaccesibles o robarlos.
Desde un punto de vista técnico
SSH es un protocolo utilizado principalmente para la administración de máquinas Linux. Permite, entre otras cosas, acceder de forma remota a un pseudo-terminal, lo que significa que la compromisión de SSH en un servidor a menudo implica la compromisión del servidor en su totalidad.
Por defecto, SSH generalmente consulta el archivo de contraseñas de los usuarios del sistema, por lo que el acceso está protegido por las mismas contraseñas que se requieren para iniciar sesión localmente en la máquina o cambiar de usuario una vez conectado (con los comandos su o sudo, por ejemplo). Sin embargo, una contraseña puede ser suficiente para ralentizar a un atacante que ya cuenta con acceso inicial al servidor, pero es muy insuficiente frente a la multitud de hackers.
Remediación
Este documento tiene como objetivo detallar cómo reemplazar el acceso por contraseña por un acceso mediante clave criptográfica. Pero antes de continuar, es importante recordar que si has expuesto accesos SSH en máquinas cuando no es necesario o ya no lo es, la mejor protección es desactivar este servicio.
Si no es el caso y ya usas claves para conectarte, consulta este artículo, ya que también es necesario asegurarse de que el acceso por contraseña esté prohibido.
El primer paso consiste en generar un par de claves. La autenticación por clave SSH se basa en el principio de clave privada - clave pública, de modo que un servidor que posea la clave pública puede cifrar un desafío y asegurarse de que solo el titular de la clave privada puede descifrarlo, probando así su identidad.
Para ello, conéctese mediante SSH a su servidor y luego ingrese los siguientes comandos:
mkdir .ssh
cd .ssh
ssh-keygen -f my_new_ssh_key
Se le pedirá una contraseña. Esta servirá exclusivamente para cifrar su clave privada y se le solicitará antes de cada uso de la misma. Una buena contraseña ayuda a evitar que un tercero que haya obtenido su clave privada (en este caso, el archivo my_new_ssh_key) se conecte a su servidor. Esto constituye, por tanto, una forma de doble autenticación.
Su par de claves ha sido generado. my_new_ssh_key es su clave privada y my_new_ssh_key.pub es su clave pública. Ahora es necesario indicar al servidor que el titular de my_new_ssh_key.pub está autorizado a conectarse.
Para ello, ejecuta el siguiente comando:
Luego, copie el archivo my_new_ssh_key a su puesto de trabajo. Después, puede eliminar este archivo del servidor.
Tenga en cuenta que esta etapa de generación de claves y las instrucciones de configuración del lado del cliente que siguen deben ser realizadas por cada usuario que acceda al servidor.
Configuración del lado del cliente en Windows con PuTTY
Si utiliza una máquina con Windows y PuTTY para conectarse, deberá convertir su clave privada al formato adecuado. Para ello, ejecute puttygen.exe (que normalmente se encuentra en la carpeta donde instaló PuTTY), seleccione Conversions > Import key, elija su clave privada y luego haga clic en "Save private key". A continuación se ilustra el procedimiento:
Es probable que, en su primer intento, vea el siguiente mensaje de advertencia:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/user/.ssh/my_new_ssh_key' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "/home/user/.ssh/my_new_ssh_key": bad permissions
Es su cliente SSH quien te advierte que su clave privada es legible por otros usuarios en su ordenador. Para solucionar esto, ejecute el siguiente comando:
3ª etapa: configuración del lado del servidor
La última etapa consiste en prohibir la conexión por contraseña. Sin esta etapa, lo que se ha hecho hasta ahora tiene poco interés para la seguridad, ya que conocer la contraseña de sesión es suficiente para conectarse.
Antes de continuar, asegúrese de que puede conectarse correctamente mediante SSH con su clave. Si desactiva el acceso por contraseña sin poder conectarte, puede quedarse fuera.
También debe ser administrador (root) para continuar. Si no es así, use su - o sudo su - para elevar los privilegios de su terminal.
Luego, abra el archivo /etc/ssh/sshd_config con su editor de texto. En este archivo, busque la opción PasswordAuthentication y cambie a no para que le quede la siguiente línea:
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
Ahora queda recargar la configuración de su servidor SSH para que tenga efecto. Si utiliza systemd como sistema de inicialización, ejecuta, siempre con privilegios de root, el siguiente comando:
systemctl reload sshd.service
No cierre su sesión SSH ahora, abra otro terminal en su cliente y pruebe a conectarse de nuevo. Si puede hacerlo, ha terminado: su servidor ahora solo aceptará claves criptográficas como medio de conexión. Si no es así, reactive la autenticación por contraseña.
Database publicly exposed (base de datos expuesta públicamente)
La exposición de una base de datos en Internet es intrínsecamente insegura:
- La autenticación por nombre de usuario/contraseña es débil y susceptible a ataques de fuerza bruta y pulverización de contraseñas. La doble autenticación es compleja de implementar.
- Si bien algunas bases de datos soportan el cifrado de las comunicaciones, la mayoría no lo hace y, por lo tanto, son vulnerables a la interceptación de las comunicaciones.
- Los ataques de denegación de servicio (DDoS) son fáciles de realizar.
- La gestión de usuarios es difícil; la mayoría de las empresas utilizan un solo usuario para conectarse a la base de datos.
- Las actualizaciones de parches son complicadas de instalar.
Desde un punto de vista técnico
En el caso de que un atacante logre adivinar una contraseña y acceder a la base de datos, podrá acceder a los datos almacenados y, potencialmente, al servidor que aloja la base de datos.
Desarrollar un script de fuerza bruta para el protocolo de la base de datos es bastante fácil; la parte complicada es adivinar la combinación de usuario/contraseña para conectarse. Según el tipo de base de datos, a menudo existe una cuenta predeterminada, como mysql o postgresql.
Consecuencias
- Desde un punto de vista cibernético, esto puede tener un impacto directo en la confidencialidad, integridad, disponibilidad y trazabilidad de la información almacenada en la base de datos.
- Desde un punto de vista organizativo, una conexión exitosa genera pérdidas indirectas para la empresa, ya que se deben implementar copias de seguridad para recuperar los datos perdidos o modificados.
Remediación
- A corto plazo, recomendamos implementar un firewall para establecer una lista blanca de direcciones IP autorizadas a conectarse a la base de datos.
- A medio plazo, el acceso a la base de datos debe realizarse a partir de una API pública. Se recomienda que la API se conecte, preferiblemente a través de un WAF (Web Application Firewall), a la base de datos. La API puede otorgar tokens con permisos específicos (vistas de la base de datos) y un tiempo de acceso. Estos tokens son fácilmente revocables y su base de datos es mucho más segura cuando está configurada correctamente. La API puede asegurarse fácilmente mediante TLS, listas blancas, MFA (autenticación multifactor) y otros controles, como bloquear a un usuario tras un determinado número de intentos fallidos.
Symfony FOSJsRoutingBundle
Desde un punto de vista técnico
Esta falla explota el complemento Symfony FOSJsRoutingBundle, que permite exponer el enrutamiento de la aplicación en el código JavaScript.
Para comenzar, usted puede acceder al bundle JsRouting con la siguiente URL:
{IMPACTED-ASSET}/js/routing
A continuación se muestra un ejemplo de resultado:
Un atacante puede deducir inmediatamente que la API expone el método sylius_admin_order_creation_order_create con el método GET. A continuación, puede comenzar a manipularlo para encontrar una vulnerabilidad explotable.
No hay consecuencias directas de este ataque, ya que se trata de un defecto de configuración que facilita la etapa de cartografía del atacante, pero aumenta considerablemente los riesgos de un ataque posterior.
A corto plazo, recomendamos restringir el acceso al directorio /js/routing a la aplicación que necesite un mapeo de las API disponibles (como una restricción de dominio o de IP, por ejemplo).
CVE-2018-15473
Esta vulnerabilidad permite la enumeración de usuarios, lo que facilita mostrar una lista de usuarios y credenciales del protocolo OpenSSH. En el caso de que el modo de autenticación por contraseña esté activado, el atacante puede enfocarse en las cuentas cuya existencia conoce y atacarlas mediante fuerza bruta hasta que logre conectarse.
Desde un punto de vista técnico
Esta vulnerabilidad afecta al protocolo OpenSSH en las versiones comprendidas entre 2.3 y 7.6. Debido a un mal manejo de los paquetes recibidos por el protocolo, un atacante puede enumerar a los usuarios válidos.
En la captura de pantalla a continuación, hemos logrado encontrar los usuarios 'root' y 'mail', que son válidos en el servidor. Esta información ayudará a los atacantes a elaborar ataques por fuerza bruta. Si el modo de autenticación por contraseña está habilitado, el atacante puede enfocarse en las cuentas cuya existencia conoce y atacarlas mediante fuerza bruta hasta lograr conectarse.
El código de explotación es público y accesible en Internet. El código utilizado aquí para la demostración está disponible en GitHub.
Consecuencias
- Desde un punto de vista cibernético, en el caso de que el atacante encuentre una combinación de nombre de usuario/contraseña válida, la seguridad del servidor de alojamiento se ve comprometida.
- Desde un punto de vista organizativo, la explotación de la vulnerabilidad y el descubrimiento de contraseñas válidas generan pérdidas financieras directas al afectar la disponibilidad de los activos de la empresa y requieren una investigación posterior por parte de expertos en seguridad para confirmar que la red no ha sido comprometida.
Remediación
A corto y medio plazo, la única forma de remediar esta vulnerabilidad es restringir el acceso al punto de extremo SSH a direcciones IP específicas, lo que resulta difícil de mantener a largo plazo, o actualizar el protocolo SSH a la versión más reciente (recomendado).
Volver al menú principal de página
Symfony-profiler
Symfony es un framework de aplicación de código abierto utilizado para aplicaciones PHP. Cuando la aplicación se despliega en modo desarrollo, Symfony activa un componente de depuración llamado "web profiler". Este componente ofrece numerosas funcionalidades a los desarrolladores para inspeccionar la aplicación en tiempo de ejecución. Sin embargo, muchos datos pueden ser extraídos del profiler por parte de atacantes: rutas, cookies, identificadores, archivos, etc.
Desde un punto de vista técnico
Esta vulnerabilidad puede afectar al servidor subyacente que aloja el framework Symfony, así como a los componentes de la aplicación que interactúan si se encuentran credenciales.
Usted puede acceder al panel de control del profiler Symfony con la siguiente URL:
{IMPACTED-ASSET}/app_dev.php/_profiler/vide/recherche/résultats?limit=10
Desde Symfony 3.x, el Web Profiler permite leer los archivos de la aplicación en el directorio raíz. Esta funcionalidad es utilizada por los desarrolladores para identificar rápidamente el código fuente responsable del procesamiento de una solicitud. Sin embargo, puede ser utilizada de manera malintencionada para leer archivos de configuración:
Es posible leer archivos de configuración de la aplicación que contienen potencialmente secretos técnicos (credenciales de base de datos, tokens de sesiones de aplicación).
Consecuencias
- Desde un punto de vista cibernético, en el escenario en el que el atacante obtenga credenciales válidas, el impacto puede variar desde la confidencialidad de detalles técnicos hasta la compromisión de la información de la base de datos.
- Desde un punto de vista organizativo, el impacto de la vulnerabilidad puede llevar a pérdidas financieras directas debido a la alteración del contenido de la base de datos comprometida o del servidor subyacente.
Remediación
Basta con desactivar el modo de depuración modificando el archivo de configuración de Symfony:
# app/config/config.yml
framework:
profiler:
enabled: false
SQLMap: SQL Injection
Un ataque por inyección SQL, o SQLI, consiste en explotar las vulnerabilidades de software de una aplicación web con el objetivo de robar, eliminar o modificar datos, así como obtener control sobre los sistemas que ejecutan las aplicaciones infectadas. Estas ataques, aunque fáciles de contrarrestar, son igualmente sencillos de implementar.
La información comprometida puede incluir una gran cantidad de elementos, como datos sensibles de la empresa, tales como nombres de usuario y contraseñas, detalles personales del usuario o incluso datos privados de los clientes, como información relacionada con tarjetas de crédito.
El impacto de la inyección SQL sobre una empresa es considerable. Un ataque exitoso puede llevar a la consulta no autorizada de listas de usuarios, la eliminación de tablas enteras y, en algunos casos, la obtención por parte del atacante de derechos de administración sobre una base de datos, lo cual es extremadamente perjudicial para una empresa.
Desde un punto de vista técnico
La inyección SQL es un vector de ataque común que utiliza código SQL malicioso para manipular una base de datos subyacente y acceder a información que no estaba destinada a ser visible.
Consecuencias
- Desde un punto de vista cibernético, esto puede tener un impacto directo en la confidencialidad de los datos. Todos los datos almacenados en la base de datos están comprometidos y, dependiendo de la configuración, pueden obtenerse otros accesos, como la ejecución de código en el servidor que aloja la base de datos. Dado que la explotación de la vulnerabilidad no requiere autenticación en la aplicación, su impacto es crítico.
- Desde un punto de vista organizativo, la explotación de la vulnerabilidad puede generar pérdidas financieras indirectas al afectar la confidencialidad de los datos almacenados, lo que puede resultar en consecuencias públicas y en una pérdida de confianza. Además, el acceso a todos los servicios que dependen de la base de datos afectada podría estar potencialmente indisponible hasta que se mitigue el ataque, lo que puede resultar en tiempos de inactividad significativos.
Remediación
- Establecer una API con declaraciones parametrizadas: el paso de la entrada directa a través de una aplicación web a la utilización de una API segura es la forma más segura de abordar una inyección SQL. Esto evita llamar al intérprete SQL utilizando, en su lugar, llamadas preestablecidas. La creación de una API parametrizada es la mejor manera de mitigar los ataques por inyección SQL.
- Implementar el escape de caracteres: si no se dispone de una API, sus aplicaciones web deben ser capaces de escapar caracteres especiales (es decir, todos los caracteres que impactan en la sintaxis de los lenguajes SQL). Esto debe considerarse como una última línea de defensa, ya que el escape de caracteres no es adecuado para enfrentar todas las situaciones. Además, la propia aplicación web puede intentar escapar las consultas, pero dependiendo de cómo se procesen las consultas, puede resultar aún más difícil evadirlo.
Volver al menú principal de página
CVE-2022-23808
Esta vulnerabilidad afecta a phpMyAdmin, una herramienta de administración libre y gratuita para MySQL y MariaDB. Como aplicación web portátil escrita principalmente en PHP, se ha convertido en una de las herramientas de administración de MySQL más populares, especialmente para servicios de alojamiento web.
Desde un punto de vista técnico
Esta CVE fue descubierta en el panel de administración de la base de datos de phpMyAdmin en las versiones 5.1.1 a 5.1.2. Debido a la necesidad de estar autenticado en el panel de administración, no pudimos explotar esta vulnerabilidad. Sin embargo, están disponibles detalles públicos en GitHub.
Consecuencias
- Desde un punto de vista cibernético, es posible desencadenar una vulnerabilidad XSS (Cross-Site Scripting), donde una entrada de usuario malintencionada conduce a la ejecución de JavaScript en el navegador de la víctima. La explotación de la vulnerabilidad XSS puede resultar en la usurpación de identidad de un usuario o el robo de su cuenta en la plataforma phpMyAdmin.
- Desde un punto de vista organizativo, un usuario autenticado podría explotar la falta de saneamiento de entradas de usuario y hacerse pasar por una cuenta con privilegios elevados. El uso de estas cuentas privilegiadas puede llevar a pérdidas financieras indirectas.
Adjuntamos un diagrama para comprender mejor las XSS:
Remediación
La única manera de remediar esta vulnerabilidad es actualizar la plataforma phpMyAdmin a la última versión disponible.
Volver al menú principal de página
Wordpress-accessible-wpconfig
El archivo wp-config es uno de los más importantes de WordPress. Este archivo de configuración puede contener información clave, como la conexión a la base de datos. Si este archivo es accesible, la confidencialidad y la integridad de los datos pueden verse comprometidas.
Desde un punto de vista técnico
El archivo wp-config generalmente se encuentra en https://wordpress-path/wp-config.php.
Remediación
La solución es restringir el acceso al archivo, como se indica en este artículo.
Para un servidor Apache:
- Abra el archivo .htaccess con un editor de texto.
- Integre las siguientes líneas de código al final del archivo .htaccess:
# Deny access to wp-config/php
<Files wp-config.php>
Order allow,deny
Deny from all
</Files>
Para otros servidores de aplicaciones relacionados, consulte el manual del archivo de configuración (por ejemplo, el archivo de configuración de nginx se encuentra en /usr/local/nginx/conf en un servidor Unix):
/location ~ /(wp-config.php) {
deny all;
return 404;
}
...
Laravel env.
El archivo .env contiene los secretos cargados desde el código fuente en el entorno de producción o de desarrollo. Nunca debe ser desplegado en producción, ya que contiene secretos de desarrollo que podrían ser reutilizados en producción.
Desde un punto de vista técnico
Aquí hay un ejemplo de archivo .env:
Una comprometida del archivo .env amenaza directamente cada activo involucrado en las credenciales del archivo. Generalmente, se puede encontrar en la ruta https://web-server-path/.env.
Consecuencias
En el caso de que las credenciales brinden acceso al repositorio de código público, la confidencialidad y la integridad del código fuente pueden verse comprometidas. Estos archivos también pueden contener credenciales para bases de datos. Este escenario, combinado con una base de datos expuesta públicamente, puede tener un impacto directo en los datos almacenados.
Remediación
Se presentan dos soluciones:
- Restringir el acceso al archivo modificando el archivo de configuración del servidor. La modificación del archivo .htaccess, como en el siguiente código, restringirá el acceso al archivo .env:
# Deny access to .env
<Files .env>
Order allow,deny
Deny from all
</Files> - Eliminar el archivo desplegado, ya que ningún archivo .env debe ser desplegado, independientemente de si su acceso está restringido o no.
CVE-2021-34473
Esta vulnerabilidad, también conocida como Proxyshell, es la combinación de 3 CVE:
- CVE-2021-31207: eludir el control de acceso;
- CVE-2021-34523: escalada de privilegios en el backend del servidor Exchange;
- CVE-2021-34473: ejecución de código remoto en el servidor a través de la escritura de archivos arbitrarios.
Desde un punto de vista técnico
La explotación puede realizarse utilizando código público. Las búsquedas realizadas en navegadores web conducen a fuentes de código accesibles en GitHub.
Es posible probar el primer paso de la explotación ejecutando el script Python proxyshell_enumerate, que nos proporcionará la lista de direcciones de correo electrónico del servidor de correo:
Esta etapa prueba que el servidor Exchange es vulnerable al exploit, y que también es posible la ejecución de código remoto.
Consecuencias
- Desde un punto de vista cibernético, un atacante que interactúe con el servidor Exchange afectado puede obtener privilegios de administrador local en el servidor. Dado que el servidor de correo Exchange a menudo opera con privilegios de administrador de dominio, todo el dominio de Active Directory corre el riesgo de ser comprometido.
- Desde un punto de vista organizativo, la explotación de la vulnerabilidad conlleva pérdidas financieras directas e indirectas al otorgar a un atacante acceso privilegiado a la red.
Remediación
La única forma de remediar esta vulnerabilidad es actualizar la versión del servidor Exchange. Dado que esta vulnerabilidad ha sido activamente explotada, recomendamos consultar a profesionales de ciberseguridad para asegurarse de que la red no ha sido comprometida.
Volver al menú principal de página
WordPress Core < 4.7.1 - Username Enumeration (CVE-2017-5487)
La enumeración de usuarios permite mostrar una lista de usuarios de la cuenta de WordPress. Un hacker malintencionado puede intentar realizar un ataque de fuerza bruta para encontrar las contraseñas asociadas a las cuentas de usuario, lo que puede llevar a la comprometimiento de cuentas de WordPress.
Desde un punto de vista técnico
Remediación
- Si está utilizando una versión de WordPress < 4.7.1, debe actualizar WordPress a través del panel de administración a la última versión disponible.
- Si su versión de WordPress está actualizada, la solución es instalar un plugin de seguridad llamado "Disable REST API".
-
- Desde su panel de control de WordPress, vaya a "Añadir un plugin";
- Busque el plugin "Disable REST API" o "iThemes Security" (u otros con buenas reseñas sobre el mismo tema);
- Instale y active el plugin.
Volver al menú principal de página
CVE-2020-9490
Esta vulnerabilidad puede permitir a un hacker malintencionado desencadenar un ataque de denegación de servicio (DDoS), lo que puede afectar la disponibilidad de su infraestructura.
Desde un punto de vista técnico
Esta vulnerabilidad es un ataque de denegación de servicio que afecta a los servidores Apache HTTPD en versiones anteriores a 2.4.46. Al fabricar encabezados HTTP especiales (Cache-Digest), un atacante puede comprometer un servidor HTTPD vulnerable.
Consecuencias
- Desde un punto de vista cibernético, puede haber un impacto directo en la disponibilidad del servidor vulnerable. La explotación de la vulnerabilidad no requiere autenticación, lo que la hace aún más fácil de implementar.
- Desde un punto de vista organizativo, si el servidor aloja una aplicación utilizada en producción, la explotación llevará a pérdidas financieras directas debido a la pérdida de actividad, ya que el activo estará fuera de servicio e intentará reiniciarse cada vez que la explotación tenga éxito. Todos los sitios web alojados en la máquina afectada serán inaccesibles.
Remediación
Se debe actualizar el servidor HTTP Apache a la última versión disponible lista para producción (versión 2.4.54 publicada el 06-08-2022).
Volver al menú principal de página
Directory-listing
Una lista de directorios proporciona a un atacante el índice completo de todos los recursos dentro del directorio. Los riesgos y consecuencias específicas varían dependiendo de los archivos listados y accesibles.
Stoïk solo revela esta vulnerabilidad cuando los archivos afectados son:
- El código fuente de la aplicación;
- Nombres de usuario, contraseñas o hashes;
- Datos personales de los usuarios (datos bancarios, identificaciones, currículums).
Desde un punto de vista técnico
No hay ningún comando que ejecutar; se accede a un índice de directorio para listar los archivos. La mayoría de ellos se encuentran en instancias de WordPress, como /wp-content/uploads.
Consecuencias
La exposición del contenido de un directorio puede permitir a un atacante acceder al código fuente o proporcionar información útil para diseñar exploits, como las horas de creación de los archivos o cualquier información que pueda estar codificada en los nombres de archivo. La lista de directorios también puede comprometer datos privados o confidenciales.
Remediación
En Apache, debe agregar código al archivo .htaccess de su sitio para desactivar el listado de directorios.
Para acceder al archivo, necesitará un cliente FTP. De lo contrario, puede usar la aplicación de gestión de archivos en su panel de control de alojamiento de WordPress. Después de conectarse a su sitio, simplemente abra la carpeta pública de su sitio web y encuentre el archivo .htaccess. Puede modificar el archivo .htaccess descargándolo a su escritorio y luego abriéndolo en un editor de texto como el Bloc de notas.
Al final del archivo, agregue el siguiente código:
Esto aparecerá así:
Una vez que haya terminado, guarde su archivo .htaccess y súbalo a su servidor utilizando un cliente FTP.
Si su servidor web es diferente de Apache, puede consultar este artículo.
Volver al menú principal de página
Docker-compose.yml exposure
Docker Compose es una herramienta que permite definir y ejecutar aplicaciones Docker. La exposición de este archivo puede facilitar el acceso a toda la información necesaria para desplegar una aplicación. No es raro encontrar contraseñas y otros secretos en este archivo.
Desde un punto de vista técnico
Con Compose, los desarrolladores utilizan un único archivo de configuración (docker-compose.yml) para definir y ejecutar múltiples servicios de la aplicación. A veces, los desarrolladores envían por error este archivo a los entornos de producción. Dado que este archivo generalmente contiene toda la información necesaria para el despliegue de una aplicación, no es raro que contenga contraseñas y otros secretos.
Es posible acceder al archivo docker-compose a través de la siguiente URL en su navegador favorito: http://example.com/docker-compose.yml.
Consecuencias
Al acceder a un archivo docker-compose.yml expuesto, un atacante podría aprovechar la vulnerabilidad para obtener acceso no autorizado a información sensible. Si se encuentran contraseñas, se puede obtener acceso inmediato al servidor; e incluso si no hay secretos presentes, se pueden revelar datos importantes sobre los aspectos internos de la aplicación, permitiendo así a un actor malicioso elaborar un ataque dirigido.
Aquí hay un ejemplo:
Remediación
Se debe asegurar que el archivo docker-compose.yml no se despliegue junto con la aplicación o, al menos, que no esté expuesto en un directorio del servidor web, definiendo los permisos apropiados.
Si se divulga información sensible, como accesos, en el archivo expuesto, estas deben ser revocadas y restablecidas en los activos correspondientes.
Volver al menú principal de página
CVE-2022-41040
Esta vulnerabilidad, cuando se combina con la vulnerabilidad CVE-2022-41082, permite a un atacante autenticado desencadenar una ejecución de código remoto.
Desde un punto de vista técnico
Dos vulnerabilidades de tipo zero-day (que nunca han sido publicadas) afectan a Microsoft Exchange Server 2013, Exchange Server 2016 y Exchange Server 2019.
La primera, CVE-2022-41040, es una vulnerabilidad de tipo Server-Side Request Forgery (SSRF). La segunda, CVE-2022-41082, permite la ejecución de código remoto (RCE) cuando PowerShell es accesible para el atacante.
A fecha del 03/10/22, Microsoft tiene conocimiento de ataques dirigidos limitados que utilizan estas dos vulnerabilidades. En estos ataques, la vulnerabilidad CVE-2022-41040 puede permitir a un atacante autenticado desencadenar una ejecución de código remoto a través de la vulnerabilidad CVE-2022-41082. Cabe destacar que se requiere acceso autenticado al servidor Exchange vulnerable para explotar exitosamente cualquiera de estas vulnerabilidades.
Puede referirse a este artículo de Microsoft.
Consecuencias
- Desde un punto de vista cibernético, la explotación de estas dos vulnerabilidades permite la ejecución de código remoto en el servidor, a menudo lanzada con derechos de administrador. Un atacante puede, por lo tanto, obtener control total sobre el dominio o la red conectada al servidor Exchange.
- Desde un punto de vista organizativo, un atacante provocará pérdidas financieras directas e indirectas para la víctima, al afectar la disponibilidad y la integridad de la red.
Remediación
Para corregir esta vulnerabilidad, debe actualizar el servidor Exchange.
CVE-2022-35914
Esta vulnerabilidad explota una falla de actualización que permite escribir código malicioso de forma remota en su infraestructura.
Desde un punto de vista técnico
Esta vulnerabilidad afecta a los software GLPI cuando utilizan una biblioteca de terceros llamada htmlawed. Para reproducir la vulnerabilidad, hemos utilizado el PoC (Prueba de Concepto) disponible públicamente en GitHub.
El PoC está listo para usar y es muy sencillo de utilizar:
%20%5BEn%20fonction%5D%20-%20Oracle%20VM%20VirtualBox.png?alt=media&token=26c8db2e-2ff2-4c7c-8506-97b074a5a93a)
Consecuencias
- Desde un punto de vista cibernético, hay un impacto directo en la confidencialidad, integridad, disponibilidad y trazabilidad de los activos almacenados en el servidor. La explotación de la vulnerabilidad, que no requiere autenticación en la plataforma o el servidor, tiene un impacto crítico y permite un acceso directo al servidor de alojamiento.
- Desde un punto de vista organizativo, la explotación de la vulnerabilidad provoca pérdidas financieras directas al afectar la disponibilidad de los activos de la empresa y requiere una investigación posterior por parte de expertos en seguridad para asegurarse de que la red no ha sido comprometida.
Remediación
Para remediar esta vulnerabilidad, actualice el software GLPI a la última versión disponible.
Volver al menú principal de página
VMSA-2021-0002
Esta vulnerabilidad reside en la explotación de una falla en un sistema llamado ESXi. Puede permitir a un hacker malintencionado ejecutar código de forma remota y lanzar un ataque de tipo ransomware.
Desde un punto de vista técnico
Las múltiples vulnerabilidades, denominadas VMSA-2021-0002, afectan a varias versiones de VMware ESXi y vSphere Client. En particular, una de las vulnerabilidades es ampliamente explotada para penetrar en el sistema de información y desplegar un ransomware: la vulnerabilidad CVE-2021-21974.
La vulnerabilidad CVE-2021-21974 explota el hecho de que OpenSLP, tal como se utiliza en ESXi, presenta una vulnerabilidad de tipo "heap-overflow", lo que permite, a través de este medio, ejecutar código de forma remota con privilegios elevados en el ESXi, aprovechando el servicio asociado expuesto en el puerto 427.
Las versiones afectadas son las siguientes (y anteriores):
-
- ESXi 7.0 Update 1c (solo seguridad)
- Fecha de salida: 17/12/2020;
- Número de compilación: 17325020.
- ESXi 6.7 P04
- Fecha de salida: 19/11/2020;
- Número de compilación: 17167734.
- ESXi 6.5 EP 23
- Fecha de salida: 19/11/2020;
- Número de compilación: 17167537.
- Todas las versiones de ESXi 6.0.
- ESXi 7.0 Update 1c (solo seguridad)
Remediación
- A corto plazo, es posible desactivar el servicio SLP directamente en el ESXi, según la documentación de VMware.
- A moyen terme, il est recommandé de mettre à jour la dernière version de l'ESXi.