Microsoft declara oficialmente obsoleto el protocolo de autenticación NTLM en Windows

Hace unos días, Microsoft anunció que finalmente optará por “deprecar” NTLM. Aunque esto pueda parecer un cambio drástico en la postura de Windows y su conocida retro-compatibilidad, lo cierto es que se trataba de “una muerte anunciada”. Este cambio era previsible, y tanto Microsoft como sus empleados lo han estado manifestando desde octubre de 2023 a través de diferentes medios. 

Figura 1: Microsoft declara oficialmente obsoleto el protocolo

de autenticación NTLM en Windows

Podemos verlo en esta charla de Steve Syfuhs, Principal Engineer en Microsoft, y también en este post del blog de Microsoft escrito por Matthew Palko, donde ambos hablan de la evolución de la autenticación en Windows y cómo NTLM está quedando relegado por Kerberos. NTLM siempre ha sido uno de los grandes problemas de seguridad que obliga a tomar medidas de fortificación en Windows para evitar riesgos.

Figura 2: "Máxima Seguridad en Windows: Secretos Técnicos. 6ª Edición"

de Sergio de los Santos en 0xWord.

Sin embargo, no ha sido hasta ahora, el 11 junio de 2024, que Microsoft, en su lista de funcionalidades “deprecated” para Windows ha anunciado oficialmente la desaparición y “deprecación” del mítico protocolo de autenticación NTLM, que será oficialmente reemplazado por Kerberos siempre que sea posible. Esto significa, que Microsoft dejará de mantener de forma activa este protocolo y priorizará el soporte de otros como Kerberos.

Figura 3: Anuncio de que NTLM está en la lista de

funciones deprecadas en Windows

Si bien en el anuncio se comenta que seguirá funcionando en la próxima versión de Windows Server y en la próxima versión anual de Windows, es cierto que todas las llamadas a NTLM deberían intentar autenticarse haciendo uso de Kerberos, de esta forma solo se recurriría a NTLM en los casos que sea estrictamente necesario.

Funcionamiento y Riesgos de NTLM

Ya sabéis que NTLM, tuvo un predecesor (y también unos cuantos sucesores o alternativas), todos conoceréis LM o LAN Manager. Este protocolo que nació en 1987 cuando Microsoft, junto con IBM, desarrollaban un sistema operativo de redes, el denominado OS/2. No tardaron en mostrarse al mundo las vulnerabilidades inherentes del algoritmo de hash LM. 

Para crear estos hashes, comenzamos con la primera de las restricciones, contraseñas de un máximo de 14 caracteres. Luego, a pesar de permitir introducir mayúsculas y minúsculas, todas las letras se convertían a mayúsculas, por lo que el conjunto de caracteres se reducía a la mitad, y contraseñas como “HaCkEr” o “hacker” generaban el mismo hash. 

Por último, y para más “inri”, se generaban dos hashes concatenados al segmentar la contraseña de 14 caracteres en dos de 7 caracteres cada una. El resultado, cómo podéis imaginar, todo un protocolo digno de aplicar un ataque de fuerza bruta. En la siguiente imagen os dejo una explicación básica de este algoritmo:

Figura 4: Funcionamiento del Hash LM

Microsoft tenía que hacer algo, y nació NTLM (New Technology LAN Manager), el protocolo de autenticación sucesor de LAN Manager. Este protocolo, que apareció por primera vez en 1993 junto a Windows NT 3.1, utiliza un mecanismo de desafío-respuesta para autenticar a un cliente en un servidor mediante una contraseña. El flujo de funcionamiento de NTLM es el siguiente:

1) El cliente comienza una negociación con un servidor y envía un NEGOTIATE_MESSAGE anunciando sus capacidades y características de seguridad soportadas. 

 

2) Una vez negociados los detalles de la comunicación (por ejemplo, la versión de LDAP a utilizar), el servidor responde con un CHALLENGE_MESSAGE, que incluye un nonce (un número aleatorio) que el cliente tendrá que cifrar con el hash de su contraseña (que debe ser igual al hash NTLM guardado en la SAM). Este nonce es de 8 bytes en NTLMv1 y de 16 bytes en NTLMv2. 

 

3) Tras esto, el cliente responde con un AUTHENTICATE_MESSAGE, que contiene el nonce cifrado con el hash NT de la contraseña del usuario, junto con otros datos de autenticación.

• En el caso de un entorno de Active Directory, el servidor envía el desafío y la respuesta enviada por el cliente al controlador de dominio para que este verifique su validez.
• El controlador de dominio verifica la respuesta y envía la confirmación de autenticación al servidor.

4) Finalmente, si la verificación enviada por el controlador de dominio es correcta, el servidor validará correctamente al usuario o, por el contrario, devolverá un error.

Figura 5: Flujo de autenticación NTLM

