A fost odată un pentest, sau Cum să spargi totul cu ajutorul unui urolog și Roskomnadzor

Acest articol a fost scris pe baza unui pentest de mare succes pe care specialiștii Grupului IB l-au condus acum câțiva ani: s-a întâmplat o poveste care ar putea fi adaptată pentru film la Bollywood. Acum, probabil, va urma reacția cititorului: „Oh, un alt articol de PR, iar acestea sunt descrise, cât de buni sunt, nu uitați să cumpărați un pentest.” Ei bine, pe de o parte, este. Cu toate acestea, există o serie de alte motive pentru care acest articol a apărut. Am vrut să arăt ce fac exact pentesterii, cât de interesantă și netrivială poate fi această lucrare, ce circumstanțe amuzante pot apărea în proiecte și, cel mai important, să arăt material live cu exemple reale.

Pentru a restabili echilibrul modestiei în lume, după un timp vom scrie despre un pentest care nu a mers bine. Vom arăta cum procesele bine concepute dintr-o companie pot proteja împotriva unei game întregi de atacuri, chiar și a celor bine pregătite, pur și simplu pentru că aceste procese există și funcționează efectiv.

Pentru clientul din acest articol, totul a fost, de asemenea, în general excelent, cel puțin mai bine decât 95% din piața din Federația Rusă, conform sentimentelor noastre, dar au existat o serie de mici nuanțe care au format un lung lanț de evenimente, care mai întâi a condus la un raport lung asupra lucrării și apoi la acest articol.

Așadar, să ne aprovizionăm cu floricele de porumb și bine ați venit la povestea detectivului. Cuvânt - Pavel Suprunyuk, director tehnic al departamentului „Audit și Consultanță” al Grupului-IB.

Partea 1. Doctor Pochkin

2018 Există un client - o companie IT de înaltă tehnologie, care ea însăși deservește mulți clienți. Dorește să obțină un răspuns la întrebarea: este posibil, fără cunoștințe și acces inițial, lucrând prin Internet, să obții drepturi de administrator de domeniu Active Directory? Nu sunt interesat de nicio inginerie socială (a, dar degeaba), nu intenționează să interfereze cu munca în mod intenționat, dar pot reîncărca accidental un server care funcționează ciudat, de exemplu. Un obiectiv suplimentar este de a identifica cât mai mulți alți vectori de atac împotriva perimetrului exterior. Compania efectuează în mod regulat astfel de teste, iar acum a sosit termenul limită pentru un nou test. Condițiile sunt aproape tipice, adecvate, de înțeles. Să începem.

Există un nume al clientului - să fie „Companie”, cu site-ul principal www.company.ru. Desigur, clientul este numit diferit, dar în acest articol totul va fi impersonal.
Efectuez recunoașterea rețelei - află ce adrese și domenii sunt înregistrate la client, desenează o diagramă de rețea, cum sunt distribuite serviciile la aceste adrese. Obțin rezultatul: peste 4000 de adrese IP live. Mă uit la domeniile din aceste rețele: din fericire, marea majoritate sunt rețele destinate clienților clienților și nu suntem interesați oficial de ele. Clientul crede la fel.

Rămâne o singură rețea cu 256 de adrese, pentru care până în acest moment există deja o înțelegere a distribuției domeniilor și subdomeniilor pe adrese IP, există informații despre porturile scanate, ceea ce înseamnă că puteți privi serviciile pentru cele interesante. În paralel, toate tipurile de scanere sunt lansate pe adresele IP disponibile și separat pe site-uri web.

Există o mulțime de servicii. De obicei, aceasta este bucurie pentru pentester și anticiparea unei victorii rapide, deoarece cu cât există mai multe servicii, cu atât câmpul de atac este mai mare și cu atât este mai ușor să găsiți un artefact. O privire rapidă asupra site-urilor web a arătat că majoritatea sunt interfețe web ale unor produse cunoscute ale marilor companii globale, care după toate aparențele vă spun că nu sunt binevenite. Ei cer un nume de utilizator și o parolă, scutură câmpul pentru introducerea celui de-al doilea factor, cer un certificat de client TLS sau îl trimit la Microsoft ADFS. Unele sunt pur și simplu inaccesibile de pe Internet. Pentru unii, evident că trebuie să aveți un client special plătit pentru trei salarii sau să știți adresa URL exactă pe care să o introduceți. Să omitem încă o săptămână de descurajare treptată în procesul de încercare de a „spărge” versiuni de software pentru vulnerabilități cunoscute, căutând conținut ascuns în căile web și conturi scurse de la servicii terțe precum LinkedIn, încercând să ghicească parolele folosindu-le, de asemenea precum excavarea vulnerabilităților în site-urile web auto-scrise - apropo, conform statisticilor, acesta este cel mai promițător vector de atac extern astăzi. Voi observa imediat arma de film care a tras ulterior.

