Escalada de privilegios de Windows

Práctica de gestión de seguridad de la información: pentest

Elevar los privilegios de usuario al nivel de administrador de dominio de Windows

Introduccion

Un buen sistema de gestión de seguridad de la información (SGSI) requiere una evaluación periódica de su eficacia. Existen diferentes métodos para tales evaluaciones, una de cuyas variedades es la llamada. "Prueba de penetración" o pentest: una simulación autorizada de un ataque de piratas informáticos en un sistema de información para identificar vulnerabilidades en su protección antes de que un atacante real las detecte. En este caso, se puede utilizar cualquier herramienta de hacker, exploits, métodos, etc. disponibles en la vida real.

Este artículo describe una de estas prácticas contra la piratería, que tenía como objetivo aumentar los privilegios de un usuario de dominio ordinario de Microsoft Windows al nivel de un administrador de dominio. El artículo se basó en un informe sobre los resultados de una prueba que se puso en práctica. Por razones de confidencialidad, toda la información que permite identificar el lugar (nombres de dominio y host, cuentas, etc.) se elimina o cambia. El artículo muestra las técnicas básicas, para una mejor comprensión, proporcioné los fundamentos teóricos y las vulnerabilidades utilizadas para versiones específicas de los sistemas operativos, así como recomendaciones generales para la protección. Y aunque la mayoría de estas versiones de Windows se considerarán obsoletas en el momento de la publicación, este artículo puede ser útil para los administradores de sistemas novatos para comprender mejor los métodos de protección de credenciales en un entorno de Windows.

Descripción del objeto de prueba.

El objeto de prueba es bastante estándar: el sistema de información de una pequeña empresa (menos de 200 empleados) especializada en desarrollo de software. La red interna de la compañía también es típica: dial-up Gigabit Ethernet, dominio de Microsoft Windows (lo llamaremos CORP.LOCAL). Los hosts internos se dividen en subredes IP en función de su afiliación funcional (como: un grupo de desarrolladores, ingenieros de calidad, departamento de recursos humanos, contabilidad, marketing, alta dirección, instalaciones, etc.), toda la segmentación se realiza en el conmutador L3 . También hay un parque de servidores internos que está dedicado a una subred IP separada y contiene: dos controladores de dominio de Windows Server 2008 con DNS integrado, un servidor de correo interno que ejecuta Exchange, un servidor de archivos, un servidor de terminal y algunos otros servidores auxiliares que ejecutan Windows y Linux. Por separado, vale la pena señalar un laboratorio de pruebas con una flota de máquinas que ejecutan diferentes versiones de Microsoft Windows (tanto de escritorio como de servidor) y están diseñadas para probar el software desarrollado. El acceso a los hosts del laboratorio de pruebas está disponible para todos los empleados. La versión principal del sistema operativo de escritorio es Windows 7. En las computadoras y servidores de escritorio, se instala un software antivirus mal configurado de diferentes fabricantes (de Symantec, Kaspersky y Trend Micro, por qué se discutirá uno mal configurado más adelante).

Modelo de intrusos

Intruso: un empleado interno que tiene una cuenta de usuario sin privilegios en el dominio, una computadora de escritorio, acceso físico a computadoras de prueba (posiblemente tiene una computadora portátil corporativa), pero no tiene privilegios de administrador local en ninguna de ellas. Además, la cuenta de intrusos no tiene la capacidad de cambiar la configuración del software antivirus. La intención del atacante es obtener un acceso equivalente al acceso del administrador al controlador de dominio y / o al servidor de archivos.

Como vemos, tanto el modelo del intruso como la descripción de la empresa son bastante típicos.

Implementación de ataque

Paso 0. Recolección de información sobre la red interna

Entonces, actuamos en nombre del delincuente. En este paso, necesitamos recopilar información sobre:

• direccionamiento interno y subredes
• nombres de host y direcciones IP, en primer lugar estamos interesados ​​en una lista de servidores
• utilizando el protocolo NetBIOS.