Como se puede comprobar, en este proceso de autenticación NTLM no se ha utilizado en ningún momento la contraseña del usuario de manera directa, sino que se emplea para crear su hash NTLM, hash que está almacenado en la SAM (Security Account Manager) del equipo. Debido a la ausencia de “salting” y que el hash NTLM y la contraseña son equivalentes a nivel de secreto en el protocolo NTLM, el conocido ataque PassTheHash tiene sentido. En este tipo de ataque, un atacante que ha obtenido el hash NTLM de un usuario puede autenticarse como ese usuario sin necesidad de conocer su contraseña en texto plano.

Figura 6: Hacking Windows: Ataques a sistemas y redes Microsoft 2ª Edición

escrito por Carlos García, Valentín Martín y Pablo González en 0xWord.

Por último, comentar acerca del sucesor definitivo de NTLM, Kerberos, un protocolo de autenticación creado por el MIT en 1989, de código abierto y mantenido por una gran comunidad, entre la cual se encuentra Microsoft que desarrolla su propia versión (compatible en gran medida con la “oficial”).

Kerberos, deja atrás el método de desafío-respuesta propio del protocolo de autenticación NTLM y pasa a utilizar un sistema de tickets para autenticar a los usuarios. En Kerberos encontramos componentes claves como el centro de distribución de claves (KDC), el servidor de autenticación (AS), el servidor de concesión de tickets (TGS), … Todo esto, da para verlo con más detalle en otro post.

Figura 7: Misión de Kerberos.org

La misión de Kerberos es establecerse como la plataforma universal de autenticación en todas las redes del mundo, así lo comentan kerberos.org. Actualmente, Kerberos es el protocolo de autenticación principal por defecto, mientras que NTLM interviene en circunstancias específicas. Por ejemplo, se utiliza NTLM cuando se autentica a través de sistemas configurados en un grupo de trabajo en lugar de un dominio, en la autenticación local en controladores que no forman parte de un dominio o en aplicaciones que no soportan otros tipos de protocolos.

Tú mismo puedes hacer uso de un Fiddler (un proxy que registra todo el tráfico HTTP/HTTPS entre el equipo e Internet) para recopilar todas las peticiones realizadas, y mediante la observación de las cabeceras, detectar en qué casos se está usando Kerberos o NTLM. En una cabecera de autorización, si el token comienza por “YII” estaremos ante un caso donde se está utilizando Kerberos. Si, por el contrario, comienza por “TlR” estaremos ante un protocolo de autenticación distinto a Kerberos (normalmente NTLM). Por ejemplo:

• Cabecera de autenticación de Kerberos:
• Authorization: Negotiate YIIVDAYGKwYBE...

• Cabecera de autenticación no perteneciente a Kerberos:
• Authorization: Negotiate TlRMTVNTUA...

Volviendo a la noticia, con este anuncio, Microsoft se ha comprometido a trabajar para eliminar y mitigar todos estos escenarios que hacen uso de NTLM en componentes de Windows, y en el momento que lo vean oportuno lo deshabilitaran por completo. Este movimiento ha provocado toda una ola de reacciones entre los usuarios. Algunos elogian este cambio, otros se preguntan por qué ahora y no hace 20 años, y otros defienden el uso de NTLM, criticando la falta de retro-compatibilidad que esta modificación implicará para los equipos más antiguos.

Figura 8: Libro de Ethical Hacking 2ª Edición  de 0xWord
escrito por Pablo González Pérez

Ahora toca esperar y ver cómo Microsoft sigue moviendo ficha hasta que veamos por completo la eliminación de NTLM. No obstante, es un cambio positivo ya que pasamos de utilizar un protocolo de autenticación donde el conocimiento del hash del usuario rompe por completo la seguridad; a utilizar por defecto un protocolo más seguro como es Kerberos. Y para los Ethical Hacking, pues a ponerse las pilas con Pass-the-ticket.

Saludos,

Autor: Javier Álvarez Páramo (Investigador en el IdeasLocas)

Contactar con Javier Álvarez Páramo

DLL Hijacking: Identificando programas vulnerables con Process Monitor

Hace unos días revisábamos lo que es una DLL y en qué consistían los ataques de DLL Hijacking. En esta ocasión, atendiendo a los conceptos explicados en el artículo anterior, vamos a comprobar cómo se puede buscar si un programa es vulnerable a este ataque y, en el próximo artículo,  cómo poder explotarlo. 

Figura 1: DLL Hijacking: Identificando programas vulnerables con Process Monitor

En este artículo de hoy en concreto vamos a trabajar con la última versión de Slack que en el momento de escribir el artículo es la 4.15.0, que es una de las aplicaciones más utilizadas en estos tiempos de teletrabajo en los equipos Windows de las empresas, y puede ser un buen objetivo para atacar en un Hacking a sistemas Windows y redes Microsoft.

Identificando oportunidades de DLL Hijacking