Așadar, am găsit două site-uri care s-au remarcat din sute de servicii. Aceste site-uri aveau un lucru în comun: dacă nu vă angajați într-o recunoaștere meticuloasă a rețelei în funcție de domeniu, dar căutați frontal porturi deschise sau vizați un scanner de vulnerabilități folosind un interval IP cunoscut, atunci aceste site-uri vor scăpa de scanare și pur și simplu nu vor fi vizibil fără a cunoaște numele DNS. Poate că au fost ratate mai devreme, cel puțin, iar instrumentele noastre automate nu au găsit probleme cu ele, chiar dacă au fost trimise direct la resursă.

Apropo, despre ce au găsit scanerele lansate anterior în general. Permiteți-mi să vă reamintesc: pentru unii oameni, „pentest” este echivalent cu „scanare automată”. Dar scanerele de pe acest proiect nu au spus nimic. Ei bine, maximul l-au arătat vulnerabilitățile Mediu (3 din 5 din punct de vedere al gravității): pe unele servicii un certificat TLS prost sau algoritmi de criptare învechiți, iar pe majoritatea site-urilor Clickjacking. Dar asta nu te va duce la obiectivul tău. Poate că scanerele ar fi mai utile aici, dar permiteți-mi să vă reamintesc: clientul însuși este capabil să achiziționeze astfel de programe și să se testeze cu ele și, judecând după rezultatele nefaste, el a verificat deja.

Să revenim la site-urile „anomale”. Primul este ceva de genul unui Wiki local la o adresă non-standard, dar în acest articol să fie wiki.company[.]ru. Ea a cerut imediat un login și o parolă, dar prin NTLM în browser. Pentru utilizator, aceasta arată ca o fereastră ascetică care cere să introducă un nume de utilizator și o parolă. Și aceasta este o practică proastă.

O mică notă. NTLM în site-urile web perimetrale este rău din mai multe motive. Primul motiv este că numele de domeniu Active Directory este dezvăluit. În exemplul nostru, s-a dovedit a fi, de asemenea, company.ru, la fel ca numele DNS „extern”. Știind acest lucru, puteți pregăti cu atenție ceva rău intenționat, astfel încât să fie executat numai pe mașina de domeniu a organizației, și nu într-un sandbox. În al doilea rând, autentificarea trece direct prin controlerul de domeniu prin NTLM (surpriză, nu?), cu toate caracteristicile politicilor de rețea „interne”, inclusiv blocarea conturilor pentru a nu depăși numărul de încercări de introducere a parolei. Dacă un atacator află datele de conectare, va încerca parole pentru ele. Dacă sunteți configurat să blocați conturile să nu introducă parole incorecte, va funcționa și contul va fi blocat. În al treilea rând, este imposibil să adăugați un al doilea factor la o astfel de autentificare. Dacă vreunul dintre cititori mai știe cum, vă rog să-mi spuneți, este foarte interesant. În al patrulea rând, vulnerabilitatea la atacurile pass-the-hash. ADFS a fost inventat, printre altele, pentru a proteja împotriva tuturor acestor lucruri.

Există o proprietate proastă a produselor Microsoft: chiar dacă nu ați publicat în mod specific un astfel de NTLM, acesta va fi instalat implicit în OWA și Lync, cel puțin.

Apropo, autorul acestui articol a blocat odată accidental aproximativ 1000 de conturi ale angajaților unei bănci mari în doar o oră folosind aceeași metodă și apoi a părut oarecum palid. Serviciile IT ale băncii au fost și ele palide, dar totul s-a terminat bine și adecvat, chiar am fost lăudați că am găsit primii această problemă și am provocat o remediere rapidă și hotărâtă.

Al doilea site avea adresa „evident un fel de nume de familie.company.ru”. L-am găsit prin Google, ceva de genul acesta la pagina 10. Designul a fost de la începutul anilor XNUMX și o persoană respectabilă îl privea de pe pagina principală, ceva de genul acesta:

Aici am luat un alambic din „Heart of a Dog”, dar credeți-mă, era vag asemănător, chiar și designul de culoare era în tonuri similare. Lasă site-ul să fie numit preobrazhensky.company.ru.

Era un site web personal... pentru un urolog. M-am întrebat ce face site-ul unui urolog pe subdomeniul unei companii de înaltă tehnologie. O analiză rapidă în Google a arătat că acest medic a fost co-fondator al uneia dintre entitățile juridice ale clienților noștri și chiar a contribuit cu aproximativ 1000 de ruble în capitalul autorizat. Site-ul a fost creat probabil cu mulți ani în urmă, iar resursele de server ale clientului au fost folosite ca găzduire. Site-ul și-a pierdut de multă relevanță, dar din anumite motive a fost lăsat să funcționeze mult timp.

