Había unha pentest, ou Como romper todo coa axuda dun urólogo e Roskomnadzor

Este artigo foi escrito a partir dun pentest de gran éxito que os especialistas do Grupo-IB realizaron hai un par de anos: aconteceu unha historia que podería adaptarse ao cine en Bollywood. Agora, probablemente, seguirá a reacción do lector: "Oh, outro artigo de RP, de novo estes están sendo retratados, que bos son, non esquezas mercar un pentest". Ben, por unha banda, é. Non obstante, hai outras moitas razóns polas que apareceu este artigo. Quería mostrar o que fan exactamente os pentesteres, o interesante e nada trivial que pode ser este traballo, que circunstancias divertidas poden darse nos proxectos e, o máis importante, mostrar material en directo con exemplos reais.

Para restablecer o equilibrio da modestia no mundo, despois dun tempo escribiremos sobre un pentest que non saíu ben. Mostraremos como os procesos ben deseñados nunha empresa poden protexer contra toda unha serie de ataques, incluso ben preparados, simplemente porque estes procesos existen e realmente funcionan.

Para o cliente deste artigo, todo foi en xeral excelente, polo menos mellor que o 95% do mercado na Federación Rusa, segundo os nosos sentimentos, pero houbo unha serie de pequenos matices que formaron unha longa cadea de eventos, que primeiro levou a un longo informe sobre o traballo, e despois a este artigo.

Entón, imos abastecernos de palomitas e benvidos á historia de detectives. palabra - Pavel Suprunyuk, responsable técnico do departamento de “Auditoria e Consultoría” do Grupo-IB.

Parte 1. Doutor Pochkin

2018 Hai un cliente: unha empresa de TI de alta tecnoloxía, que atende a moitos clientes. Quere obter unha resposta á pregunta: é posible, sen ningún coñecemento e acceso inicial, traballando a través de Internet, obter dereitos de administrador de dominios de Active Directory? Non me interesa ningunha enxeñería social (ai, pero en balde), non pretenden interferir co traballo adrede, pero poden recargar accidentalmente un servidor estraño, por exemplo. Un obxectivo adicional é identificar tantos outros vectores de ataque como sexa posible contra o perímetro exterior. A empresa realiza regularmente este tipo de probas, e agora chegou o prazo para unha nova proba. As condicións son case típicas, adecuadas, comprensibles. Imos comezar.

Hai un nome do cliente: sexa "Empresa", co sitio web principal www.company.ru. Por suposto, o cliente chámase de forma diferente, pero neste artigo todo será impersoal.
Realizo o recoñecemento da rede: descubro que enderezos e dominios están rexistrados co cliente, debuxo un diagrama de rede e como se distribúen os servizos a estes enderezos. Recibo o resultado: máis de 4000 enderezos IP en directo. Observo os dominios destas redes: afortunadamente, a gran maioría son redes destinadas aos clientes do cliente, e formalmente non nos interesan elas. O cliente pensa o mesmo.

Queda unha rede con 256 enderezos, para o que a estas alturas xa hai unha comprensión da distribución de dominios e subdominios por enderezos IP, hai información sobre os portos escaneados, o que significa que podes consultar os servizos para outros interesantes. Paralelamente, lánzanse todo tipo de escáneres en enderezos IP dispoñibles e por separado en sitios web.

Hai moitos servizos. Normalmente isto é a alegría para o pentester e a anticipación dunha vitoria rápida, xa que cantos máis servizos haxa, máis grande é o campo de ataque e máis fácil é atopar un artefacto. Unha ollada rápida aos sitios web demostrou que a maioría deles son interfaces web de produtos coñecidos de grandes empresas globais, que por todas as aparencias din que non son benvidos. Piden un nome de usuario e contrasinal, sacuden o campo para introducir o segundo factor, piden un certificado de cliente TLS ou envíano a Microsoft ADFS. Algúns son simplemente inaccesibles desde Internet. Para algúns, obviamente necesitas ter un cliente pagado especial por tres salarios ou saber o URL exacto para ingresar. Omitamos outra semana de abatemento gradual no proceso de tentar "romper" versións de software para vulnerabilidades coñecidas, buscar contido oculto en rutas web e contas filtradas de servizos de terceiros como LinkedIn, tentando adiviñar contrasinais que os usan, así como como escavar vulnerabilidades en sitios web autoescritos; por certo, segundo as estatísticas, este é o vector máis prometedor de ataque externo na actualidade. Inmediatamente notarei a pistola de cine que disparou posteriormente.