Primero, usando la utilidad ipconfig, obtenemos las direcciones IP de los servidores DNS: 192.168.12.1 y 192.168.12.2. Porque DNS está integrado con Active Directory, lo que nos da razones para creer que conocemos las direcciones IP de los controladores de dominio. Luego, usando la utilidad nslookup en modo interactivo, intentamos obtener una lista de todos los hosts en la zona corp.local:

> ls –d corp.local> archivo

De hecho, este comando inicia una transferencia de zona DNS completa y la guarda en un archivo. Muchos administradores olvidan establecer restricciones en la transferencia de zona para la red interna, lo que facilita que un atacante potencial recopile información sobre la infraestructura de la compañía, para más detalles, consulte [12].

Resultado Éxito Una transferencia de zona desprotegida nos dio una lista completa de nombres de host internos, incluidos los servidores, y sus direcciones IP. Utilizando las utilidades nbtstat, telnet, así como cualquiera de los escáneres de vulnerabilidad comunes, un atacante puede recopilar información sobre la plataforma, los servicios en ejecución y las versiones del sistema operativo en los hosts que le interesan.

Paso 1. Obtener privilegios de administrador local

Teoría Para obtener la contraseña del administrador local, se aplica un ataque al valor hash de esta contraseña almacenada en el registro del sistema. A pesar de que la función hash es matemáticamente irreversible, el cálculo de la contraseña es posible mediante la enumeración directa de sus valores junto con un ataque de diccionario. Históricamente, Windows ha utilizado dos algoritmos para calcular una función hash de contraseña: el algoritmo LM heredado y el algoritmo NT más nuevo (a veces también llamado NTLM). La función hash de LM es vulnerable debido a su baja complejidad computacional, lo que hace posible enumerar sus valores incluso en una computadora débil. La presencia de hash de contraseñas LM y NT en el registro del sistema garantiza que el atacante pueda descifrarla en un período de tiempo aceptable. El valor hash de LM en la configuración predeterminada se almacena en el registro de Windows XP / 2003, lo que hace que estos sistemas sean especialmente atractivos para el hacker. La función de hash NT es computacionalmente más compleja, sin embargo, enumerar sus valores se simplifica enormemente por el hecho de que hay disponibles tablas de valores precalculados (las llamadas tablas Rainbow); reducen el cálculo del valor de hash a la búsqueda del hash deseado entre valores precalculados

Objeto de ataque. Hashes de contraseña en la base de datos SAM (registro). En nuestro caso, estas son todas las máquinas a las que tenemos acceso físico. En primer lugar, este es nuestro escritorio de trabajo y, en segundo lugar, hosts para realizar pruebas.

Implementación Con máquinas que tienen acceso físico, realizamos la siguiente operación: arrancar desde un medio externo (usando un CD de entorno de preinstalación de Windows o un CD de Linux Live), montar la partición del sistema NTFS y copiar las ramas de registro HKLM \ SYSTEM y HKLM \ SAM (% WINDIR archivos % \ System32 \ Config \ System y% WINDIR% \ System32 \ Config \ Sam respectivamente). Prestamos especial atención a las máquinas que ejecutan Windows XP \ Windows 2003, en las que es probable que se encuentre el hash LM. Para volcar las contraseñas de los archivos de registro copiados, utilizamos las herramientas [1], [2] (todos los enlaces al final del artículo). Resultado:



La última línea contiene el hash NT requerido del administrador local. En los hosts del laboratorio de pruebas (llamemos a estos hosts LAB1 y LAB2) encontramos un hash LM distinto de cero:





Entonces, obtuvimos hashes NT y LM. ¿Pero cómo recuperar la contraseña de ellos? Para hacer esto, usaremos las mismas herramientas [1], [2], así como los servicios de hash reverse en línea [8] - [11]:



Nota: la contraseña real consistía en el nombre de la empresa con un pequeño modificador y rápidamente se rompió bajo un ataque de diccionario).

Resultado Éxito Contraseñas (que sean "Pa $$ word1" y "Pa $$ word2") de la cuenta de administrador local de nuestro escritorio de trabajo y se han recibido dos computadoras de prueba. ¿Pero ayudarán a obtener derechos de administrador de dominio? Sobre esto más allá.

