Panorama: la máquina que reparte el poder#

Entre el hardware y los programas hay un árbitro: el sistema operativo. Su trabajo, mirado desde la seguridad, se puede resumir en una sola frase —administrar el privilegio y hacer cumplir el aislamiento—. Administrar el privilegio significa decidir qué puede hacer cada programa y cada usuario: leer este archivo, escribir en aquel, abrir un puerto, apagar la máquina. Hacer cumplir el aislamiento significa que un programa no pueda entrar en la memoria de otro, ni un usuario en los datos de otro, salvo cuando está explícitamente autorizado. Casi todo lo que el manual llamó escalada de privilegios, volcado de credenciales o evasión es, en el fondo, un intento de torcer una de esas dos funciones: conseguir más autoridad de la que corresponde, o esconderse de quien la vigila.

La razón por la que el sistema operativo puede arbitrar es que él corre en un nivel de privilegio que los programas no alcanzan. El procesador distingue, por hardware, al menos dos modos de ejecución: uno privilegiado, donde el código puede tocar el hardware y la memoria de cualquiera, y uno restringido, donde no. En ese modo privilegiado corre el núcleo (kernel), el corazón del sistema operativo; en el restringido corren los programas, en lo que se llama el espacio de usuario (user space). Esa separación —la frontera kernel/usuario— es el aislamiento primario del que dependen todos los demás. Si un atacante logra ejecutar código en el núcleo, no hay control por encima que lo detenga: se convierte en el árbitro.

Este capítulo recorre cómo dos familias de sistemas operativos —Windows y los de tipo Unix, con Linux como referente— implementan esa administración del privilegio, y por qué las técnicas ofensivas que el manual detalló son maniobras sobre estas estructuras. No repite esas técnicas; nombra el terreno que presuponen.

La frontera kernel/usuario: el aislamiento primario#

Cuando un programa necesita algo que solo el núcleo puede hacer —abrir un archivo, enviar un paquete, crear otro proceso— no lo hace directo: pide permiso al núcleo a través de una llamada al sistema (system call o syscall). La llamada al sistema es la única puerta legítima entre el espacio de usuario y el núcleo, y esa es exactamente la propiedad que la vuelve tan importante para la seguridad. Cada cruce de la frontera pasa por esa puerta, y cada puerta es un punto donde el núcleo puede validar quién pide qué. Es la mediación completa del capítulo de principios hecha hardware: no se confía en el programa, se lo obliga a pedir en cada operación.

flowchart TB
  subgraph U["espacio de usuario (modo restringido)"]
    P1["programa de usuario\nsin privilegio directo sobre el hardware"]
  end
  subgraph K["núcleo (modo privilegiado)"]
    KS["kernel — árbitro total\nmemoria, hardware, procesos"]
  end
  P1 -->|"syscall = la única puerta legítima\n(el kernel valida quién pide qué)"| KS
  P1 -.->|"escalada de privilegios =\ncruzar la frontera sin permiso"| KS

De esta estructura salen dos ideas que recorren toda la seguridad de sistemas operativos. La primera: la escalada de privilegios es, en esencia, cruzar esa frontera sin autorización —o moverse hacia arriba dentro del espacio de usuario, de una cuenta común a una administrativa, y desde ahí eventualmente al núcleo—. La Parte 3 recorrió el catálogo de cómo se logra ese cruce; aquí basta con ver que todos esos métodos apuntan al mismo lugar: llegar a donde el árbitro no tiene a nadie por encima. La segunda: como el núcleo lo ve y lo puede todo, un compromiso a nivel de núcleo —un rootkit, un controlador malicioso— es el más difícil de detectar, porque el atacante controla al mismo componente que debería delatarlo. Esa es la raíz de la tensión que la evasión explota: la defensa y el atacante pelean por quién tiene el punto de vista más privilegiado sobre la máquina.

El privilegio en Windows#

Windows construye su modelo de privilegio alrededor de dos objetos. El identificador de seguridad (Security Identifier, SID) es el nombre interno, único e inmutable, de cada principal de seguridad —un usuario, un grupo, un equipo—. Cuando se habla de «el administrador» o «los usuarios del dominio», por debajo son SID; y una cuenta puede renombrarse sin cambiar su SID, razón por la cual el SID, y no el nombre, es lo que de verdad identifica. El token de acceso (access token) es el otro objeto clave: cuando un usuario inicia sesión, el sistema le arma un token que contiene su SID, los SID de todos los grupos a los que pertenece y la lista de privilegios especiales que tiene. Cada proceso que lanza ese usuario lleva una copia de ese token, y el token es lo que el sistema consulta en cada acceso para decidir si permite o niega. Manipular tokens —robar el de un proceso más privilegiado, o duplicarlo— es una vía de escalada precisamente porque el token es la identidad efectiva del proceso.

Sobre esa base, Windows agrega los niveles de integridad (integrity levels): una etiqueta —bajo, medio, alto, sistema— que se asigna a procesos y objetos y que impone una regla adicional independiente de los permisos clásicos, un proceso de integridad baja no puede modificar un objeto de integridad más alta aunque los permisos se lo permitirían. Es lo que confina, por ejemplo, a un navegador comprometido. El control de cuentas de usuario (User Account Control, UAC) se apoya en esto: cuando un administrador inicia sesión, recibe en realidad dos tokens, uno restringido para el uso cotidiano y uno completo que solo se activa con consentimiento explícito, de modo que el privilegio administrativo no esté encendido todo el tiempo. UAC es mínimo privilegio aplicado a la vida diaria del administrador; rodearlo (UAC bypass) es reactivar el token completo sin el consentimiento.