Así, atopamos dous sitios que destacaron entre centos de servizos. Estes sitios tiñan unha cousa en común: se non realizas un minucioso recoñecemento da rede por dominio, pero buscas de frente portos abertos ou apuntas a un escáner de vulnerabilidades usando un rango de IP coñecido, estes sitios escaparán da exploración e simplemente non serán visible sen coñecer o nome DNS. Quizais se perderon antes, polo menos, e as nosas ferramentas automáticas non atoparon ningún problema con elas, aínda que fosen enviadas directamente ao recurso.

Por certo, sobre o que os escáneres lanzados anteriormente atopaban en xeral. Permíteme lembrarche: para algunhas persoas, "pentest" é equivalente a "escaneo automático". Pero os escáneres deste proxecto non dixeron nada. Pois ben, o máximo mostrárono as vulnerabilidades Medianas (3 de cada 5 en canto a gravidade): nalgún servizo un certificado TLS incorrecto ou algoritmos de cifrado desactualizados e na maioría dos sitios Clickjacking. Pero isto non che levará ao teu obxectivo. Quizais os escáneres sexan máis útiles aquí, pero permíteme lembrarche: o propio cliente é capaz de mercar tales programas e probarse con eles e, a xulgar polos pésimos resultados, xa comprobou.

Volvamos aos sitios "anómalos". O primeiro é algo así como un Wiki local nun enderezo non estándar, pero neste artigo déixao ser wiki.company[.]ru. Tamén pediu inmediatamente un inicio de sesión e un contrasinal, pero a través de NTLM no navegador. Para o usuario, isto parece unha xanela ascética que pide que introduza un nome de usuario e un contrasinal. E esta é unha mala práctica.

Unha pequena nota. NTLM nos sitios web perimetrais é malo por varias razóns. O primeiro motivo é que se revela o nome de dominio de Active Directory. No noso exemplo, tamén resultou ser company.ru, igual que o nome DNS "externo". Sabendo isto, podes preparar coidadosamente algo malicioso para que se execute só na máquina de dominio da organización, e non nalgún sandbox. En segundo lugar, a autenticación pasa directamente polo controlador de dominio a través de NTLM (sorpresa, non?), con todas as funcións das políticas de rede "internas", incluíndo o bloqueo de contas para evitar que superen o número de intentos de entrada de contrasinal. Se un atacante descobre os inicios de sesión, buscará contrasinais para eles. Se estás configurado para impedir que as contas introduzan contrasinais incorrectos, funcionará e bloquearase a conta. En terceiro lugar, é imposible engadir un segundo factor a tal autenticación. Se algún dos lectores aínda sabe como facelo, por favor, avísame, é moi interesante. En cuarto lugar, a vulnerabilidade aos ataques pass-the-hash. ADFS inventouse, entre outras cousas, para protexer contra todo isto.

Hai unha propiedade errónea dos produtos de Microsoft: aínda que non publicou especificamente tal NTLM, instalarase por defecto en OWA e Lync, polo menos.

Por certo, o autor deste artigo bloqueou accidentalmente unhas 1000 contas de empregados dun gran banco en só unha hora usando o mesmo método e despois parecía algo pálido. Os servizos informáticos do banco tamén foron pálidos, pero todo rematou ben e axeitadamente, mesmo nos encomiaron por ser os primeiros en atopar este problema e provocar unha solución rápida e decidida.

O segundo sitio tiña o enderezo "obviamente algún tipo de apelido.company.ru". Atopámolo a través de Google, algo así na páxina 10. O deseño era de principios e mediados da década de XNUMX, e unha persoa respectable estaba mirando desde a páxina principal, algo así:

Aquí tirei un fotograma de "Heart of a Dog", pero créame, era vagamente semellante, incluso o deseño da cor era en tons similares. Deixa que o sitio sexa chamado preobrazhensky.company.ru.

Era un sitio web persoal... para un urólogo. Pregunteime que estaba facendo o sitio web dun urólogo no subdominio dunha empresa de alta tecnoloxía. Unha investigación rápida en Google demostrou que este doutor era cofundador dunha das persoas xurídicas dos nosos clientes e mesmo achegou uns 1000 rublos no capital autorizado. O sitio probablemente foi creado hai moitos anos e os recursos do servidor do cliente utilizáronse como hospedaxe. O sitio perdeu a súa relevancia hai tempo, pero por algún motivo deixouse funcionar durante moito tempo.