Paso 2. Obtención de credenciales de administrador de dominio

Teoría En la mayoría de los casos, es suficiente para obtener el valor del hash NT de la contraseña para el administrador del dominio. Esto se debe al hecho de que cuando se verifica a un usuario utilizando el protocolo NTLM, el sistema autenticado solo presenta el hash NT al autenticador y no se realiza la verificación de la contraseña. El hash NT se puede obtener del llamado Almacenamiento de LSA haciendo referencia al llamado Sesiones de inicio de sesión de administrador (la sesión de inicio de sesión es un área de datos especial creada por el proceso Winlogon donde el nombre de usuario, el dominio de inicio de sesión y el valor de hash de la contraseña NT se almacenan, en conjunto, esto se denomina secreto LSA). Este proceso de NTLM es utilizado por el proceso NTLMSSP para la autenticación NTLM. La sesión de inicio de sesión se guarda todo el tiempo mientras la cuenta se conecta al sistema. También puede interceptar un hash NT desde una sesión de autenticación de administrador NTLM. Además, es posible obtener una contraseña de administrador del caché de Credenciales en caché de dominio (DCC). DCC es un caché local que se completa cuando un usuario inicia sesión con éxito en un dominio. El propósito de la caché DCC es poder autenticar al usuario cuando el controlador de dominio no está disponible.

Atacar objetos:

• DCC hashes (rama de registro HKLM \ Security).
• Sesión de inicio de sesión de administrador de dominio (LSA-secret).
• Intercepción de sesiones NTLM (no considerado debido a una mayor complejidad práctica).

Practica Muchos administradores de Windows usan una cuenta de administrador de dominio para realizar varios tipos de operaciones en las computadoras de los usuarios. Al mismo tiempo, sus datos caen en el caché DCC. Por lo tanto, primero intente obtener la contraseña del caché DCC. Vamos a nuestra estación de trabajo, guardamos la rama de registro HKLM \ Security e importamos a [1]. Porque tenemos una contraseña de administrador local, ya no necesitamos iniciar la máquina desde medios externos para guardar el registro:



El caché contiene los datos de la contraseña de tres cuentas. La última cuenta (*** usuario) no nos interesa, la segunda cuenta no tiene los privilegios requeridos, pero el usuario shadmin se parece al administrador que está buscando. Desafortunadamente, el algoritmo MS-CACHE2 tiene una gran complejidad computacional y un ataque directo de fuerza bruta sobre él es ineficiente. La función MS-CACHEv2 contiene un "secreto computacional" - salt (el nombre de la cuenta se usa como "salt"), lo que lo protege contra ataques a las tablas Rainbow. Sin embargo, en el futuro, pueden aparecer tablas de valores hash para cuentas estándar: "Administrador", "Administrador", etc. En aras del interés, enviamos el "hash de caché" encontrado al servicio en la nube [8] - [11] (sobre los resultados y la eficacia de dichos servicios al final del artículo). Mientras la nube está pensando, estamos tratando de encontrar otros DCC. Analizamos la lista de hosts obtenida en el paso 0, verificamos a qué servidores podemos acceder bajo el administrador local utilizando las contraseñas obtenidas en el paso 1. Dado que el administrador local está bloqueado en el controlador de dominio y el servidor de correo generalmente está mejor protegido, debe experimentar con Servidores secundarios. En nuestro caso, se encontró un servidor con el discreto nombre Upd en la lista de servidores. El inicio de sesión con la contraseña "Pa $$ word2" encontrada en el paso 1 es exitosa. Encontramos eso en el host Upd:

1. No hay software antivirus instalado.
2. Ejecuta Apache, que es el servidor de administración para el antivirus corporativo (esto significa que también hay una contraseña para la cuenta utilizada para instalar el software antivirus de forma remota y, en teoría, puede sacarlo de allí).
3. El host no audita los intentos fallidos de inicio de sesión.
4. Versión del sistema operativo: Windows 2008 R2.