Para buscar un programa vulnerable a DLL Hijacking vamos a hacer uso de Process Monitor (procmon), una herramienta capaz de monitorizar en tiempo real un gran número de eventos relacionados con los procesos del sistema. Hemos visto en varios artículos cómo esta herramienta se puede utilizar para revisar los niveles de integridad de los procesos o para encontrar y explotar UAC Bypass:

- Cómo ownear Windows 7 y Windows 10 con el nuevo bypass de UAC

- Bypass de UAC en Windows 10 con DLL Hijacking vía SystemPropertiesAdvanced.exe

- Fileless 3: Otro bypass de UAC en Windows 10

Lo que nos interesa en este caso es que, seleccionando los filtros adecuados, podemos listar las DLL que un proceso intenta cargar, la rutas en la que se buscan esas DLL y si éstas se han encontrado con éxito o no en esos directorios.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Ahora que ya sabemos lo que debemos buscar, conviene recordar que la finalidad del DLL Hijacking es, generalmente, la de elevar privilegios o generar persistencia en el sistema. Esto ya nos da una pista sobre qué programas nos pueden interesar más:

• Si la intención es la de elevar privilegios parece razonable buscar programas que se ejecuten por un usuario con privilegios de administrador o servicios que se ejecuten como “NT AUTHORITY/SYSTEM”. Si se carga una DLL cuyo payload genere una shell, ésta tendrá los mismos privilegios que el usuario que levantó el proceso.

• Si lo que se pretende es generar persistencia, la estrategia sería buscar programas que se ejecuten de forma habitual (como un navegador de Internet) y programas configurados para ejecutarse automáticamente cuando se inicia el sistema. Algunos de los programas que yo he visto que con frecuencia se configuran para iniciarse con el sistema son: Microsoft Teams, OneDrive, Skype, Dropbox y Slack.

En este caso, vamos a trabajar con Slack y vamos a filtrar en procmon todas aquellas DLL que la aplicación intenta cargar, pero no encuentra en el directorio donde las busca. Para ello, tras ejecutar procmon abriremos la pestaña “filter” (ctrl+L) y añadiremos estos tres filtros:

1. Primer desplegable “Process name”, segundo desplegable “is” y “slack.exe”.
2. Primer desplegable “Path”, segundo desplegable “ends with” y “.dll”.
3. Primer desplegable “Result”, segundo desplegable “is” y “NAME NOT FOUND”.

Nuestro filtro debe quedar así:

Figura 3: Filtro para la búsqueda de DLLs no encontradas por Slack

Tras aplicar el filtro en procmon y ejecutar Slack aparecerá la lista de DLLs que cumplen estos criterios que se puede ver en la Figura 4. De todas estas DLLs las más interesantes son aquellas que se han buscado en el propio directorio de la aplicación. Ahora hay comprobar si en dicho directorio contamos con permisos de escritura, lo que en nuestro caso se cumple, para depositar ahí una DLL maliciosa.

Figura 4: Lista de DLLs no encontradas por Slack

Es importante aclarar que en este punto vamos “a ciegas”, es decir, no hemos hecho ningún análisis del binario. Para nosotros slack.exe es una caja negra; no sabemos cómo carga cada DLL, qué funciones de esa DLL utiliza o qué hará el programa si se encuentra con una DLL inválida o si no consigue importar función alguna de esa DLL.

Figura 5: Ejemplo de DLL "vacía"

Desde este momento el trabajo que nos queda por hacer es bastante manual; hay que ir comprobando para cada DLL si existe una oportunidad real de secuestro o "Hijacking". Esto puede hacerse introduciendo en el directorio de la aplicación una DLL “vacía” (sin ningún payload), tal y como aparece en la figura anterior. Basta con renombrar esa DLL vacía con el nombre de la DLL legítima a la que pretendemos suplantar.

Figura 6: Máxima Seguridad en Windows Gold Edition

Una vez hecho esto, deberíamos eliminar los filtros de procmon que habíamos creado anteriormente y crear un filtro con el nombre de la DLL con la que estamos trabajando. Si al ejecutar Slack de nuevo comprobamos en procmon que el resultado para esa DLL ha cambiado de “NAME NOT FOUND” a “SUCCESS” entonces puede haber una oportunidad para el hijacking. 

Figura 7: Resultado para USERENV.DLL antes de introducir la

DLL "vacía" en el directorio de la aplicación

También puede ocurrir que el programa no se inicie correctamente o que su ejecución se rompa. Esto es normal y no debe preocuparnos, hay que entender que está cargando una librería que no exporta ninguna función. Lo importante es detectar signos de que la DLL vacía se ha cargado. En la Figura 7 y la Figura 8 se puede ver la comparación de los resultados de procmon para USERENV.dll al introducir una DLL vacía en el directorio de la aplicación.

Figura 8: Resultados para USERENV.dll después de introducir la

DLL "vacía" en el directorio de la aplicación