En canto ás vulnerabilidades, o sitio web en si era seguro. De cara ao futuro, direi que se trataba dun conxunto de información estática: páxinas html sinxelas con ilustracións inseridas en forma de riles e vexigas. É inútil "romper" tal sitio.

Pero o servidor web de abaixo era máis interesante. A xulgar pola cabeceira do servidor HTTP, tiña IIS 6.0, o que significa que usaba Windows 2003 como sistema operativo. O escáner identificara previamente que este sitio web de urólogos en particular, a diferenza doutros servidores virtuais do mesmo servidor web, respondeu ao comando PROPFIND, o que significa que estaba a executar WebDAV. Por certo, o escáner devolveu esta información coa marca Información (no idioma dos informes do escáner, este é o perigo máis baixo) - tales cousas adoitan omitirse. En combinación, isto deu un efecto interesante, que só se revelou despois doutra escavación en Google: unha rara vulnerabilidade de desbordamento do búfer asociada ao conxunto Shadow Brokers, a saber, CVE-2017-7269, que xa tiña un exploit preparado. Noutras palabras, haberá problemas se tes Windows 2003 e WebDAV funciona con IIS. Aínda que executar Windows 2003 en produción en 2018 é un problema en si mesmo.

O exploit acabou en Metasploit e probouse inmediatamente cunha carga que enviou unha solicitude de DNS a un servizo controlado: Burp Collaborator úsase tradicionalmente para capturar solicitudes de DNS. Para a miña sorpresa, funcionou a primeira vez: recibiuse un knockout de DNS. A continuación, intentouse crear unha conexión posterior a través do porto 80 (é dicir, unha conexión de rede do servidor ao atacante, con acceso a cmd.exe no host da vítima), pero entón produciuse un fiasco. A conexión non chegou e despois do terceiro intento de usar o sitio, xunto con todas as imaxes interesantes, desapareceron para sempre.

Normalmente isto vai seguido dunha carta do estilo de "cliente, esperta, deixamos todo". Pero dixéronnos que o sitio non ten nada que ver cos procesos comerciais e funciona alí sen ningún motivo, como todo o servidor, e que podemos usar este recurso como queiramos.
Aproximadamente un día despois, o sitio comezou a funcionar de súpeto. Despois de construír un banco de WebDAV en IIS 6.0, descubrín que a configuración predeterminada é reiniciar os procesos de traballo de IIS cada 30 horas. É dicir, cando o control saíu do shellcode, o proceso de traballo de IIS rematou, reiniciouse por si mesmo un par de veces e despois foi parado durante 30 horas.

Dado que a conexión posterior a tcp fallou a primeira vez, atribuín este problema a un porto pechado. É dicir, asumiu a presenza dalgún tipo de cortalumes que non permitía pasar as conexións de saída ao exterior. Comecei a executar shellcodes que buscaban a través de moitos portos tcp e udp, non houbo ningún efecto. As cargas de conexión inversa a través de http(s) de Metasploit non funcionaron: meterpreter/reverse_http(s). De súpeto, estableceuse unha conexión co mesmo porto 80, pero caeu inmediatamente. Atribuín isto á acción do aínda imaxinario IPS, ao que non lle gustaba o tráfico de meterpreter. Tendo en conta o feito de que non pasou unha conexión tcp pura ao porto 80, pero si unha conexión http, concluín que un proxy http estaba configurado dalgún xeito no sistema.

Incluso probei meterpreter a través de DNS (grazas d00kie polos teus esforzos, salvou moitos proxectos), recordando o primeiro éxito, pero nin sequera funcionou no stand: o shellcode era demasiado voluminoso para esta vulnerabilidade.

En realidade, parecía así: 3-4 intentos de ataque en 5 minutos, despois esperando 30 horas. E así durante tres semanas seguidas. Incluso fixen un recordatorio para non perder o tempo. Ademais, houbo unha diferenza no comportamento dos contornos de proba e produción: para esta vulnerabilidade houbo dous exploits similares, un de Metasploit, o segundo de Internet, convertido da versión de Shadow Brokers. Entón, só Metasploit foi probado en combate, e só o segundo foi probado no banco, o que dificultou aínda máis a depuración e rompeu o cerebro.