În ceea ce privește vulnerabilitățile, site-ul în sine era securizat. Privind în perspectivă, voi spune că a fost un set de informații statice - simple pagini html cu ilustrații inserate sub formă de rinichi și vezici urinare. Este inutil să „spărgi” un astfel de site.

Dar serverul web de dedesubt era mai interesant. Judecând după antetul serverului HTTP, avea IIS 6.0, ceea ce înseamnă că folosea Windows 2003 ca ​​sistem de operare. Scanerul a identificat anterior că acest site web special de urolog, spre deosebire de alte gazde virtuale de pe același server web, a răspuns la comanda PROPFIND, ceea ce înseamnă că rula WebDAV. Apropo, scanerul a returnat aceste informații cu marca Info (în limba rapoartelor scanerului, acesta este pericolul cel mai mic) - astfel de lucruri sunt de obicei omise pur și simplu. În combinație, acest lucru a dat un efect interesant, care a fost dezvăluit abia după o altă săpătură pe Google: o vulnerabilitate rară de depășire a tamponului asociată cu setul Shadow Brokers, și anume CVE-2017-7269, care avea deja un exploit gata făcut. Cu alte cuvinte, vor fi probleme dacă aveți Windows 2003 și WebDAV rulează pe IIS. Deși rularea Windows 2003 în producție în 2018 este o problemă în sine.

Exploita-ul a ajuns în Metasploit și a fost imediat testat cu o încărcare care a trimis o solicitare DNS către un serviciu controlat - Burp Collaborator este folosit în mod tradițional pentru a captura cererile DNS. Spre surprinderea mea, a funcționat prima dată: a fost primit un knockout DNS. Apoi, a existat o încercare de a crea o conexiune prin portul 80 (adică o conexiune de rețea de la server la atacator, cu acces la cmd.exe pe gazda victimei), dar apoi a avut loc un fiasco. Conexiunea nu s-a realizat, iar după a treia încercare de a folosi site-ul, împreună cu toate pozele interesante, au dispărut pentru totdeauna.

De obicei, aceasta este urmată de o scrisoare în stilul „client, trezește-te, am scăpat totul”. Dar ni s-a spus că site-ul nu are nicio legătură cu procesele de afaceri și funcționează acolo fără niciun motiv, la fel ca întregul server și că putem folosi această resursă după bunul plac.
Aproximativ o zi mai târziu, site-ul a început brusc să funcționeze singur. După ce am construit o bancă din WebDAV pe IIS 6.0, am descoperit că setarea implicită este repornirea proceselor de lucru IIS la fiecare 30 de ore. Adică, când controlul a părăsit codul shell, procesul de lucru IIS s-a încheiat, apoi s-a repornit de câteva ori și apoi s-a oprit timp de 30 de ore.

Deoarece backconnect-ul la tcp a eșuat prima dată, am atribuit această problemă unui port închis. Adică a presupus prezența unui fel de firewall care nu permitea conexiunilor de ieșire să treacă în exterior. Am început să rulez coduri shell care au căutat prin multe porturi tcp și udp, nu a avut niciun efect. Încărcările inverse ale conexiunii prin http(e) de la Metasploit nu au funcționat - meterpreter/reverse_http(s). Dintr-o dată, s-a stabilit o conexiune la același port 80, dar a încetat imediat. Am pus acest lucru pe seama acțiunii IPS-ului încă imaginar, căruia nu-i plăcea traficul meterpreter. Având în vedere faptul că o conexiune pur tcp la portul 80 nu a trecut, dar o conexiune http, am ajuns la concluzia că un proxy http a fost cumva configurat în sistem.

Am încercat chiar și meterpreter prin DNS (mulțumesc d00kie pentru eforturile tale, a salvat multe proiecte), amintind de primul succes, dar nici măcar nu a funcționat pe stand - shellcode-ul era prea voluminos pentru această vulnerabilitate.

În realitate, arăta așa: 3-4 încercări de atac în 5 minute, apoi așteptarea timp de 30 de ore. Și așa mai departe timp de trei săptămâni la rând. Am setat chiar și un memento pentru a nu pierde timpul. În plus, a existat o diferență în comportamentul mediilor de testare și de producție: pentru această vulnerabilitate au existat două exploit-uri similare, unul de la Metasploit, al doilea de pe Internet, convertit din versiunea Shadow Brokers. Deci, doar Metasploit a fost testat în luptă, iar doar al doilea a fost testat pe bancă, ceea ce a făcut ca depanarea să fie și mai dificilă și a fost explozivă.

