Dreamlab Technologies se caracteriza por realizar evaluaciones de seguridad en detalle, donde los consultores utilizan su vasta experiencia, conocimientos e instinto para identificar oportunidades de mejora en la postura de seguridad de sus clientes. Muchos de los casos corresponden a pentesting a infraestructuras internas y corporativas. Dichas infraestructuras representan en su mayoría activos críticos para cualquier organización, por lo que es necesario asegurar que las brechas de seguridad identificadas sean subsanadas. Pero ¿qué sucede con las observaciones que no fueron identificadas por un escáner de vulnerabilidades o que no fueron remediadas ya que no existe un parche de seguridad? En este artículo, expondremos algunas de estas cuestiones que el equipo consultor ha observado a lo largo de las diferentes experiencias.
Cuando se habla de infraestructuras internas, lo primero en que se piensa es en diagramas de red interminables con cientos o miles de equipos y servidores interconectados entre sí, servicios desplegados, bases de datos, etc. A esta idea se le agrega el factor humano y los funcionarios que trabajan en las distintas áreas. Para un atacante, conocer esta interconexión de equipos, servicios y personas es una mina de oro de información, ya que podría estudiar qué personas realizan acciones sobre qué servidores y equipos, determinar cuáles son los recursos que se comparten entre áreas y dónde se encuentran ubicados lógicamente, para buscar y determinar vulnerabilidades en estos flujos de información.
Ahora, cuando se reflexiona sobre la búsqueda de vulnerabilidades realizada por un atacante, el escenario más común es el escaneo de puertos y servicios, con el fin de identificar las versiones de software en ejecución y de buscar algún exploit público que permita vulnerar el sistema asociado. En caso de identificar algún exploit funcional, la contramedida común es la actualización del software a su última versión o aplicar algún parche de seguridad provisto por el fabricante. Esta tarea muchas veces es automatizada y logra mantener a los sistemas seguros; pero ¿qué sucede con las malas prácticas de seguridad en el manejo de la información?
Como miembro del equipo consultor de Dreamlab Technologies, parte de las evaluaciones que se realizan se enfocan en la búsqueda de configuraciones deficientes de seguridad o en malas prácticas a nivel operativo. Esta elección permite identificar debilidades que no están asociadas a un parche de seguridad o a una actualización en especial, sino a una práctica común en las organizaciones en la cual, si bien a nivel operativo se funciona de manera excelente, se deja la puerta abierta para que atacantes puedan aprovecharse de la «funcionalidad esperada» para obtener acceso a información privilegiada.
Estas maneras de operar se ven reflejadas en incidentes recientes, donde compañías muy reconocidas fueron vulneradas debido a malas prácticas de seguridad, pese a tener todos los sistemas operativos actualizados, antivirus y EDR. Durante estos incidentes, el acceso se realizó a través del uso de credenciales que fueron comprometidas de alguna u otra manera; este acceso permitió a los actores de amenaza interactuar con recursos internos, con los que llegaron a identificar un directorio compartido con scripts que contenían credenciales de acceso a sistemas críticos. Este acceso llevó al compromiso de credenciales privilegiadas de otros sistemas de control, lo cual condujo al compromiso total de las entidades.
El caso anterior es un ejemplo significativo sobre cómo las malas prácticas de seguridad pueden tener consecuencias severas y deberían ser atendidas de manera inmediata, pero ¿cómo se pueden identificar estas malas prácticas si, en muchos casos, estas configuraciones requieren validación manual?
Sobre la base de la experiencia, se recopiló una lista de las malas prácticas y vulnerabilidades más comunes.
1) Credenciales almacenadas en texto claro
Muchas veces, en un ejercicio, se identifica alguna vulnerabilidad o configuración defectuosa que otorga acceso a uno o más equipos internos, ya sea servidores o estaciones de trabajo. Si se llega a acceder a un servidor, lo más común es buscar qué software tiene instalado y dónde. En muchos casos, se almacenan credenciales de usuarios de base de datos de dominio en su fichero de configuración (web.config). Si bien el uso de este fichero no es una mala práctica, la falta de cifrado en él sí lo es.
Algo similar sucede en las estaciones de trabajo, en las que suele identificarse a usuarios que guardan información en rutas comunes, como Escritorio, Mis Documentos, Descargas. Muchas veces se identifica el famoso fichero «contraseñas.txt» o «accesos.txt», los que otorgan al equipo consultor nuevas rutas de explotación.
La recomendación, en estos casos, es promover el uso de gestores de contraseñas, siempre recomendando que la contraseña maestra para el gestor no esté en un fichero de texto en la misma ruta, la cual es otra mala práctica que se ha observado.
2) Credenciales de baja complejidad o por defecto
Este es un problema que afecta a gran parte del mundo, sin importar el continente, ya que es más fácil para un funcionario recordar que su contraseña es «Abril2024» que «&p4$$w0Rd&SUp3r&53gUr0&» y, definitivamente, más fácil de escribir en una terminal. Las campañas de concientización son una de las contramedidas sugeridas, pero el problema persistirá hasta que no se cambie la mentalidad de las personas, y a una verdadera toma de conciencia del peligro de utilizar contraseñas fáciles o relacionadas con las corporaciones o el año en curso.
Este problema llega a escalar cuando se definen credenciales sencillas para cuentas de dominio asociadas a servicios críticos o cuentas privilegiadas. Muchas veces se comienza con el servidor de pruebas que llega a funcionar tan bien que pasa a producción de manera directa, y se mantienen las credenciales de baja complejidad como «root:Temporal1».
Otro caso es sobre servicios críticos que están en ejecución por años o hasta décadas, donde la contraseña se definió en el año 2000. Desde ese punto hasta la actualidad, se avanzó tanto con la tecnología de la entidad y se generaron tantas nuevas relaciones con este sistema que realizar un simple cambio de contraseña puede llegar a ser un proyecto de actualización de toda la infraestructura interna que puede durar meses. Lo recomendado en estos casos, es reforzar la política de gestión de contraseñas, con tecnología que soporte los requerimientos. Si no se puede considerar el cambio de la contraseña, se deben aplicar medidas estrictas de segmentación de red, utilizar equipos pivotes fuera de dominio y de uso exclusivo para la gestión y soporte de estos sistemas, así como monitorear cualquier intento de acceso a estos sistemas a través de un SIEM.
Similar al caso anterior, es bastante común identificar sistemas desplegados hace tiempo que no cambiaron la configuración por defecto y en los que realizar el cambio de contraseñas puede extenderse como un proyecto mucho más grande: el cambio de contraseña por defecto en una base de datos representa la necesidad de actualizar los parámetros operativos de cientos de servicios internos, sin antes realizar pruebas de funcionalidad. Sin embargo, estos cambios muchas veces son necesarios, ya que lo primero que probaría tanto el equipo consultor como un actor de amenaza son las credenciales mencionadas en la documentación oficial.
3) Uso de cuentas privilegiadas para el despliegue de servicios
Este caso se encuentra con frecuencia. En él se identifican servicios o aplicaciones web que utilizan, en muchos casos, cuentas de administradores de dominio para conectarse a una base de datos o para ejecutar una instancia de motor de base de datos. Incluso se llegan a ver impresoras que utilizan una cuenta de administrador de dominio para conectarse a un directorio compartido y almacenar documentos escaneados. Una manera rápida para obtener credenciales privilegiadas es a través de los tickets SPN del dominio, asociados a servicios desplegados utilizando cuentas de dominio. Combinando este nivel de privilegios con el uso de credenciales de baja complejidad, se llega a obtener el control sobre un dominio interno en múltiples ocasiones.
Otro caso similar es cuando se obtiene el control administrativo sobre servidores de aplicaciones, ya que se puede extraer los contenidos del proceso LSA y, en muchos casos, obtener las credenciales en texto claro de las cuentas utilizadas para desplegar los servicios (este proceso es ligeramente distinto al volcado del famoso proceso LSASS.exe). Este caso se ve con frecuencia en instancias MSSQL, que almacenan la contraseña del usuario que despliega el servicio en texto claro.
Si bien el uso de cuentas con privilegios elevados (administrador de dominio, servidores o servicios) evita en muchos casos que se tengan problemas relacionados con permisos y privilegios en el despliegue de un sistema, es un riesgo bastante grande que debe ser atendido de manera inmediata. La recomendación es el uso de cuentas de dominio creadas específicamente para el despliegue de cualquier servicio interno, que no tengan más privilegios de los necesarios y definitivamente no sean administradores de dominio.
4) NTLM Relaying y Coerce Authentication
NTLM Relaying y Coerce Authentication son dos vulnerabilidades un poco más técnicas que permiten a un atacante forzar la autenticación de un usuario o servidor hacia el equipo actor de amenaza. El usuario es reenviado hacia otro recurso, lo cual permite al atacante personificar al primer objetivo: el servidor (S) se autentica hacia el actor de amenaza (A) y este reenvía la autenticación hacia el recurso (R); por ende, A obtiene acceso a R utilizando la cuenta de S, como se ve en el siguiente diagrama:
Situación inicial
Existen numerosos escenarios de explotación, pero algunos de los más populares son las vulnerabilidades PetitPotam y PrivExchange: ambos utilizan una técnica de Coerce Authentication para completar la cadena de explotación. Es decir, usan un script para forzar la autenticación del ADCS, en el caso de Petit Potam o un servidor Exchange, en el caso de Privexchange y, junto a un Relay, llegan a explotar las vulnerabilidades mencionadas.
La contramedida sugerida para temas de Relay es la implementación de SMB Signing, en la totalidad de los equipos, lo cual evitaría que los equipos reconozcan como válida una autenticación enviada a través de un Relay.
Para Coerce Authentication, las contramedidas sugeridas son un poco más complicadas de implementar, ya que si bien en algunos casos se puede aplicar un parche de seguridad, en otros es necesario restringir funcionalidades en la tecnología RPC, según la técnica utilizada. Otra contramedida es la segmentación de red y restringir la visibilidad desde ciertos servidores hacia segmentos de usuarios.
5) Problemas con el ADCS (Active Directory Certificate Services)
Muchas infraestructuras internas cuentan con un ADCS, lo cual les permite gestionar sus propios certificados digitales; sin embargo, como equipo consultor, se observaron múltiples instancias donde las plantillas de certificados digitales no contaban con las protecciones necesarias para evitar el abuso de la funcionalidad interna. En muchos casos, se observó que cualquier usuario autenticado tenía permisos de enrolamiento para una plantilla específica. Esto permitiría a este usuario de bajos privilegios personificar a un administrador de dominio y obtener un certificado digital a su nombre, que a su vez puede ser convertido en un ticket de Kerberos y obtener su hash NTLM utilizando esta información.
Existen trece (13) escenarios distintos (ESC1 al ESC13) de explotación, por lo que existen contramedidas específicas para cada uno. Sin embargo, una contramedida general es asegurarse de que los usuarios de bajos privilegios no tengan permisos de enrolamiento sobre plantillas críticas.
6) Shadow Admins
Los Shadow Admins son prácticamente usuarios, grupos o equipos de dominio que no son parte de grupos privilegiados (Domain Admins, Administrators, Enterprise Admins, etc.), pero que, a través de permisos DACL, tienen el control sobre objetos asociados a estos grupos. Para entender la idea, se plantean los siguientes ejemplos:
Ejemplo 1
Usuario (U), Administrador (A), donde A pertenece al grupo de Domain Admins y U pertenece únicamente a Domain Users (grupo de bajos privilegios), pero se identificó que U tiene privilegios de ForceChangePassword sobre A.
Situación inicial
Esto implica que, si por alguna razón, un atacante compromete al usuario U, puede utilizar sus credenciales para modificar la contraseña del administrador A y obtener el control sobre el dominio interno, lo cual convierte a U en un Shadow Admin.
Explotación
Ejemplo 2
Usuario (U), Administrador (A), Grupo Domain Admins (DA), donde A pertenece al grupo de Domain Admins y U pertenece únicamente a Domain Users, pero se identificó que U tiene privilegios de AddMember sobre el grupo DA.
Situación inicial
Esta configuración implica que este usuario podría agregar a cualquier otro usuario del dominio o a sí mismo al grupo de Domain Admins y obtener los privilegios respectivos una vez que se realice la tarea, otorgando al usuario U los mismos privilegios del administrador A, lo que lo convierte nuevamente en un Shadow Admin.
Explotación
Sin duda existen más escenarios, y para identificarlos se pueden utilizar herramientas como Bloodhound, Jackdaw o similares, las cuales realizan consultas sobre los objetos del dominio interno e identifican estas configuraciones. La contramedida sugerida es eliminar este tipo de privilegios en caso de que no sean necesarios; pero si lo son, asegurarse de proteger la cuenta privilegiada a través de un doble factor de autenticación y con credenciales robustas, que no estén asociadas a servicios internos, etc.
Finalmente, si bien existen muchos otros escenarios de malas configuraciones en dominios internos, estos son algunos de los más comunes que se han observado durante los ejercicios y las recomendaciones propuestas son generales. Cada entidad deberá ajustar los cambios sugeridos para su propia infraestructura.