Ao final, un shellcode que descargaba un ficheiro exe dun servidor determinado a través de http e o lanzou no sistema de destino resultou ser eficaz. O shellcode era o suficientemente pequeno como para caber, pero polo menos funcionou. Dado que ao servidor non lle gustaba nada o tráfico TCP e inspeccionáronse http(s) para detectar a presenza de meterpreter, decidín que o xeito máis rápido era descargar un ficheiro exe que contiña DNS-meterpreter a través deste shellcode.

Aquí de novo xurdiu un problema: ao descargar un ficheiro exe e, como demostraron os intentos, sen importar cal, a descarga interrompeuse. De novo, a algún dispositivo de seguridade entre o meu servidor e o urólogo non lle gustou o tráfico http cun exe dentro. A solución "rápida" parecía ser cambiar o shellcode para que ofuscase o tráfico http sobre a marcha, de xeito que se transferirían datos binarios abstractos en lugar de exe. Finalmente, o ataque foi exitoso, recibiuse o control a través da fina canle DNS:

Inmediatamente quedou claro que teño os dereitos de fluxo de traballo de IIS máis básicos, que non me permiten facer nada. Este é o que parecía na consola Metasploit:

Todas as metodoloxías de Pentest suxiren encarecidamente que cómpre aumentar os dereitos ao acceder. Normalmente non o fago localmente, xa que o primeiro acceso é visto simplemente como un punto de entrada á rede, e comprometer outra máquina na mesma rede adoita ser máis fácil e rápido que aumentar os privilexios nun host existente. Pero este non é o caso aquí, xa que a canle DNS é moi estreita e non permitirá limpar o tráfico.

Asumindo que este servidor de Windows 2003 non foi reparado pola famosa vulnerabilidade MS17-010, túnel o tráfico ao porto 445/TCP a través do túnel DNS de meterpreter ata localhost (si, isto tamén é posible) e intento executar o exe descargado anteriormente a través a vulnerabilidade. O ataque funciona, recibo unha segunda conexión, pero con dereitos de SISTEMA.

É interesante que aínda intentaron protexer o servidor de MS17-010: tiña os servizos de rede vulnerables desactivados na interface externa. Isto protexe contra ataques a través da rede, pero o ataque desde dentro de localhost funcionou, xa que non podes desactivar rapidamente SMB en localhost.

A continuación, revélanse novos detalles interesantes:

1. Tendo dereitos de SISTEMA, pode establecer facilmente unha retroconexión a través de TCP. Obviamente, desactivar TCP directo é estrictamente un problema para o usuario limitado de IIS. Spoiler: o tráfico de usuarios de IIS estaba envolto dalgún xeito no proxy ISA local en ambas direccións. Como funciona exactamente, non o reproducín.
2. Estou nunha determinada "DMZ" (e este non é un dominio de Active Directory, senón un GRUPO DE TRABALLO) - parece lóxico. Pero en lugar do esperado enderezo IP privado ("gris"), teño un enderezo IP completamente "branco", exactamente o mesmo que o que atacei anteriormente. Isto significa que a empresa é tan antiga no mundo do enderezo IPv4 que pode permitirse o luxo de manter unha zona DMZ para 128 enderezos "brancos" sen NAT segundo o esquema, como se describe nos manuais de Cisco de 2005.

Dado que o servidor é antigo, Mimikatz pode funcionar directamente desde a memoria:

Recibo o contrasinal do administrador local, túnel o tráfico RDP a través de TCP e inicie sesión nun escritorio acolledor. Como podía facer o que quixese co servidor, quitei o antivirus e atopei que o servidor era accesible desde Internet só a través dos portos TCP 80 e 443, e 443 non estaba ocupado. Configurei un servidor OpenVPN en 443, engado funcións NAT para o meu tráfico VPN e teño acceso directo á rede DMZ de forma ilimitada a través do meu OpenVPN. Cabe destacar que ISA, ao ter algunhas funcións IPS non desactivadas, bloqueou o meu tráfico coa exploración de portos, para o que tivo que ser substituído por un RRAS máis sinxelo e compatible. Entón, os pentestres ás veces aínda teñen que administrar todo tipo de cousas.

Un lector atento preguntará: "E o segundo sitio: unha wiki con autenticación NTLM, sobre a que se escribiu tanto?" Máis sobre isto despois.

Parte 2. Aínda non estás a cifrar? Entón xa estamos chegando a ti

