Escalada de privilegios

La escalada de privilegios es el proceso por el que un atacante consigue dentro de un sistema un nivel de acceso o de control mayor del que tenía al entrar. Empieza con privilegios bajos, los de un usuario corriente, busca una vulnerabilidad que le sirva (una configuración insegura, un permiso concedido de más, un fallo sin parchear) y la usa para sortear las restricciones que lo limitaban.

Una vez arriba, el movimiento siguiente es consolidar: mantener el acceso elevado, tapar el rastro y asegurarse de poder volver. De ahí que en un informe lo importante no sea el nombre de la cuenta que se alcanzó, sino qué pasó a ser alcanzable con ella.

La escalada tiene dos formas, y tratarlas como una sola es la razón de que los parques se defiendan de la equivocada.

La escalada vertical gana permisos que la cuenta no tenía: de usuario a administrador, de contenedor a anfitrión, de cuenta normal a administrador del directorio. La escalada horizontal se queda en el mismo nivel y llega a los datos de otro sujeto, que en una aplicación es una comprobación rota a nivel de objeto y en un directorio es tomar una cuenta del mismo rango que resulta tener algo que el atacante quiere.

Las rutas se dividen por capas. En una sola máquina, las aperturas clásicas son un servicio que corre con privilegios altos y cuyo binario o cuya configuración puede escribir una cuenta sin privilegios, una tarea programada que apunta a una ruta escribible, un orden de búsqueda que permite a un atacante colocar una librería donde la va a cargar un proceso privilegiado, un privilegio de token que permite suplantar, o un fallo del núcleo sin parchear. En un directorio, casi nada de esto es un exploit: son permisos delegados, grupos anidados, opciones de delegación de cuentas de equipo y plantillas de certificado que dejan al solicitante nombrar cualquier sujeto. En cloud es una identidad que puede modificar políticas, asumir un rol más privilegiado, o actualizar el código de una función que ya corre como uno.

El patrón es el mismo en los tres. Algo es escribible, asumible o modificable por una cuenta que no debería poder, y la plataforma está haciendo exactamente lo que dice la configuración.

El hallazgo que más escribimos no es una vulnerabilidad. Es un permiso concedido por un motivo que tenía sentido entonces y que nunca se retiró. Un grupo al que se le dieron permisos para restablecer contraseñas por un proceso del servicio de soporte, y que resulta incluir cuentas con permisos sobre el directorio. Un rol cloud al que se le dio permiso para adjuntar políticas durante una migración. Una cuenta de servicio metida en un grupo privilegiado hace años porque averiguar los permisos correctos habría llevado quince días.

Estas cosas se acumulan en silencio. Ninguna concesión suelta parece irrazonable en su ticket, y nadie vuelve a leer nunca la suma. El resultado es un grafo en el que existe una ruta desde cualquier usuario autenticado hasta el control total, compuesta enteramente por permisos que se concedieron a propósito. Por eso lo primero que hacemos en una prueba interna es dibujar el grafo, y por eso ese dibujo suele ser la página más valiosa del informe.

El segundo fallo recurrente es el local: las rutas escribibles. Un binario de servicio en un directorio donde pueden escribir los usuarios autenticados, una aplicación instalada bajo una ruta con permisos heredados, una tarea programada que ejecuta un script desde un recurso compartido. Las herramientas de gestión de configuración distribuyen esto de forma idéntica por todo un parque, lo que convierte un error de empaquetado en una escalada disponible en todas partes.

El tercero son los contenedores y el cloud, donde la frontera en la que la gente cree y la frontera que existe son distintas. Un contenedor que corre en modo privilegiado, o con una ruta del anfitrión montada, o con una capacidad que no necesitaba, es un proceso del anfitrión disfrazado. Una carga de trabajo cuya identidad puede modificar su propia política es un administrador que todavía no ha ejercido el derecho.

Cuatro palabras que se usan a la ligera. Las distinciones deciden a quién le toca arreglarlo.

Lo práctico está en la última fila. La escalada local deja telemetría de endpoint. La escalada de directorio deja eventos del plano de control. La escalada horizontal dentro de una aplicación no suele dejar nada, porque leer el registro de otro cliente es una petición correcta que devuelve un 200, y nadie registra qué objeto se devolvió.

Equiparar escalada con exploits. Casi todo lo que usamos es configuración. Parchear por sí solo no lo resuelve.