În cele din urmă, un shellcode care a descărcat un fișier exe de pe un anumit server prin http și l-a lansat pe sistemul țintă s-a dovedit a fi eficient. Shellcode-ul a fost suficient de mic pentru a se potrivi, dar cel puțin a funcționat. Deoarece serverului nu i-a plăcut deloc traficul TCP și http(e) a fost inspectat pentru prezența meterpreter, am decis că cea mai rapidă modalitate a fost să descarc un fișier exe care conținea DNS-meterpreter prin acest shellcode.

Aici a apărut din nou o problemă: la descărcarea unui fișier exe și, după cum au arătat încercările, indiferent care, descărcarea a fost întreruptă. Din nou, un dispozitiv de securitate dintre serverul meu și urolog nu i-a plăcut traficul http cu un exe înăuntru. Soluția „rapidă” părea să fie schimbarea codului shell, astfel încât să ofusca traficul http din mers, astfel încât datele binare abstracte să fie transferate în loc de exe. În cele din urmă, atacul a avut succes, controlul a fost primit prin canalul subțire DNS:

Imediat a devenit clar că am cele mai elementare drepturi de flux de lucru IIS, care îmi permit să nu fac nimic. Iată cum arăta pe consola Metasploit:

Toate metodologiile pentest sugerează cu tărie că trebuie să măriți drepturile atunci când obțineți acces. De obicei, nu fac acest lucru la nivel local, deoarece primul acces este văzut pur și simplu ca un punct de intrare în rețea, iar compromiterea unei alte mașini din aceeași rețea este de obicei mai ușoară și mai rapidă decât escaladarea privilegiilor pe o gazdă existentă. Dar nu este cazul aici, deoarece canalul DNS este foarte îngust și nu va permite traficului să se curățeze.

Presupunând că acest server Windows 2003 nu a fost reparat pentru faimoasa vulnerabilitate MS17-010, tunelez traficul către portul 445/TCP prin tunelul DNS meterpreter către localhost (da, acest lucru este posibil) și încerc să rulez exe descărcat anterior prin vulnerabilitatea. Atacul funcționează, primesc o a doua conexiune, dar cu drepturi de SISTEM.

Este interesant că au încercat în continuare să protejeze serverul de MS17-010 - avea serviciile de rețea vulnerabile dezactivate pe interfața externă. Acest lucru protejează împotriva atacurilor în rețea, dar atacul din interior pe localhost a funcționat, deoarece nu puteți dezactiva rapid SMB pe localhost.

În continuare, sunt dezvăluite noi detalii interesante:

1. Având drepturi de SISTEM, puteți stabili cu ușurință o backconnection prin TCP. Evident, dezactivarea TCP directă este strict o problemă pentru utilizatorul IIS limitat. Spoiler: traficul utilizatorului IIS a fost oarecum împachetat în proxy-ul ISA local în ambele direcții. Cum funcționează exact, nu am reprodus.
2. Sunt într-un anumit „DMZ” (și acesta nu este un domeniu Active Directory, ci un WORKGROUP) - sună logic. Dar în loc de adresa IP privată așteptată („gri”), am o adresă IP complet „albă”, exact aceeași cu cea pe care am atacat-o mai devreme. Aceasta înseamnă că compania este atât de veche în lumea adresei IPv4 încât își poate permite să mențină o zonă DMZ pentru 128 de adrese „albe” fără NAT, conform schemei, așa cum este descris în manualele Cisco din 2005.

Deoarece serverul este vechi, Mimikatz este garantat să funcționeze direct din memorie:

Primesc parola de administrator local, tunelul traficului RDP prin TCP și mă conectez la un desktop confortabil. Întrucât puteam face tot ce voiam cu serverul, am eliminat antivirusul și am constatat că serverul era accesibil de pe Internet doar prin porturile TCP 80 și 443, iar 443 nu era ocupat. Am configurat un server OpenVPN pe 443, adaug funcții NAT pentru traficul meu VPN și am acces direct la rețeaua DMZ într-o formă nelimitată prin OpenVPN-ul meu. Este de remarcat faptul că ISA, având câteva funcții IPS nedezactivate, mi-a blocat traficul cu scanarea portului, pentru care a trebuit să fie înlocuit cu un RRAS mai simplu și mai conform. Așa că, uneori, pentesterii mai trebuie să administreze tot felul de lucruri.

Un cititor atent va întreba: „Dar al doilea site - un wiki cu autentificare NTLM, despre care s-au scris atât de multe?” Mai multe despre asta mai târziu.

Partea 2. Încă nu criptați? Atunci venim la tine deja aici