Y en el centro de todo está un proceso que merece mención propia: LSASS (Local Security Authority Subsystem Service), el servicio que valida los inicios de sesión y que, para poder ofrecer el inicio de sesión único, mantiene en memoria material de credenciales de los usuarios activos —hashes, tickets, a veces secretos derivados—. Esa concentración es funcional y es peligrosa: convierte a LSASS en el objetivo de mayor valor de la máquina, porque quien lee su memoria cosecha las credenciales de todos los que iniciaron sesión. El volcado de credenciales de la Parte 4 es, en su forma más pura, leer la memoria de LSASS; y las defensas que esa Parte mencionó —proteger el proceso, aislar los secretos en un entorno virtualizado— son intentos de sacar el material de credenciales del alcance de un atacante que ya tiene privilegio. Aquí solo importa fijar por qué LSASS es el premio: porque el sistema operativo eligió guardar ahí lo que abre todas las puertas.

El privilegio en Linux#

El mundo Unix parte de un modelo más antiguo y más simple, y lo fue refinando. La base es la tríada de usuarios y grupos con los bits de permiso: cada archivo tiene un dueño, un grupo y tres ternas de permisos —lectura, escritura, ejecución— para el dueño, el grupo y el resto. Sobre esa rejilla se apoya el control de acceso cotidiano. Y por encima de todos está root (UID 0), el superusuario, que tradicionalmente saltea toda la verificación de permisos: root puede todo. Esa concentración —un único principal que lo puede todo— es la contracara del LSASS de Windows, y el motivo por el que en Linux la escalada de privilegios se formula casi siempre como «llegar a root».

Los refinamientos apuntan justamente a fragmentar ese poder absoluto. Las capabilities parten el monolito de root en piezas —la capacidad de abrir puertos privilegiados, la de cambiar la propiedad de archivos, la de cargar módulos del núcleo— de modo que un proceso pueda recibir solo la que necesita sin ser root entero; es mínimo privilegio aplicado al superusuario. El bit setuid es el mecanismo, tan útil como peligroso, que permite que un programa se ejecute con el privilegio de su dueño en vez del de quien lo lanza —así un usuario común puede, por ejemplo, cambiar su contraseña ejecutando un programa que corre como root—; cada binario setuid es una compuerta de escalada legítima, y por eso cada uno mal escrito o mal configurado es una compuerta de escalada ilegítima, uno de los primeros lugares donde la enumeración de privesc mira. Los espacios de nombres (namespaces) y los grupos de control (cgroups) son la maquinaria que hace posibles los contenedores: aíslan a un proceso dándole su propia visión de los procesos, la red, los identificadores de usuario y el sistema de archivos, de modo que crea estar solo en la máquina. Ese aislamiento es real pero es más delgado que el de una máquina virtual —comparte el mismo núcleo—, y de esa delgadez salen las fugas de contenedor.

Toda operación privilegiada en Linux, como en Windows, pasa finalmente por una llamada al sistema. Por eso la telemetría de seguridad moderna en Linux se construye observando las llamadas al sistema: son el punto de paso obligado donde se ve lo que un proceso realmente hizo, más allá de lo que su nombre sugiera.

Procesos, memoria y aislamiento#

Debajo de los modelos de privilegio de ambos sistemas hay una abstracción común: el proceso. Un proceso es un programa en ejecución con su propio espacio de memoria, aislado del de los demás por el núcleo con ayuda del hardware —cada proceso ve una memoria que cree suya y no puede alcanzar la de otro—. Ese aislamiento de memoria es otra de las fronteras primarias, y romperlo —hacer que un proceso lea o escriba la memoria de otro— es la base tanto de la inyección de código como del robo de credenciales de memoria.

Dos consecuencias cierran el capítulo. Primera: como los procesos se crean unos a otros en una relación de padre a hijo, la cadena de parentesco es una fuente riquísima de señal defensiva —un procesador de texto que engendra un intérprete de comandos, un servidor web que lanza una consola, son parentescos anómalos que delatan una intrusión aunque cada proceso individual parezca legítimo—. Segunda: como el material sensible vive en la memoria de los procesos, la memoria es también la mejor fuente de evidencia. El forense de memoria de la Parte 5 lee exactamente esta capa —los procesos vivos, sus conexiones, el código inyectado, las credenciales residentes— porque es donde el atacante, por más que borre archivos, tuvo que existir para ejecutarse. La memoria no miente sobre lo que corrió: es la frontera donde el atacante y el defensor terminan mirando lo mismo.

Ese es el sentido en que el sistema operativo es un sustrato de la seguridad y no un tema aparte. Reparte el privilegio, aísla los procesos y media cada cruce de frontera por la puerta de las llamadas al sistema; y las tres grandes familias ofensivas que el manual recorrió —escalar, volcar credenciales, evadir— son maniobras sobre esas mismas estructuras. Entender el modelo de privilegio no es un prerrequisito académico: es ver el tablero sobre el que se juega.

Referencias#

  • El modelo de modos de ejecución del procesador, la frontera kernel/usuario y las llamadas al sistema son material fundacional de sistemas operativos; su lectura como el aislamiento primario de la seguridad es enriquecimiento propio.
  • El modelo de privilegio de Windows (SID, tokens de acceso, niveles de integridad, UAC) y el papel de LSASS conectan con el volcado de credenciales de la Parte 4; el modelo de Linux (usuarios/permisos, capabilities, setuid, namespaces) conecta con la escalada de la Parte 3.
  • El aislamiento de memoria de procesos y la cadena de parentesco conectan con la evasión (la pelea por el punto de vista privilegiado) y con el forense de memoria de la Parte 5 (la memoria como la frontera donde atacante y defensor miran lo mismo). El privilegio como abstracción central es la aplicación del mínimo privilegio de 0.1 al sustrato de ejecución.