Polo tanto, hai acceso ao segmento de rede DMZ. Debes ir ao administrador do dominio. O primeiro que se me ocorre é comprobar automaticamente a seguridade dos servizos dentro do segmento DMZ, especialmente porque agora moitos máis están abertos para a investigación. Unha imaxe típica durante unha proba de penetración: o perímetro externo está mellor protexido que os servizos internos, e cando se accede a calquera acceso dentro dunha gran infraestrutura, é moito máis doado obter dereitos ampliados nun dominio só debido ao feito de que este dominio comeza a ser accesible ás ferramentas e, en segundo lugar, nunha infraestrutura con varios miles de hosts, sempre haberá un par de problemas críticos.

Cargo os escáneres vía DMZ a través dun túnel OpenVPN e espero. Abro o informe, de novo nada grave, ao parecer alguén pasou polo mesmo método antes que min. O seguinte paso é examinar como se comunican os hosts dentro da rede DMZ. Para iso, primeiro inicie o Wireshark habitual e escoite as solicitudes de transmisión, principalmente ARP. Os paquetes ARP recolléronse durante todo o día. Resulta que neste segmento utilízanse varias pasarelas. Isto será útil máis tarde. Ao combinar datos sobre solicitudes-respostas ARP e datos de exploración de portos, atopei os puntos de saída do tráfico de usuarios desde dentro da rede local ademais dos servizos que antes se coñecían, como a web e o correo.

Dado que polo momento non tiña acceso a outros sistemas e non tiña unha única conta para os servizos corporativos, decidiuse pescar polo menos algunha conta do tráfico mediante ARP Spoofing.

Cain&Abel lanzouse no servidor do urólogo. Tendo en conta os fluxos de tráfico identificados, seleccionáronse os pares máis prometedores para o ataque man-in-the-middle, e despois recibiuse algo de tráfico de rede mediante un lanzamento a curto prazo durante 5-10 minutos, cun temporizador para reiniciar o servidor. en caso de conxelación. Como na broma, había dúas novidades:

1. Ben: recolléronse moitas credenciais e funcionou o ataque no seu conxunto.
2. O malo: todas as credenciais eran dos propios clientes do cliente. Mentres prestaban servizos de soporte, os especialistas en clientes conectaron aos servizos de clientes que non sempre tiñan configurado o cifrado de tráfico.

Como resultado, adquirín moitas credenciais que foron inútiles no contexto do proxecto, pero definitivamente interesantes como demostración do perigo do ataque. Enrutadores fronteirizos de grandes empresas con telnet, portos http de depuración reenviados a CRM interno con todos os datos, acceso directo a RDP desde Windows XP na rede local e outro escurantismo. Resultou así Compromiso da cadea de subministración segundo a matriz MITRE.

Tamén atopei unha divertida oportunidade de recoller cartas do tráfico, algo así. Este é un exemplo dunha carta preparada que pasou do noso cliente ao porto SMTP do seu cliente, de novo, sen cifrado. Un tal Andrey pídelle ao seu homónimo que reenvíe a documentación e cárgase nun disco na nube cun inicio de sesión, contrasinal e ligazón nunha carta de resposta:

Este é outro recordatorio para cifrar todos os servizos. Descoñécese quen e cando lerá e utilizará os seus datos específicamente: o provedor, o administrador do sistema doutra empresa ou un pentester deste tipo. Calo sobre o feito de que moitas persoas poden simplemente interceptar o tráfico sen cifrar.

A pesar do aparente éxito, isto non nos achegou ao gol. Era posible, por suposto, sentarse durante moito tempo e pescar información valiosa, pero non é un feito que aparecese alí, e o ataque en si é moi arriscado en canto á integridade da rede.

Despois de outra indagación nos servizos, veu á cabeza unha idea interesante. Existe unha utilidade deste tipo chamada Responder (é fácil atopar exemplos de uso con este nome), que, ao "envelenar" as solicitudes de difusión, provoca conexións a través de diversos protocolos como SMB, HTTP, LDAP, etc. de diferentes xeitos, despois pídelles a todos os que se conecten que se autentiquen e configúreo para que a autenticación se realice a través de NTLM e dun modo transparente para a vítima. Na maioría das veces, un atacante recolle deste xeito os apretóns de mans de NetNTLMv2 e a partir deles, mediante un dicionario, recupera rapidamente os contrasinais do dominio dos usuarios. Aquí quería algo parecido, pero os usuarios sentáronse "detrás dunha parede", ou mellor dito, estaban separados por un cortalumes e accedían á WEB a través do clúster de proxy Blue Coat.