El siguiente paso para descubrir si esto puede traducirse en un DLL Hijacking será introducir un payload en nuestro DLL para que se ejecute cuando Slack lo carga. Este tema es algo más complejo que simplemente introducir el código del payload en la DLL y vamos a ver el porqué en el siguiente artículo.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

Qué es una DLL y en qué consiste el DLL Hijacking

La primera vez que nos topamos con el concepto de DLL Hijacking puede resultar un poco tedioso o difícil de comprender. Es habitual acudir a tutoriales y vídeos sobre este ataque para luego replicarlo - y en El lado del mal se ha hablado muchas veces de DLL Hijacking - y comprender en qué consiste. Aunque esto es una buena idea, creo que merece la pena invertir algo de tiempo en comprender algunos fundamentos teóricos relacionados con las DLLs y la forma en la que impacta en la seguridad de Windows.

Figura 1: Qué es una DLL y en qué consiste el DLL Hijacking

Además, como los más expertos saben, esta técnica de DLL Hijacking es una de las utilizadas en esquemas de elevación de privilegios, bypass de AMSI, evadir AppLocker, y, por supuesto, para escapar del User Account Control, en proyectos de Red Team que necesitan de realizar un Hacking de Windows, por lo que hay que conocer los detalles de esta técnica para avanzar en nuestros proyectos de Ethical Hacking.

Figura 2: Libro de Hacking Windows en 0xWord
de Valentín Martín, Carlos García y Pablo González

Para entender lo que es una DLL y la función que cumple vamos a prestar atención a su nombre: Biblioteca de Enlace Dinámico. Si programas en algún lenguaje compilado, como los de la familia del lenguaje de programación C, sabrás que una biblioteca no es otra cosa que un archivo que contiene código (como un conjunto de funciones) ya compilado y listo para ser usado en nuestros propios desarrollos.

Esto nos permite reutilizar código optimizado, testado y bien documentado para ahorramos trabajo y no “reinventar la rueda” como se suele decir. Para hacer uso de una biblioteca, un programa llamado "linker" tiene que enlazar (o vincular) esa biblioteca con nuestro código. Este enlace puede hacerse de dos formas distintas: de forma estática (Static Linking) o de forma dinámica (Dinamic Linking).

Enlace estático (Static Linking)

En este caso el "linker" enlaza la biblioteca justo después de compilar nuestro código y como resultado de este enlazamiento se obtiene el ejecutable final. A efectos prácticos se puede entender este proceso como si el "linker" hiciese un “copia y pega” de las funciones de la biblioteca estática directamente a nuestro código.

Esta forma de enlazar una biblioteca tiene sus ventajas y sus inconvenientes. Imagina que en tu sistema están corriendo diez programas que hacen uso de una misma biblioteca. Cada uno de esos programas tendría que haberse compilado y enlazado con la biblioteca, aumentando el peso de cada ejecutable en el disco y el espacio que ocupa el proceso en la memoria. Que cada uno de estos programas cargue la misma biblioteca en memoria es algo que no parece muy eficiente, por esta razón existe el enlace dinámico.

Enlace Dinámico (Dinamic Linking)

Para solucionar esta duplicidad de bibliotecas cargadas en la memoria y obtener ejecutables más ligeros se hace uso de bibliotecas compartidas o de enlace dinámico: las famosas DLLs de Windows o los archivos .so (shared object) que tan importantes son también para la seguridad y la explotación de vulnerabilidades en GNU/Linux. 

Figura 3: Diferencias entre el enlace estático y el enlace dinámico de bibliotecas

En esencia, estas bibliotecas se cargan en un espacio propio de la memoria del sistema y pueden ser accedidas por uno o varios procesos en tiempo de ejecución. Siguiendo con el ejemplo anterior; esos diez procesos harían uso de una misma biblioteca compartida que se ha cargado una sola vez en una partición de la memoria. En la figura anterior se ve más claramente las diferencias entre estas dos formas de vinculación:

La búsqueda predefinida de DLLs en Windows

En posteriores artículos de esta serie profundizaremos más en la manera en la que se vinculan los ejecutables de Windows con las DLLs, pero de momento nos basta con saber que hay dos formas de hacerlo: mediante la vinculación implícita y la explícita.

• Vinculación implícita (Implicit linking): las DLLs se cargan en la memoria a la vez que el programa que las usa. Es decir, Windows busca las DLLs que tiene que cargar al ejecutar el programa.

Figura 4: Prototipos para LoadLibraryW y LoadLibraryExW

• Vinculación explícita (Explicit linking): en este caso el sistema carga las DLLs cuando son llamadas por el programa mientras éste se está ejecutando. Esto se consigue mediante el uso de las funciones LoadLibrary y LoadLibraryEx cuyos prototipos son los de la figura anterior.

