Este artículo fue escrito basándose en un pentest muy exitoso que los especialistas del Grupo IB realizaron hace un par de años: sucedió una historia que podría adaptarse al cine en Bollywood. Ahora, probablemente, seguirá la reacción del lector: "Oh, otro artículo de relaciones públicas, nuevamente se están retratando, qué buenos son, no olvides comprar un pentest". Bueno, por un lado lo es. Sin embargo, hay otras razones por las que apareció este artículo. Quería mostrar qué hacen exactamente los pentesters, cuán interesante y no trivial puede ser este trabajo, qué circunstancias divertidas pueden surgir en los proyectos y, lo más importante, mostrar material en vivo con ejemplos reales.
Para restablecer el equilibrio de la modestia en el mundo, después de un tiempo escribiremos sobre un pentest que no salió bien. Mostraremos cómo los procesos bien diseñados en una empresa pueden proteger contra una amplia gama de ataques, incluso los bien preparados, simplemente porque estos procesos existen y realmente funcionan.
Para el cliente de este artículo, en general todo también fue excelente, al menos mejor que el 95% del mercado en la Federación de Rusia, en nuestra opinión, pero hubo una serie de pequeños matices que formaron una larga cadena de eventos, que al principio condujo a un extenso informe sobre el trabajo y luego a este artículo.
Entonces, abastezcamos de palomitas de maíz y bienvenidos a la historia de detectives. Palabra - Pavel Suprunyuk, responsable técnico del departamento de “Auditoría y Consultoría” del Grupo-IB.
Parte 1. Doctor Pochkin
2018 Hay un cliente: una empresa de TI de alta tecnología, que a su vez presta servicios a muchos clientes. Quiere obtener una respuesta a la pregunta: ¿es posible, sin ningún conocimiento ni acceso inicial, trabajando a través de Internet, obtener derechos de administrador de dominio de Active Directory? No estoy interesado en ninguna ingeniería social (), no pretenden interferir intencionalmente en el trabajo, pero pueden hacerlo accidentalmente, por ejemplo, recargar un servidor que funciona de manera extraña. Un objetivo adicional es identificar tantos otros vectores de ataque como sea posible contra el perímetro exterior. La empresa realiza periódicamente este tipo de pruebas y ahora ha llegado la fecha límite para realizar una nueva prueba. Las condiciones son casi típicas, adecuadas y comprensibles. Empecemos.
Hay un nombre del cliente, que sea "Empresa", con el sitio web principal. . Por supuesto, al cliente se le llama de otra manera, pero en este artículo todo será impersonal.
Realizo un reconocimiento de red: averiguo qué direcciones y dominios están registrados con el cliente, dibujo un diagrama de red y cómo se distribuyen los servicios a estas direcciones. Obtengo el resultado: más de 4000 direcciones IP activas. Miro los dominios en estas redes: afortunadamente, la gran mayoría son redes destinadas a los clientes del cliente y no estamos formalmente interesados en ellas. El cliente piensa lo mismo.
Queda una red con 256 direcciones, para la cual en este momento ya se conoce la distribución de dominios y subdominios por direcciones IP, hay información sobre los puertos escaneados, lo que significa que se pueden buscar servicios interesantes. Paralelamente, se lanzan todo tipo de escáneres en las direcciones IP disponibles y por separado en los sitios web.
Hay muchos servicios. Por lo general, esto es alegría para el pentester y la anticipación de una victoria rápida, ya que cuantos más servicios haya, mayor será el campo de ataque y más fácil será encontrar un artefacto. Un vistazo rápido a los sitios web mostró que la mayoría de ellos son interfaces web de productos conocidos de grandes empresas globales, que aparentemente dicen que no son bienvenidos. Solicitan un nombre de usuario y contraseña, sacuden el campo para ingresar el segundo factor, solicitan un certificado de cliente TLS o lo envían a Microsoft ADFS. Algunos son simplemente inaccesibles desde Internet. Para algunos, obviamente necesitas tener un cliente pago especial por tres salarios o saber la URL exacta para ingresar. Saltemos otra semana de desaliento gradual en el proceso de intentar "romper" versiones de software en busca de vulnerabilidades conocidas, buscar contenido oculto en rutas web y cuentas filtradas de servicios de terceros como LinkedIn, intentar adivinar contraseñas usándolas, también como excavar vulnerabilidades en sitios web escritos por uno mismo; por cierto, según las estadísticas, este es el vector de ataque externo más prometedor en la actualidad. Inmediatamente notaré el arma de la película que disparó posteriormente.
Entonces, encontramos dos sitios que se destacaron entre cientos de servicios. Estos sitios tenían una cosa en común: si no realiza un reconocimiento meticuloso de la red por dominio, sino que busca de frente puertos abiertos o apunta a un escáner de vulnerabilidades utilizando un rango de IP conocido, entonces estos sitios escaparán del escaneo y simplemente no serán visible sin conocer el nombre DNS. Quizás al menos se les pasó por alto antes y nuestras herramientas automáticas no encontraron ningún problema con ellos, incluso si fueron enviados directamente al recurso.
Por cierto, sobre lo que encontraron en general los escáneres lanzados anteriormente. Permítanme recordarles: para algunas personas, "pentest" equivale a "escaneo automático". Pero los escáneres de este proyecto no dijeron nada. Bueno, el máximo lo mostraron las vulnerabilidades Medias (3 de 5 en términos de gravedad): en algunos servicios, un certificado TLS incorrecto o algoritmos de cifrado obsoletos, y en la mayoría de los sitios Clickjacking. Pero esto no le llevará a su objetivo. Quizás los escáneres serían más útiles aquí, pero permítanme recordarles: el propio cliente puede comprar dichos programas y probarse con ellos y, a juzgar por los pésimos resultados, ya lo ha comprobado.
Volvamos a los sitios “anómalos”. El primero es algo así como un Wiki local en una dirección no estándar, pero en este artículo será wiki.company[.]ru. También solicitó inmediatamente un nombre de usuario y una contraseña, pero a través de NTLM en el navegador. Para el usuario, esto parece una ventana ascética que solicita ingresar un nombre de usuario y contraseña. Y esta es una mala práctica.
Una pequeña nota. NTLM en sitios web perimetrales es malo por varias razones. La primera razón es que se revela el nombre de dominio de Active Directory. En nuestro ejemplo, también resultó ser empresa.ru, al igual que el nombre DNS "externo". Sabiendo esto, puedes preparar cuidadosamente algo malicioso para que se ejecute sólo en la máquina del dominio de la organización y no en algún entorno limitado. En segundo lugar, la autenticación pasa directamente a través del controlador de dominio a través de NTLM (sorpresa, ¿no?), con todas las características de las políticas de red "internas", incluido el bloqueo de cuentas para que no excedan el número de intentos de ingreso de contraseña. Si un atacante descubre los inicios de sesión, probará las contraseñas. Si está configurado para impedir que las cuentas ingresen contraseñas incorrectas, funcionará y la cuenta se bloqueará. En tercer lugar, es imposible añadir un segundo factor a dicha autenticación. Si alguno de los lectores todavía sabe cómo, hágamelo saber, es realmente interesante. Cuarto, la vulnerabilidad a los ataques de paso de hash. ADFS se inventó, entre otras cosas, para protegerse contra todo esto.
Hay una mala propiedad de los productos de Microsoft: incluso si no publicó específicamente dicho NTLM, se instalará de forma predeterminada en OWA y Lync, al menos.
Por cierto, una vez el autor de este artículo bloqueó accidentalmente aproximadamente 1000 cuentas de empleados de un gran banco en sólo una hora usando el mismo método y luego se puso algo pálido. Los servicios informáticos del banco también palidecieron, pero todo acabó bien y adecuadamente, incluso fuimos elogiados por ser los primeros en detectar este problema y provocar una solución rápida y decisiva.
El segundo sitio tenía la dirección "obviamente algún tipo de apellido.empresa.ru". Lo encontré a través de Google, algo como esto en la página 10. El diseño era de principios o mediados de la década de XNUMX y una persona respetable lo estaba mirando desde la página principal, algo como esto:
Aquí tomé una foto fija de “Corazón de perro”, pero créanme, era vagamente similar, incluso el diseño de color era en tonos similares. Que se llame el sitio preobrazhensky.company.ru.
Era un sitio web personal... para un urólogo. Me preguntaba qué hacía el sitio web de un urólogo en el subdominio de una empresa de alta tecnología. Una rápida búsqueda en Google mostró que este médico era cofundador de una de las entidades legales de nuestro cliente e incluso aportó alrededor de 1000 rublos al capital autorizado. El sitio probablemente se creó hace muchos años y los recursos del servidor del cliente se utilizaron como alojamiento. El sitio hace tiempo que perdió su relevancia, pero por alguna razón permaneció funcionando durante mucho tiempo.
En términos de vulnerabilidades, el sitio web en sí era seguro. De cara al futuro, diré que se trataba de un conjunto de información estática: páginas HTML simples con ilustraciones insertadas en forma de riñones y vejigas. Es inútil "romper" un sitio así.
Pero el servidor web debajo era más interesante. A juzgar por el encabezado del servidor HTTP, tenía IIS 6.0, lo que significa que usaba Windows 2003 como sistema operativo. El escáner había identificado previamente que este sitio web de urólogo en particular, a diferencia de otros hosts virtuales en el mismo servidor web, respondía al comando PROPFIND, lo que significa que estaba ejecutando WebDAV. Por cierto, el escáner devolvió esta información con la marca Info (en el lenguaje de los informes del escáner, este es el peligro más bajo); estas cosas generalmente simplemente se omiten. En combinación, esto produjo un efecto interesante, que se reveló solo después de otra investigación en Google: una rara vulnerabilidad de desbordamiento de búfer asociada con el conjunto Shadow Brokers, concretamente CVE-2017-7269, que ya tenía un exploit listo para usar. En otras palabras, habrá problemas si tiene Windows 2003 y WebDAV se ejecuta en IIS. Aunque ejecutar Windows 2003 en producción en 2018 es un problema en sí mismo.
El exploit terminó en Metasploit y se probó inmediatamente con una carga que enviaba una solicitud de DNS a un servicio controlado: Burp Collaborator se utiliza tradicionalmente para detectar solicitudes de DNS. Para mi sorpresa, funcionó la primera vez: se recibió una desactivación de DNS. Luego, hubo un intento de crear una conexión de regreso a través del puerto 80 (es decir, una conexión de red desde el servidor al atacante, con acceso a cmd.exe en el host de la víctima), pero luego ocurrió un fiasco. La conexión no se produjo y después del tercer intento de utilizar el sitio, junto con todas las imágenes interesantes, desapareció para siempre.
Por lo general, esto va seguido de una carta del estilo "cliente, despierta, lo dejamos todo". Pero nos dijeron que el sitio no tiene nada que ver con los procesos comerciales y funciona allí sin ningún motivo, como todo el servidor, y que podemos usar este recurso como queramos.
Aproximadamente un día después, el sitio de repente empezó a funcionar por sí solo. Habiendo construido un banco de WebDAV en IIS 6.0, descubrí que la configuración predeterminada es reiniciar los procesos de trabajo de IIS cada 30 horas. Es decir, cuando el control salió del shellcode, el proceso de trabajo de IIS finalizó, luego se reinició un par de veces y luego permaneció en reposo durante 30 horas.
Dado que la conexión de regreso a TCP falló la primera vez, atribuí este problema a un puerto cerrado. Es decir, supuso la presencia de algún tipo de firewall que no permitía el paso de las conexiones salientes al exterior. Comencé a ejecutar códigos de shell que buscaban en muchos puertos tcp y udp, pero no hubo ningún efecto. Las cargas de conexión inversa a través de http(s) desde Metasploit no funcionaron - meterpreter/reverse_http(s). De repente, se estableció una conexión con el mismo puerto 80, pero se interrumpió inmediatamente. Lo atribuí a la acción del todavía imaginario IPS, a quien no le gustaba el tráfico de meterpreter. A la luz del hecho de que no se realizó una conexión TCP pura al puerto 80, pero sí una conexión http, llegué a la conclusión de que de alguna manera se configuró un proxy http en el sistema.
Incluso probé meterpreter a través de DNS (gracias por sus esfuerzos, salvó muchos proyectos), recordando el primer éxito, pero ni siquiera funcionó en el stand: el código shell era demasiado voluminoso para esta vulnerabilidad.
En realidad, se veía así: 3 o 4 intentos de ataque en 5 minutos y luego esperar 30 horas. Y así durante tres semanas seguidas. Incluso puse un recordatorio para no perder el tiempo. Además, hubo una diferencia en el comportamiento de los entornos de prueba y producción: para esta vulnerabilidad había dos exploits similares, uno de Metasploit y el segundo de Internet, convertido de la versión Shadow Brokers. Entonces, solo Metasploit se probó en combate, y solo el segundo se probó en el banco, lo que dificultó aún más la depuración y fue destrozado.
Al final, un código shell que descargaba un archivo exe desde un servidor determinado a través de http y lo ejecutaba en el sistema de destino resultó ser efectivo. El código shell era lo suficientemente pequeño como para caber, pero al menos funcionó. Como al servidor no le gustaba en absoluto el tráfico TCP y se inspeccionó http(s) para detectar la presencia de meterpreter, decidí que la forma más rápida era descargar un archivo exe que contuviera DNS-meterpreter a través de este código shell.
Aquí nuevamente surgió un problema: al descargar un archivo exe y, como lo demostraron los intentos, no importa cuál, la descarga se interrumpió. Nuevamente, a algún dispositivo de seguridad entre mi servidor y el urólogo no le gustó el tráfico http con un exe dentro. La solución "rápida" parecía ser cambiar el código shell para que ofusque el tráfico http sobre la marcha, de modo que se transfieran datos binarios abstractos en lugar de exe. Finalmente, el ataque tuvo éxito, el control se obtuvo a través del canal DNS delgado:
Inmediatamente quedó claro que tengo los derechos de flujo de trabajo de IIS más básicos, lo que me permite no hacer nada. Así se veía en la consola de Metasploit:
Todas las metodologías de pentest sugieren firmemente que es necesario aumentar los derechos al obtener acceso. Normalmente no hago esto localmente, ya que el primer acceso se considera simplemente como un punto de entrada a la red, y comprometer otra máquina en la misma red suele ser más fácil y rápido que escalar privilegios en un host existente. Pero este no es el caso aquí, ya que el canal DNS es muy estrecho y no permitirá que el tráfico se aclare.
Suponiendo que este servidor Windows 2003 no haya sido reparado por la famosa vulnerabilidad MS17-010, canalizo el tráfico al puerto 445/TCP a través del túnel DNS de meterpreter hacia localhost (sí, esto también es posible) e intento ejecutar el archivo ejecutable previamente descargado a través de la vulnerabilidad. El ataque funciona, recibo una segunda conexión, pero con derechos de SISTEMA.
Es interesante que todavía intentaron proteger el servidor de MS17-010: tenía servicios de red vulnerables deshabilitados en la interfaz externa. Esto protege contra ataques a través de la red, pero el ataque desde dentro en localhost funcionó, ya que no se puede desactivar rápidamente SMB en localhost.
A continuación, se revelan nuevos detalles interesantes:
- Al tener derechos de SISTEMA, puede establecer fácilmente una conexión posterior a través de TCP. Obviamente, deshabilitar TCP directo es estrictamente un problema para el usuario limitado de IIS. Spoiler: el tráfico de usuarios de IIS estaba de alguna manera envuelto en el proxy ISA local en ambas direcciones. Cómo funciona exactamente, no lo he reproducido.
- Estoy en una determinada "DMZ" (y este no es un dominio de Active Directory, sino un GRUPO DE TRABAJO); suena lógico. Pero en lugar de la dirección IP privada (“gris”) esperada, tengo una dirección IP completamente “blanca”, exactamente igual a la que ataqué antes. Esto significa que la empresa es tan antigua en el mundo de las direcciones IPv4 que puede permitirse el lujo de mantener una zona DMZ para 128 direcciones "blancas" sin NAT según el esquema, como se describe en los manuales de Cisco de 2005.
Dado que el servidor es antiguo, se garantiza que Mimikatz funcionará directamente desde la memoria:
Obtengo la contraseña del administrador local, canalizo el tráfico RDP a través de TCP e inicio sesión en un escritorio acogedor. Como podía hacer lo que quisiera con el servidor, eliminé el antivirus y descubrí que solo se podía acceder al servidor desde Internet a través de los puertos TCP 80 y 443, y el 443 no estaba ocupado. Configuré un servidor OpenVPN en 443, agregué funciones NAT para mi tráfico VPN y obtengo acceso directo a la red DMZ de forma ilimitada a través de mi OpenVPN. Es de destacar que ISA, al tener algunas funciones IPS no deshabilitadas, bloqueó mi tráfico con escaneo de puertos, por lo que tuvo que ser reemplazado por un RRAS más simple y compatible. Así que a veces los pentesters todavía tienen que administrar todo tipo de cosas.
Un lector atento preguntará: "¿Qué pasa con el segundo sitio, un wiki con autenticación NTLM, sobre el cual se ha escrito tanto?" Más sobre esto más adelante.
Parte 2. ¿Aún no estás cifrando? Entonces ya vamos a verte aquí.
Entonces, hay acceso al segmento de la red DMZ. Debes acudir al administrador del dominio. Lo primero que me viene a la mente es comprobar automáticamente la seguridad de los servicios dentro del segmento DMZ, sobre todo porque muchos más de ellos ahora están abiertos a la investigación. Una imagen típica durante una prueba de penetración: el perímetro externo está mejor protegido que los servicios internos, y cuando se obtiene acceso dentro de una gran infraestructura, es mucho más fácil obtener derechos extendidos en un dominio solo porque este dominio comienza a ser accesible a las herramientas y, en segundo lugar, en una infraestructura con varios miles de hosts, siempre habrá un par de problemas críticos.
Cargo los escáneres a través de DMZ a través de un túnel OpenVPN y espero. Abro el informe; nuevamente, nada grave, aparentemente alguien pasó por el mismo método antes que yo. El siguiente paso es examinar cómo se comunican los hosts dentro de la red DMZ. Para hacer esto, primero inicie el Wireshark habitual y escuche las solicitudes de transmisión, principalmente ARP. Los paquetes ARP se recogieron durante todo el día. Resulta que en este segmento se utilizan varias puertas de enlace. Esto será útil más adelante. Al combinar datos sobre solicitudes-respuestas de ARP y datos de escaneo de puertos, encontré los puntos de salida del tráfico de usuarios desde dentro de la red local, además de aquellos servicios que se conocían anteriormente, como web y correo.
Como por el momento no tenía acceso a otros sistemas y no tenía ni una sola cuenta para servicios corporativos, se decidió eliminar al menos una parte del tráfico mediante ARP Spoofing.
Cain&Abel se lanzó en el servidor del urólogo. Teniendo en cuenta los flujos de tráfico identificados, se seleccionaron los pares más prometedores para el ataque del intermediario y luego se recibió parte del tráfico de red mediante un lanzamiento a corto plazo durante 5 a 10 minutos, con un temporizador para reiniciar el servidor. en caso de congelación. Como en el chiste, hubo dos novedades:
- Bien: se recopilaron muchas credenciales y el ataque en su conjunto funcionó.
- Lo malo: todas las credenciales eran de los propios clientes del cliente. Mientras brindaban servicios de soporte, los especialistas en clientes se conectaban a los servicios de clientes que no siempre tenían configurado el cifrado de tráfico.
Como resultado, obtuve muchas credenciales que eran inútiles en el contexto del proyecto, pero definitivamente interesantes como demostración del peligro del ataque. Enrutadores fronterizos de grandes empresas con telnet, puertos http de depuración reenviados al CRM interno con todos los datos, acceso directo a RDP desde Windows XP en la red local y otros oscurantismo. Resultó así .
También encontré una oportunidad divertida para coleccionar cartas del tráfico, algo como esto. Este es un ejemplo de una carta ya preparada que pasó de nuestro cliente al puerto SMTP de su cliente, nuevamente, sin cifrar. Un tal Andrey le pide a su tocayo que reenvíe la documentación y la carga en un disco en la nube con un nombre de usuario, contraseña y enlace en una carta de respuesta:
Este es otro recordatorio para cifrar todos los servicios. Se desconoce quién y cuándo leerá y utilizará sus datos específicamente: el proveedor, el administrador del sistema de otra empresa o un pentester de este tipo. No digo nada sobre el hecho de que muchas personas pueden simplemente interceptar el tráfico no cifrado.
A pesar del aparente éxito, esto no nos acercó a la meta. Por supuesto, era posible sentarse durante mucho tiempo y extraer información valiosa, pero no es un hecho que apareciera allí, y el ataque en sí es muy riesgoso en términos de integridad de la red.
Después de profundizar de nuevo en los servicios, me vino a la mente una idea interesante. Existe una utilidad llamada Responder (es fácil encontrar ejemplos de uso con este nombre) que, al "envenenar" las solicitudes de transmisión, provoca conexiones a través de una variedad de protocolos como SMB, HTTP, LDAP, etc. de diferentes maneras, luego pide a todos los que se conectan que se autentiquen y lo configura para que la autenticación se realice a través de NTLM y en un modo transparente para la víctima. La mayoría de las veces, un atacante recopila protocolos de enlace NetNTLMv2 de esta manera y, a partir de ellos, utilizando un diccionario, recupera rápidamente las contraseñas de dominio de los usuarios. Aquí quería algo similar, pero los usuarios se sentaban "detrás de una pared", o mejor dicho, estaban separados por un firewall y accedían a la WEB a través del clúster de proxy de Blue Coat.
¿Recuerda que especifiqué que el nombre de dominio de Active Directory coincidía con el dominio "externo", es decir, era empresa.ru? Así, Windows, más precisamente Internet Explorer (y Edge y Chrome), permiten al usuario autenticarse de forma transparente en HTTP vía NTLM si considera que el sitio está ubicado en alguna “Zona de Intranet”. Una de las señales de una “Intranet” es el acceso a una dirección IP “gris” o un nombre DNS corto, es decir, sin puntos. Como tenían un servidor con una IP "blanca" y un nombre DNS preobrazhensky.company.ru, y las máquinas de dominio generalmente reciben el sufijo de dominio de Active Directory a través de DHCP para simplificar la entrada del nombre, solo tenían que escribir la URL en la barra de direcciones. , para que encuentren el camino correcto al servidor del urólogo comprometido, sin olvidar que ahora se llama “Intranet”. Es decir, al mismo tiempo darme el apretón de manos NTLM del usuario sin su conocimiento. Sólo queda obligar a los navegadores de los clientes a pensar en la necesidad urgente de ponerse en contacto con este servidor.
La maravillosa utilidad Intercepter-NG vino al rescate (gracias ). Le permitía cambiar el tráfico sobre la marcha y funcionó muy bien en Windows 2003. Incluso tenía una funcionalidad separada para modificar sólo archivos JavaScript en el flujo de tráfico. Se planeó una especie de Cross-Site Scripting masivo.
Los servidores proxy de Blue Coat, a través de los cuales los usuarios accedían a la WEB global, almacenaban en caché periódicamente contenido estático. Al interceptar el tráfico, quedó claro que estaban trabajando las XNUMX horas del día, solicitando interminablemente estática de uso frecuente para acelerar la visualización del contenido durante las horas pico. Además, BlueCoat contaba con un User-Agent específico, que lo distinguía claramente de un usuario real.
Se preparó Javascript, el cual utilizando Intercepter-NG se implementó durante una hora en la noche para cada respuesta con archivos JS para Blue Coat. El guión hizo lo siguiente:
- Determinado el navegador actual por User-Agent. Si era Internet Explorer, Edge o Chrome seguía funcionando.
- Esperé hasta que se formó el DOM de la página.
- Insertó una imagen invisible en el DOM con un atributo src del formulario :8080/NNNNNNN.png, donde NNN son números arbitrarios para que BlueCoat no los almacene en caché.
- Establezca una variable de bandera global para indicar que la inyección se completó y que ya no es necesario insertar imágenes.
El navegador intentó cargar esta imagen; en el puerto 8080 del servidor comprometido, un túnel TCP estaba esperando hasta mi computadora portátil, donde se estaba ejecutando el mismo Responder, lo que requería que el navegador iniciara sesión a través de NTLM.
A juzgar por los registros de Responder, la gente vino a trabajar por la mañana, encendió sus estaciones de trabajo y luego, en masa y sin ser notada, comenzaron a visitar el servidor del urólogo, sin olvidar "agotar" los apretones de manos de NTLM. Los apretones de manos llovieron durante todo el día y claramente se acumuló material para un ataque obviamente exitoso para recuperar contraseñas. Así es como se veían los registros de Responder:
Visitas masivas y secretas al servidor de urólogo por parte de los usuarios
Probablemente ya hayas notado que toda esta historia se basa en el principio "todo estuvo bien, pero luego hubo un fastidio, luego hubo una superación y luego todo llegó al éxito". Entonces, hubo un fastidio aquí. De los cincuenta apretones de manos únicos, no se reveló ni uno solo. Y esto tiene en cuenta el hecho de que incluso en una computadora portátil con un procesador inactivo, estos protocolos de enlace NTLMv2 se procesan a una velocidad de varios cientos de millones de intentos por segundo.
Tuve que armarme con técnicas de mutación de contraseñas, una tarjeta de video, un diccionario más grueso y esperar. Después de mucho tiempo, se revelaron varias cuentas con contraseñas del tipo “Q11111111....1111111q”, lo que sugiere que todos los usuarios alguna vez se vieron obligados a crear una contraseña muy larga con diferentes caracteres en mayúsculas y minúsculas, que también se suponía que ser complejo. Pero no se puede engañar a un usuario experimentado, y así es como él mismo se hizo más fácil de recordar. En total, unas cinco cuentas se vieron comprometidas y sólo una de ellas tenía derechos valiosos sobre los servicios.
Parte 3. Roskomnadzor contraataca
Entonces se recibieron las primeras cuentas de dominio. Si a estas alturas no te has quedado dormido tras una larga lectura, probablemente recordarás que mencioné un servicio que no requería un segundo factor de autenticación: es un wiki con autenticación NTLM. Por supuesto, lo primero que había que hacer era entrar allí. Profundizar en la base de conocimientos interna rápidamente arrojó resultados:
- La empresa dispone de una red WiFi con autenticación mediante cuentas de dominio con acceso a la red local. Con el conjunto de datos actual, este ya es un vector de ataque funcional, pero es necesario ir a la oficina con los pies y ubicarse en algún lugar del territorio de la oficina del cliente.
- Encontré una instrucción según la cual había un servicio que permitía... registrar de forma independiente un dispositivo de autenticación de "segundo factor" si el usuario está dentro de una red local y recuerda con seguridad su nombre de usuario y contraseña de dominio. En este caso, “interior” y “exterior” estaban determinados por la accesibilidad del puerto de este servicio para el usuario. No se podía acceder al puerto desde Internet, pero sí a través de la DMZ.
Por supuesto, inmediatamente se agregó un “segundo factor” a la cuenta comprometida en forma de una aplicación en mi teléfono. Había un programa que podía enviar en voz alta una solicitud push al teléfono con botones de “aprobar”/“rechazar” para la acción, o mostrar silenciosamente el código OTP en la pantalla para una entrada independiente adicional. Además, las instrucciones suponían que el primer método era el único correcto, pero no funcionó, a diferencia del método OTP.
Con el “segundo factor” roto, pude acceder al correo de Outlook Web Access y al acceso remoto en Citrix Netscaler Gateway. Había una sorpresa en el correo de Outlook:
En esta rara toma puedes ver cómo Roskomnadzor ayuda a los pentesters.
Fueron los primeros meses después del famoso bloqueo de Telegram por parte de los “fanáticos”, cuando redes enteras con miles de direcciones desaparecieron inexorablemente del acceso. Quedó claro por qué la presión no funcionó de inmediato y por qué mi “víctima” no hizo sonar la alarma porque comenzaron a usar su cuenta durante el horario de atención.
Cualquiera que esté familiarizado con Citrix Netscaler imagina que generalmente se implementa de tal manera que solo se puede transmitir al usuario una interfaz de imagen, tratando de no darle las herramientas para ejecutar aplicaciones de terceros y transferir datos, limitando en todos los sentidos las acciones. a través de shells de control estándar. Mi “víctima”, debido a su ocupación, solo obtuvo 1C:
Después de recorrer un poco la interfaz 1C, descubrí que allí hay módulos de procesamiento externos. Se pueden cargar desde la interfaz y se ejecutarán en el cliente o servidor, según los derechos y la configuración.
Les pedí a mis amigos programadores de 1C que crearan un procesamiento que aceptara una cadena y la ejecutara. En lenguaje 1C, iniciar un proceso se parece a esto (tomado de Internet). ¿Está de acuerdo en que la sintaxis del idioma 1C sorprende a los hablantes de ruso por su espontaneidad?
El procesamiento se ejecutó perfectamente, resultó ser lo que los pentesters llaman un "shell": a través de él se lanzó Internet Explorer.
Anteriormente en el correo se encontró la dirección de un sistema que permite solicitar pases para el territorio. Pedí un pase en caso de que tuviera que utilizar un vector de ataque WiFi.
Se habla en Internet de que todavía había un delicioso catering gratuito en la oficina del cliente, pero yo preferí desarrollar el ataque de forma remota, es más tranquilo.
AppLocker se activó en el servidor de aplicaciones que ejecuta Citrix, pero se omitió. El mismo Meterpreter se cargó y se inició a través de DNS, ya que las versiones http(s) no querían conectarse y yo no conocía la dirección del proxy interno en ese momento. Por cierto, a partir de este momento, el pentest externo se convirtió esencialmente por completo en interno.
Parte 4. Los derechos de administrador para los usuarios son malos, ¿de acuerdo?
La primera tarea de un pentester al obtener el control de la sesión de un usuario de dominio es recopilar toda la información sobre los derechos en el dominio. Existe una utilidad BloodHound que le permite descargar automáticamente información sobre usuarios, computadoras, grupos de seguridad a través del protocolo LDAP desde un controlador de dominio y a través de SMB: información sobre qué usuario inició sesión recientemente, dónde y quién es el administrador local.
Una técnica típica para obtener derechos de administrador de dominio parece simplificada como un ciclo de acciones monótonas:
- Nos dirigimos a las computadoras del dominio donde hay derechos de administrador local, según las cuentas de dominio ya capturadas.
- Lanzamos Mimikatz y obtenemos contraseñas almacenadas en caché, tickets de Kerberos y hashes NTLM de cuentas de dominio que iniciaron sesión recientemente en este sistema. O eliminamos la imagen de memoria del proceso lsass.exe y hacemos lo mismo por nuestra parte. Esto funciona bien con Windows anterior a 2012R2/Windows 8.1 con la configuración predeterminada.
- Determinamos dónde las cuentas comprometidas tienen derechos de administrador local. Repetimos el primer punto. En algún momento obtenemos derechos de administrador para todo el dominio.
“Fin del ciclo”, como escribirían aquí los programadores de 1C.
Entonces, nuestro usuario resultó ser un administrador local en un solo host con Windows 7, cuyo nombre incluía la palabra "VDI" o "Virtual Desktop Infrastructure", máquinas virtuales personales. Probablemente, el diseñador del servicio VDI quiso decir que, dado que VDI es el sistema operativo personal del usuario, incluso si el usuario cambia el entorno del software a su gusto, el host aún se puede "recargar". También pensé que en general la idea era buena, fui a este host VDI personal e hice un nido allí:
- Instalé allí un cliente OpenVPN, que creó un túnel a través de Internet hasta mi servidor. El cliente tuvo que ser obligado a pasar por el mismo Blue Coat con autenticación de dominio, pero OpenVPN lo hizo, como dicen, "listo para usar".
- OpenSSH instalado en VDI. Bueno, en serio, ¿qué es Windows 7 sin SSH?
Así se veía en vivo. Permítanme recordarles que todo esto debe hacerse a través de Citrix y 1C:
Una técnica para promover el acceso a computadoras vecinas es verificar que las contraseñas del administrador local coincidan. Aquí la suerte nos aguardó de inmediato: el hash NTLM del administrador local predeterminado (que de repente se llamó Administrador) fue abordado mediante un ataque pass-the-hash a hosts VDI vecinos, de los cuales había varios cientos. Por supuesto, el ataque los golpeó de inmediato.
Aquí los administradores de VDI se pegaron dos tiros en el pie:
- La primera vez fue cuando las máquinas VDI no se incorporaron a LAPS, esencialmente conservando la misma contraseña de administrador local de la imagen que se implementó masivamente en VDI.
- El administrador predeterminado es la única cuenta local vulnerable a ataques de paso de hash. Incluso con la misma contraseña, sería posible evitar un compromiso masivo creando una segunda cuenta de administrador local con una contraseña aleatoria compleja y bloqueando la predeterminada.
¿Por qué hay un servicio SSH en ese Windows? Muy simple: ahora el servidor OpenSSH no solo proporcionó un conveniente shell de comandos interactivo sin interferir con el trabajo del usuario, sino también un proxy calcetines5 en VDI. A través de estos calcetines, me conecté a través de SMB y recopilé cuentas en caché de todos estos cientos de máquinas VDI, luego busqué la ruta al administrador del dominio usándolas en los gráficos de BloodHound. Con cientos de hosts a mi disposición, encontré este camino con bastante rapidez. Se han obtenido derechos de administrador de dominio.
Aquí hay una imagen de Internet que muestra una búsqueda similar. Las conexiones muestran quién está dónde está el administrador y quién ha iniciado sesión y dónde.
Por cierto, recuerde la condición desde el inicio del proyecto: "no utilizar ingeniería social". Por lo tanto, propongo pensar en cuánto se eliminaría todo este Bollywood con efectos especiales si todavía fuera posible utilizar el phishing banal. Pero personalmente fue muy interesante para mí hacer todo esto. Espero que hayas disfrutado leyendo esto. Por supuesto, no todos los proyectos parecen tan intrigantes, pero el trabajo en su conjunto es muy desafiante y no permite que se estanque.
Probablemente alguien tendrá una pregunta: ¿cómo protegerse? Incluso este artículo describe muchas técnicas, muchas de las cuales los administradores de Windows ni siquiera conocen. Sin embargo, propongo mirarlos desde la perspectiva de principios trillados y medidas de seguridad de la información:
- no utilice software obsoleto (¿recuerda Windows 2003 al principio?)
- no mantenga encendidos sistemas innecesarios (¿por qué había un sitio web de urólogo?)
- verifique usted mismo las contraseñas de los usuarios (de lo contrario, los soldados... los pentesters harán esto)
- no tener las mismas contraseñas para diferentes cuentas (compromiso de VDI)
- y otro
Por supuesto, esto es muy difícil de implementar, pero en el próximo artículo mostraremos en la práctica que es bastante posible.
Fuente: habr.com