Lembra que especifiquei que o nome de dominio de Active Directory coincidía co dominio "externo", é dicir, era company.ru? Así, Windows, máis precisamente Internet Explorer (e Edge e Chrome), permiten ao usuario autenticarse de forma transparente en HTTP a través de NTLM se considera que o sitio está situado nalgunha "Zona Intranet". Un dos signos dunha "Intranet" é o acceso a un enderezo IP "gris" ou un nome DNS curto, é dicir, sen puntos. Dado que tiñan un servidor cunha IP "branca" e un nome DNS preobrazhensky.company.ru, e as máquinas de dominio adoitan recibir o sufixo de dominio de Active Directory a través de DHCP para a entrada de nome simplificada, só tiñan que escribir o URL na barra de enderezos. preobrazhensky, para que atopen o camiño correcto ao servidor do urólogo comprometido, sen esquecer que agora se chama "Intranet". É dicir, ao mesmo tempo dándome o apretón de mans NTLM do usuario sen o seu coñecemento. Só queda obrigar aos navegadores clientes a pensar na necesidade urxente de contactar con este servidor.

A marabillosa utilidade Intercepter-NG veu ao rescate (grazas Interceptor). Permitiu cambiar o tráfico sobre a marcha e funcionou moi ben en Windows 2003. Incluso tiña unha funcionalidade separada para modificar só ficheiros JavaScript no fluxo de tráfico. Planificouse unha especie de Cross-Site Scripting masivo.

Os proxies de Blue Coat, a través dos cales os usuarios accedían á WEB global, almacenaban periodicamente en caché contido estático. Ao interceptar o tráfico, quedou claro que traballaban as XNUMX horas, solicitando sen cesar a estática de uso frecuente para acelerar a visualización do contido nas horas punta. Ademais, BlueCoat tiña un axente de usuario específico, que o distinguía claramente dun usuario real.

Preparouse Javascript, que, usando Intercepter-NG, implementouse durante unha hora pola noite para cada resposta con ficheiros JS para Blue Coat. O guión fixo o seguinte:

• User-Agent determinou o navegador actual. Se era Internet Explorer, Edge ou Chrome, seguía funcionando.
• Agardei ata que se formase o DOM da páxina.
• Inseriuse unha imaxe invisible no DOM cun atributo src do formulario preobrazhensky:8080/NNNNNNN.png, onde NNN son números arbitrarios para que BlueCoat non o garde na caché.
• Establece unha variable de marca global para indicar que a inxección completouse e que xa non hai necesidade de inserir imaxes.

O navegador intentou cargar esta imaxe; no porto 8080 do servidor comprometido, un túnel TCP agardaba por ela no meu portátil, onde estaba a executar o mesmo Responder, requirindo que o navegador inicie sesión a través de NTLM.

A xulgar polos rexistros de Responder, a xente chegou ao traballo pola mañá, acendeu os seus postos de traballo, despois comezou a visitar o servidor do urólogo en masa e sen ser notado, sen esquecerse de "drenar" os apretóns de mans NTLM. Os apretóns de mans choveron durante todo o día e acumularon claramente material para un ataque obviamente exitoso para recuperar contrasinais. Este é o aspecto dos rexistros de resposta:

Visitas secretas masivas ao servidor do urólogo por parte dos usuarios

Probablemente xa te deches conta de que toda esta historia está construída sobre o principio "todo estaba ben, pero despois houbo un desgusto, despois houbo unha superación, e despois todo foi exitoso". Entón, aquí houbo un desgusto. Dos cincuenta apertóns de mans únicos, non se revelou nin un. E isto ten en conta o feito de que mesmo nun portátil cun procesador morto, estes axustes de man NTLMv2 procesan a unha velocidade de varios centos de millóns de intentos por segundo.

Tiven que armarme con técnicas de mutación de contrasinal, unha tarxeta de vídeo, un dicionario máis groso e esperar. Despois de moito tempo, reveláronse varias contas con contrasinais da forma "Q11111111....1111111q", o que suxire que todos os usuarios víronse obrigados no seu día a crear un contrasinal moi longo con maiúsculas e minúsculas diferentes, o que tamén debía ser complexo. Pero non podes enganar a un usuario experimentado, e así o fixo máis fácil de lembrar. En total, unhas 5 contas foron comprometidas, e só unha delas tiña dereitos valiosos sobre os servizos.

Parte 3. Roskomnadzor contraataca

Así, recibíronse as primeiras contas de dominio. Se non te quedaches durmido a estas alturas dunha longa lectura, probablemente lembrarás que mencionei un servizo que non requiría un segundo factor de autenticación: é un wiki con autenticación NTLM. Por suposto, o primeiro que había que facer era entrar alí. Indagar na base de coñecemento interna deu resultados rapidamente:

• A empresa dispón dunha rede WiFi con autenticación mediante contas de dominio con acceso á rede local. Co conxunto actual de datos, este xa é un vector de ataque que funciona, pero cómpre ir á oficina cos pés e estar situado nalgún lugar do territorio da oficina do cliente.
• Atopei unha instrución segundo a cal existía un servizo que permitía... rexistrar de forma independente un dispositivo de autenticación de "segundo factor" se o usuario está dentro dunha rede local e lembra con confianza o seu inicio de sesión e contrasinal de dominio. Neste caso, o “interior” e o “exterior” foron determinados pola accesibilidade do porto deste servizo ao usuario. O porto non era accesible desde Internet, pero era bastante accesible a través da DMZ.

Por suposto, un "segundo factor" engadiuse inmediatamente á conta comprometida en forma dunha aplicación no meu teléfono. Había un programa que podía enviar en voz alta unha solicitude de inserción ao teléfono cos botóns "aprobar"/"desaprobar" para a acción, ou mostrar silenciosamente o código OTP na pantalla para realizar unha entrada independente. Ademais, as instrucións supoñían que o primeiro método era o único correcto, pero non funcionou, a diferenza do método OTP.

Co "segundo factor" roto, puiden acceder ao correo de Outlook Web Access e ao acceso remoto en Citrix Netscaler Gateway. Houbo unha sorpresa no correo en Outlook:

Nesta foto rara podes ver como Roskomnadzor axuda aos pentesters

Foron os primeiros meses despois do famoso bloqueo de "fans" de Telegram, cando redes enteiras con miles de enderezos desapareceron inexorablemente do acceso. Quedou claro por que o pulo non funcionaba de inmediato e por que a miña "vítima" non deu a voz de alarma porque comezaron a usar a súa conta durante o horario de apertura.

Calquera persoa familiarizada con Citrix Netscaler imaxina que adoita implementarse de tal xeito que só se pode transmitir ao usuario unha interface de imaxe, intentando non darlle as ferramentas para lanzar aplicacións de terceiros e transferir datos, limitando de todas as formas posibles accións. a través de carcasas de control estándar. A miña "vítima", debido á súa ocupación, só conseguiu 1C:

Despois de percorrer un pouco a interface 1C, descubrín que alí hai módulos de procesamento externos. Pódense cargar desde a interface, e executaranse no cliente ou servidor, dependendo dos dereitos e configuracións.

Pedin aos meus amigos programadores de 1C que creasen un procesamento que aceptase unha cadea e a executase. Na linguaxe 1C, comezar un proceso parece algo así (tomado de Internet). Estás de acordo en que a sintaxe da lingua 1C sorprende a xente de fala rusa coa súa espontaneidade?

O procesamento executouse á perfección; resultou ser o que os pentesters chaman "shell": a través del lanzouse Internet Explorer.

Antes, no correo atopouse o enderezo dun sistema que permite pedir pases para o territorio. Pedín un pase por se tivese que usar un vector de ataque WiFi.

Fálase en Internet de que aínda había un delicioso catering gratuíto na oficina do cliente, pero aínda así preferín desenvolver o ataque a distancia, é máis tranquilo.

AppLocker activouse no servidor de aplicacións que executaba Citrix, pero omitiuse. Cargouse e lanzouse o mesmo Meterpreter a través de DNS, xa que as versións http(s) non querían conectarse e non coñecía o enderezo do proxy interno nese momento. Por certo, a partir deste momento, o pentest externo converteuse esencialmente nun interno.

Parte 4. Os dereitos de administrador dos usuarios son malos, vale?

A primeira tarefa dun pentester ao conseguir o control dunha sesión de usuario de dominio é recoller toda a información sobre os dereitos do dominio. Hai unha utilidade BloodHound que che permite descargar automaticamente información sobre usuarios, ordenadores, grupos de seguridade a través do protocolo LDAP desde un controlador de dominio e a través de SMB: información sobre cal usuario iniciou sesión recentemente onde e quen é o administrador local.

Unha técnica típica para facerse con dereitos de administrador de dominios parece simplificada como un ciclo de accións monótonas:

• Imos aos equipos de dominio nos que hai dereitos de administrador local, baseados en contas de dominio xa capturadas.
• Lanzamos Mimikatz e obtemos contrasinais almacenados na caché, tickets Kerberos e hash NTLM das contas de dominio que iniciaron sesión recentemente neste sistema. Ou eliminamos a imaxe de memoria do proceso lsass.exe e facemos o mesmo do noso lado. Isto funciona ben con Windows máis novo que 2012R2/Windows 8.1 coa configuración predeterminada.
• Determinamos onde as contas comprometidas teñen dereitos de administrador local. Repetimos o primeiro punto. Nalgún momento conseguimos dereitos de administrador para todo o dominio.

"Fin do ciclo;", como escribirían aquí os programadores de 1C.

Entón, o noso usuario resultou ser un administrador local nun só host con Windows 7, cuxo nome incluía a palabra "VDI" ou "Virtual Desktop Infrastructure", máquinas virtuais persoais. Probablemente, o deseñador do servizo VDI quixo dicir que, dado que VDI é o sistema operativo persoal do usuario, aínda que o usuario cambie o ambiente de software como quere, o host aínda se pode "recargar". Tamén pensei que en xeral a idea era boa, fun a este host VDI persoal e fixen alí un niño:

• Instalei alí un cliente OpenVPN, que fixo un túnel a través de Internet ata o meu servidor. O cliente tivo que ser obrigado a pasar polo mesmo Blue Coat coa autenticación de dominio, pero OpenVPN fíxoo, como din, "fóra da caixa".
• OpenSSH instalado en VDI. Ben, realmente, que é Windows 7 sen SSH?

Así parecía en directo. Permíteme recordarche que todo isto hai que facer a través de Citrix e 1C:

Unha técnica para promover o acceso aos ordenadores veciños é comprobar as coincidencias dos contrasinais dos administradores locais. Aquí a sorte esperou inmediatamente: o hash NTLM do administrador local predeterminado (que de súpeto se chamou Administrador) foi abordado mediante un ataque de paso a hash aos hosts VDI veciños, dos cales había varios centos. Por suposto, o ataque alcanzoulles inmediatamente.

Aquí é onde os administradores de VDI se dispararon no pé dúas veces:

• A primeira vez foi cando as máquinas VDI non se incorporaron a LAPS, conservando esencialmente o mesmo contrasinal de administrador local da imaxe que se despregou masivamente en VDI.
• O administrador predeterminado é a única conta local que é vulnerable aos ataques pass-the-hash. Aínda co mesmo contrasinal, sería posible evitar un compromiso masivo creando unha segunda conta de administrador local cun contrasinal aleatorio complexo e bloqueando o predeterminado.

Por que o servizo SSH nese Windows? Moi sinxelo: agora o servidor OpenSSH non só proporciona un shell de comandos interactivo cómodo sen interferir co traballo do usuario, senón tamén un proxy socks5 en VDI. A través destes calcetíns, conecteime a través de SMB e recompilei contas almacenadas en caché de todos estes centos de máquinas VDI, despois busquei o camiño para o administrador do dominio usándoas nos gráficos de BloodHound. Con centos de anfitrións á miña disposición, atopei este camiño bastante rápido. Obtivéronse os dereitos de administrador de dominios.

Aquí tes unha imaxe de Internet que mostra unha busca similar. As conexións mostran quen está onde está o administrador e quen está conectado onde.

Por certo, recorda a condición desde o inicio do proxecto: "non uses enxeñería social". Entón, propoño pensar en canto se cortaría todo este Bollywood con efectos especiais se aínda fose posible utilizar o phishing banal. Pero persoalmente, foi moi interesante para min facer todo isto. Espero que vos gustara ler isto. Por suposto, non todos os proxectos parecen tan intrigantes, pero o traballo no seu conxunto é moi desafiante e non permite que se estanque.

Probablemente alguén teña unha pregunta: como protexerse? Incluso este artigo describe moitas técnicas, moitas das cales os administradores de Windows nin sequera coñecen. Non obstante, propoño miralos desde a perspectiva de principios trillados e medidas de seguridade da información:

• non use software obsoleto (lembra Windows 2003 ao principio?)
• non manteña acendidos os sistemas innecesarios (por que había o sitio web dun urólogo?)
• comprobe os contrasinais dos usuarios para obter forza (se non, os soldados... os pentesters farán isto)
• non teñen os mesmos contrasinais para diferentes contas (compromiso VDI)
• e outros

Por suposto, isto é moi difícil de implementar, pero no seguinte artigo mostraremos na práctica que é moi posible.

Fonte: www.habr.com