Lo importante aquí es el parámetro lpLibFileName que reciben estas funciones y que puede hacer referencia a la ruta absoluta o también al nombre de la DLL que el sistema debe cargar. Si la DLL se vincula implícitamente o si en la vinculación explícita no se especifica una ruta en la función LoadLIbrary/LoadLibraryEx, el sistema operativo Windows se encarga de buscar la DLL siguiendo un orden preestablecido. Conocer este comportamiento de Windows es el primer paso para entender el DLL Hijacking, por eso merece la pena prestarle atención a la siguiente figura:

Figura 5: Orden de búsqueda de DLLs de Windows

Antes de buscar la DLL en los archivos del sistema Windows hace dos cosas. Primero comprueba si la DLL está ya cargada en memoria. En caso afirmativo el proceso de búsqueda, se para aquí. Después comprueba si la DLL pertenece a una lista conocida como "Known DLLs". Si está en esa lista, el sistema usará su propia copia de la DLL (incluyendo las dependencias de esa DLL). Puedes encontrar la lista de los "Known DLLs" para tu sistema en el registro:

Figura 6: HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\KnownDLLs.

En cualquiera de estos dos casos la DLL se vinculará con el programa y no existirá oportunidad para un ataque de DLL Hijacking. De otra forma, cuando la DLL no está cargada en memoria y no pertenece a las Known DLL Windows buscará la DLL en los directorios en el orden especificado en la figura anterior.

Figura 7: Máxima Seguridad en Windows Gold Edition
de Sergio de los Santos en 0xWord

De todos estos directorios los más interesantes de cara a un ataque DLL Hijacking son los sombrados en rojo: el propio directorio de la aplicación y aquellos directorios definidos en la variable del sistema %PATH%, ya que son aquellos que tienen mayor probabilidad de contar con permisos mal configurados.

¿Qué es el secuestro de DLL o DLL Hijacking?

Llegados a este punto podemos definir el DLL Hijacking como el abuso de esta búsqueda sistemática de Windows mediante la detección de permisos mal configurados en los directorios en los que se buscan las DLLs. El objetivo de un ataque de DLL Hijacking es aprovechar permisos de escritura en uno de estos directorios para depositar en él una DLL con el mismo nombre que la DLL legítima pero que contenga código malicioso. 

De esta manera el sistema encontrará y cargará esa DLL antes que la DLL legítima que se pretendía cargar. El código malicioso que se introduce en la DLL suele tener el objetivo de elevar privilegios en el sistema, si el proceso que carga esa DLL se ejecuta con privilegios altos, o de generar persistencia si es un proceso que se ejecuta frecuentemente o al iniciarse el sistema.

Figura 8: DLL Hijacking para hacer un bypass de UAC en Windows 10
Aunque el concepto es siempre el mismo, se puede hablar de diferentes variantes o técnicas de DLL Hijacking. Al buscar información sobre este ataque es probable que te encuentres con términos como DLL Sideload o Phantom DLL Hijacking:

• DLL Sideload: Cuando se cuenta con permisos de escritura en un directorio que aparece en el orden de búsqueda antes que el directorio donde se encuentra el DLL legítimo. En ese directorio se pondrá la DLL maliciosa.

• Phantom DLL Hijacking: Cuando el DLL no se encuentra en ninguno de los directorios donde se busca y se tienen permisos de escritura en alguno de estos directorios, por lo que se depositará la DLL maliciosa ahí.

Cómo protegerse del DLL Hijacking

Desde el punto de vista de un programador puedes proteger tu programa del DLL Hijacking teniendo en cuenta algunas buenas prácticas de desarrollo:

1) Usar el Full Path de la DLL en las funciones LoadLibraryW / LoadLibraryA y consultar la documentación de las funciones LoadLibraryExW / LoadLibraryExA ya que permiten usar flags para modificar el comportamiento de búsqueda de DLLs por defecto. También hay que tener en cuenta que, cuando la DLL que se va a cargar tiene dependencias, éstas dependencias van a ser buscadas por Windows mediante la búsqueda sistemática habitual incluso cuando hemos especificado el Full Path para esa DLL.

2) Siempre que sea posible se deberían usar DLL firmadas y verificar esa firma antes de cargar la DLL en la memoria. Otra opción es comprobar el hash de la DLL para evitar cargar un DLL cuya integridad ha sido comprometida.

3) No es recomendable instalar programas en la raíz de una partición (por ejemplo: “C:\”) ya que por defecto los directorios creados en la raíz conceden permisos de escritura a cualquier usuario autenticado y es fácil olvidar configurarlos correctamente.

Y, por supuesto, una vez desarrollada tu aplicación conviene analizar su comportamiento para saber si es vulnerable al DLL Hijacking. Esto mismo es lo que haremos en el siguiente artículo de la serie, junto a una demostración del ataque en una aplicación vulnerable.

Saludos,  

Autor: Roberto Aranda  (Conseguir 100 Tempos para MyPublicInbox gratis con ESET)