Deci, există acces la segmentul de rețea DMZ. Trebuie să mergeți la administratorul de domeniu. Primul lucru care îmi vine în minte este să verificăm automat securitatea serviciilor din segmentul DMZ, mai ales că multe altele sunt acum deschise pentru cercetare. O imagine tipică în timpul unui test de penetrare: perimetrul extern este mai bine protejat decât serviciile interne, iar atunci când obțineți orice acces în interiorul unei infrastructuri mari, este mult mai ușor să obțineți drepturi extinse într-un domeniu doar datorită faptului că acest domeniu începe să fie accesibil instrumentelor și, în al doilea rând, într-o infrastructură cu câteva mii de gazde, vor exista întotdeauna câteva probleme critice.

Încarc scanerele prin DMZ printr-un tunel OpenVPN și aștept. Deschid raportul - iarăși nimic grav, se pare că cineva a trecut prin aceeași metodă înaintea mea. Următorul pas este să examinăm modul în care gazdele din rețeaua DMZ comunică. Pentru a face acest lucru, mai întâi lansați Wireshark obișnuit și ascultați cererile de difuzare, în primul rând ARP. Pachetele ARP au fost colectate toată ziua. Se pare că în acest segment sunt folosite mai multe gateway-uri. Acest lucru va fi util mai târziu. Combinând datele privind cererile-răspunsuri ARP și datele de scanare porturi, am găsit punctele de ieșire ale traficului utilizatorilor din interiorul rețelei locale, pe lângă acele servicii care erau cunoscute anterior, cum ar fi web și e-mail.

Deoarece în momentul de față nu aveam acces la alte sisteme și nu aveam un singur cont pentru serviciile corporative, s-a decis să scot măcar un cont din trafic folosind ARP Spoofing.

Cain&Abel a fost lansat pe serverul urologului. Luând în considerare fluxurile de trafic identificate, au fost selectate cele mai promițătoare perechi pentru atacul man-in-the-middle, iar apoi o parte din trafic de rețea a fost primit prin lansare pe termen scurt timp de 5-10 minute, cu un temporizator pentru a reporni serverul în caz de îngheț. Ca și în glumă, au fost două știri:

1. Bine: au fost prinse o mulțime de acreditări și atacul în ansamblu a funcționat.
2. De rău: toate acreditările au fost de la proprii clienți ai clientului. În timp ce oferă servicii de asistență, specialiștii clienți s-au conectat la serviciile clienților care nu au avut întotdeauna configurată criptarea traficului.

Drept urmare, am dobândit o mulțime de acreditări care au fost inutile în contextul proiectului, dar cu siguranță interesante ca demonstrație a pericolului atacului. Routere de frontieră ale companiilor mari cu telnet, porturi http de depanare redirecționate către CRM intern cu toate datele, acces direct la RDP din Windows XP în rețeaua locală și alte obscurantism. A ieșit așa Compromisul lanțului de aprovizionare conform matricei MITRE.

Am găsit și o oportunitate amuzantă de a aduna scrisori din trafic, ceva de genul acesta. Acesta este un exemplu de scrisoare gata făcută care a trecut de la clientul nostru la portul SMTP al clientului său, din nou, fără criptare. Un anume Andrey îi cere omonimului său să trimită din nou documentația și aceasta este încărcată pe un disc cloud cu autentificare, parolă și link într-o scrisoare de răspuns:

Acesta este un alt memento pentru a cripta toate serviciile. Nu se știe cine și când va citi și utiliza datele dvs. în mod specific - furnizorul, administratorul de sistem al altei companii sau un astfel de pentester. Tac despre faptul că mulți oameni pot pur și simplu intercepta traficul necriptat.

În ciuda succesului aparent, acest lucru nu ne-a apropiat de obiectiv. Era posibil, desigur, să stai mult timp și să scoți informații valoroase, dar nu este un fapt că ar apărea acolo, iar atacul în sine este foarte riscant în ceea ce privește integritatea rețelei.

După încă o săpătură în servicii, mi-a venit în minte o idee interesantă. Există un astfel de utilitar numit Responder (este ușor de găsit exemple de utilizare cu acest nume), care, prin „otrăvirea” solicitărilor de difuzare, provoacă conexiuni printr-o varietate de protocoale precum SMB, HTTP, LDAP etc. în moduri diferite, apoi le cere tuturor celor care se conectează să se autentifice și o configurează astfel încât autentificarea să aibă loc prin NTLM și într-un mod transparent pentru victimă. Cel mai adesea, un atacator colectează strângeri de mână NetNTLMv2 în acest fel și de la acestea, folosind un dicționar, recuperează rapid parolele utilizatorului de domeniu. Aici am vrut ceva asemănător, dar utilizatorii stăteau „în spatele unui perete”, sau mai bine zis, erau separați de un firewall și accesau WEB-ul prin clusterul proxy Blue Coat.

