Escalada de privilegios en Windows

Un servicio necesita escribir informes. ¿Significa eso que cualquier persona que pueda iniciarlo debería poder cambiar su programa? Esta es la pregunta central de los límites de privilegio: quién provoca una acción, bajo qué autoridad y sobre qué objeto.

La escalada de privilegios consiste en obtener autoridad más allá del contexto previsto. Comprender el límite permite prevenir errores, explicar un hallazgo y elegir una corrección proporcionada. Empieza con este modelo y explora después las lecciones cortas a tu ritmo.

Un proceso lleva un contexto de seguridad

Un token de acceso incluye identidad de usuario, grupos, privilegios y otros atributos de seguridad. Normalmente un proceso usa su token primario. Un hilo puede usar un token de suplantación al actuar para un cliente. Son contextos relacionados, pero no intercambiables.

El nombre de cuenta ayuda a identificar; no describe toda la autoridad. Importan grupos, restricciones del token, privilegios habilitados y operación solicitada. Continúa con tokens de acceso e identificadores de seguridad para separar identidad y nombre visible.

Pregunta por una operación sobre un objeto

Un archivo, clave de registro u objeto de servicio ofrece operaciones concretas. Leer un documento, modificar su contenido y cambiar sus permisos son solicitudes distintas. Una DACL describe acceso discrecional mediante entradas para identidades de seguridad. El orden, la herencia y los atributos del token pueden afectar la evaluación.

No concluyas a partir de un permiso visible aislado. Una DACL nula y una vacía también significan cosas muy diferentes. La lección de DACL explica estas distinciones; la de herencia muestra cómo cambia el acceso durante la vida de un objeto.

La integridad añade otro control

El nivel de integridad es una etiqueta de confianza separada de los permisos ordinarios. Bajo la política no-write-up, un proceso de integridad inferior no puede escribir en un objeto de nivel superior aunque la DACL conceda esa escritura. Coincidir en nivel tampoco concede acceso por sí solo.

El Control de cuentas de usuario influye en cómo las tareas administrativas obtienen un contexto elevado. Pertenecer a Administradores no significa que todos los procesos tengan el mismo token sin restricciones. Lee contexto UAC después del modelo.

EXPLORA EL CONCEPTO

Por qué un permiso puede no bastar

Compara las situaciones y cambia después los dos controles del modelo.

La DACL concede escritura

Un proceso de integridad media no puede escribir en este archivo de integridad alta bajo la política que impide escribir hacia arriba. El permiso discrecional no anula la integridad.

Coinciden los niveles de integridad

La coincidencia elimina ese bloqueo concreto. El token aún necesita permiso de la DACL para la operación solicitada.

Ambos controles permiten escribir

El modelo permite escribir cuando se cumplen ambas condiciones. Un sistema real puede aplicar más controles; aquí aislamos estos dos conceptos.

Modelo simplificado para aprender. No se conecta a sistemas ni usa datos reales.

Los servicios tienen dos límites que revisar

La identidad de servicio establece su contexto de ejecución. El acceso efectivo debe ajustarse a su propósito. Revisa por separado quién cambia su configuración, ejecutable o dependencias de confianza: controlar esas entradas puede cambiar el trabajo realizado bajo esa identidad.

Para el servicio de informes, registra el destino, el permiso de escritura necesario, el responsable de configuración y la aprobación de cambios. Considera también los fallos: archivos temporales sensibles, información de registros y permisos después de recuperar el servicio. Explora control de cambios y tareas programadas.

Reduce la autoridad y verifica el resultado

Aislamiento de credenciales, contraseñas locales separadas, control de aplicaciones y mantenimiento de parches cubren fallos distintos. Ningún control sustituye comprender los permisos efectivos. La autoridad SYSTEM local tampoco demuestra automáticamente administración de todo el dominio.

Un hallazgo sólido identifica cuenta, objeto, operación y evidencia. Recomienda el cambio mínimo que retire autoridad innecesaria y conserve el trabajo legítimo. Verifica después funcionamiento normal, operaciones denegadas, supervisión y recuperación. Así conviertes una observación en una mejora útil.

Aplica estas ideas en el caso de revisión de permisos de un servicio Windows. Compara funciones aprobadas y permisos, distingue la gestión del servicio del acceso a archivos y explica qué evidencias justificarían cerrar los hallazgos.

Revisión resuelta: separa los dos límites

El servicio ficticio Ledger publica informes. Estos registros corresponden a procesos ordinarios, descriptores válidos y la política de integridad indicada. El caso excluye privilegios especiales que eludan controles y bloqueos adicionales.

W1: Un proceso de informes de integridad media solicita escribir en un archivo de informes de integridad alta. La DACL lo permite, pero el archivo aplica no-write-up.

W2: El responsable aprueba que Operadores inicie Ledger y consulte su estado. Los permisos efectivos del objeto de servicio también permiten a Operadores cambiar su configuración.

W3: Mantenimiento controla los ejecutables. El acceso del servicio a archivos se limita a las carpetas de entrada e informes. No se aporta evidencia de permisos de dominio.

Predice¿Conceder más permisos de archivos resolvería W1 y W2?

No. W1 ya tiene permiso discrecional; lo bloquea la integridad. W2 corresponde a gestión del servicio, otro objeto y otra operación. Ampliar acceso a archivos durante la ejecución no resuelve ninguna discrepancia.

En W1, el responsable debe decidir si proceso y destino se diseñaron para el mismo nivel de confianza. Un rediseño compatible podría usar un destino de informes protegido adecuadamente o un componente de publicación con autorización acotada. Elevar automáticamente toda la aplicación amplía su autoridad y exige una justificación separada.

En W2, retira el cambio de configuración sin respaldo y conserva inicio y consulta aprobados. Mantén la protección de ejecutables de W3: sigue siendo útil, pero no anula la autoridad sobre configuración. Registra los permisos de cada objeto por separado.

La aceptación debe confirmar que Operadores inicia Ledger y consulta estado, pero no cambia configuración. Confirma también que el diseño previsto genera el informe con su contexto aprobado. Estas comprobaciones respaldan una corrección local. Ni publicar con éxito ni el nombre de la cuenta del servicio establecen autoridad sobre todo el dominio.