Contactar con Roberto Aranda

Cursos Online de HackBySecurity en Diciembre para entrar a trabajar en Ciberseguridad.

Durante este mes de Diciembre, nuestros compañeros de HackBySecurity - que ayer publicaron una entrevista que me hicieron - han preparado un calendario de cinco formaciones online de seguridad con las que puedes formarte  para el futuro, si quieres trabajar en seguridad informática o ciberseguridad. Todas ellas tienen un 50% de descuento si utilizas el código NAVIDAD20, además de llevar incluidas un libro de 0xWord y 200 Tempos de  MyPublicInbox.

Figura 1: Cursos Online de HackBySecurity en Diciembre

para entrar a trabajar en Ciberseguridad.

Como ya os he dicho muchas veces, las formaciones están pensadas para prepararte el acceso al mundo profesional de ciberseguridad, así que después de hacerlas no dudes en mirar los puestos de trabajo que tenemos en ElevenPaths y Telefónica de Ciberseguridad. Estas son las que tienes para el mes de diciembre.

- CNCC (Ciberseguridad  y Normativa en Cloud Computing): El 4 de Diciembre da comienzo este curso, centrado en formar profesionales que sepan de seguridad en entornos de Cloud Computing. La computación en la nube ofrece inmensos beneficios potenciales en agilidad, flexibilidad y economía. Las organizaciones pueden moverse más rápido (ya que no tienen que comprar y aprovisionar hardware, y todo está definido por software), reducir el tiempo de inactividad (gracias a la elasticidad inherente y a otras características de la nube), y ahorrar dinero (debido a la reducción de los gastos de capital y una mejor vinculación entre la demanda y capacidad).  

Figura 2: Libro de Cifrado de las comunicaciones digitales:
de la cifra clásica a RSA 2ª Edición de 0xWord

- CSCE (Curso de Seguridad de Creación de Exploits) El próximo 9 de Diciembre da comienzo un curso de nivel intermedio en el que se va a explicar cómo construir exploits para vulnerabilidades localizadas. Es decir, cómo explotar vulnerabilidades descubiertas, así que es un curso de nivel intermedio ya que debes tener conocimientos previos de pentesting para saber cómo funciona los bugs, los exploits y la automatización de la explotación de vulnerabilidades.

 

Figura 3: Curso de Seguridad de Creación de Exploits

 

Este libro lleva como material de estudio y acompañamiento el libro de Linux Exploiting de 0xWord donde se explican las metodologías de descubrimiento y explotación de vulnerabilidades en sistemas GNU/Linux.

Figura 4: Linux Exploiting de 0xWord

- CSIO (Curso de Seguridad Informatica Ofensiva): A partir del 16 de Diciembre da comienzo este curso online de seguridad informática ofensiva donde el alumno adquirirá los conocimientos y habilidades necesarias para realizar pruebas de penetración y auditorías de seguridad informática pudiendo llegar a desempeñar puesto como el de hacker ético, pentester o auditor de ciberseguridad. Se le introducirán desde los conceptos de hacking básicos hasta la creación de sus propios exploits, pasando por las técnicas de ataque y herramientas más avanzadas y efectivas.

Figura 5: Curso Online de Seguridad Informática Ofensiva

Además, el alumno tendrá como complemento del mismo el libro de Metasploit para Pentesters Gold Edition. Este Curso Online de Seguridad Informática Ofensiva en HackBySecurity es una de las mejores opciones si lo que estás es buscando formarte profesionalmente para trabajar de pentester, y además quieres un modelo flexible de formación. 

Figura 6: Metasploit para Pentesters Gold Edition 

 

- DFIR (Curso Online de Digital Forensic & Incident Response): El 22 de Diciembre da comienzo el curso online dedicado a la disciplina de Análisis Forense tanto para el peritaje judicial, como para la gestión de los incidentes y su respuesta. El curso lo imparten los profesionales de HackBySecurity y cuenta con un temario formado por doce módulos que recorren los principales temas a conocer por todo buen analista forense.

Figura 7: Curso Online de Digital Forensic & Incident Response

El curso tiene como complemento a la formación el libro de 0xWord escrito por Pilar Vila, llamado "Técnicas de Análisis Forense para Peritos Judiciales profesionales". Pilar Vila, recientemente, ha sido nominada recientemente a los premios European Women Legal Tech 2020 por su trayectoria profesional.

Figura 8: "Técnicas de Análisis Forense Informático para
Peritos Judiciales Profesionales"
Libro de Pilar Vila en 0xWord para todos los alumnos.

- CSWS (Curso Online de Seguridad en Windows Server): Para terminar, el 29 de Diciembre, en plenas vacaciones de navidad da comienzo un nuevo curso para introducirse en el mundo de seguridad informática, en este caso para entrar en el mundo del Blue Team o los equipos de IT con perfiles de seguridad.