Amintiți-vă, am specificat că numele de domeniu Active Directory coincide cu domeniul „extern”, adică era company.ru? Deci, Windows, mai exact Internet Explorer (și Edge și Chrome), permit utilizatorului să se autentifice transparent în HTTP prin NTLM dacă consideră că site-ul se află într-o „Zonă Intranet”. Unul dintre semnele unui „Intranet” este accesul la o adresă IP „gri” sau un nume DNS scurt, adică fără puncte. Deoarece aveau un server cu un nume IP și DNS „alb” preobrazhensky.company.ru, iar mașinile de domeniu primesc de obicei sufixul de domeniu Active Directory prin DHCP pentru introducerea simplificată a numelui, au trebuit doar să scrie URL-ul în bara de adrese. preobrazhensky, astfel încât să găsească calea corectă către serverul urologului compromis, fără a uita că aceasta se numește acum „Intranet”. Adică, în același timp, dându-mi strângerea de mână NTLM a utilizatorului fără știrea lui. Tot ce rămâne este să forțezi browserele client să se gândească la necesitatea urgentă de a contacta acest server.

Minunatul utilitar Intercepter-NG a venit în ajutor (mulțumesc Interceptor). Ți-a permis să schimbi traficul din mers și a funcționat excelent pe Windows 2003. Avea chiar și funcționalitate separată pentru modificarea numai fișierelor JavaScript în fluxul de trafic. A fost planificat un fel de cross-site Scripting masiv.

Proxy-urile Blue Coat, prin care utilizatorii au accesat WEB-ul global, au stocat periodic conținut static. Prin interceptarea traficului, era clar că lucrează non-stop, solicitând la nesfârșit statice utilizate frecvent pentru a accelera afișarea conținutului în orele de vârf. În plus, BlueCoat avea un User-Agent specific, care îl deosebea clar de un utilizator real.

A fost pregătit Javascript, care, folosind Intercepter-NG, a fost implementat timp de o oră noaptea pentru fiecare răspuns cu fișiere JS pentru Blue Coat. Scenariul a făcut următoarele:

• A determinat browserul curent de către User-Agent. Dacă era Internet Explorer, Edge sau Chrome, a continuat să funcționeze.
• Am așteptat până s-a format DOM-ul paginii.
• S-a inserat o imagine invizibilă în DOM cu un atribut src al formularului preobrazhensky:8080/NNNNNNN.png, unde NNN sunt numere arbitrare, astfel încât BlueCoat să nu-l memoreze în cache.
• Setați o variabilă flag globală pentru a indica faptul că injecția a fost finalizată și că nu mai este nevoie să inserați imagini.

Browserul a încercat să încarce această imagine; pe portul 8080 al serverului compromis, un tunel TCP o aștepta pe laptopul meu, unde rula același Responder, solicitând browserului să se conecteze prin NTLM.

Judecând după jurnalele Responder, oamenii au venit la muncă dimineața, și-au pornit stațiile de lucru, apoi au început în masă și neobservați să viziteze serverul urologului, fără a uita să „scurgă” strângerile de mână NTLM. Strângeri de mână au plouat toată ziua și au acumulat clar material pentru un atac evident de succes de recuperare a parolelor. Iată cum arătau jurnalele de răspuns:

Vizite secrete în masă la serverul urologului de către utilizatori

Probabil ați observat deja că toată povestea este construită pe principiul „totul a fost bine, dar apoi a fost o dezamăgire, apoi a fost o depășire și apoi totul a ajuns la succes”. Așadar, a fost o prostie aici. Din cele cincizeci de strângeri de mână unice, nici una nu a fost dezvăluită. Și asta ține cont de faptul că, chiar și pe un laptop cu un procesor mort, aceste strângeri de mână NTLMv2 sunt procesate cu o viteză de câteva sute de milioane de încercări pe secundă.

A trebuit să mă înarmez cu tehnici de mutare a parolelor, o placă video, un dicționar mai gros și să aștept. După mult timp, au fost dezvăluite mai multe conturi cu parole de forma „Q11111111....1111111q”, ceea ce sugerează că toți utilizatorii au fost odată forțați să vină cu o parolă foarte lungă cu diferite majuscule de caractere, care ar fi trebuit fi complex. Dar nu poți păcăli un utilizator experimentat și așa și-a făcut să-și amintească mai ușor. În total, aproximativ 5 conturi au fost compromise, iar doar unul dintre ele avea drepturi valoroase asupra serviciilor.

Partea 3. Roskomnadzor replică

Deci, au fost primite primele conturi de domeniu. Dacă nu ați adormit până în acest moment dintr-o lectură lungă, probabil vă veți aminti că am menționat un serviciu care nu necesita un al doilea factor de autentificare: este un wiki cu autentificare NTLM. Desigur, primul lucru de făcut a fost să intri acolo. Săpătura în baza internă de cunoștințe a adus rapid rezultate:

• Compania are o rețea WiFi cu autentificare folosind conturi de domeniu cu acces la rețeaua locală. Cu setul actual de date, acesta este deja un vector de atac funcțional, dar trebuie să mergeți la birou cu picioarele și să vă aflați undeva pe teritoriul biroului clientului.
• Am găsit o instrucțiune conform căreia exista un serviciu care permitea... să înregistreze independent un dispozitiv de autentificare „al doilea factor” dacă utilizatorul se află într-o rețea locală și își amintește cu încredere autentificarea și parola de domeniu. În acest caz, „înăuntru” și „exterior” au fost determinate de accesibilitatea portului acestui serviciu pentru utilizator. Portul nu era accesibil de pe Internet, dar era destul de accesibil prin DMZ.

Desigur, un „al doilea factor” a fost adăugat imediat la contul compromis sub forma unei aplicații pe telefonul meu. A existat un program care putea fie să trimită cu voce tare o solicitare push către telefon cu butoanele „aprobă”/„dezaprobă” pentru acțiune, fie să arate în tăcere codul OTP pe ecran pentru o introducere independentă ulterioară. Mai mult, prima metodă a fost presupusă de instrucțiuni a fi singura corectă, dar nu a funcționat, spre deosebire de metoda OTP.

Cu „al doilea factor” rupt, am putut accesa e-mailul Outlook Web Access și accesul de la distanță în Citrix Netscaler Gateway. A fost o surpriză în e-mail în Outlook:

În această fotografie rară puteți vedea cum Roskomnadzor îi ajută pe pentesteri

Au fost primele luni de la celebra blocare „fan” a Telegramului, când rețele întregi cu mii de adrese au dispărut inexorabil de la acces. A devenit clar de ce împingerea nu a funcționat imediat și de ce „victima” mea nu a sunat un semnal de alarmă, deoarece au început să-i folosească contul în timpul orelor deschise.

Oricine cunoaște Citrix Netscaler își imaginează că acesta este de obicei implementat în așa fel încât să poată fi transmisă utilizatorului doar o interfață de imagine, încercând să nu-i ofere instrumentele pentru a lansa aplicații terțe și a transfera date, limitând în orice mod posibil acțiunile. prin carcase de control standard. „Victima mea”, datorită ocupației sale, a primit doar 1C:

După ce m-am plimbat puțin prin interfața 1C, am constatat că acolo există module de procesare externe. Acestea pot fi încărcate de pe interfață, și vor fi executate pe client sau server, în funcție de drepturi și setări.

Mi-am cerut prietenilor mei programatori 1C să creeze o procesare care să accepte un șir și să-l execute. În limbajul 1C, începerea unui proces arată cam așa (preluat de pe Internet). Sunteți de acord că sintaxa limbii 1C uimește pe cei vorbitori de limbă rusă prin spontaneitatea ei?

Procesarea a fost executată perfect; s-a dovedit a fi ceea ce pentesterii numesc „cochilie” - Internet Explorer a fost lansat prin intermediul acestuia.

Anterior, adresa unui sistem care vă permite să comandați permise către teritoriu a fost găsită prin poștă. Am comandat o trecere în cazul în care a trebuit să folosesc un vector de atac WiFi.

Se vorbește pe internet că încă mai exista catering delicios gratuit la biroul clientului, dar tot am preferat să dezvolt atacul de la distanță, e mai calm.

AppLocker a fost activat pe serverul de aplicații care rulează Citrix, dar a fost ocolit. Același Meterpreter a fost încărcat și lansat prin DNS, deoarece versiunile http(e) nu doreau să se conecteze și nu știam adresa proxy internă la acel moment. Apropo, din acest moment, pentestul extern s-a transformat în esență complet într-unul intern.

Partea 4. Drepturile de administrator pentru utilizatori sunt proaste, bine?

Prima sarcină a unui pentester atunci când obține controlul asupra unei sesiuni de utilizator de domeniu este să colecteze toate informațiile despre drepturile din domeniu. Există un utilitar BloodHound care vă permite automat să descărcați informații despre utilizatori, computere, grupuri de securitate prin protocolul LDAP de la un controler de domeniu și prin SMB - informații despre ce utilizator s-a autentificat recent, unde și cine este administratorul local.

O tehnică tipică de confiscare a drepturilor de administrator de domeniu pare simplificată ca un ciclu de acțiuni monotone:

• Mergem la computere de domeniu unde există drepturi de administrator local, pe baza conturilor de domeniu deja capturate.
• Lansăm Mimikatz și obținem parole memorate în cache, bilete Kerberos și hash-uri NTLM ale conturilor de domeniu care s-au conectat recent la acest sistem. Sau eliminăm imaginea de memorie a procesului lsass.exe și facem același lucru din partea noastră. Acest lucru funcționează bine cu Windows mai vechi de 2012R2/Windows 8.1 cu setări implicite.
• Determinăm unde conturile compromise au drepturi de administrator local. Repetăm ​​primul punct. La un moment dat obținem drepturi de administrator pentru întregul domeniu.

„Sfârșitul ciclului”, așa cum ar scrie aici programatorii 1C.

Deci, utilizatorul nostru s-a dovedit a fi un administrator local pe o singură gazdă cu Windows 7, al cărui nume includea cuvântul „VDI” sau „Virtual Desktop Infrastructure”, mașini virtuale personale. Probabil, designerul serviciului VDI a vrut să spună că, deoarece VDI este sistemul de operare personal al utilizatorului, chiar dacă utilizatorul schimbă mediul software după bunul plac, gazda poate fi în continuare „reîncărcată”. De asemenea, am crezut că, în general, ideea a fost bună, am fost la această gazdă VDI personală și am făcut un cuib acolo:

• Am instalat acolo un client OpenVPN, care a făcut un tunel prin Internet către serverul meu. Clientul a trebuit să fie forțat să treacă prin același Blue Coat cu autentificarea domeniului, dar OpenVPN a făcut-o, așa cum se spune, „din cutie”.
• S-a instalat OpenSSH pe VDI. Ei bine, într-adevăr, ce este Windows 7 fără SSH?

Așa arăta în direct. Permiteți-mi să vă reamintesc că toate acestea trebuie făcute prin Citrix și 1C:

O tehnică de promovare a accesului la computerele vecine este verificarea parolelor de administrator local pentru o potrivire. Aici norocul a așteptat imediat: hash-ul NTLM al administratorului local implicit (care a fost numit brusc Administrator) a fost abordat printr-un atac de tip pass-the-hash către gazdele VDI vecine, dintre care erau câteva sute. Desigur, atacul i-a lovit imediat.

Aici administratorii VDI s-au împușcat în picior de două ori:

• Prima dată a fost când mașinile VDI nu au fost aduse sub LAPS, păstrând în esență aceeași parolă de administrator local din imaginea care a fost implementată masiv în VDI.
• Administratorul implicit este singurul cont local care este vulnerabil la atacurile pass-the-hash. Chiar și cu aceeași parolă, ar fi posibil să se evite compromisurile în masă prin crearea unui al doilea cont de administrator local cu o parolă aleatorie complexă și blocând-o pe cea implicită.

De ce există un serviciu SSH pe acel Windows? Foarte simplu: acum serverul OpenSSH nu numai că a oferit un shell de comandă interactiv convenabil fără a interfera cu munca utilizatorului, ci și un proxy socks5 pe VDI. Prin intermediul acestor șosete, m-am conectat prin SMB și am colectat conturi stocate în cache de la toate aceste sute de mașini VDI, apoi am căutat calea către administratorul de domeniu folosindu-le în graficele BloodHound. Cu sute de gazde la dispoziție, am găsit acest mod destul de repede. Au fost obținute drepturi de administrator de domeniu.

Iată o imagine de pe Internet care arată o căutare similară. Conexiunile arată cine este administratorul și cine este conectat unde.

Apropo, amintiți-vă de condiția de la începutul proiectului - „nu folosiți ingineria socială”. Așadar, îmi propun să mă gândesc cât de mult ar fi tăiat tot acest Bollywood cu efecte speciale dacă ar mai fi posibil să se folosească banal phishing. Dar personal, a fost foarte interesant pentru mine să fac toate acestea. Sper că ți-a plăcut să citești asta. Desigur, nu orice proiect pare atât de intrigant, dar munca în ansamblu este foarte provocatoare și nu îi permite să stagneze.

Probabil cineva va avea o întrebare: cum să te protejezi? Chiar și acest articol descrie multe tehnici, multe dintre care administratorii Windows nici măcar nu le cunosc. Cu toate acestea, îmi propun să le privesc din perspectiva principiilor și măsurilor de securitate a informațiilor:

• nu utilizați software învechit (vă amintiți Windows 2003 la început?)
• nu păstrați sistemele inutile pornite (de ce a existat un site web al unui urolog?)
• verificați singur parolele de utilizator pentru putere (altfel soldații... pentesterii vor face asta)
• nu au aceleași parole pentru conturi diferite (compromis VDI)
• si altul

Desigur, acest lucru este foarte greu de implementat, dar în articolul următor vom arăta în practică că este foarte posibil.

Sursa: www.habr.com