Después de descargar el registro HKLM \ Security, obtenemos el hash DCC de la cuenta CORP.LOCAL \ Administrator (y varias otras):



Teóricamente, puede intentar encontrar la contraseña para el Administrador a través de un servicio en la nube. Sin embargo, como mencioné anteriormente, un ataque de fuerza bruta en MS-CACHEv2 es inútil (aunque es posible que en un par de años la situación cambie). Deje solo DCC y continúe buscando sesiones de inicio de sesión. Compruebe qué usuario ha iniciado sesión en el host Upd:



Vemos que dos sesiones inactivas se cuelgan en la máquina Upd: el administrador y el usuario Shadmin, que ya conocemos, lo que significa que podemos obtener NT-hash de sus contraseñas robando el secreto LSA. Esta es la clave para determinar el éxito de todo el ataque. Para robar un hash, usa el exploit Lslsass [3]. Para ejecutarlo, necesita derechos de administrador local (o más bien, derechos para depurar procesos), que ya tenemos. Obtenemos la lista de secretos de LSA (en el formato "dominio \ cuenta: LM hash: NT hash :::"):

lslsass v1.0 - Copyright (C) 2010 Bjorn Brolin, Truesec (www.truesec.com) Found Lsass pid: 520 Lsass process open Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:<i>8833c58febc977799520e7536bb2011e</i>::: Found possible primary token Found possible primary token Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token UPD\Administrator::00000000000000000000000000000000:8833c58febc977799520e7536bb2011e::: Found possible primary token Found real token CORP.LOCAL\UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \UPD$::00000000000000000000000000000000:68987a0fb5529dbf99d5eac3bfce773b::: Found possible primary token Found real token CORP.LOCAL \Administrator::00000000000000000000000000000000: <b> c690e441dc78bc5da8b389e78daa6392 </b>::: Found possible primary token Found real token CORP.LOCAL \shadmin::00000000000000000000000000000000: <b> 5794cba8b464364eacf366063ff70e78 </b> ::: 

Las líneas resaltadas en negrita contienen los hashes de contraseña necesarios. También tenga en cuenta el hash en cursiva en la sexta línea. Ya lo hemos visto en alguna parte, ¿verdad?

Resultado Éxito Tenemos el hash de contraseña NT de la cuenta de administrador de dominio en nuestras manos. Pero, ¿de qué sirve un hash si no es posible restaurar la contraseña original en un tiempo aceptable? Sobre esto en el siguiente paso.

Paso 3. Hacer trampa en la sesión de autenticación NTLM

Teoría Windows nunca usa una contraseña pura para la autenticación, el sistema autenticado siempre presenta un hash. Esto da lugar a la idea: al reemplazar el nombre de usuario, el dominio de inicio de sesión y el hash de NT en la sesión de inicio de sesión del usuario conectado con los valores de administrador de dominio correspondientes, podemos autenticarnos utilizando el protocolo NTLM antes del sistema remoto como administrador de dominio. Este ataque [7] es posible solo con autenticación usando el protocolo NTLM. A pesar del uso generalizado del protocolo Kerberos, NTLM es la única forma posible de autenticar a un cliente cuando accede a un recurso compartido de red no es por nombre simbólico, sino por dirección IP [13].

Objeto de ataque. Sesión de inicio de sesión del administrador local.

Practica Hay varios exploits disponibles que le permiten implementar un ataque en las plataformas Windows Server 2008 x86 y x64. El exploit principal es el Editor de credenciales de Windows [4]. Para llevar a cabo el ataque, vamos al host LAB2 usando las credenciales "Administrador" \ "Pa $$ word2". Con [4], reemplazamos el nombre de la cuenta, el dominio de inicio de sesión y los datos hash de NT en la sesión de inicio de sesión con los valores Shadmin correspondientes que obtuvimos en el paso anterior:



El nombre de la cuenta del administrador del dominio y su hash NT se pasan al comando wce como argumento desde la línea de comandos. Resultado: el hash se modificó correctamente. Observo que la membresía del usuario en el grupo y el token de acceso no cambian durante el ataque:



Todavía somos el administrador local, el nombre de host en verde en la captura de pantalla anterior está manchado con verde - LAB2. Sin embargo, durante la autenticación NTLM, el sistema remoto recibirá el nombre de dominio CORP.LOCAL, el nombre de usuario Shadmin y el hash de contraseña Shadmin. Aquí hay un volcado de un único paquete de red que contiene la sesión de blob de seguridad NTLM:



El nombre de dominio (CORP.LOCAL) y el nombre de host (LAB2) están atenuados en verde), se presenta una cuenta: Shadmin. Ahora intentamos conectarnos a la partición raíz del volumen del sistema en el controlador de dominio con el comando net use utilizando la dirección IP del controlador de dominio:



Con exito. Para verificar el acceso, creé un archivo de texto en la raíz (encuéntralo en la captura de pantalla). Después de crear un archivo por lotes en el disco del controlador de dominio con la secuencia de comandos que necesitamos, podemos, utilizando [5], realizar la operación necesaria en el controlador de dominio (por ejemplo, agregar el usuario al grupo de administradores de dominio). La operación se realizará con los derechos de la cuenta Shadmin. Para ilustrar, cree un archivo por lotes simple en un host remoto que agregue un usuario local:

usuario neto TstUsr Pa $$ palabra / agregar

Ejecútelo de forma remota desde el host LAB2:



Se ejecutará en el sistema remoto 192.168.13.125 con los privilegios del usuario de nuestra sesión actual: shadmin (es decir, administrador de dominio). Comprobamos:



La segunda salida del comando net user muestra al nuevo usuario. A pesar de la imposibilidad de iniciar aplicaciones que requieren la interacción interactiva del usuario de esta manera (por ejemplo, complementos MMC), se puede realizar una amplia gama de acciones mediante scripts.

Resultado Éxito Obtuvo acceso al sistema de archivos y al shell del controlador de dominio.

Resumen

Brevemente, la cadena de ataque se veía así: Recopilando información sobre la estructura de la red -> Obteniendo una contraseña de administrador local -> Usando esta contraseña para iniciar sesión en uno de los servidores secundarios -> Robo de credenciales de administrador de dominio "dejado desatendido" -> Modificando su sesión de inicio de sesión y escalada de privilegios.

El éxito del ataque fue facilitado por:

1. Protección débil de la zona DNS de la transferencia a hosts no confiables.
2. Política de contraseña débil. La mayoría de las computadoras de dominio usaban la misma contraseña para la cuenta de administrador local, que era vulnerable a un ataque de diccionario.
3. La ausencia o configuración débil de software antivirus en hosts críticos.
4. Protección de hash de contraseña débil: dos sesiones de inicio de sesión de administrador inactivas en el host Upd, hash de LM en la base de datos SAM.
5. Mala política de auditoría.

En base a esto, se pueden derivar recomendaciones generales de protección:

0. Ocultar completamente la estructura interna de la red de posibles atacantes. Por lo tanto, los usuarios no deberían poder obtener el contenido completo del archivo de zona DNS. Los usuarios que no son de confianza (por ejemplo, aprendices, empleados que no han completado el período de prueba, etc.) tiene sentido transferir a una subred separada usando NAT para falsificar direcciones (incluyendo, por ejemplo, modificar respuestas DNS).

1. La política correcta para asignar contraseñas al administrador local. La contraseña del administrador local debe ser diferente en los hosts que tienen diferentes grados de protección contra el acceso no autorizado. Comprometer la contraseña del administrador local en cualquiera de los hosts del dominio debería minimizar la posibilidad de que un atacante use esta contraseña.

2. El almacenamiento del hash LM en SAM debe estar prohibido por las políticas de seguridad.

3. No utilice el nombre de la empresa o su dominio como parte de la contraseña del administrador) Esto dificultará que un atacante ataque el diccionario. Pero incluso utilizando una contraseña compleja, no se olvide de usted mismo y verifique regularmente su hash para mayor durabilidad utilizando los servicios en línea.

4. No se recomienda realizar operaciones de rutina en equipos de dominio desde la cuenta de administrador de dominio. Esto protegerá la cuenta de la interceptación de los datos de la sesión de inicio de sesión y del ingreso del hash de contraseña en el caché DCC.