Figura 9: Curso Online de Seguridad en Windows Server

En este curso el alumno adquirirá los conocimientos y habilidades necesarias para fortificar un sistema operativo Windows Server. En el aprenderá qué es el hardening, desde los conceptos más básicos como la defensa en profundidad, mínimo punto de exposición, mínimo privilegio posible hasta los servicios y mecanismos de protección más actuales dentro de los sistemas Microsoft.

Figura 10: Libro Windows Server 2016: Administración, Seguridad y Operaciones
 de Ángel A. Nuñez en 0xWord

Y con él, va acompañado el libro de 0xWord de Windows Server 2016: Administración, Seguridad y Operaciones escrito por Ángel A. Nuñez, que fue nombrado Most Valuable Profesional de Microsoft por su trabajo y con el que puedes contactar en MyPublicInbox.

Y esto es todo. Hasta fin de año tendrás la oportunidad de prepararte para el futuro que nos viene en 2021. Y me niego a hacer ninguna predicción de cómo será, pero estoy convencido de que mejor estar preparado al máximo que no estarlo.

Saludos Malignos,

Autor: Chema Alonso (Contactar con Chema Alonso) - Consigue 100 Tempos en MyPublicInbox

Hacking Windows: Introducción a los ataques de “Abuse Active Directory ACLs & ACEs”

Las empresas han tenido y tienen un directorio activo para la organización de los recursos, la gestión de políticas de seguridad, para controlar las acciones, para un montón de finalidades. Es uno de los elementos clave cuando se hace un Ethical Hacking interno. Hay que saber manejarse con él, ya que las posibilidades que éste ofrece son casi infinitas.

Figura 1: Hacking Windows: Introducción a los ataques de
“Abuse Active Directory ACLs & ACEs”

En el pasado, hemos hablado de cómo llevar a cabo enumeración de usuarios con herramientas de Kali Linux a través de llamadas RPC. El pentesting a Directorio Activo abarca un gran número de técnicas, tanto de enumeración como de ataque que son interesantes estudiarlas. Es casi un “must” en los proyectos de Ethical Hacking.

Figura 2: Pentesting con Kali Silver Edition

Antes de hablar del tema del artículo de hoy, el cual es el cómo detectar que tenemos ACLs y ACEs en el Active Directory mal configuradas y que se puede aprovechar en un Hacking Windows de ello para tomar la identidad o privilegios de otro usuario, incluyendo alguna escalada de privilegio a "admin". del dominio, quería ver algunos comandos de interés que se pueden utilizar en las pruebas de hoy.

Figura 3: Hacking Windows: "Ataques a sistemas y redes Microsoft"

Pero antes de nada vamos a ver algunas órdenes útiles, ya que si se compromete un proceso de un usuario de dominio en un pentesting, se pueden ejecutar algunos de los siguientes comandos para recopilar cierta información. Lo primero es saber que el proceso que se ha comprometido pertenece a un usuario que está en dominio y no es un usuario local. Tenemos una serie de variables de entorno que estarán configuradas con información como, por ejemplo:

• USERDOMAIN. Indica el usuario de dominio que somos. Esto es equivalente al “getuid” de un Meterpreter. 

 

• LOGONSERVER. Esta variable de entorno nos dará información sobre el controlador de dominio que se ha utilizado para la autenticación. 

 

• El comando net user [usuario] /domain nos dará información sobre un usuario del dominio concreto. Lógicamente, esa máquina debe estar “atada” al dominio. 

 

• El comando net users /domain proporciona información sobre los usuarios del dominio. 

 

• El comando net groups /domain nos devuelve los grupos que hay en el dominio. 

 

• El comando net group [grupo] /domain devuelve información concreta de un grupo.

Para el artículo de hoy vamos a trabajar con Powersploit y, en particular, con PowerView. De este tipo de conjunto de scripts se habla bastante en el libro de Pentesting con Powershell 2ª Edición.

Abuse: Derechos de Generic All en grupos. A por la escalada

Existen muchas formas de detectar una mala configuración de permisos en el directorio activo. En algunas ocasiones se delegan permisos de forma no segura, quedando una mala configuración de permisos en el directorio activo. Esto es lo que vamos a aprovechar para poder escalar privilegios, metiéndonos en el grupo de administradores de dominio o tomando la identidad de otro usuario con o sin privilegios.

Figura 4: PowerSploit

Dar permisos de control total a un grupo de usuarios o a un usuario en concreto sobre algún objeto de Active Directory puede tener consecuencias graves. Con el comando Get-ObjectAcl de PowerView podemos encontrar este tipo de permisos interesantes.  Si nos fijamos en la siguiente instrucción:

‘Get-ObjectAcl -ResolveGUIDs | ? {$_.objectdn -eq "CN=Admins. del dominio,CN=Users,DC=hc,DC=local" -and $_.SecurityIdentifier -eq “[SID]”}’ 

