Hierdie artikel is geskryf op grond van 'n baie suksesvolle pentest wat Group-IB-spesialiste 'n paar jaar gelede gedoen het: 'n storie het gebeur wat in Bollywood vir film aangepas kan word. Nou, waarskynlik, sal die leser se reaksie volg: "O, nog 'n PR-artikel, weereens word hierdie uitgebeeld, hoe goed is hulle, moenie vergeet om 'n pentest te koop nie." Wel, aan die een kant is dit. Daar is egter 'n aantal ander redes waarom hierdie artikel verskyn het. Ek wou wys wat presies pentesters doen, hoe interessant en nie-triviaal hierdie werk kan wees, watter snaakse omstandighede in projekte kan ontstaan, en bowenal, lewendige materiaal met werklike voorbeelde wys.
Om die balans van beskeidenheid in die wêreld te herstel, sal ons na 'n rukkie skryf oor 'n pentest wat nie goed gegaan het nie. Ons sal wys hoe goed ontwerpte prosesse in 'n maatskappy kan beskerm teen 'n hele reeks aanvalle, selfs goed voorbereide, bloot omdat hierdie prosesse bestaan en werklik werk.
Vir die kliënt in hierdie artikel was alles ook oor die algemeen uitstekend, ten minste beter as 95% van die mark in die Russiese Federasie, volgens ons gevoelens, maar daar was 'n aantal klein nuanses wat 'n lang ketting van gebeure gevorm het, wat eers gelei tot 'n lang verslag oor die werk, en dan na hierdie artikel.
So, kom ons maak voorraad op springmielies, en welkom by die speurverhaal. Woord - Pavel Suprunyuk, tegniese bestuurder van die “Oudit and Consulting”-afdeling van Group-IB.
Deel 1. Pochkin dokter
2018 Daar is 'n kliënt - 'n hoë-tegnologie IT-maatskappy, wat self baie kliënte bedien. Wil jy 'n antwoord op die vraag kry: is dit moontlik, sonder enige aanvanklike kennis en toegang, om via die internet te werk om Active Directory-domeinadministrateurregte te verkry? Ek stel nie belang in enige sosiale ingenieurswese nie (), is hulle nie van plan om doelbewus met die werk in te meng nie, maar hulle kan per ongeluk - byvoorbeeld 'n vreemd werkende bediener herlaai. 'n Bykomende doelwit is om soveel as moontlik ander aanvalvektore teen die buitenste omtrek te identifiseer. Die maatskappy doen gereeld sulke toetse, en nou het die sperdatum vir 'n nuwe toets aangebreek. Die toestande is amper tipies, voldoende, verstaanbaar. Laat ons begin.
Daar is 'n naam van die kliënt - laat dit "Maatskappy" wees, met die hoofwebwerf . Natuurlik word die kliënt anders genoem, maar in hierdie artikel sal alles onpersoonlik wees.
Ek doen netwerkverkenning - vind uit watter adresse en domeine by die kliënt geregistreer is, teken 'n netwerkdiagram, hoe dienste na hierdie adresse versprei word. Ek kry die resultaat: meer as 4000 lewendige IP-adresse. Ek kyk na die domeine in hierdie netwerke: gelukkig is die oorgrote meerderheid netwerke wat vir die kliënt se kliënte bedoel is, en ons stel nie formeel daarin belang nie. Die kliënt dink dieselfde.
Daar is nog een netwerk met 256 adresse, waarvoor daar op hierdie oomblik reeds 'n begrip is van die verspreiding van domeine en subdomeine deur IP-adresse, daar is inligting oor die geskandeerde poorte, wat beteken dat u na die dienste kan kyk vir interessantes. Terselfdertyd word alle soorte skandeerders op beskikbare IP-adresse en afsonderlik op webwerwe bekendgestel.
Daar is baie dienste. Gewoonlik is dit vreugde vir die penster en die afwagting van 'n vinnige oorwinning, aangesien hoe meer dienste daar is, hoe groter die veld vir aanval en hoe makliker is dit om 'n artefak te vind. ’n Vinnige blik op die webwerwe het gewys dat die meeste van hulle webkoppelvlakke is van bekende produkte van groot wêreldwye maatskappye, wat jou blykbaar sê dat hulle nie welkom is nie. Hulle vra vir 'n gebruikersnaam en wagwoord, skud die veld uit om die tweede faktor in te voer, vra vir 'n TLS-kliëntsertifikaat, of stuur dit na Microsoft ADFS. Sommige is eenvoudig ontoeganklik vanaf die internet. Vir sommige moet jy natuurlik 'n spesiale betaalde kliënt hê vir drie salarisse of weet wat die presiese URL is om in te voer. Kom ons slaan nog 'n week van geleidelike moedeloosheid oor in die proses om sagteware-weergawes te probeer "deurbreek" vir bekende kwesbaarhede, soek na verborge inhoud in webpaaie en uitgelekte rekeninge van derdeparty-dienste soos LinkedIn, en probeer om wagwoorde te raai deur dit ook te gebruik. as die opgrawing van kwesbaarhede in selfgeskrewe webwerwe - terloops, volgens statistieke, is dit vandag die mees belowende vektor van eksterne aanval. Ek sal dadelik let op die filmgeweer wat daarna afgevuur het.
So, ons het twee webwerwe gevind wat uitgestaan het van honderde dienste. Hierdie werwe het een ding in gemeen gehad: as jy nie betrokke is by noukeurige netwerkverkenning per domein nie, maar kop-aan-kop soek vir oop poorte of 'n kwesbaarheidskandeerder teiken met 'n bekende IP-reeks, dan sal hierdie werwe skandering vryspring en eenvoudig nie sigbaar sonder om die DNS-naam te ken. Miskien is hulle ten minste vroeër gemis, en ons outomatiese gereedskap het geen probleme met hulle gevind nie, selfs al is dit direk na die hulpbron gestuur.
Terloops, oor wat voorheen geloods skandeerders in die algemeen gevind het. Laat ek jou herinner: vir sommige mense is "pentest" gelykstaande aan "outomatiese skandering". Maar die skandeerders op hierdie projek het niks gesê nie. Wel, die maksimum is getoon deur medium kwesbaarhede (3 uit 5 in terme van erns): op een of ander diens 'n slegte TLS-sertifikaat of verouderde enkripsie-algoritmes, en op die meeste werwe Clickjacking. Maar dit sal jou nie by jou doel bring nie. Miskien sal skandeerders hier nuttiger wees, maar laat ek jou herinner: die kliënt kan self sulke programme koop en homself daarmee toets, en te oordeel aan die somber resultate, het hy reeds nagegaan.
Kom ons keer terug na die “afwykende” webwerwe. Die eerste is iets soos 'n plaaslike Wiki by 'n nie-standaard adres, maar laat dit in hierdie artikel wiki.company[.]ru wees. Sy het ook dadelik vir 'n login en wagwoord gevra, maar deur NTLM in die blaaier. Vir die gebruiker lyk dit soos 'n asketiese venster wat vra om 'n gebruikersnaam en wagwoord in te voer. En dit is slegte praktyk.
'n Klein nota. NTLM in omtrekwebwerwe is sleg om 'n aantal redes. Die eerste rede is dat die Active Directory-domeinnaam geopenbaar word. In ons voorbeeld het dit ook geblyk company.ru te wees, net soos die “eksterne” DNS-naam. As u dit weet, kan u iets kwaadwilligs versigtig voorberei sodat dit slegs op die organisasie se domeinmasjien uitgevoer word, en nie in een of ander sandbox nie. Tweedens gaan verifikasie direk deur die domeinbeheerder via NTLM (verrassing, reg?), met al die kenmerke van die “interne” netwerkbeleide, insluitend die blokkering van rekeninge om die aantal wagwoordinvoerpogings te oorskry. As 'n aanvaller die aanmeldings uitvind, sal hy wagwoorde daarvoor probeer. As jy opgestel is om rekeninge te blokkeer om verkeerde wagwoorde in te voer, sal dit werk en die rekening sal geblokkeer word. Derdens is dit onmoontlik om 'n tweede faktor by so 'n verifikasie te voeg. As enige van die lesers nog weet hoe, laat weet my asseblief, dit is regtig interessant. Vierdens, kwesbaarheid vir pass-the-hash-aanvalle. ADFS is onder meer uitgevind om teen dit alles te beskerm.
Daar is een slegte eienskap van Microsoft-produkte: selfs al het jy nie spesifiek sulke NTLM gepubliseer nie, sal dit ten minste by verstek in OWA en Lync geïnstalleer word.
Terloops, die skrywer van hierdie artikel het een keer per ongeluk ongeveer 1000 XNUMX rekeninge van werknemers van een groot bank in net een uur met dieselfde metode geblokkeer en toe ietwat bleek gelyk. Die bank se IT-dienste was ook bleek, maar alles het goed en voldoende geëindig, ons is selfs geprys omdat ons die eerste was wat hierdie probleem opgespoor het en 'n vinnige en beslissende oplossing uitgelok het.
Die tweede webwerf het die adres "natuurlik 'n soort van van.company.ru." Het dit deur Google gevind, iets soos hierdie op bladsy 10. Die ontwerp was van die vroeë middel XNUMX's, en 'n gerespekteerde persoon het vanaf die hoofblad daarna gekyk, iets soos hierdie:
Hier het ek 'n foto van "Heart of a Dog" geneem, maar glo my, dit was vaagweg soortgelyk, selfs die kleurontwerp was in soortgelyke kleure. Laat die webwerf genoem word preobrazhensky.company.ru.
Dit was 'n persoonlike webwerf... vir 'n uroloog. Ek het gewonder wat 'n uroloog se webwerf op die subdomein van 'n hoë-tegnologie maatskappy doen. 'n Vinnige grawe in Google het getoon dat hierdie dokter 'n medestigter van een van ons kliënt se regsentiteite was en selfs ongeveer 1000 XNUMX roebels in die gemagtigde kapitaal bygedra het. Die webwerf is waarskynlik baie jare gelede geskep, en die kliënt se bedienerhulpbronne is as gasheer gebruik. Die webwerf het lankal sy relevansie verloor, maar om een of ander rede is dit lank gelaat.
Wat kwesbaarhede betref, was die webwerf self veilig. As ek vorentoe kyk, sal ek sê dat dit 'n stel statiese inligting was - eenvoudige html-bladsye met ingevoegde illustrasies in die vorm van niere en blaas. Dit is nutteloos om so 'n webwerf te "breek".
Maar die webbediener daaronder was interessanter. Te oordeel aan die HTTP-bediener-kopskrif, het dit IIS 6.0 gehad, wat beteken dat dit Windows 2003 as die bedryfstelsel gebruik het. Die skandeerder het voorheen geïdentifiseer dat hierdie spesifieke uroloog-webwerf, anders as ander virtuele gashere op dieselfde webbediener, op die PROPFIND-opdrag gereageer het, wat beteken dat dit WebDAV loop. Terloops, die skandeerder het hierdie inligting teruggestuur met die merk Info (in die taal van skandeerderverslae is dit die laagste gevaar) - sulke goed word gewoonlik eenvoudig oorgeslaan. In kombinasie het dit 'n interessante effek gegee, wat eers na 'n ander grawery op Google onthul is: 'n seldsame buffer-oorloop-kwesbaarheid wat verband hou met die Shadow Brokers-stel, naamlik CVE-2017-7269, wat reeds 'n klaargemaakte ontginning gehad het. Met ander woorde, daar sal probleme wees as jy Windows 2003 het en WebDAV op IIS loop. Alhoewel Windows 2003 in produksie in 2018 'n probleem op sigself is.
Die ontginning het in Metasploit beland en is onmiddellik getoets met 'n vrag wat 'n DNS-versoek na 'n beheerde diens gestuur het - Burp Collaborator word tradisioneel gebruik om DNS-versoeke op te vang. Tot my verbasing het dit die eerste keer gewerk: 'n DNS-uitklop is ontvang. Vervolgens was daar 'n poging om 'n terugverbinding te skep via poort 80 (dit is 'n netwerkverbinding van die bediener na die aanvaller, met toegang tot cmd.exe op die slagoffergasheer), maar toe gebeur 'n fiasko. Die verbinding het nie deurgekom nie, en na die derde poging om die webwerf te gebruik, saam met al die interessante foto's, het dit vir altyd verdwyn.
Gewoonlik word dit gevolg deur 'n brief in die styl van "kliënt, word wakker, ons het alles laat val." Maar ons is meegedeel dat die webwerf niks met besigheidsprosesse te doen het nie en sonder enige rede daar werk, soos die hele bediener, en dat ons hierdie hulpbron kan gebruik soos ons wil.
Ongeveer 'n dag later het die webwerf skielik op sy eie begin werk. Nadat ek 'n bank van WebDAV op IIS 6.0 gebou het, het ek gevind dat die verstekinstelling is om IIS-werkerprosesse elke 30 uur te herbegin. Dit wil sê, toe beheer die dopkode verlaat het, het die IIS-werkerproses geëindig, dan het dit homself 'n paar keer herbegin en dan vir 30 uur gaan rus.
Aangesien die terugkoppeling na tcp die eerste keer misluk het, het ek hierdie probleem toegeskryf aan 'n geslote poort. Dit wil sê, hy het die teenwoordigheid van 'n soort firewall aanvaar wat nie toelaat dat uitgaande verbindings na buite beweeg nie. Ek het begin om dopkodes uit te voer wat deur baie tcp- en udp-poorte gesoek het, daar was geen effek nie. Omgekeerde verbindingladings via http(s) van Metasploit het nie gewerk nie - meterpreter/reverse_http(s). Skielik is 'n verbinding met dieselfde poort 80 tot stand gebring, maar het dadelik verval. Ek het dit toegeskryf aan die optrede van die steeds denkbeeldige IPS, wat nie van die meterpreterverkeer gehou het nie. In die lig van die feit dat 'n suiwer tcp-verbinding na poort 80 nie deurgegaan het nie, maar 'n http-verbinding wel, het ek tot die gevolgtrekking gekom dat 'n http-instaanbediener op een of ander manier in die stelsel opgestel is.
Ek het selfs meterpreter via DNS probeer (dankie vir jou pogings, het baie projekte gered), en herinner aan die heel eerste sukses, maar dit het nie eers op die staander gewerk nie - die dopkode was te lywig vir hierdie kwesbaarheid.
In werklikheid het dit so gelyk: 3-4 pogings tot aanvalle binne 5 minute, dan wag vir 30 uur. En so aan vir drie weke in 'n ry. Ek het selfs 'n herinnering gestel om nie tyd te mors nie. Daarbenewens was daar 'n verskil in die gedrag van die toets- en produksie-omgewings: vir hierdie kwesbaarheid was daar twee soortgelyke uitbuitings, een van Metasploit, die tweede van die internet, omgeskakel vanaf die Shadow Brokers-weergawe. So, net Metasploit is in 'n geveg getoets, en slegs die tweede een is op die bank getoets, wat ontfouting nog moeiliker gemaak het en breinbrekend was.
Op die ou end het 'n dopkode wat 'n exe-lêer vanaf 'n gegewe bediener via http afgelaai en dit op die teikenstelsel bekendgestel het, effektief bewys. Die dopkode was klein genoeg om te pas, maar dit het ten minste gewerk. Aangesien die bediener glad nie van TCP-verkeer gehou het nie en http(s) vir die teenwoordigheid van meterpreter geïnspekteer is, het ek besluit dat die vinnigste manier was om 'n exe-lêer af te laai wat DNS-meterpreter bevat deur hierdie dopkode.
Hier het weer 'n probleem ontstaan: wanneer 'n exe-lêer afgelaai is en, soos pogings getoon het, maak nie saak watter een nie, die aflaai is onderbreek. Weereens, een of ander sekuriteitstoestel tussen my bediener en die uroloog het nie van http-verkeer met 'n exe binne gehou nie. Die "vinnige" oplossing was blykbaar om die dopkode te verander sodat dit http-verkeer dadelik sou verduister, sodat abstrakte binêre data in plaas van exe oorgedra sou word. Uiteindelik was die aanval suksesvol, beheer is deur die dun DNS-kanaal ontvang:
Dit het dadelik duidelik geword dat ek die mees basiese IIS-werkvloeiregte het, wat my toelaat om niks te doen nie. Dit is hoe dit gelyk het op die Metasploit-konsole:
Alle beste metodologieë stel sterk voor dat u regte moet verhoog wanneer u toegang verkry. Ek doen dit gewoonlik nie plaaslik nie, aangesien die heel eerste toegang bloot as 'n netwerktoegangspunt gesien word, en om 'n ander masjien op dieselfde netwerk te kompromitteer is gewoonlik makliker en vinniger as om voorregte op 'n bestaande gasheer te eskaleer. Maar dit is nie hier die geval nie, aangesien die DNS-kanaal baie smal is en dit nie sal toelaat dat verkeer opklaar nie.
As ons aanvaar dat hierdie Windows 2003-bediener nie vir die bekende MS17-010-kwesbaarheid herstel is nie, tonnel ek verkeer na poort 445/TCP deur die meterpreter DNS-tonnel op localhost (ja, dit is ook moontlik) en probeer om die voorheen afgelaaide exe deur te laat loop die kwesbaarheid. Die aanval werk, ek ontvang 'n tweede verbinding, maar met STELSEL regte.
Dit is interessant dat hulle steeds probeer het om die bediener teen MS17-010 te beskerm - dit het kwesbare netwerkdienste op die eksterne koppelvlak gedeaktiveer. Dit beskerm wel teen aanvalle oor die netwerk, maar die aanval van binne op localhost het gewerk, aangesien jy nie net vinnig SMB op localhost kan afskakel nie.
Vervolgens word nuwe interessante besonderhede onthul:
- As u STELSELregte het, kan u maklik 'n terugverbinding tot stand bring via TCP. Dit is duidelik dat die deaktivering van direkte TCP streng 'n probleem is vir die beperkte IIS-gebruiker. Bederf: die IIS-gebruikersverkeer was op een of ander manier in die plaaslike ISA Proxy in beide rigtings toegedraai. Hoe dit presies werk, het ek nie weergegee nie.
- Ek is in 'n sekere "DMZ" (en dit is nie 'n Active Directory-domein nie, maar 'n WERKGROEP) - dit klink logies. Maar in plaas van die verwagte private (“grys”) IP-adres, het ek 'n heeltemal "wit" IP-adres, presies dieselfde as die een wat ek vroeër aangeval het. Dit beteken dat die maatskappy so oud is in die wêreld van IPv4-adressering dat dit kan bekostig om 'n DMZ-sone vir 128 "wit" adresse sonder NAT volgens die skema te onderhou, soos uitgebeeld in Cisco-handleidings van 2005.
Aangesien die bediener oud is, is Mimikatz gewaarborg om direk uit die geheue te werk:
Ek kry die plaaslike administrateur wagwoord, tonnel RDP verkeer oor TCP en meld aan by 'n gesellige lessenaar. Aangesien ek met die bediener kon doen wat ek wil, het ek die antivirus verwyder en gevind dat die bediener slegs van die internet af toeganklik was via TCP-poorte 80 en 443, en 443 was nie besig nie. Ek stel 'n OpenVPN-bediener op 443 op, voeg NAT-funksies by vir my VPN-verkeer en kry direkte toegang tot die DMZ-netwerk in 'n onbeperkte vorm deur my OpenVPN. Dit is opmerklik dat ISA, met 'n paar nie-gedeaktiveerde IPS-funksies, my verkeer met poortskandering geblokkeer het, waarvoor dit vervang moes word met 'n eenvoudiger en meer voldoenende RRAS. So pentesters moet soms nog allerhande dinge administreer.
'n Oplettende leser sal vra: "Wat van die tweede webwerf - 'n wiki met NTLM-verifikasie, waaroor so baie geskryf is?" Meer hieroor later.
Deel 2. Enkripteer steeds nie? Dan kom ons reeds hier na jou toe
Daar is dus toegang tot die DMZ-netwerksegment. Jy moet na die domeinadministrateur gaan. Die eerste ding wat in gedagte kom, is om outomaties die sekuriteit van dienste binne die DMZ-segment na te gaan, veral aangesien baie meer daarvan nou oop is vir navorsing. 'n Tipiese prentjie tydens 'n penetrasietoets: die eksterne omtrek is beter beskerm as interne dienste, en wanneer enige toegang binne 'n groot infrastruktuur verkry word, is dit baie makliker om uitgebreide regte in 'n domein te verkry slegs as gevolg van die feit dat hierdie domein begin word toeganklik vir gereedskap, en tweedens, In 'n infrastruktuur met etlike duisende gashere, sal daar altyd 'n paar kritieke probleme wees.
Ek laai die skandeerders via DMZ via 'n OpenVPN-tonnel en wag. Ek maak die verslag oop - weereens niks ernstigs nie, iemand het blykbaar voor my deur dieselfde metode gegaan. Die volgende stap is om te ondersoek hoe gashere binne die DMZ-netwerk kommunikeer. Om dit te doen, begin eers die gewone Wireshark en luister vir uitsaaiversoeke, hoofsaaklik ARP. ARP-pakkies is die hele dag lank versamel. Dit blyk dat verskeie poorte in hierdie segment gebruik word. Dit sal later handig te pas kom. Deur data oor ARP-versoekreaksies en poortskanderingdata te kombineer, het ek die uitgangpunte van gebruikersverkeer van binne die plaaslike netwerk gevind bykomend tot die dienste wat voorheen bekend was, soos web en pos.
Aangesien ek op die oomblik geen toegang tot ander stelsels gehad het nie en nie 'n enkele rekening vir korporatiewe dienste gehad het nie, is daar besluit om ten minste 'n rekening uit die verkeer uit te haal met ARP Spoofing.
Cain&Abel is op die uroloog se bediener bekendgestel. Met inagneming van die geïdentifiseerde verkeersvloei, is die mees belowende pare vir die man-in-die-middel-aanval gekies, en daarna is 'n mate van netwerkverkeer ontvang deur korttermyn-bekendstelling vir 5-10 minute, met 'n tydhouer om die bediener te herlaai in geval van vries. Soos in die grap, was daar twee nuus:
- Goed: baie geloofsbriewe is gevang en die aanval as geheel het gewerk.
- Die slegte: alle geloofsbriewe was van die kliënt se eie kliënte. Terwyl hulle ondersteuningsdienste verskaf het, het klantespesialiste gekoppel aan die dienste van kliënte wat nie altyd verkeerskodering opgestel het nie.
Gevolglik het ek baie geloofsbriewe bekom wat nutteloos was in die konteks van die projek, maar beslis interessant was as 'n demonstrasie van die gevaar van die aanval. Grensrouters van groot maatskappye met telnet, het debug http-poorte na interne CRM gestuur met alle data, direkte toegang tot RDP vanaf Windows XP op die plaaslike netwerk en ander obskurantisme. Dit het so uitgedraai .
Ek het ook 'n snaakse geleentheid gekry om briewe van die verkeer in te samel, so iets. Dit is 'n voorbeeld van 'n klaargemaakte brief wat van ons kliënt na sy kliënt se SMTP-poort gegaan het, weer, sonder enkripsie. 'n Sekere Andrey vra sy naamgenoot om die dokumentasie weer te stuur, en dit word na 'n wolkskyf opgelaai met 'n login, wagwoord en skakel in een antwoordbrief:
Dit is nog 'n herinnering om alle dienste te enkripteer. Dit is onbekend wie en wanneer jou data spesifiek sal lees en gebruik - die verskaffer, die stelseladministrateur van 'n ander maatskappy, of so 'n pentester. Ek swyg oor die feit dat baie mense eenvoudig ongeënkripteerde verkeer kan onderskep.
Ten spyte van die oënskynlike sukses, het dit ons nie nader aan die doel gebring nie. Dit was natuurlik moontlik om lank te sit en waardevolle inligting uit te vis, maar dit is nie 'n feit dat dit daar sou verskyn nie, en die aanval self is baie riskant in terme van die integriteit van die netwerk.
Na nog 'n deurbraak in die dienste, het 'n interessante idee by my opgekom. Daar is so 'n hulpprogram genaamd Responder (dit is maklik om voorbeelde van gebruik met hierdie naam te vind), wat, deur uitsaaiversoeke te "vergiftig", verbindings uitlok via 'n verskeidenheid protokolle soos SMB, HTTP, LDAP, ens. op verskillende maniere, vra dan almal wat koppel om te verifieer en stel dit so op dat verifikasie via NTLM plaasvind en in 'n modus wat deursigtig is vir die slagoffer. Dikwels versamel 'n aanvaller NetNTLMv2-handdrukke op hierdie manier en herwin vinnig gebruikersdomeinwagwoorde met behulp van 'n woordeboek. Hier wou ek iets soortgelyks hê, maar die gebruikers het "agter 'n muur" gesit, of liewer, hulle is geskei deur 'n brandmuur, en het toegang tot die WEB verkry deur die Blue Coat-instaanbedienergroepering.
Onthou, ek het gespesifiseer dat die Active Directory-domeinnaam saamgeval het met die "eksterne" domein, dit wil sê, dit was company.ru? Dus, Windows, meer presies Internet Explorer (en Edge en Chrome), laat die gebruiker toe om deursigtig in HTTP te verifieer via NTLM as hulle dink dat die webwerf in een of ander "Intranet-sone" geleë is. Een van die tekens van 'n "Intranet" is toegang tot 'n "grys" IP-adres of 'n kort DNS-naam, dit wil sê sonder kolletjies. Aangesien hulle 'n bediener met 'n "wit" IP- en DNS-naam preobrazhensky.company.ru gehad het, en domeinmasjiene gewoonlik die Active Directory-domein-agtervoegsel via DHCP ontvang vir vereenvoudigde naaminvoer, moes hulle net die URL in die adresbalk skryf , sodat hulle die regte pad na die gekompromitteerde uroloog se bediener vind, en nie vergeet dat dit nou "Intranet" genoem word nie. Dit wil sê, gee my terselfdertyd die gebruiker se NTLM-handdruk sonder sy medewete. Al wat oorbly, is om kliëntblaaiers te dwing om na te dink oor die dringende behoefte om hierdie bediener te kontak.
Die wonderlike Intercepter-NG-nutsding het tot die redding gekom (dankie ). Dit het jou toegelaat om verkeer dadelik te verander en het uitstekend gewerk op Windows 2003. Dit het selfs aparte funksionaliteit gehad om slegs JavaScript-lêers in die verkeersvloei te wysig. 'n Soort massiewe Cross-Site Scripting is beplan.
Blue Coat-gevolmagtigdes, waardeur gebruikers toegang tot die wêreldwye WEB verkry het, het statiese inhoud periodiek gekas. Deur verkeer te onderskep, was dit duidelik dat hulle XNUMX uur per dag gewerk het en eindeloos gereeld statiese stowwe gevra het om die vertoon van inhoud tydens spitstye te bespoedig. Boonop het BlueCoat 'n spesifieke User-Agent gehad, wat dit duidelik van 'n regte gebruiker onderskei het.
Javascript is voorberei, wat, met behulp van Intercepter-NG, vir 'n uur in die nag geïmplementeer is vir elke reaksie met JS-lêers vir Blue Coat. Die draaiboek het die volgende gedoen:
- Bepaal die huidige blaaier deur User-Agent. As dit Internet Explorer, Edge of Chrome was, het dit aanhou werk.
- Ek het gewag totdat die DOM van die bladsy gevorm is.
- Het 'n onsigbare beeld in die DOM ingevoeg met 'n src-kenmerk van die vorm :8080/NNNNNNNN.png, waar NNN arbitrêre getalle is sodat BlueCoat dit nie kas nie.
- Stel 'n globale vlagveranderlike om aan te dui dat die inspuiting voltooi is en dat dit nie meer nodig is om beelde in te voeg nie.
Die blaaier het probeer om hierdie prent te laai; op poort 8080 van die gekompromitteerde bediener het 'n TCP-tonnel daarvoor gewag na my skootrekenaar, waar dieselfde Responder aan die gang was, wat vereis het dat die blaaier via NTLM moes aanmeld.
Te oordeel aan die Responder-logboeke, het mense in die oggend werk toe gekom, hul werkstasies aangeskakel, en dan massaal en ongemerk die uroloog se bediener begin besoek, sonder om te vergeet om NTLM-handdrukke te "dreineer". Handdrukke het die hele dag gereën en materiaal het duidelik opgehoop vir 'n duidelik suksesvolle aanval om wagwoorde te herwin. Dit is hoe die Responder logs gelyk het:
Massa geheime besoeke aan die uroloog-bediener deur gebruikers
Jy het waarskynlik al opgemerk dat hierdie hele storie gebou is op die beginsel "alles was reg, maar toe was daar 'n bummer, toe was daar 'n oorwinning, en toe kom alles tot sukses." So, hier was 'n bummer. Van die vyftig unieke handdrukke is nie een geopenbaar nie. En dit neem die feit in ag dat selfs op 'n skootrekenaar met 'n dooie verwerker, hierdie NTLMv2-handdrukke teen 'n spoed van 'n paar honderd miljoen pogings per sekonde verwerk word.
Ek moes myself bewapen met wagwoordmutasietegnieke, 'n videokaart, 'n dikker woordeboek en wag. Na 'n lang tyd is verskeie rekeninge met wagwoorde van die vorm "Q11111111....1111111q" onthul, wat daarop dui dat alle gebruikers een keer gedwing is om met 'n baie lang wagwoord vorendag te kom met verskillende hoofletters van karakters, wat ook veronderstel was om kompleks wees. Maar jy kan nie 'n gesoute gebruiker flous nie, en dit is hoe hy dit vir homself makliker gemaak het om te onthou. In totaal is ongeveer 5 rekeninge gekompromitteer, en slegs een van hulle het enige waardevolle regte op die dienste gehad.
Deel 3. Roskomnadzor slaan terug
Dus, die eerste domeinrekeninge is ontvang. As jy nog nie deur 'n lang lees aan die slaap geraak het nie, sal jy waarskynlik onthou dat ek 'n diens genoem het wat nie 'n tweede faktor van verifikasie vereis het nie: dit is 'n wiki met NTLM-verifikasie. Natuurlik was die eerste ding om daar in te gaan. Deur in die interne kennisbasis te delf het vinnig resultate gebring:
- Die maatskappy het 'n WiFi-netwerk met verifikasie met behulp van domeinrekeninge met toegang tot die plaaslike netwerk. Met die huidige stel data is dit reeds 'n werkende aanvalsvektor, maar jy moet met jou voete na die kantoor gaan en iewers op die grondgebied van die kliënt se kantoor geleë wees.
- Ek het 'n instruksie gevind waarvolgens daar 'n diens was wat dit toegelaat het om onafhanklik 'n "tweede faktor" stawing toestel te registreer as die gebruiker binne 'n plaaslike netwerk is en met selfvertroue sy domein login en wagwoord onthou. In hierdie geval is "binne" en "buite" bepaal deur die toeganklikheid van die hawe van hierdie diens vir die gebruiker. Die poort was nie toeganklik vanaf die internet nie, maar was redelik toeganklik deur die DMZ.
Natuurlik is 'n "tweede faktor" onmiddellik by die gekompromitteerde rekening gevoeg in die vorm van 'n toepassing op my foon. Daar was ’n program wat óf hardop ’n drukversoek na die foon kon stuur met “goedkeur”/“afkeur”-knoppies vir die aksie, óf die OTP-kode stilweg op die skerm kon wys vir verdere onafhanklike inskrywing. Boonop was die eerste metode volgens die instruksies veronderstel om die enigste korrekte een te wees, maar dit het nie gewerk nie, anders as die OTP-metode.
Met die "tweede faktor" gebreek, kon ek toegang tot Outlook Web Access-pos en afstandtoegang in Citrix Netscaler Gateway verkry. Daar was 'n verrassing in die pos in Outlook:
In hierdie seldsame skoot kan jy sien hoe Roskomnadzor pentesters help
Dit was die eerste maande ná die beroemde "aanhanger"-blokkering van Telegram, toe hele netwerke met duisende adresse onverbiddelik van toegang verdwyn het. Dit het duidelik geword hoekom die druk nie dadelik gewerk het nie en hoekom my "slagoffer" nie alarm gemaak het nie omdat hulle haar rekening tydens oop ure begin gebruik het.
Enigiemand wat vertroud is met Citrix Netscaler stel voor dat dit gewoonlik op so 'n manier geïmplementeer word dat slegs 'n prentjie-koppelvlak aan die gebruiker oorgedra kan word, en probeer om hom nie die gereedskap te gee om derdeparty-toepassings te begin en data oor te dra nie, wat aksies op elke moontlike manier beperk. deur standaard beheer doppe. My “slagoffer”, as gevolg van sy beroep, het net 1C gekry:
Nadat ek 'n bietjie rond die 1C-koppelvlak geloop het, het ek gevind dat daar eksterne verwerkingsmodules daar is. Hulle kan vanaf die koppelvlak gelaai word, en hulle sal op die kliënt of bediener uitgevoer word, afhangende van die regte en instellings.
Ek het my 1C programmeerder vriende gevra om 'n verwerking te skep wat 'n string sal aanvaar en dit sal uitvoer. In 1C-taal lyk die begin van 'n proses so (van die internet geneem). Stem jy saam dat die sintaksis van die 1C-taal Russiessprekende mense verstom met sy spontaniteit?
Die verwerking is perfek uitgevoer; dit het geblyk te wees wat pentesters 'n "dop" noem - Internet Explorer is daardeur bekendgestel.
Vroeër is die adres van 'n stelsel wat u toelaat om passe na die gebied te bestel, in die pos gevind. Ek het 'n pas bestel ingeval ek 'n WiFi-aanvalsvektor moet gebruik.
Daar word op die internet gepraat dat daar nog heerlike gratis spyseniering by die kliënt se kantoor was, maar ek het steeds verkies om die aanval op afstand te ontwikkel, dis rustiger.
AppLocker is geaktiveer op die toepassingsbediener wat Citrix gebruik, maar dit is omseil. Dieselfde Meterpreter is gelaai en geloods via DNS, aangesien die http(s) weergawes nie wou koppel nie, en ek het nie die interne proxy-adres op daardie stadium geken nie. Terloops, van hierdie oomblik af het die eksterne pentest in wese heeltemal in 'n interne een verander.
Deel 4. Admin regte vir gebruikers is sleg, reg?
Die eerste taak van 'n pentester wanneer beheer oor 'n domeingebruikersessie verkry word, is om alle inligting oor regte in die domein in te samel. Daar is 'n BloodHound-hulpmiddel waarmee u outomaties inligting oor gebruikers, rekenaars, sekuriteitsgroepe via die LDAP-protokol vanaf 'n domeinbeheerder kan aflaai, en via SMB - inligting oor watter gebruiker onlangs waar aangemeld het en wie die plaaslike administrateur is.
'n Tipiese tegniek vir die beslaglegging op domeinadministrateurregte lyk vereenvoudig as 'n siklus van eentonige aksies:
- Ons gaan na domeinrekenaars waar daar plaaslike administrateurregte is, gebaseer op reeds vasgelê domeinrekeninge.
- Ons begin Mimikatz en kry kaswagwoorde, Kerberos-kaartjies en NTLM-hashes van domeinrekeninge wat onlangs by hierdie stelsel aangemeld het. Of ons verwyder die geheuebeeld van die lsass.exe-proses en doen dieselfde aan ons kant. Dit werk goed met Windows jonger as 2012R2/Windows 8.1 met verstekinstellings.
- Ons bepaal waar die gekompromitteerde rekeninge plaaslike administrateurregte het. Ons herhaal die eerste punt. Op 'n stadium kry ons administrateur regte vir die hele domein.
"Einde van die siklus;", soos 1C-programmeerders hier sou skryf.
So, ons gebruiker het geblyk 'n plaaslike administrateur te wees op net een gasheer met Windows 7, waarvan die naam die woord "VDI", of "Virtual Desktop Infrastructure", persoonlike virtuele masjiene, ingesluit het. Waarskynlik het die ontwerper van die VDI-diens bedoel dat aangesien VDI die gebruiker se persoonlike bedryfstelsel is, selfs al verander die gebruiker die sagteware-omgewing soos hy wil, die gasheer steeds "herlaai" kan word. Ek het ook gedink dat die idee oor die algemeen goed was, ek het na hierdie persoonlike VDI-gasheer gegaan en daar 'n nes gemaak:
- Ek het 'n OpenVPN-kliënt daar geïnstalleer, wat 'n tonnel deur die internet na my bediener gemaak het. Die kliënt moes gedwing word om deur dieselfde Blue Coat met domein-verifikasie te gaan, maar OpenVPN het dit, soos hulle sê, “buite die boks” gedoen.
- OpenSSH op VDI geïnstalleer. Wel, regtig, wat is Windows 7 sonder SSH?
Dit is hoe dit regstreeks gelyk het. Laat ek jou daaraan herinner dat dit alles deur Citrix en 1C gedoen moet word:
Een tegniek om toegang tot naburige rekenaars te bevorder, is om plaaslike administrateurwagwoorde na te gaan vir 'n pasmaat. Hier het geluk dadelik gewag: die NTLM-hash van die verstek plaaslike administrateur (wat skielik Administrateur genoem is) is deur 'n pass-the-hash-aanval na naburige VDI-gashere genader, waarvan daar 'n paar honderd was. Natuurlik het die aanval hulle dadelik getref.
Dit is waar VDI-administrateurs hulself twee keer in die voet geskiet het:
- Die eerste keer was toe VDI-masjiene nie onder LAPS gebring is nie, wat in wese dieselfde plaaslike administrateurwagwoord behou het van die prent wat grootliks na VDI ontplooi is.
- Die verstekadministrateur is die enigste plaaslike rekening wat kwesbaar is vir pass-the-hash-aanvalle. Selfs met dieselfde wagwoord sou dit moontlik wees om massa-kompromie te vermy deur 'n tweede plaaslike administrateurrekening met 'n komplekse ewekansige wagwoord te skep en die verstek een te blokkeer.
Hoekom is daar 'n SSH-diens op daardie Windows? Baie eenvoudig: nou het die OpenSSH-bediener nie net 'n gerieflike interaktiewe opdragdop verskaf sonder om met die gebruiker se werk in te meng nie, maar ook 'n socks5-instaanbediener op VDI. Deur hierdie sokkies het ek via SMB gekoppel en rekeninge in die kas van al hierdie honderde VDI-masjiene versamel, en toe die pad na die domeinadministrateur gesoek wat hulle in die BloodHound-grafieke gebruik. Met honderde gashere tot my beskikking, het ek hierdie manier redelik vinnig gevind. Domein administrateur regte is verkry.
Hier is 'n foto van die internet wat 'n soortgelyke soektog wys. Verbindings wys wie is waar die administrateur is en wie waar aangemeld is.
Terloops, onthou die toestand vanaf die begin van die projek - "moenie sosiale ingenieurswese gebruik nie." So, ek stel voor om te dink oor hoeveel al hierdie Bollywood met spesiale effekte afgesny sou word as dit steeds moontlik was om banale uitvissing te gebruik. Maar persoonlik was dit vir my baie interessant om dit alles te doen. Ek hoop jy het dit geniet om hierdie te lees. Natuurlik lyk nie elke projek so intrigerend nie, maar die werk as geheel is baie uitdagend en laat dit nie stagneer nie.
Waarskynlik sal iemand 'n vraag hê: hoe om jouself te beskerm? Selfs hierdie artikel beskryf baie tegnieke, waarvan baie Windows-administrateurs nie eers weet nie. Ek stel egter voor om daarna te kyk vanuit die perspektief van afgesaagde beginsels en inligtingsekuriteitsmaatreëls:
- moenie verouderde sagteware gebruik nie (onthou u Windows 2003 aan die begin?)
- moenie onnodige stelsels aangeskakel hou nie (hoekom was daar 'n uroloog se webwerf?)
- kontroleer self gebruikerswagwoorde vir krag (anders sal soldate ... pentesters dit doen)
- nie dieselfde wagwoorde vir verskillende rekeninge hê nie (VDI-kompromie)
- en ander
Dit is natuurlik baie moeilik om te implementeer, maar in die volgende artikel sal ons in die praktyk wys dat dit heel moontlik is.
Bron: will.com