- La defensa de red empieza por enumerar y priorizar activos, pero la superficie de ataque real se forma como un grafo de dependencias de seguridad entre los activos
- En vez de atacar de frente el activo más fuerte, los atacantes buscan rutas indirectas hacia activos de alto valor a través de estaciones de trabajo o rutas de administración débilmente protegidas
- En redes Windows, elementos como los métodos de inicio de sesión, las credenciales, los TGT de Kerberos, los hashes NTLM, las contraseñas locales de administrador compartidas y los scripts de inicio de sesión pueden convertirse en aristas del grafo
- Los defensores deben convertir la lista de activos en un grafo y reducir la conectividad con segmentación de infraestructura, silos de credenciales, privilegio mínimo, autenticación de dos factores y rotación de credenciales
- Como los atacantes aprenden la infraestructura real pieza por pieza, y no a partir de diagramas viejos, los defensores solo pueden sacar ventaja si entienden con más precisión las relaciones de conexión de la red actual
Lo que la defensa basada en listas pasa por alto
- Muchas defensas de red se descarrilan antes siquiera de entrar en contacto con el atacante, porque entienden mal el campo de batalla
- Los defensores se concentran en proteger activos, priorizarlos y ordenarlos por carga de trabajo y función de negocio
- Los servicios de administración de sistemas, las bases de datos de inventario de activos y las hojas de cálculo de BCDR están llenos de listas de activos
- Pero lo que en realidad deben manejar los defensores no es una lista de activos individuales, sino un grafo en el que los activos están conectados por relaciones de seguridad
- Los atacantes aterrizan en algún punto del grafo con técnicas como el spearphishing y luego se mueven por la red buscando sistemas vulnerables
- Este grafo no viene dado desde afuera: lo crean los propios defensores al diseñar y operar la red
Qué significa el grafo dentro de una red
- El grafo de una red es un conjunto de dependencias de seguridad que crea clases de equivalencia entre activos
- Hay cuatro grandes factores que influyen en el grafo
- El diseño de la red
- La forma en que se administra la red
- El software y los servicios que se usan en la red
- El comportamiento de los usuarios
- En el caso de los controladores de dominio, una sola ruta de administración débil reduce el nivel de seguridad de todo el conjunto de activos de alto valor
- Bob administra el controlador de dominio desde una estación de trabajo
- Si esa estación de trabajo no está protegida al mismo nivel que el controlador de dominio, el controlador de dominio también puede verse comprometido
- Otras cuentas con privilegios de administrador sobre la estación de trabajo de Bob también pueden comprometer a Bob y al controlador de dominio
- Esos administradores inician sesión, por motivos de trabajo, en una o más máquinas adicionales
- Si un atacante compromete una de ellas, aparece una ruta hacia el controlador de dominio
Six Degrees of Mallory: movimiento lateral siguiendo el grafo
- Un atacante puede esperar en una máquina comprometida y usar un dumper de contraseñas como mimikatz hasta que inicie sesión una cuenta de alto valor
- El clúster de la izquierda en el grafo de ejemplo es un único Terminal Server usado por cientos de personas
- Si el atacante compromete esa máquina, con el tiempo puede volcar las credenciales de muchos usuarios
- Una búsqueda en el grafo revela múltiples rutas hacia el High Value Asset
- Al comprometer el Terminal Server, también se puede comprometer a User46 y User128
- User46 es administrador de Machine2821, y User128 es administrador de Machine115
- Si se comprometen esas estaciones de trabajo, se puede comprometer a User1 y User34
- User1 y User34 son ambos administradores del High Value Asset
- Para proteger un High Value Asset, todos los elementos de los que depende deben protegerse con el mismo rigor que el High Value Asset, y juntos forman una clase de equivalencia
Relaciones que crean dependencias de seguridad
- En redes Windows, cuando un usuario realiza ciertos tipos de inicio de sesión, como Interactive o Terminal Server, sus credenciales quedan expuestas al robo si el host subyacente se ve comprometido
- Lo expuesto no son solo las credenciales, sino también equivalentes de inicio de sesión único como TGT de Kerberos y hashes NTLM
- Las dependencias de seguridad también se crean en relaciones administrativas cotidianas
- Cuentas locales de administrador que usan una contraseña compartida: al volcar la contraseña local de administrador de un sistema, puede usarse en otros hosts con la misma contraseña
- Servidores de archivos y servidores de actualización de software que contienen scripts de inicio de sesión ejecutados por muchos usuarios
- Servidores de impresión que entregan drivers de impresión a las máquinas cliente cuando se usan
- Autoridades certificadoras que emiten certificados válidos para inicio de sesión con smartcard
- Administradores de bases de datos capaces de ejecutar código en el contexto de un servidor de base de datos que corre como usuario privilegiado
- Las relaciones indirectas también forman parte del grafo
- Si una máquina vulnerable se ve comprometida, el atacante puede crear nuevas aristas en el grafo
- Si un usuario tiene cuentas con la misma contraseña en dos dominios sin relación de confianza, aparece una arista oculta entre los dominios
Cómo reducir el grafo desde la defensa
- El primer paso del defensor es convertir la lista de activos en un grafo para visualizar la red
- Después hay que podar el grafo, buscando aristas no deseadas que causan una gran explosión de conectividad
- Implementar segmentación de infraestructura y silos de credenciales
- Reducir el número de administradores y minimizar privilegios con técnicas Just-In-Time / Just Enough
- Usar autenticación de dos factores para mitigar ciertos desplazamientos por aristas específicas
- Aplicar una rotación de credenciales robusta para prepararse ante la toma de cuentas de usuario
- Revisar las relaciones de forest trust
Construir un modelo de la realidad mejor que el del atacante
- Al visualizar el campo de batalla, los defensores no deben cederle ventaja al atacante
- Los defensores pueden tener información completa sobre su propia red, mientras que el atacante debe aprenderla fragmento por fragmento
- El atacante no estudia modelos mentales inexactos, sistemas de inventario incompletos ni diagramas de red desactualizados, sino la infraestructura que existe en este momento
- Los defensores también deben administrar la red con base en la realidad para acercarse más a una mentalidad de defensa verdaderamente preparada
Para seguir leyendo
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices: Gerardo Richarte
- Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1 comentarios
Opiniones en Hacker News
Los atacantes suelen tener una sola misión, por ejemplo filtrar datos importantes, desestabilizar un objetivo o ransomware, y pueden explorar tan profundo como haga falta hasta cumplirla.
En cambio, los defensores tienen que rastrear muchas señales y vectores de amenaza al mismo tiempo, así que no les queda otra que pensar en listas, y además deben priorizar incluso los elementos sobre los que tienen que actuar por regulación.
A menos que los defensores estén colocados arbitrariamente por todo el grafo buscando actividad interesante, no veo cómo podrían pensar en grafos. Lo que propone el autor al final no serían más que señales dentro de una lista que el defensor tendría que contrastar.
Cuando los defensores adoptaron ese método, pudieron identificar ataques potenciales antes de que el equipo rojo los ejecutara. Un equipo inteligente adoptaría de inmediato, por ejemplo, la técnica de equipo rojo de rastrear AWS como grafo para encontrar rutas desde cuentas de bajo valor hacia cuentas de alto valor.
No es una cuestión de suma cero ni de un cambio radical, pero los defensores también pueden pensar más como atacantes y usar con más frecuencia herramientas de ataque para la defensa.
Entonces hay que proteger las rutas que llevan a ese objetivo, sin importar cómo sean esas rutas ni si se limitan al software.
Un atacante podría explotar un CVE para dejar el sistema de entretenimiento en denegación de servicio, pero es dudoso qué tan importante sería eso en la práctica.
La gran mayoría de los ataques reales se parece más a “veamos qué podemos encontrar y luego decidimos cómo usarlo”. Lo mismo ocurre con muchas actividades ofensivas como recopilación de información, operaciones de influencia y propaganda.
Los defensores usan listas porque tienen que gestionar cientos o miles de activos al mismo tiempo. Cuando hay que gestionar muchas cosas, uno hace listas, las revisa y aplica checklists.
Por supuesto, los defensores también deberían crear grafos de dependencias, pero primero tienen que hacer listas y comprobar que estén actualizadas, que asuman confianza limitada y que los recursos estén aislados; después pueden crear el grafo de dependencias.
Los defensores tienen que pensar tanto en listas como en grafos y gestionar una cantidad enorme de elementos; los atacantes solo necesitan mirar unas pocas cosas.
Si no tienes la visión para convertir la lista en un grafo, terminas con solo una lista de activos críticos y tapando, como en un juego de “whack-a-mole”, decenas de miles de rutas de acceso que no habías considerado.
Siento que este artículo se mete demasiado profundo. O quizá acierta en la razón, pero se equivoca en la causa. El trabajo del defensor no es la defensa en sí.
La ciberseguridad no es un partido deportivo con objetivos claros y equivalentes y posiciones que se alternan; es más bien un evento secundario y una distracción junto al otro negocio principal que el defensor realmente quiere hacer.
En cambio, todo el trabajo del atacante consiste en atacar sistemas. No hay otros objetivos, dueños secundarios ni consideraciones que debiliten el ataque.
La razón por la que el atacante gana es la misma por la que Microsoft lanza sistemas operativos mejor que Cisco. Para Cisco, un sistema operativo es un medio; para Microsoft, es el fin.
También explica por qué las empresas casi no son castigadas por el mercado cuando sufren una filtración de datos.
Los ciberataques sí tienen objetivos claros, como robo de datos o interrupción de servicios. Puede aplicar a actores inmaduros que solo quieren romper cosas y generar caos, pero si consideras actores estatales o delincuentes motivados por dinero, esa visión queda completamente errada.
Este artículo, más bien, siento que no profundiza lo suficiente :-)
Una “lista” es una representación abreviada de los componentes, y un “grafo” es una representación abreviada de la interoperación. La perspectiva de componentes es análisis; la perspectiva de interacción todavía no tiene una buena palabra, pero como dice el artículo, a menudo se convierte en la superficie de ataque.
Lo importante de los sistemas adaptativos complejos es que tienen componentes y un bus de mensajes, y ese bus proporciona la forma en que los componentes interoperan. Puedes atrapar hormigas una por una, pero si de verdad quieres detenerlas, tienes que eliminar su capacidad de dejar rastros de feromonas.
Ojalá hubiera una palabra como “análisis” para entender las formas de interoperación. ¿Algo como Gestaltysis?
Trabajé un tiempo en una empresa de ciberseguridad, pero no lograba poner en palabras por qué no me gustaba su producto y por qué el enfoque de esa empresa, y de buena parte de la industria, al final me parecía falso.
Ahora lo entiendo. Estábamos creando una herramienta para respaldar la práctica más inútil de la ciberseguridad: las listas de verificación a nivel organizacional.
En el centro de toda actividad hay listas y calendarios recurrentes. Hay que presentarse periódicamente y hacer lo que toca.
Por supuesto, estoy de acuerdo en que en la etapa de “lo que toca” hace falta un enfoque más profundo y mejor.
Es para poder decir: “Seguimos todas las listas de verificación y el software de seguridad no lo detectó, así que no fue culpa nuestra”.
Si a una empresa de verdad le importara la seguridad, contrataría un red team en vez de pagar por escáneres inútiles con una relación señal-ruido inferior al 1%.
Mira la aviación: los pilotos viven apoyándose en listas de verificación. Eso no garantiza que nunca vaya a haber problemas durante un vuelo, pero no seguir una lista de verificación o tomarla a la ligera es invitar al desastre. Esas listas se construyen sobre años de experiencia costosa.
Pero una lista que existe solo para decir “tenemos una lista de verificación”, o que no se revisa y actualiza periódicamente según las condiciones reales, no sirve de nada.
Muchas empresas entienden mal esto. Creen que la lista de verificación en sí es la seguridad, cuando en realidad es solo una herramienta para recordarte que debes seguir manteniendo algo que antes hiciste bien. En cuanto tratas la lista como el objetivo, te sales del camino.
Hablando como pentester, los atacantes tampoco necesariamente piensan en grafos.
Salvo BloodHound, no se me vienen a la mente muchas herramientas que usen grafos.
Tampoco se me ocurre que el “pensamiento en grafos” aplique en seguridad web. En cambio, la lista de ataques que hay que probar es enorme: https://portswigger.net/web-security/all-topics
Y lo que al final termina dentro de un informe de pentest no es un grafo, sino una lista de tareas: por ejemplo, firma SMB, no usar cuentas de administrador de dominio para administrar todas las máquinas, etc.
La principal razón por la que esta frase es popular es que acaricia el ego de la comunidad hacker: “nosotros somos los inteligentes y los defensores solo juegan con hojas de Excel”.
Dicho eso, hay algo de verdad. Los defensores pueden dedicar muchísimo tiempo a cosas poco importantes. Por ejemplo, aplicar manualmente el benchmark CIS en todos los servidores mientras se les escapan las frutas al alcance de la mano que sí les darían una postura de seguridad fuerte.
En muchas empresas, los defensores no son más que administradores de sistemas que no saben en qué enfocarse.
Un ejemplo que se me viene de inmediato es una cadena de bugs. Si juntas varias vulnerabilidades de nivel CVSS 4 a 7, pueden convertirse en un resultado de nivel 9.8, como ejecución remota de código completa. Conectar esos bugs es, en esencia, recorrer un grafo a través de elementos de compromiso.
BloodHound es excelente y es una buena herramienta visual para conceptualizar grafos de ataque, pero solo forma parte del proceso de entender un dominio objetivo desde la perspectiva del atacante.
La razón por la que en pentesting web no existe una herramienta tan limpia como BloodHound es que las cadenas de compromiso son difíciles de reducir simplemente a una herramienta. En AD, los límites de seguridad están más o menos entendidos y codificados, pero en una app web las cadenas suelen depender más de esa aplicación en particular que del framework subyacente.
Si un informe de pentest incluye elementos como firma SMB o “no administrar todo con cuentas DA”, es porque esos son nodos que brillan intensamente muy al inicio de la cadena de compromiso. En la práctica, muchas intrusiones ocurren así.
No es tanto que el pentester no entienda el pensamiento en grafos, sino que muchas veces el primer nodo del grafo ya implica, en la práctica, un compromiso total, así que no hay mucho motivo para seguir recorriéndolo.
Esto se parece más a una forma elegante de decir que el defensor tiene que proteger todos los puntos de entrada, mientras que al atacante le basta encontrar una sola debilidad.
Por ejemplo, me pregunto si se podría usar honeypots para devolver exploits de día cero al equipo del atacante. Tal vez sea algo diseñado intencionalmente en productos de Google, Microsoft y otros.
Sería ir en modo black hat total, con una especie de negación plausible, y hacer que los operadores de ransomware se coman ransomware.
Al escribirlo, suena como una corporación malvada y omnipotente de ciencia ficción, aunque esas empresas normalmente también llegan a asesinar enemigos.
He hecho respuesta a incidentes y también tengo experiencia en pentesting y red team. Aunque es una formulación abreviada, creo que es correcta hasta cierto punto, y no tiene por qué ser tan negativa como la presenta el texto.
La defensa se compone de varios elementos. Por ejemplo, desarrollar controles eficaces que reduzcan el riesgo y el impacto de incidentes de seguridad, identificar ataques y compromisos, y responder a incidentes. Las listas de estándares y respuestas funcionan bien.
La defensa también incluye decisiones de arquitectura en las que hay que pensar en grafos de red para diseñar esos controles. El campo defensivo también es diverso: arquitectura/ingeniería, gestión de riesgos, respuesta a incidentes, seguridad de aplicaciones, capacitación, inteligencia de amenazas, etc.
También es interesante que el autor insinúe que pensar la defensa como listas es un problema, y luego presente una lista de aspectos a considerar para mejorar la defensa.
La razón por la que los atacantes ganan es que, después de encontrar una debilidad, solo tienen que acertar una vez. Los defensores tienen que proteger todo al mismo tiempo.
Parece que cada red necesita al menos un honeypot para atrapar intrusos. Cosas como credenciales falsas de criptomonedas o depósitos falsos de contraseñas.