nos vamos a fijar en el CN de Admins. Del Dominio y vamos a ver si el SID del usuario que hemos comprometido tiene algún tipo de permiso. El SID acabado en 1103 de la Figura 4 pertenece al usuario del proceso que hemos comprometido, es decir, tengo algún tipo de derecho sobre el CN de Administradores del Dominio. La sorpresa viene cuando vemos que ActiveDirectoryRights es ‘GenericAll’. 

 

Figura 5: Pentesting con PowerShell

Si revisamos la información del usuario ‘pablo’, que es el del SID acabado en 1103, vemos que no pertenece al grupo de Administradores del Dominio, pero tiene la posibilidad de pertenecer, ya que tiene permisos para ello, por una mala configuración. Este es un caso llevado al extremo, quizá no encontremos un usuario concreto, pero sí un grupo al que pertenece el usuario y podamos hacer lo mismo. O en otras ocasiones, no tendrá derechos ‘GenericAll’, pero quizá otro tipo de derechos menos ‘potentes’, pero que pueden dar el mismo resultado. Todo es ir mirando la configuración de las ACLs y los ACEs. 

Figura 6: Usuario 'pablo' no es Admin, pero podría serlo

Ahora, ejecutamos la instrucción net group “Admins. del dominio” pablo /add /domain y el usuario pertenecerá a los Administradores del Dominio, ya que por la mala configuración detectada se puede hacer. Como se puede ver en la imagen, se ha conseguido una escalada de privilegio de manera sencilla en el dominio.

Figura 7: Hemos hecho al usuario pablo administrador del dominio

Generic All sobre un usuario

En el caso de encontrarte un derecho ‘GenericAll’ sobre un usuario concreto podremos tomar la identidad de dicho usuario de manera sencilla. Puede haber o no escalada, dependiendo de los privilegios que tenga el usuario en el dominio, y de lo bien o mal que haya sido fortificado el servidor Windows Server a la hora de configurar su seguridad.

Figura 8: Windows Server 2016: Administración, Seguridad y Operaciones

La instrucción para consultar este hecho es la siguiente:

‘Get-ObjectAcl -SamAccountName [nombre_usuario] -ResolveGUIDs | ? {$_.ActiveDirectoryRights -eq "GenericAll"}’

De esta forma consultamos los permisos. En este caso lo hacemos sobre el usuario ‘fran’ y observamos que el usuario con SID acabado en 1103, es decir, el usuario ‘pablo’ tiene un control total sobre el objeto ‘fran’. De nuevo una mala configuración que permite, entre otras cosas, cambiar la credencial.

Figura 9: Pablo tiene control total sobre Fran

Para comprobar un posible cambio de credencial, ejecutamos el siguiente comando ‘net user fran [contraseña_nueva] /domain. Lo normal sería no poder hacer esto, pero en este caso, y debido a una mala configuración, obtenemos un premio.

Figura 10: Cambio de contraseña para el usuario Fran

Ahora podemos ejecutar un terminal o un proceso con la identidad del usuario ‘fran’, tal y como puede verse en la siguiente imagen.

Figura 11: Suplantando a Fran para ejecutar un terminal

Write Property & Self-Membership

Estos ‘rights’ son también interesantes. Cuando los encontramos combinados tenemos muchas posibilidades de poder hacer escalada. En este caso hemos vuelto a poner la lupa sobre el CN de Admins. del dominio.

Figura 12: CN=Admins. del dominio

Este tipo de derecho permite al usuario poder escribir y modificar o agregar usuario al grupo, en este caso. Cuando este tipo de situación se detecta podemos pasar al grupo de Administradores del Dominio, como hemos hecho anteriormente. 

Figura 13:  Pasando al grupo de "Administradores del Dominio"

El estar revisando la configuración de las ACLs puede ser un trabajo de tiempo, aunque es fundamental para mantener la seguridad de los sistemas operativos Windows. Para ello tenemos herramientas que nos ayudan a detectar este tipo de situaciones. Además, haciendo uso del lenguaje y filtros de Powershell podemos optimizar este tiempo.

Figura 14: Máxima Seguridad en Windows Gold Edition

Existen más situaciones en las ACLs y ACEs del Directorio Activo que debemos tener en cuenta:

• ForceChangePassword 

 

• WriteOwner sobre un grupo concreto 

 

• GenericWrite sobre un usuario 

 

• WriteDACL + WriteOwner

Como se puede ver es un tema que requiere de conocimiento de cómo funcionan los permisos en un nivel avanzado en el directorio activo y de tener ciertos conceptos identificados. Es un tema bastante interesante y que se puede poner en práctica y es necesario para evaluarlo en un pentesting.

Saludos,

 Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell”, "Pentesting con Kali Silver Edition" y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González - Conseguir 100 Tempos Gratis en MyPublicInbox

Figura 15: Contactar con Pablo González