5. Establezca una regla para no dejar desatendida la sesión de inicio de sesión del administrador del dominio. Práctica recomendada: trabajo terminado: cierre sesión.

6. Las utilidades de falsificación de LSA son bastante pequeñas. Tiene sentido rastrear su evolución y verificar su detección exitosa por el software antivirus corporativo.

7. Un usuario, incluso con derechos de administrador local, no debería poder cambiar la configuración de un antivirus corporativo. Desactivar el servicio antivirus en las estaciones de trabajo de dominio debería generar una notificación al administrador del dominio (en este sentido, Symantec Endpoint Protection funcionó bien durante la prueba).

Apéndice 1. Comportamiento antivirus

Las computadoras de la compañía usaban tres tipos de antivirus: KAV, actual en el momento de la prueba de Symantec Endpoint Protection, y un producto obsoleto de Trend Micro. En la mayoría de los casos, las herramientas utilizadas durante el ataque se identificaron como Hack Tool / Rootkit / Trojan. KAV los eliminó sin previo aviso, y SEP (incluso apagado) emitió un aviso y lo movió a cuarentena para evitar que se inicie. Sin embargo, tener derechos de administrador local le permite deshabilitar KAV, y la protección SEP se omitió configurando manualmente una ruta de excepción para la verificación, nuevamente utilizando la cuenta de administrador local. El antivirus de Trend Micro instalado en algunos hosts no reaccionó de ninguna manera al lanzamiento de exploits.

Anexo 2. Eficiencia del uso de servicios de verificación de hash en línea

Hay muchos servicios en línea disponibles para probar la solidez de los hashes de contraseñas. Le permiten trabajar con los hashes más comunes: LM, NTLM, MD4, MD5, WPA, con hashes que usan sal, etc. Para verificar el hash, la enumeración directa se usa utilizando el poder de procesamiento de las GPU modernas, la enumeración de diccionarios, los ataques híbridos, etc. Una vez abierto, el hash puede reponer la base de datos y ser utilizado en el futuro. El servicio puede ser gratuito para verificar una contraseña corta (menos de 8 caracteres) o cobrar una pequeña tarifa. Durante la prueba utilicé cuatro de estos servicios, los enlaces se dan al final del artículo. Envié varios hashes encontrados en el paso 2 y después de 15 meses recibí una notificación del servicio On-line Hash Crack [9] sobre la restauración exitosa de uno de ellos)

Referencias

Herramientas usadas

[1] Cain & Abel : una herramienta de recuperación de contraseña para los sistemas operativos de Microsoft. Permite la recuperación fácil de varios tipos de contraseñas al rastrear la red, descifrar contraseñas cifradas mediante ataques de Diccionario, Fuerza Bruta y Criptoanálisis, grabar conversaciones VoIP, decodificar contraseñas codificadas, recuperar claves de red inalámbricas, revelar cajas de contraseñas, descubrir contraseñas almacenadas en caché y analizar rutas protocolos
[2] Grieta L0pht.
[3] Explotación de Lslsass. Vuelca los hash de contraseña de sesión de inicio de sesión activo del proceso lsass.
[4] Editor de credenciales de Windows post-exploit. Herramienta para cambiar las credenciales de inicio de sesión.
[5] PsExec de PS Tools

Descripciones detalladas de vulnerabilidad

[6] Serie de artículos "Obtención efectiva de un hash de contraseña en Windows" en www.securitylab.ru
[7] Pass-the-Hash, una descripción de un ataque a un sistema remoto al proporcionarle un hash comprometido.

Servicios de hackeo de Cloud Hash
[8] Question-defense.com (parece estar fuera de servicio en el momento de la publicación ()
[9] www.onlinehashcrack.com
[10] www.cloudcracker.com
[11] Asesino de hash en línea

Materiales adicionales

[12] Seguridad y ajuste de DNS en Windows Server
[13] Kerberos no se utiliza cuando se conecta a recursos compartidos SMB utilizando la dirección IP