Aquest article es va escriure a partir d'un pentest de gran èxit que els especialistes del Grup-IB van fer fa un parell d'anys: va passar una història que es podria adaptar al cinema a Bollywood. Ara, probablement, seguirà la reacció del lector: "Oh, un altre article de relacions públiques, de nou s'estan retratant, que bons són, no us oblideu de comprar un pentest". Bé, d'una banda, ho és. Tanmateix, hi ha altres motius pels quals va aparèixer aquest article. Volia mostrar què fan exactament els pentesters, com d'interessant i no trivial pot ser aquest treball, quines circumstàncies divertides poden sorgir en els projectes i, el més important, mostrar material en directe amb exemples reals.
Per restablir l'equilibri de la modèstia al món, al cap d'un temps escriurem sobre un pentest que no va sortir bé. Mostrarem com els processos ben dissenyats d'una empresa poden protegir contra tota una sèrie d'atacs, fins i tot els ben preparats, simplement perquè aquests processos existeixen i funcionen realment.
Per al client d'aquest article, tot va ser generalment excel·lent, almenys millor que el 95% del mercat de la Federació Russa, segons els nostres sentiments, però hi havia una sèrie de petits matisos que van formar una llarga cadena d'esdeveniments, que primer va donar lloc a un llarg informe sobre el treball, i després a aquest article.
Així doncs, abastem-nos de crispetes i benvinguts a la història del detectiu. paraula - Pavel Suprunyuk, responsable tècnic del departament “Auditoria i Consultoria” del Grup-IB.
Part 1. Doctor Pochkin
2018 Hi ha un client: una empresa informàtica d'alta tecnologia, que serveix a molts clients. Vol obtenir una resposta a la pregunta: és possible, sense cap coneixement ni accés inicial, treballant a través d'Internet, obtenir drets d'administrador de dominis d'Active Directory? No m'interessa cap enginyeria social (), no pretenen interferir amb el treball a propòsit, però poden tornar a carregar accidentalment un servidor que funciona estranyament, per exemple. Un objectiu addicional és identificar tants altres vectors d'atac com sigui possible contra el perímetre exterior. L'empresa realitza regularment aquestes proves, i ara ha arribat el termini per a una nova prova. Les condicions són gairebé típiques, adequades, comprensibles. Comencem.
Hi ha un nom del client, que sigui "Empresa", amb el lloc web principal . Per descomptat, el client es diu de manera diferent, però en aquest article tot serà impersonal.
Realitzo el reconeixement de la xarxa: esbrineu quines adreces i dominis estan registrats amb el client, dibuixeu un diagrama de xarxa, com es distribueixen els serveis a aquestes adreces. Tinc el resultat: més de 4000 adreces IP en directe. Miro els dominis d'aquestes xarxes: afortunadament, la gran majoria són xarxes destinades als clients del client, i formalment no ens interessen. El client pensa el mateix.
Queda una xarxa amb 256 adreces, per a la qual a hores d'ara ja s'ha entès la distribució de dominis i subdominis per adreces IP, hi ha informació sobre els ports escanejats, la qual cosa significa que podeu consultar els serveis per als més interessants. Paral·lelament, es llança tot tipus d'escàners a les adreces IP disponibles i per separat als llocs web.
Hi ha molts serveis. Normalment això és alegria per al pentester i l'anticipació d'una victòria ràpida, ja que com més serveis hi ha, més gran és el camp d'atac i més fàcil és trobar un artefacte. Una ullada ràpida als llocs web va demostrar que la majoria d'ells són interfícies web de productes coneguts de grans empreses globals, que segons sembla us diuen que no són benvinguts. Demanen un nom d'usuari i una contrasenya, sacsegen el camp per introduir el segon factor, demanen un certificat de client TLS o l'envien a Microsoft ADFS. Alguns són simplement inaccessibles des d'Internet. Per a alguns, és evident que necessiteu tenir un client especial pagat per tres sous o saber l'URL exacte per introduir-lo. Ometem-nos una altra setmana de descoratjament gradual en el procés d'intentar "sobrepassar" versions de programari per a vulnerabilitats conegudes, cercant contingut ocult en camins web i comptes filtrats de serveis de tercers com LinkedIn, intentant endevinar contrasenyes utilitzant-les, així com com l'excavació de vulnerabilitats en llocs web escrits per ells mateixos; per cert, segons les estadístiques, aquest és el vector més prometedor d'atac extern avui. De seguida notaré la pistola de pel·lícula que es va disparar posteriorment.
Així doncs, hem trobat dos llocs que destacaven entre centenars de serveis. Aquests llocs tenien una cosa en comú: si no feu un reconeixement minuciós de la xarxa per domini, però busqueu de front els ports oberts o orienteu un escàner de vulnerabilitats amb un rang IP conegut, aquests llocs s'escaparan de l'exploració i simplement no seran visible sense saber el nom DNS. Potser se'ls va perdre abans, almenys, i les nostres eines automàtiques no van trobar cap problema amb ells, encara que s'enviessin directament al recurs.
Per cert, sobre el que es van trobar els escàners llançats anteriorment en general. Permeteu-me que us recordi: per a algunes persones, "pentest" és equivalent a "escaneig automatitzat". Però els escàners d'aquest projecte no van dir res. Bé, el màxim el van mostrar les vulnerabilitats Mitjanes (3 de 5 en termes de gravetat): en alguns serveis un certificat TLS dolent o algorismes de xifratge obsolets, i a la majoria de llocs Clickjacking. Però això no us portarà al vostre objectiu. Potser els escàners serien més útils aquí, però deixeu-me que us recordi: el mateix client pot comprar aquests programes i provar-los amb ells i, a jutjar pels desoladors resultats, ja ho ha comprovat.
Tornem als llocs "anòmals". El primer és una cosa semblant a un wiki local en una adreça no estàndard, però en aquest article deixeu que sigui wiki.company[.]ru. També va demanar immediatament un inici de sessió i una contrasenya, però mitjançant NTLM al navegador. Per a l'usuari, sembla una finestra ascètica que demana introduir un nom d'usuari i una contrasenya. I això és una mala pràctica.
Una petita nota. NTLM als llocs web perimetrals és dolent per diverses raons. El primer motiu és que es revela el nom de domini de l'Active Directory. En el nostre exemple, també va resultar ser company.ru, igual que el nom DNS "extern". Sabent això, podeu preparar amb cura alguna cosa maliciós perquè només s'executi a la màquina del domini de l'organització, i no en una caixa de proves. En segon lloc, l'autenticació passa directament pel controlador de domini mitjançant NTLM (sorpresa, oi?), amb totes les característiques de les polítiques de xarxa "internes", inclòs el bloqueig dels comptes perquè superin el nombre d'intents d'entrada de contrasenya. Si un atacant descobreix els inicis de sessió, provarà amb contrasenyes. Si esteu configurat per bloquejar els comptes perquè no introdueixin contrasenyes incorrectes, funcionarà i el compte es bloquejarà. En tercer lloc, és impossible afegir un segon factor a aquesta autenticació. Si algun dels lectors encara sap com, si us plau, feu-m'ho saber, és realment interessant. En quart lloc, la vulnerabilitat als atacs pass-the-hash. ADFS es va inventar, entre altres coses, per protegir-se de tot això.
Hi ha una propietat dolenta dels productes de Microsoft: fins i tot si no heu publicat específicament aquest NTLM, s'instal·larà per defecte a OWA i Lync, almenys.
Per cert, l'autor d'aquest article va bloquejar una vegada per accident aproximadament 1000 comptes d'empleats d'un gran banc en només una hora utilitzant el mateix mètode i després va semblar una mica pàl·lid. Els serveis informàtics del banc també eren pàl·lids, però tot va acabar bé i adequadament, fins i tot ens van elogiar per ser els primers a trobar aquest problema i provocar una solució ràpida i decidida.
El segon lloc tenia l'adreça "òbviament una mena de cognom.company.ru". L'he trobat a Google, una cosa així a la pàgina 10. El disseny era de principis de mitjans dels anys XNUMX i una persona respectable el mirava des de la pàgina principal, una cosa així:
Aquí vaig agafar un fotograma de "Heart of a Dog", però creieu-me, era vagament semblant, fins i tot el disseny del color era en tons similars. Que es digui el lloc preobrazhensky.company.ru.
Era un lloc web personal... per a un uròleg. Em vaig preguntar què feia el lloc web d'un uròleg al subdomini d'una empresa d'alta tecnologia. Una recerca ràpida a Google va demostrar que aquest metge era cofundador d'una de les persones jurídiques del nostre client i fins i tot va aportar uns 1000 rubles al capital autoritzat. El lloc probablement es va crear fa molts anys i els recursos del servidor del client es van utilitzar com a allotjament. El lloc fa temps que ha perdut la seva rellevància, però per alguna raó es va deixar funcionant durant molt de temps.
Pel que fa a les vulnerabilitats, el lloc web en si era segur. De cara al futur, diré que es tractava d'un conjunt d'informació estàtica: pàgines HTML senzilles amb il·lustracions inserides en forma de ronyons i bufetes. És inútil "trencar" un lloc així.
Però el servidor web de sota era més interessant. A jutjar per la capçalera del servidor HTTP, tenia IIS 6.0, el que significa que utilitzava Windows 2003 com a sistema operatiu. L'escàner havia identificat anteriorment que aquest lloc web d'uròleg en particular, a diferència d'altres hosts virtuals del mateix servidor web, responia a l'ordre PROPFIND, és a dir, executava WebDAV. Per cert, l'escàner va retornar aquesta informació amb la marca Info (en l'idioma dels informes de l'escàner, aquest és el perill més baix) - aquestes coses normalment es salten. En combinació, això va donar un efecte interessant, que només es va revelar després d'una altra investigació a Google: una rara vulnerabilitat de desbordament de memòria intermèdia associada al conjunt de Shadow Brokers, és a dir, CVE-2017-7269, que ja tenia un exploit ja fet. En altres paraules, hi haurà problemes si teniu Windows 2003 i WebDAV s'executa a IIS. Tot i que executar Windows 2003 en producció el 2018 és un problema en si mateix.
L'explotació va acabar a Metasploit i es va provar immediatament amb una càrrega que enviava una sol·licitud de DNS a un servei controlat: Burp Collaborator s'utilitza tradicionalment per capturar sol·licituds de DNS. Per a la meva sorpresa, va funcionar per primera vegada: es va rebre un nocaut de DNS. A continuació, es va intentar crear una connexió posterior a través del port 80 (és a dir, una connexió de xarxa del servidor a l'atacant, amb accés a cmd.exe a l'amfitrió de la víctima), però després va passar un fiasco. La connexió no es va produir i després del tercer intent d'utilitzar el lloc, juntament amb totes les imatges interessants, va desaparèixer per sempre.
En general, això va seguit d'una carta a l'estil de "client, desperta, ho hem deixat tot". Però ens van dir que el lloc no té res a veure amb els processos empresarials i hi funciona sense cap motiu, com tot el servidor, i que podem utilitzar aquest recurs com vulguem.
Aproximadament un dia després, el lloc va començar a funcionar de sobte. Després d'haver creat un banc de WebDAV a IIS 6.0, vaig trobar que la configuració predeterminada és reiniciar els processos de treball d'IIS cada 30 hores. És a dir, quan el control va sortir del codi intèrpret de comandaments, el procés de treball d'IIS va finalitzar, després es va reiniciar un parell de vegades i després es va deixar en repòs durant 30 hores.
Com que la connexió posterior a tcp va fallar la primera vegada, vaig atribuir aquest problema a un port tancat. És a dir, va suposar la presència d'alguna mena de tallafocs que no permetia passar les connexions sortints a l'exterior. Vaig començar a executar codis shell que cercaven a través de molts ports tcp i udp, no hi va haver cap efecte. Les càrregues de connexió inversa mitjançant http(s) de Metasploit no van funcionar: meterpreter/reverse_http(s). De sobte, es va establir una connexió al mateix port 80, però immediatament es va caure. Ho vaig atribuir a l'acció de l'IPS encara imaginari, que no li agradava el trànsit del metrepreter. A la llum del fet que una connexió tcp pura al port 80 no va passar, però sí una connexió http, vaig concloure que d'alguna manera es va configurar un servidor intermediari http al sistema.
Fins i tot vaig provar meterpreter mitjançant DNS (gràcies pels vostres esforços, va salvar molts projectes), recordant el primer èxit, però ni tan sols va funcionar a l'estand: el codi de comandament era massa voluminós per a aquesta vulnerabilitat.
En realitat, semblava així: 3-4 intents d'atac en 5 minuts, i després 30 hores d'espera. I així durant tres setmanes seguides. Fins i tot vaig posar un recordatori per no perdre el temps. A més, hi va haver una diferència en el comportament dels entorns de prova i producció: per a aquesta vulnerabilitat hi havia dos exploits similars, un de Metasploit, el segon d'Internet, convertit a partir de la versió de Shadow Brokers. Per tant, només Metasploit es va provar en combat, i només el segon es va provar al banc, la qual cosa va fer encara més difícil la depuració i es va trencar el cervell.
Al final, un shellcode que baixava un fitxer exe d'un servidor determinat mitjançant http i el llançava al sistema de destinació va resultar eficaç. El shellcode era prou petit com per cabre, però almenys va funcionar. Com que al servidor no li agradava gens el trànsit TCP i es va inspeccionar http(s) per detectar la presència de meterpreter, vaig decidir que la manera més ràpida era descarregar un fitxer exe que contingués DNS-meterpreter a través d'aquest shellcode.
Aquí va tornar a sorgir un problema: en baixar un fitxer exe i, com van demostrar els intents, independentment de quin, la descàrrega es va interrompre. De nou, a algun dispositiu de seguretat entre el meu servidor i l'uròleg no li va agradar el trànsit http amb un exe dins. La solució "ràpida" semblava ser canviar l'shellcode de manera que ofusqués el trànsit http sobre la marxa, de manera que es transferirien dades binàries abstractes en lloc d'exe. Finalment, l'atac va tenir èxit, el control es va rebre a través del canal DNS prim:
Immediatament es va fer evident que tinc els drets de flux de treball d'IIS més bàsics, que no em permeten fer res. Aquest és el que semblava a la consola Metasploit:
Totes les metodologies de Pentest suggereixen fermament que necessiteu augmentar els drets en obtenir accés. Normalment no ho faig localment, ja que el primer accés es veu simplement com un punt d'entrada a la xarxa, i comprometre una altra màquina a la mateixa xarxa sol ser més fàcil i ràpid que augmentar els privilegis en un amfitrió existent. Però aquest no és el cas aquí, ja que el canal DNS és molt estret i no permetrà aclarir el trànsit.
Suposant que aquest servidor de Windows 2003 no s'ha reparat per la famosa vulnerabilitat MS17-010, túnel el trànsit al port 445/TCP a través del túnel DNS de meterpreter fins a localhost (sí, això també és possible) i intento executar l'exe descarregat anteriorment a través de la vulnerabilitat. L'atac funciona, rebo una segona connexió, però amb drets de SISTEMA.
És interessant que encara van intentar protegir el servidor de MS17-010: tenia serveis de xarxa vulnerables desactivats a la interfície externa. Això protegeix contra atacs a la xarxa, però l'atac des de l'interior a localhost va funcionar, ja que no podeu desactivar ràpidament SMB a localhost.
A continuació, es revelen nous detalls interessants:
- Tenint drets de SISTEMA, podeu establir fàcilment una connexió posterior mitjançant TCP. Òbviament, desactivar TCP directe és estrictament un problema per a l'usuari limitat d'IIS. Spoiler: el trànsit d'usuaris d'IIS es va embolicar d'alguna manera al servidor intermediari ISA local en ambdues direccions. Com funciona exactament, no ho he reproduït.
- Estic en una determinada "DMZ" (i això no és un domini d'Active Directory, sinó un GRUP DE TREBALL) - sembla lògic. Però en comptes de l'adreça IP privada ("grisa") esperada, tinc una adreça IP completament "blanca", exactament la mateixa que la que vaig atacar abans. Això significa que l'empresa és tan antiga en el món de l'adreçament IPv4 que es pot permetre el luxe de mantenir una zona DMZ per a 128 adreces "blanques" sense NAT segons l'esquema, tal com es mostra als manuals de Cisco de 2005.
Com que el servidor és antic, Mimikatz funciona directament des de la memòria:
Rebo la contrasenya de l'administrador local, túnel el trànsit RDP a través de TCP i inicio sessió en un escriptori acollidor. Com que podia fer el que volgués amb el servidor, vaig eliminar l'antivirus i vaig trobar que el servidor només era accessible des d'Internet mitjançant els ports TCP 80 i 443, i el 443 no estava ocupat. He configurat un servidor OpenVPN a 443, afegeixo funcions NAT per al meu trànsit VPN i tinc accés directe a la xarxa DMZ de forma il·limitada a través del meu OpenVPN. Cal destacar que ISA, amb algunes funcions IPS no desactivades, em va bloquejar el trànsit amb l'exploració de ports, per la qual cosa va haver de ser substituït per un RRAS més senzill i compatible. Així que els pentesters de vegades encara han d'administrar tot tipus de coses.
Un lector atent preguntarà: "Què passa amb el segon lloc: un wiki amb autenticació NTLM, sobre el qual s'ha escrit tant?" Més sobre això més endavant.
Part 2. Encara no s'està xifrant? Llavors ja anem a tu aquí
Per tant, hi ha accés al segment de xarxa DMZ. Heu d'anar a l'administrador del domini. El primer que em ve al cap és comprovar automàticament la seguretat dels serveis dins del segment DMZ, sobretot perquè ara molts més estan oberts a la investigació. Una imatge típica durant una prova de penetració: el perímetre extern està millor protegit que els serveis interns, i quan s'accedeix dins d'una gran infraestructura, és molt més fàcil obtenir drets ampliats en un domini només pel fet que aquest domini comença a ser accessible a les eines i, en segon lloc, en una infraestructura amb diversos milers d'amfitrions, sempre hi haurà un parell de problemes crítics.
Carrego els escàners mitjançant DMZ mitjançant un túnel OpenVPN i espero. Obro l'informe; de nou, res greu, pel que sembla algú va passar pel mateix mètode abans que jo. El següent pas és examinar com es comuniquen els amfitrions de la xarxa DMZ. Per fer-ho, primer inicieu el Wireshark habitual i escolteu les sol·licituds de difusió, principalment ARP. Els paquets ARP es van recollir durant tot el dia. Resulta que s'utilitzen diverses passarel·les en aquest segment. Això serà útil més endavant. En combinar les dades de les sol·licituds-respostes ARP i les dades d'escaneig de ports, vaig trobar els punts de sortida del trànsit d'usuaris des de la xarxa local, a més d'aquells serveis que es coneixien anteriorment, com ara el web i el correu.
Com que de moment no tenia accés a altres sistemes i no tenia un sol compte per als serveis corporatius, es va decidir extreure almenys algun compte del trànsit mitjançant ARP Spoofing.
Cain&Abel es va llançar al servidor de l'uròleg. Tenint en compte els fluxos de trànsit identificats, es van seleccionar les parelles més prometedores per a l'atac man-in-the-middle, i després es va rebre part del trànsit de xarxa mitjançant un llançament a curt termini durant 5-10 minuts, amb un temporitzador per reiniciar el servidor. en cas de congelació. Com a la broma, hi havia dues notícies:
- Bé: es van agafar moltes credencials i l'atac en conjunt va funcionar.
- El dolent: totes les credencials eren dels propis clients del client. Mentre prestaven serveis d'assistència, els especialistes en clients es van connectar als serveis de clients que no sempre tenien configurat el xifratge del trànsit.
Com a resultat, vaig adquirir un munt de credencials inútils en el context del projecte, però definitivament interessants com a demostració del perill de l'atac. Encaminadors fronterers de grans empreses amb telnet, ports http de depuració reenviats a CRM intern amb totes les dades, accés directe a RDP des de Windows XP a la xarxa local i altres obscurantismes. Va resultar així .
També vaig trobar una oportunitat divertida per recollir cartes del trànsit, una cosa així. Aquest és un exemple d'una carta ja feta que va anar del nostre client al port SMTP del seu client, de nou, sense xifratge. Un tal Andrey demana al seu homònim que torni a enviar la documentació, i es penja a un disc al núvol amb un inici de sessió, una contrasenya i un enllaç en una carta de resposta:
Aquest és un altre recordatori per xifrar tots els serveis. Es desconeix qui i quan llegirà i utilitzarà les vostres dades específicament: el proveïdor, l'administrador del sistema d'una altra empresa o un pentester. Guardo silenci sobre el fet que moltes persones poden simplement interceptar trànsit no xifrat.
Tot i l'èxit aparent, això no ens va acostar a l'objectiu. Va ser possible, per descomptat, estar assegut durant molt de temps i pescar informació valuosa, però no és un fet que hi aparegués, i l'atac en si és molt arriscat pel que fa a la integritat de la xarxa.
Després d'una altra investigació en els serveis, va venir al cap una idea interessant. Hi ha una utilitat d'aquest tipus anomenada Responder (és fàcil trobar exemples d'ús amb aquest nom), que, en "enverinar" les sol·licituds de difusió, provoca connexions mitjançant una varietat de protocols com SMB, HTTP, LDAP, etc. de diferents maneres, després demana a tots els que es connectin que s'autentiquin i ho configuren de manera que l'autenticació es faci mitjançant NTLM i d'una manera transparent per a la víctima. Molt sovint, un atacant recull d'aquesta manera encaixades de mans NetNTLMv2 i a partir d'elles, mitjançant un diccionari, recupera ràpidament les contrasenyes dels usuaris del domini. Aquí volia una cosa semblant, però els usuaris estaven asseguts "darrere d'una paret", o més aviat, estaven separats per un tallafocs i accedien a la WEB a través del clúster de proxy Blue Coat.
Recordeu, vaig especificar que el nom de domini de l'Active Directory coincideix amb el domini "extern", és a dir, era company.ru? Així, Windows, més concretament Internet Explorer (i Edge i Chrome), permeten a l'usuari autenticar-se de manera transparent en HTTP mitjançant NTLM si considera que el lloc es troba en alguna “Zona Intranet”. Un dels signes d'una "Intranet" és l'accés a una adreça IP "grisa" o un nom DNS curt, és a dir, sense punts. Com que tenien un servidor amb una IP "blanca" i un nom DNS preobrazhensky.company.ru, i les màquines de domini solen rebre el sufix de domini Active Directory mitjançant DHCP per a l'entrada de nom simplificada, només havien d'escriure l'URL a la barra d'adreces. , perquè trobin el camí correcte cap al servidor de l'uròleg compromès, sense oblidar que aquest ara s'anomena "Intranet". És a dir, al mateix temps que em dóna l'encaixada de mans NTLM de l'usuari sense que ell ho sàpiga. Només queda obligar els navegadors dels clients a pensar en la necessitat urgent de contactar amb aquest servidor.
La meravellosa utilitat Intercepter-NG va venir al rescat (gràcies ). Us permetia canviar el trànsit sobre la marxa i funcionava molt bé a Windows 2003. Fins i tot tenia una funcionalitat separada per modificar només fitxers JavaScript al flux de trànsit. Es va planificar una mena de Cross-Site Scripting massiu.
Els servidors intermediaris de Blue Coat, a través dels quals els usuaris accedien a la WEB global, guardaven periòdicament contingut estàtic. En interceptar el trànsit, era evident que treballaven les XNUMX hores del dia, sol·licitant sense parar l'estàtica utilitzada amb freqüència per accelerar la visualització del contingut durant les hores punta. A més, BlueCoat tenia un User-Agent específic, que el distingia clarament d'un usuari real.
Es va preparar Javascript, que, utilitzant Intercepter-NG, es va implementar durant una hora a la nit per a cada resposta amb fitxers JS per a Blue Coat. El guió va fer el següent:
- Determinat el navegador actual per User-Agent. Si era Internet Explorer, Edge o Chrome, continuava funcionant.
- Vaig esperar fins que es formés el DOM de la pàgina.
- S'ha inserit una imatge invisible al DOM amb un atribut src del formulari :8080/NNNNNNN.png, on NNN són números arbitraris de manera que BlueCoat no el guarda a la memòria cau.
- Establiu una variable de senyalització global per indicar que la injecció s'ha completat i que ja no cal inserir imatges.
El navegador va intentar carregar aquesta imatge; al port 8080 del servidor compromès, un túnel TCP l'esperava al meu ordinador portàtil, on s'executava el mateix Responder, que requeria que el navegador iniciés sessió mitjançant NTLM.
A jutjar pels registres de Responder, la gent va venir a treballar al matí, va encendre les seves estacions de treball, després va començar a visitar massivament i sense adonar-se al servidor de l'uròleg, sense oblidar "drenar" les encaixades de mans NTLM. Les encaixades de mans van ploure durant tot el dia i van acumular material clarament per a un atac òbviament reeixit per recuperar contrasenyes. Aquest és el que semblaven els registres de resposta:
Visites secretes massives al servidor d'uròlegs per part dels usuaris
Probablement ja us heu adonat que tota aquesta història es basa en el principi "tot va anar bé, però després va haver-hi una llàstima, després va haver-hi una superació i tot va tenir èxit". Per tant, aquí hi va haver una llàstima. De les cinquanta encaixades de mans úniques, no se'n va revelar cap. I això té en compte el fet que fins i tot en un ordinador portàtil amb un processador mort, aquestes encaixades de mans NTLMv2 es processen a una velocitat de diversos centenars de milions d'intents per segon.
Vaig haver d'armar-me amb tècniques de mutació de contrasenyes, una targeta de vídeo, un diccionari més gruixut i esperar. Després de molt de temps, es van revelar diversos comptes amb contrasenyes de la forma "Q11111111....1111111q", cosa que suggereix que tots els usuaris es van veure obligats a crear una contrasenya molt llarga amb diferents majúscules i minúscules de caràcters, que també se suposa que ser complex. Però no es pot enganyar a un usuari experimentat, i així és com va facilitar el seu record. En total, uns 5 comptes es van veure compromesos i només un d'ells tenia drets valuosos sobre els serveis.
Part 3. Roskomnadzor contraataca
Així doncs, es van rebre els primers comptes de domini. Si encara no us heu adormit d'una llarga lectura, probablement recordareu que he esmentat un servei que no requeria un segon factor d'autenticació: és un wiki amb autenticació NTLM. Per descomptat, el primer que cal fer era entrar-hi. L'exploració de la base de coneixement interna va donar resultats ràpidament:
- L'empresa disposa d'una xarxa WiFi amb autenticació mitjançant comptes de domini amb accés a la xarxa local. Amb el conjunt de dades actual, això ja és un vector d'atac que funciona, però cal anar a l'oficina amb els peus i estar situat en algun lloc del territori de l'oficina del client.
- Vaig trobar una instrucció segons la qual hi havia un servei que permetia... registrar de manera independent un dispositiu d'autenticació de "segon factor" si l'usuari es troba dins d'una xarxa local i recorda amb seguretat el seu inici de sessió i contrasenya de domini. En aquest cas, “dins” i “fora” estaven determinats per l'accessibilitat del port d'aquest servei a l'usuari. El port no era accessible des d'Internet, però era bastant accessible a través de la DMZ.
Per descomptat, immediatament es va afegir un "segon factor" al compte compromès en forma d'aplicació al meu telèfon. Hi havia un programa que podia enviar en veu alta una sol·licitud push al telèfon amb botons "aprovar"/"desaprovar" per a l'acció, o mostrar silenciosament el codi OTP a la pantalla per a una entrada independent. A més, les instruccions suposaven que el primer mètode era l'únic correcte, però no va funcionar, a diferència del mètode OTP.
Amb el "segon factor" trencat, vaig poder accedir al correu d'Outlook Web Access i a l'accés remot a Citrix Netscaler Gateway. Hi va haver una sorpresa al correu a Outlook:
En aquesta rara fotografia podeu veure com Roskomnadzor ajuda els pentesters
Van ser els primers mesos després del famós bloqueig de "fan" de Telegram, quan xarxes senceres amb milers d'adreces van desaparèixer inexorablement de l'accés. Va quedar clar per què l'empenta no va funcionar de seguida i per què la meva "víctima" no va fer sonar l'alarma perquè van començar a utilitzar el seu compte durant l'horari obert.
Qualsevol persona familiaritzada amb Citrix Netscaler s'imagina que s'acostuma a implementar de tal manera que només es pot transmetre una interfície d'imatge a l'usuari, intentant no donar-li les eines per llançar aplicacions de tercers i transferir dades, limitant de totes les maneres possibles les accions. mitjançant carques de control estàndard. La meva "víctima", a causa de la seva ocupació, només va obtenir 1C:
Després de caminar una mica per la interfície 1C, vaig trobar que hi ha mòduls de processament externs. Es poden carregar des de la interfície, i s'executaran al client o al servidor, segons els drets i la configuració.
Vaig demanar als meus amics programadors 1C que creessin un processament que acceptés una cadena i l'executés. En llenguatge 1C, començar un procés sembla una cosa així (pres d'Internet). Esteu d'acord que la sintaxi de la llengua 1C sorprèn la gent de parla russa amb la seva espontaneïtat?
El processament es va executar perfectament; va resultar ser el que els pentesters anomenen un "shell": es va llançar Internet Explorer.
Abans, al correu es trobava l'adreça d'un sistema que permet demanar abonaments al territori. Vaig demanar una passada per si hagués d'utilitzar un vector d'atac WiFi.
Es parla a Internet que encara hi havia un deliciós càtering gratuït a l'oficina del client, però tot i així vaig preferir desenvolupar l'atac a distància, és més tranquil.
AppLocker es va activar al servidor d'aplicacions amb Citrix, però es va ometre. El mateix Meterpreter es va carregar i llançar mitjançant DNS, ja que les versions http(s) no volien connectar-se, i en aquell moment no sabia l'adreça del servidor intermediari intern. Per cert, a partir d'aquest moment, el pentest extern es va convertir essencialment completament en un intern.
Part 4. Els drets d'administrador dels usuaris són dolents, d'acord?
La primera tasca d'un pentester quan aconsegueix el control d'una sessió d'usuari de domini és recollir tota la informació sobre els drets del domini. Hi ha una utilitat BloodHound que us permet descarregar automàticament informació sobre usuaris, ordinadors, grups de seguretat mitjançant el protocol LDAP des d'un controlador de domini i mitjançant SMB: informació sobre quin usuari ha iniciat sessió recentment on i qui és l'administrador local.
Una tècnica típica per obtenir els drets d'administrador de dominis sembla simplificada com un cicle d'accions monòtones:
- Anem a ordinadors de domini on hi ha drets d'administrador local, basats en comptes de domini ja capturats.
- Llencem Mimikatz i obtenim contrasenyes emmagatzemades a la memòria cau, tiquets Kerberos i hash NTLM dels comptes de domini que han iniciat sessió recentment en aquest sistema. O eliminem la imatge de memòria del procés lsass.exe i fem el mateix pel nostre costat. Això funciona bé amb Windows anterior a 2012R2/Windows 8.1 amb la configuració predeterminada.
- Determinem on els comptes compromesos tenen drets d'administrador local. Repetim el primer punt. En algun moment obtenim drets d'administrador per a tot el domini.
"Fi del cicle;", com escriurien aquí els programadors d'1C.
Per tant, el nostre usuari va resultar ser un administrador local en un sol host amb Windows 7, el nom del qual incloïa la paraula "VDI" o "Infraestructura d'escriptori virtual", màquines virtuals personals. Probablement, el dissenyador del servei VDI va dir que, com que VDI és el sistema operatiu personal de l'usuari, fins i tot si l'usuari canvia l'entorn del programari com vulgui, l'amfitrió encara es pot "recarregar". També vaig pensar que, en general, la idea era bona, vaig anar a aquest host VDI personal i hi vaig fer un niu:
- Hi vaig instal·lar un client OpenVPN, que va fer un túnel a través d'Internet fins al meu servidor. El client s'havia de veure obligat a passar pel mateix Blue Coat amb l'autenticació de domini, però OpenVPN ho va fer, com diuen, "fora de la caixa".
- S'ha instal·lat OpenSSH a VDI. Bé, realment, què és Windows 7 sense SSH?
Així semblava en directe. Us recordo que tot això s'ha de fer mitjançant Citrix i 1C:
Una tècnica per promoure l'accés als ordinadors veïns és comprovar les contrasenyes de l'administrador local si hi ha una coincidència. Aquí la sort esperava immediatament: el hash NTLM de l'administrador local predeterminat (que de sobte es va anomenar Administrador) es va acostar mitjançant un atac de passa-hash als amfitrions VDI veïns, dels quals n'hi havia diversos centenars. Per descomptat, l'atac els va impactar immediatament.
Aquí és on els administradors de VDI es van disparar al peu dues vegades:
- La primera vegada va ser quan les màquines VDI no es van incorporar a LAPS, conservant essencialment la mateixa contrasenya d'administrador local de la imatge que es va desplegar en massa a VDI.
- L'administrador predeterminat és l'únic compte local que és vulnerable als atacs de pas-the-hash. Fins i tot amb la mateixa contrasenya, seria possible evitar un compromís massiu creant un segon compte d'administrador local amb una contrasenya aleatòria complexa i bloquejant la predeterminada.
Per què el servei SSH en aquest Windows? Molt senzill: ara el servidor OpenSSH no només proporcionava un intèrpret d'ordres interactiu còmode sense interferir amb el treball de l'usuari, sinó també un proxy socks5 a VDI. Mitjançant aquests mitjons, em vaig connectar mitjançant SMB i vaig recopilar comptes en memòria cau de tots aquests centenars de màquines VDI, després vaig buscar el camí cap a l'administrador del domini utilitzant-los als gràfics de BloodHound. Amb centenars d'amfitrions a la meva disposició, vaig trobar aquest camí amb força rapidesa. S'han obtingut els drets d'administrador del domini.
Aquí teniu una imatge d'Internet que mostra una cerca similar. Les connexions mostren qui és on és l'administrador i qui està connectat on.
Per cert, recordeu la condició des de l'inici del projecte: "no feu servir l'enginyeria social". Per tant, proposo pensar fins a quin punt es tallaria tot aquest Bollywood amb efectes especials si encara fos possible utilitzar el phishing banal. Però personalment, va ser molt interessant per a mi fer tot això. Espero que us hagi agradat llegir això. Per descomptat, no tots els projectes semblen tan intrigants, però el treball en conjunt és molt difícil i no permet que s'estanqui.
Probablement algú tindrà una pregunta: com protegir-se? Fins i tot aquest article descriu moltes tècniques, moltes de les quals els administradors de Windows ni tan sols coneixen. No obstant això, proposo mirar-los des de la perspectiva dels principis triturats i les mesures de seguretat de la informació:
- no utilitzeu programari obsolet (recordeu Windows 2003 al principi?)
- no mantingueu els sistemes innecessaris activats (per què hi havia un lloc web d'uròleg?)
- comproveu les contrasenyes d'usuari per a la vostra força (en cas contrari, els soldats... els pentesters ho faran)
- no tenir les mateixes contrasenyes per a comptes diferents (compromis VDI)
- i una altra
Per descomptat, això és molt difícil d'implementar, però en el següent article mostrarem a la pràctica que és molt possible.
Font: www.habr.com