Auditar la pertenencia a grupos y parar ahí. Los permisos sobre objetos, la delegación y las rutas de asunción de rol son donde están los caminos, y ninguno aparece en una lista de miembros.

Conceder permisos amplios de forma temporal. Las concesiones temporales se vuelven permanentes porque no hay nada que las retire. Si la concesión no tiene fecha de caducidad, es permanente.

Suponer que un contenedor es una frontera de seguridad. Es una frontera de empaquetado y de recursos. Tratado como frontera de seguridad necesita configuración específica, y el escape de contenedor es la consecuencia rutinaria de no aplicarla.

Ignorar la escalada horizontal porque no da root. Leer los datos de todos los clientes no es un desenlace menor por el hecho de que no haya intervenido ninguna cuenta de administrador.

Dibuja el mapa antes de arreglar nada. Un grafo de permisos del directorio y del tenant cloud, calculado desde la posición de partida de un usuario corriente, te dice qué rutas existen. Casi todos los parques se sorprenden con su propio resultado, y las rutas más cortas suelen poder eliminarse en un par de semanas.

Aplica el mínimo privilegio a las máquinas con la misma seriedad que a las personas. Las cuentas de servicio que ejecutan un servicio necesitan los permisos de ese servicio. Las identidades de carga de trabajo necesitan las acciones concretas que realiza su código. Cualquier identidad capaz de modificar la política de identidad es un administrador y hay que contarla como tal.

En las máquinas, arregla las rutas escribibles de forma sistemática y no de una en una: audita los permisos de los binarios de servicio, de los directorios de instalación y de los destinos de las tareas programadas en todo el parque, porque lo que distribuyó el error lo distribuyó en todas partes. Mantén las líneas base de hardening aplicadas de forma continua, para que el estado que arreglaste sea el estado que permanece.

Para detectar, las señales útiles son concretas y de poco volumen. Cambios en la pertenencia a grupos privilegiados. Rutas nuevas de asunción de rol en un tenant cloud. Peticiones de replicación de directorio desde una máquina inesperada. Solicitudes de certificado cuyo sujeto no coincide con quien las pide. Creación o modificación de servicios fuera de una ventana de cambio. Cada una de ellas es rara en un parque sano, y eso las hace baratas de alertar.

La escalada aparece en un informe como un paso de una ruta, con tres partes anotadas: el estado anterior, la configuración o el permiso concreto que permitió el paso, y el estado posterior. Esa tercera parte decide la severidad, y la decimos en términos de qué pasó a ser alcanzable y no en términos del nombre de la cuenta.

La evidencia es la propia configuración, citada para que el equipo del cliente pueda verificarla, más la demostración mínima de que el paso funcionó. Cuando la escalada dependió de un permiso delegado citamos la entrada de control de acceso; cuando dependió de una ruta escribible damos la ruta y el permiso.

Separamos la escalada que exigía un parche de la que exigía un cambio de permisos, porque van a colas de trabajo distintas y porque la segunda clase es invisible para el proceso de gestión de vulnerabilidades del cliente. Un hallazgo que jamás va a aparecer en un escaneo merece señalarse como tal.

Esta es una de las dos preguntas para las que existe un proyecto interno, junto con el movimiento, y es lo que probar desde la posición de un usuario estándar está diseñado para establecer.

¿Qué diferencia hay entre escalada vertical y horizontal? La vertical gana un nivel de privilegio superior al que tenía la cuenta. La horizontal se queda en el mismo nivel y llega a los datos de otro sujeto. La vertical es lo que casi todo el mundo entiende por el término; la horizontal es más frecuente en aplicaciones web y muchas veces tiene un impacto mayor sobre los datos.

¿La escalada de privilegios la causa siempre una vulnerabilidad? No, y en los parques que probamos normalmente no. Casi todas las rutas que usamos son permisos concedidos a propósito, más rutas escribibles y opciones de delegación. Por eso parchear por sí solo no las cierra.

¿Cómo encontramos las rutas de escalada antes que un atacante? Calcula el grafo de permisos desde un punto de partida sin privilegios, tanto en el directorio como en el tenant cloud, y lee las rutas más cortas hasta tus roles más privilegiados. Después revisa la configuración de las máquinas buscando rutas de servicio escribibles en todo el parque y no sobre una muestra.

¿Un atacante siempre necesita escalar? No. Si los datos que quiere son alcanzables con el acceso que ya tiene, escalar es trabajo innecesario. Muchos incidentes no incluyen ninguna escalada, y por eso un parque que solo la vigila a ella no ve nada.