Once upon a pentest, eller Sådan brydes alt med hjælp fra en urolog og Roskomnadzor

Denne artikel er skrevet på baggrund af en meget vellykket pentest, som Group-IB-specialister gennemførte for et par år siden: der skete en historie, der kunne tilpasses til film i Bollywood. Nu vil læserens reaktion sandsynligvis følge: "Åh, endnu en PR-artikel, igen bliver disse portrætteret, hvor er de gode, glem ikke at købe en pentest." Nå, på den ene side er det det. Der er dog en række andre grunde til, at denne artikel dukkede op. Jeg ville vise, hvad pentestere præcis gør, hvor interessant og ikke-trivielt dette arbejde kan være, hvilke sjove omstændigheder der kan opstå i projekter, og vigtigst af alt, vise levende materiale med rigtige eksempler.

For at genoprette balancen mellem beskedenhed i verden, vil vi efter et stykke tid skrive om en pentest, der ikke gik godt. Vi vil vise, hvordan veldesignede processer i en virksomhed kan beskytte mod en lang række angreb, også velforberedte, blot fordi disse processer eksisterer og faktisk fungerer.

For kunden i denne artikel var alt også generelt fremragende, i det mindste bedre end 95% af markedet i Den Russiske Føderation, ifølge vores følelser, men der var en række små nuancer, der dannede en lang kæde af begivenheder, som først førte til en lang rapport om arbejdet og derefter til denne artikel.

Så lad os fylde op med popcorn, og velkommen til detektivhistorien. Ord - Pavel Suprunyuk, teknisk leder af "Revision og Rådgivning"-afdelingen i Group-IB.

Del 1. Pochkin læge

2018 Der er en kunde - en højteknologisk IT-virksomhed, som selv betjener mange kunder. Ønsker at få svar på spørgsmålet: er det muligt, uden indledende viden og adgang, at arbejde via internettet at opnå Active Directory-domæneadministratorrettigheder? Jeg er ikke interesseret i nogen social engineering (åh, men forgæves), har de ikke til hensigt at blande sig i arbejdet med vilje, men de kan ved et uheld - genindlæse en underligt fungerende server, for eksempel. Et yderligere mål er at identificere så mange andre angrebsvektorer som muligt mod den ydre omkreds. Virksomheden gennemfører løbende sådanne tests, og nu er deadline for en ny test kommet. Betingelserne er næsten typiske, tilstrækkelige, forståelige. Lad os komme igang.

Der er et navn på kunden - lad det være "Virksomhed", med hovedhjemmesiden www.company.ru. Selvfølgelig kaldes kunden anderledes, men i denne artikel vil alt være upersonligt.
Jeg foretager netværksrekognoscering - finder ud af hvilke adresser og domæner der er registreret hos kunden, tegner et netværksdiagram, hvordan tjenester fordeles til disse adresser. Jeg får resultatet: mere end 4000 live IP-adresser. Jeg ser på domænerne i disse netværk: Heldigvis er langt de fleste netværk beregnet til kundens kunder, og vi er ikke formelt interesserede i dem. Kunden mener det samme.

Der er stadig et netværk med 256 adresser, for hvilket der allerede på nuværende tidspunkt er en forståelse af fordelingen af ​​domæner og underdomæner efter IP-adresser, der er information om de scannede porte, hvilket betyder, at du kan se på tjenesterne for interessante. Sideløbende lanceres alle slags scannere på tilgængelige IP-adresser og separat på hjemmesider.

Der er mange tjenester. Normalt er dette glæde for pentesteren og forventningen om en hurtig sejr, da jo flere tjenester der er, jo større er angrebsfeltet, og jo lettere er det at finde en artefakt. Et hurtigt kig på hjemmesiderne viste, at de fleste af dem er webgrænseflader til velkendte produkter fra store globale virksomheder, som efter alt at dømme fortæller dig, at de ikke er velkomne. De beder om et brugernavn og en adgangskode, ryster feltet ud for at indtaste den anden faktor, beder om et TLS-klientcertifikat eller sender det til Microsoft ADFS. Nogle er simpelthen utilgængelige fra internettet. For nogle skal du naturligvis have en særlig betalt kunde til tre lønninger eller kende den nøjagtige URL for at indtaste. Lad os springe endnu en uge med gradvis modløshed over i processen med at forsøge at "bryde igennem" softwareversioner for kendte sårbarheder, søge efter skjult indhold i webstier og lækkede konti fra tredjepartstjenester som LinkedIn, og forsøge at gætte adgangskoder ved hjælp af dem. som udgravning af sårbarheder i selvskrevne websteder - i øvrigt, ifølge statistikker, er dette den mest lovende vektor for eksternt angreb i dag. Jeg vil straks bemærke filmpistolen, der efterfølgende affyrede.

Så vi fandt to websteder, der skilte sig ud fra hundredvis af tjenester. Disse websteder havde én ting til fælles: Hvis du ikke deltager i omhyggelig netværksrekognoscering efter domæne, men ser direkte efter åbne porte eller målretter mod en sårbarhedsscanner ved hjælp af et kendt IP-område, så vil disse websteder undslippe scanning og vil simpelthen ikke blive synlig uden at kende DNS-navnet. Måske blev de savnet tidligere, i det mindste, og vores automatiske værktøjer fandt ingen problemer med dem, selvom de blev sendt direkte til ressourcen.

Af den måde, om hvad tidligere lancerede scannere fandt generelt. Lad mig minde dig om: for nogle mennesker svarer "pentest" til "automatiseret scanning". Men scannerne på dette projekt sagde intet. Nå, maksimum blev vist af medium sårbarheder (3 ud af 5 med hensyn til sværhedsgrad): på nogle tjenester et dårligt TLS-certifikat eller forældede krypteringsalgoritmer, og på de fleste websteder Clickjacking. Men dette vil ikke få dig til dit mål. Måske ville scannere være mere nyttige her, men lad mig minde dig om: kunden selv er i stand til at købe sådanne programmer og teste sig selv med dem, og at dømme efter de dystre resultater har han allerede tjekket.

Lad os vende tilbage til de "unormale" steder. Den første er noget som en lokal Wiki på en ikke-standard adresse, men lad det i denne artikel være wiki.company[.]ru. Hun bad også straks om login og adgangskode, men gennem NTLM i browseren. For brugeren ligner dette et asketisk vindue, der beder om at indtaste et brugernavn og en adgangskode. Og det er dårlig praksis.

En lille note. NTLM i perimeter-websteder er dårligt af en række årsager. Den første grund er, at Active Directory-domænenavnet afsløres. I vores eksempel viste det sig også at være company.ru, ligesom det "eksterne" DNS-navn. Når du ved dette, kan du omhyggeligt forberede noget ondsindet, så det kun udføres på organisationens domænemaskine og ikke i en sandkasse. For det andet går autentificeringen direkte gennem domænecontrolleren via NTLM (overraskelse, ikke?), med alle funktionerne i de "interne" netværkspolitikker, herunder blokering af konti fra at overskride antallet af adgangskodeforsøg. Hvis en angriber finder ud af logins, vil han søge efter adgangskoder til dem. Hvis du er konfigureret til at blokere konti fra at indtaste forkerte adgangskoder, vil det virke, og kontoen vil blive blokeret. For det tredje er det umuligt at tilføje en anden faktor til en sådan autentificering. Hvis nogen af ​​læserne stadig ved hvordan, så lad mig det vide, det er virkelig interessant. For det fjerde sårbarhed over for pass-the-hash-angreb. ADFS blev blandt andet opfundet for at beskytte mod alt dette.

Der er én dårlig egenskab ved Microsoft-produkter: Selv hvis du ikke specifikt har udgivet en sådan NTLM, vil den i det mindste blive installeret som standard i OWA og Lync.

Forresten blokerede forfatteren af ​​denne artikel engang ved et uheld ca. 1000 konti hos ansatte i en stor bank på bare en time ved hjælp af samme metode og så derefter noget bleg ud. Bankens IT-services var også blege, men alt endte godt og tilfredsstillende, vi fik endda ros for at være de første til at finde dette problem og fremprovokere en hurtig og afgørende løsning.

Det andet websted havde adressen "naturligvis en slags efternavn.company.ru." Fandt det gennem Google, noget som dette på side 10. Designet var fra begyndelsen af ​​midten af ​​XNUMX'erne, og en respektabel person kiggede på det fra hovedsiden, noget som dette:

Her tog jeg et stillbillede fra “Heart of a Dog”, men tro mig, det var vagt ens, selv farvedesignet var i lignende toner. Lad siden hedde preobrazhensky.company.ru.

Det var en personlig hjemmeside... for en urolog. Jeg spekulerede på, hvad en urologs hjemmeside lavede på underdomænet af en højteknologisk virksomhed. En hurtig undersøgelse på Google viste, at denne læge var medstifter af en af ​​vores kundes juridiske enheder og endda bidrog med omkring 1000 rubler i den autoriserede kapital. Siden blev formentlig oprettet for mange år siden, og kundens serverressourcer blev brugt som hosting. Siden har længe mistet sin relevans, men af ​​en eller anden grund blev den efterladt at fungere i lang tid.

Med hensyn til sårbarheder var selve hjemmesiden sikker. Ser jeg fremad, vil jeg sige, at det var et sæt statisk information - simple html-sider med indsatte illustrationer i form af nyrer og blærer. Det er nytteløst at "bryde" et sådant websted.

Men webserveren nedenunder var mere interessant. At dømme efter HTTP Server-headeren havde den IIS 6.0, hvilket betyder, at den brugte Windows 2003 som operativsystem. Scanneren havde tidligere identificeret, at denne særlige urolog-websted, i modsætning til andre virtuelle værter på den samme webserver, reagerede på PROPFIND-kommandoen, hvilket betyder, at den kørte WebDAV. Forresten returnerede scanneren disse oplysninger med mærket Info (på sproget for scannerrapporter er dette den laveste fare) - sådanne ting springes normalt blot over. I kombination gav dette en interessant effekt, som først blev afsløret efter endnu en udgravning på Google: en sjælden bufferoverløbssårbarhed forbundet med Shadow Brokers-sættet, nemlig CVE-2017-7269, som allerede havde en klar udnyttelse. Med andre ord vil der være problemer, hvis du har Windows 2003 og WebDAV kører på IIS. Selvom det er et problem i sig selv at køre Windows 2003 i produktion i 2018.

Udnyttelsen endte i Metasploit og blev straks testet med en belastning, der sendte en DNS-anmodning til en kontrolleret tjeneste - Burp Collaborator bruges traditionelt til at fange DNS-anmodninger. Til min overraskelse virkede det første gang: en DNS-knockout blev modtaget. Dernæst var der et forsøg på at oprette en backconnect via port 80 (det vil sige en netværksforbindelse fra serveren til angriberen, med adgang til cmd.exe på offerværten), men så skete der en fiasko. Forbindelsen kom ikke igennem, og efter det tredje forsøg på at bruge siden forsvandt sammen med alle de interessante billeder for altid.

Normalt efterfølges dette af et brev i stil med "kunde, vågn op, vi droppede alt." Men vi fik at vide, at siden ikke har noget med forretningsprocesser at gøre og fungerer der uden grund, ligesom hele serveren, og at vi kan bruge denne ressource, som vi vil.
Omkring et døgn senere begyndte siden pludselig at fungere af sig selv. Efter at have bygget en bænk fra WebDAV på IIS 6.0 fandt jeg ud af, at standardindstillingen er at genstarte IIS-arbejderprocesser hver 30. time. Det vil sige, at når kontrollen forlod shellkoden, sluttede IIS-arbejderprocessen, derefter genstartede den sig selv et par gange og gik derefter i hvile i 30 timer.

Da tilbageforbindelsen til tcp mislykkedes første gang, tilskrev jeg dette problem til en lukket port. Det vil sige, at han antog tilstedeværelsen af ​​en form for firewall, der ikke tillod udgående forbindelser at passere udenfor. Jeg begyndte at køre shellcodes, der søgte gennem mange tcp- og udp-porte, der var ingen effekt. Omvendt forbindelsesindlæsninger via http(s) fra Metasploit virkede ikke - meterpreter/reverse_http(s). Pludselig blev en forbindelse til den samme port 80 etableret, men faldt straks. Jeg tilskrev dette til handlingen af ​​den stadig imaginære IPS, som ikke kunne lide målerens trafik. I lyset af, at en ren tcp-forbindelse til port 80 ikke gik igennem, men det gjorde en http-forbindelse, konkluderede jeg, at en http-proxy på en eller anden måde var konfigureret i systemet.

Jeg prøvede endda meterpreter via DNS (tak d00kie for din indsats, reddede mange projekter), minde om den allerførste succes, men den virkede ikke engang på standen - shell-koden var for omfangsrig til denne sårbarhed.

I virkeligheden så det sådan ud: 3-4 forsøg på angreb inden for 5 minutter, derefter vente i 30 timer. Og så videre i tre uger i træk. Jeg har endda sat en påmindelse for ikke at spilde tid. Derudover var der en forskel i opførselen af ​​test- og produktionsmiljøerne: for denne sårbarhed var der to lignende udnyttelser, den ene fra Metasploit, den anden fra internettet, konverteret fra Shadow Brokers-versionen. Så det var kun Metasploit, der blev testet i kamp, ​​og kun den anden blev testet på bænken, hvilket gjorde fejlfinding endnu mere vanskeligt og var hjernebristende.

I sidste ende viste en shellcode, der downloadede en exe-fil fra en given server via http og lancerede den på målsystemet, at være effektiv. Shellkoden var lille nok til at passe, men den virkede i det mindste. Da serveren slet ikke kunne lide TCP-trafik og http(s) blev inspiceret for tilstedeværelsen af ​​meterpreter, besluttede jeg, at den hurtigste måde var at downloade en exe-fil, der indeholdt DNS-meterpreter gennem denne shellcode.

Her opstod der igen et problem: ved download af en exe-fil, og som forsøg viste, uanset hvilken, blev downloadingen afbrudt. Igen kunne en eller anden sikkerhedsanordning mellem min server og urologen ikke lide http-trafik med en exe indeni. Den "hurtige" løsning så ud til at være at ændre shell-koden, så den ville sløre http-trafik i farten, så abstrakte binære data ville blive overført i stedet for exe. Til sidst lykkedes angrebet, kontrol blev modtaget gennem den tynde DNS-kanal:

Det blev med det samme klart, at jeg har de mest basale IIS workflow-rettigheder, som tillader mig ikke at gøre noget. Sådan så det ud på Metasploit-konsollen:

Alle gennemtestede metoder tyder kraftigt på, at du skal øge rettighederne, når du får adgang. Jeg gør normalt ikke dette lokalt, da den allerførste adgang blot ses som et netværksadgangspunkt, og at kompromittere en anden maskine på samme netværk er normalt nemmere og hurtigere end at eskalere privilegier på en eksisterende vært. Men dette er ikke tilfældet her, da DNS-kanalen er meget smal, og den vil ikke tillade trafik at rydde op.

Forudsat at denne Windows 2003-server ikke er blevet repareret for den berømte MS17-010 sårbarhed, tunnelerer jeg trafik til port 445/TCP gennem meterpreter DNS-tunnelen på localhost (ja, det er også muligt) og forsøger at køre den tidligere downloadede exe gennem sårbarheden. Angrebet virker, jeg modtager en anden forbindelse, men med SYSTEM-rettigheder.

Det er interessant, at de stadig forsøgte at beskytte serveren mod MS17-010 - den havde sårbare netværkstjenester deaktiveret på den eksterne grænseflade. Dette beskytter mod angreb over netværket, men angrebet indefra på localhost virkede, da du ikke bare hurtigt kan slå SMB fra på localhost.

Dernæst afsløres nye interessante detaljer:

1. Med SYSTEM-rettigheder kan du nemt etablere en tilbageforbindelse via TCP. Det er klart, at deaktivering af direkte TCP er strengt taget et problem for den begrænsede IIS-bruger. Spoiler: IIS-brugertrafikken var på en eller anden måde pakket ind i den lokale ISA-proxy i begge retninger. Hvordan det helt præcist fungerer, har jeg ikke gengivet.
2. Jeg er i en bestemt "DMZ" (og dette er ikke et Active Directory-domæne, men en WORKGROUP) - det lyder logisk. Men i stedet for den forventede private (“grå”) IP-adresse, har jeg en fuldstændig “hvid” IP-adresse, nøjagtig den samme som den jeg angreb tidligere. Det betyder, at virksomheden er så gammel i verden af ​​IPv4-adressering, at den har råd til at opretholde en DMZ-zone til 128 "hvide" adresser uden NAT ifølge skemaet, som afbildet i Cisco-manualer fra 2005.

Da serveren er gammel, er Mimikatz garanteret at arbejde direkte fra hukommelsen:

Jeg får den lokale administratoradgangskode, tunnelerer RDP-trafik over TCP og logger ind på et hyggeligt skrivebord. Da jeg kunne gøre, hvad jeg ville med serveren, fjernede jeg antivirusprogrammet og fandt ud af, at serveren kun var tilgængelig fra internettet via TCP-porte 80 og 443, og 443 var ikke optaget. Jeg sætter en OpenVPN-server op på 443, tilføjer NAT-funktioner til min VPN-trafik og får direkte adgang til DMZ-netværket i en ubegrænset form gennem mit OpenVPN. Det er bemærkelsesværdigt, at ISA, der havde nogle ikke-deaktiverede IPS-funktioner, blokerede min trafik med portscanning, hvortil den skulle erstattes med en enklere og mere kompatibel RRAS. Så pentestere skal nogle gange stadig administrere alle mulige ting.

En opmærksom læser vil spørge: "Hvad med det andet websted - en wiki med NTLM-godkendelse, som der er skrevet så meget om?" Mere om dette senere.

Del 2. Krypterer du stadig ikke? Så kommer vi allerede til dig her

Så der er adgang til DMZ-netværkssegmentet. Du skal gå til domæneadministratoren. Det første, der kommer til at tænke på, er automatisk at tjekke sikkerheden af ​​tjenester inden for DMZ-segmentet, især da mange flere af dem nu er åbne for forskning. Et typisk billede under en penetrationstest: den ydre perimeter er bedre beskyttet end interne tjenester, og når man får adgang inde i en stor infrastruktur, er det meget nemmere at opnå udvidede rettigheder i et domæne, kun på grund af det faktum, at dette domæne begynder at være tilgængelige for værktøjer, og for det andet, I en infrastruktur med flere tusinde værter vil der altid være et par kritiske problemer.

Jeg oplader scannerne via DMZ via en OpenVPN-tunnel og venter. Jeg åbner rapporten - igen intet alvorligt, tilsyneladende var der nogen, der har gennemgået samme metode før mig. Det næste trin er at undersøge, hvordan værter inden for DMZ-netværket kommunikerer. For at gøre dette skal du først starte den sædvanlige Wireshark og lytte efter udsendelsesanmodninger, primært ARP. ARP-pakker blev samlet hele dagen lang. Det viser sig, at der bruges flere gateways i dette segment. Dette vil komme til nytte senere. Ved at kombinere data om ARP-anmodninger og -svar og portscanningsdata fandt jeg udgangspunkterne for brugertrafik inde fra det lokale netværk ud over de tjenester, der tidligere var kendt, såsom web og mail.

Da jeg i øjeblikket ikke havde adgang til andre systemer og ikke havde en enkelt konto til virksomhedstjenester, blev det besluttet at fiske i det mindste en konto fra trafikken ved hjælp af ARP Spoofing.

Cain&Abel blev lanceret på urologens server. Under hensyntagen til de identificerede trafikstrømme blev de mest lovende par til man-in-the-middle-angrebet valgt, og derefter blev noget netværkstrafik modtaget ved kortvarig lancering i 5-10 minutter med en timer til at genstarte serveren i tilfælde af frysning. Som i joken var der to nyheder:

1. Godt: mange akkreditiver blev fanget, og angrebet fungerede som helhed.
2. Det dårlige: alle legitimationsoplysninger var fra kundens egne kunder. Mens de leverede supporttjenester, koblede kundespecialister sig til tjenester fra klienter, som ikke altid havde konfigureret trafikkryptering.

Som et resultat fik jeg en masse legitimationsoplysninger, der var ubrugelige i forbindelse med projektet, men absolut interessante som en demonstration af faren ved angrebet. Grænseroutere for store virksomheder med telnet, videresendte debug http-porte til intern CRM med alle data, direkte adgang til RDP fra Windows XP på det lokale netværk og anden obskurantisme. Det blev sådan her Supply Chain Kompromis i henhold til MITER-matricen.

Jeg fandt også en sjov mulighed for at samle breve fra trafikken, sådan noget som dette. Dette er et eksempel på et færdiglavet brev, der gik fra vores kunde til hans klients SMTP-port, igen uden kryptering. En vis Andrey beder sin navnebror om at sende dokumentationen igen, og den uploades til en skydisk med login, adgangskode og link i ét svarbrev:

Dette er endnu en påmindelse om at kryptere alle tjenester. Det er uvist, hvem og hvornår der vil læse og bruge dine data specifikt - udbyderen, systemadministratoren for en anden virksomhed eller sådan en pentester. Jeg er tavs om, at mange mennesker simpelthen kan opsnappe ukrypteret trafik.

På trods af den tilsyneladende succes, bragte dette os ikke tættere på målet. Det var selvfølgelig muligt at sidde længe og fiske værdifuld information frem, men det er ikke et faktum, at det ville dukke op der, og selve angrebet er meget risikabelt i forhold til netværkets integritet.

Efter endnu et gravearbejde i tjenesterne dukkede en interessant idé op. Der er sådan et værktøj kaldet Responder (det er nemt at finde eksempler på brug af dette navn), som ved at "forgifte" udsendelsesanmodninger fremkalder forbindelser via en række forskellige protokoller såsom SMB, HTTP, LDAP osv. på forskellige måder, beder derefter alle, der opretter forbindelse, om at godkende og sætter det op, så autentificeringen foregår via NTLM og i en tilstand, der er transparent for offeret. Oftest indsamler en angriber NetNTLMv2-håndtryk på denne måde og fra dem, ved hjælp af en ordbog, gendannes brugerens domæneadgangskoder hurtigt. Her ville jeg have noget lignende, men brugerne sad "bag en væg", eller rettere sagt, de var adskilt af en firewall og fik adgang til WEB'et gennem Blue Coat proxy-klyngen.

Husk, jeg specificerede, at Active Directory-domænenavnet faldt sammen med det "eksterne" domæne, det vil sige, det var company.ru? Så Windows, mere præcist Internet Explorer (og Edge og Chrome), giver brugeren mulighed for gennemsigtigt at autentificere i HTTP via NTLM, hvis de mener, at webstedet er placeret i en "Intranet-zone". Et af tegnene på et "Intranet" er adgang til en "grå" IP-adresse eller et kort DNS-navn, det vil sige uden prikker. Da de havde en server med et "hvidt" IP- og DNS-navn preobrazhensky.company.ru, og domænemaskiner normalt modtager Active Directory-domæne-suffikset via DHCP for forenklet navneindtastning, skulle de kun skrive URL'en i adresselinjen preobrazhensky, så de finder den rigtige vej til den kompromitterede urologs server, ikke at glemme, at dette nu hedder "Intranet". Det vil sige, at jeg samtidig giver mig brugerens NTLM-håndtryk uden hans viden. Det eneste, der er tilbage, er at tvinge klientbrowsere til at tænke på det presserende behov for at kontakte denne server.

Det vidunderlige Intercepter-NG-værktøj kom til undsætning (tak Interceptor). Det gav dig mulighed for at ændre trafik på farten og fungerede godt på Windows 2003. Det havde endda separat funktionalitet til kun at ændre JavaScript-filer i trafikstrømmen. En slags massiv Cross-Site Scripting var planlagt.

Blue Coat proxyer, hvorigennem brugere fik adgang til det globale WEB, cachelagrede periodisk statisk indhold. Ved at opsnappe trafik var det tydeligt, at de arbejdede døgnet rundt og i det uendelige anmodede om hyppigt brugt statisk for at fremskynde visningen af ​​indhold i myldretiden. Derudover havde BlueCoat en specifik User-Agent, som tydeligt adskilte den fra en rigtig bruger.

Der blev udarbejdet Javascript, som ved hjælp af Intercepter-NG blev implementeret i en time om natten for hvert svar med JS-filer til Blue Coat. Scriptet gjorde følgende:

• Bestemt den aktuelle browser af User-Agent. Hvis det var Internet Explorer, Edge eller Chrome, fortsatte det med at fungere.
• Jeg ventede, indtil sidens DOM blev dannet.
• Indsatte et usynligt billede i DOM med en src-attribut for formularen preobrazhensky:8080/NNNNNNNN.png, hvor NNN er vilkårlige tal, så BlueCoat ikke cacher det.
• Indstil en global flagvariabel for at indikere, at injektionen var fuldført, og der ikke længere er behov for at indsætte billeder.

Browseren forsøgte at indlæse dette billede; på port 8080 på den kompromitterede server ventede en TCP-tunnel på det til min bærbare computer, hvor den samme Responder kørte, hvilket krævede, at browseren loggede på via NTLM.

At dømme ud fra Responder-loggene kom folk på arbejde om morgenen, tændte deres arbejdsstationer, og begyndte derefter massevis og ubemærket at besøge urologens server, uden at glemme at "tømme" NTLM-håndtryk. Håndtryk regnede ned hele dagen og klart akkumuleret materiale til et åbenlyst vellykket angreb for at gendanne adgangskoder. Sådan så Responder-loggene ud:

Hemmelige massebesøg på urologserveren af ​​brugere

Du har sikkert allerede bemærket, at hele denne historie er bygget på princippet "alt var i orden, men så var der en nedtur, så var der en overvindelse, og så kom alt til succes." Så her var der en nedtur. Af de halvtreds unikke håndtryk blev ikke et eneste afsløret. Og dette tager højde for det faktum, at selv på en bærbar computer med en død processor behandles disse NTLMv2-håndtryk med en hastighed på flere hundrede millioner forsøg i sekundet.

Jeg var nødt til at væbne mig med teknikker til mutation af password, et videokort, en tykkere ordbog og vente. Efter lang tid blev flere konti med adgangskoder af formen "Q11111111....1111111q", hvilket tyder på, at alle brugere engang var tvunget til at komme med et meget langt kodeord med forskellige store og små bogstaver, hvilket også skulle være kompleks. Men du kan ikke narre en erfaren bruger, og sådan gjorde han det lettere for sig selv at huske. I alt blev omkring 5 konti kompromitteret, og kun én af dem havde værdifulde rettigheder til tjenesterne.

Del 3. Roskomnadzor slår tilbage

Så de første domænekonti blev modtaget. Hvis du ikke er faldet i søvn på dette tidspunkt efter en lang læsning, vil du sikkert huske, at jeg nævnte en tjeneste, der ikke krævede en anden faktor for autentificering: det er en wiki med NTLM-godkendelse. Det første man skulle gøre var selvfølgelig at komme ind der. At grave i den interne videnbase gav hurtigt resultater:

• Virksomheden har et WiFi-netværk med autentificering ved hjælp af domænekonti med adgang til det lokale netværk. Med det nuværende sæt af data er dette allerede en fungerende angrebsvektor, men du skal gå til kontoret med dine fødder og være placeret et sted på kundens kontors territorium.
• Jeg fandt en instruktion, ifølge hvilken der var en tjeneste, der tillod... at uafhængigt registrere en "anden faktor" autentificeringsenhed, hvis brugeren er inde i et lokalt netværk og sikkert husker sit domæne login og adgangskode. I dette tilfælde blev "inde" og "udenfor" bestemt af tilgængeligheden af ​​denne tjenestes port for brugeren. Porten var ikke tilgængelig fra internettet, men var ganske tilgængelig via DMZ.

Selvfølgelig blev der straks tilføjet en "anden faktor" til den kompromitterede konto i form af en applikation på min telefon. Der var et program, der enten højlydt kunne sende en push-anmodning til telefonen med "godkend"/"afvis"-knapper for handlingen, eller lydløst vise OTP-koden på skærmen for yderligere uafhængig indtastning. Desuden skulle den første metode ifølge instruktionerne være den eneste korrekte, men den virkede ikke, i modsætning til OTP-metoden.

Med "den anden faktor" brudt, var jeg i stand til at få adgang til Outlook Web Access-mail og fjernadgang i Citrix Netscaler Gateway. Der var en overraskelse i mailen i Outlook:

I dette sjældne skud kan du se, hvordan Roskomnadzor hjælper pentestere

Det var de første måneder efter den berømte "fan"-blokering af Telegram, da hele netværk med tusindvis af adresser ubønhørligt forsvandt fra adgang. Det blev klart, hvorfor skubningen ikke virkede med det samme, og hvorfor mit "offer" ikke slog alarm, fordi de begyndte at bruge hendes konto i åbningstiden.

Enhver, der er bekendt med Citrix Netscaler, forestiller sig, at det normalt er implementeret på en sådan måde, at kun en billedgrænseflade kan formidles til brugeren, og forsøger ikke at give ham værktøjerne til at starte tredjepartsapplikationer og overføre data, hvilket på alle mulige måder begrænser handlinger gennem standard kontrolskaller. Mit "offer" fik på grund af sit erhverv kun 1C:

Efter at have gået lidt rundt på 1C-grænsefladen, fandt jeg ud af, at der er eksterne behandlingsmoduler der. De kan indlæses fra grænsefladen, og de vil blive udført på klienten eller serveren, afhængigt af rettigheder og indstillinger.

Jeg bad mine 1C-programmørvenner om at oprette en behandling, der ville acceptere en streng og udføre den. I 1C-sprog ser det sådan ud at starte en proces (taget fra internettet). Er du enig i, at syntaksen i 1C-sproget forbløffer russisktalende mennesker med dets spontanitet?

Behandlingen blev udført perfekt; det viste sig at være, hvad pentesterne kalder en "skal" - Internet Explorer blev lanceret gennem den.

Tidligere blev adressen på et system, der giver dig mulighed for at bestille kort til territoriet, fundet med posten. Jeg bestilte et pas, hvis jeg skulle bruge en WiFi-angrebsvektor.

Der tales på internettet om, at der stadig var lækker gratis forplejning på kundens kontor, men jeg foretrak alligevel at udvikle angrebet på afstand, det er mere roligt.

AppLocker blev aktiveret på applikationsserveren, der kører Citrix, men den blev omgået. Den samme Meterpreter blev indlæst og lanceret via DNS, da http(s) versionerne ikke ønskede at forbinde, og jeg kendte ikke den interne proxy-adresse på det tidspunkt. Forresten, fra dette øjeblik blev den ydre pentest i det væsentlige fuldstændig til en indre.

Del 4. Admin-rettigheder for brugere er dårlige, okay?

Den første opgave for en pentester, når han får kontrol over en domænebrugersession, er at indsamle alle oplysninger om rettigheder i domænet. Der er et BloodHound-værktøj, der automatisk giver dig mulighed for at downloade information om brugere, computere, sikkerhedsgrupper via LDAP-protokollen fra en domænecontroller, og via SMB - information om, hvilken bruger der for nylig er logget ind hvor og hvem der er den lokale administrator.

En typisk teknik til at beslaglægge domæneadministratorrettigheder ser forenklet ud som en cyklus af monotone handlinger:

• Vi går til domænecomputere, hvor der er lokale administratorrettigheder, baseret på allerede registrerede domænekonti.
• Vi lancerer Mimikatz og får cachelagrede adgangskoder, Kerberos-billetter og NTLM-hash af domænekonti, der for nylig er logget ind på dette system. Eller vi fjerner hukommelsesbilledet af lsass.exe-processen og gør det samme på vores side. Dette fungerer godt med Windows yngre end 2012R2/Windows 8.1 med standardindstillinger.
• Vi bestemmer, hvor de kompromitterede konti har lokale administratorrettigheder. Vi gentager det første punkt. På et tidspunkt opnår vi administratorrettigheder for hele domænet.

"End of the Cycle;", som 1C-programmører ville skrive her.

Så vores bruger viste sig at være en lokal administrator på kun én vært med Windows 7, hvis navn inkluderede ordet "VDI" eller "Virtual Desktop Infrastructure", personlige virtuelle maskiner. Formentlig mente designeren af ​​VDI-tjenesten, at da VDI er brugerens personlige operativsystem, kan værten stadig "genindlæses", selvom brugeren ændrer softwaremiljøet, som han vil. Jeg troede også, at ideen generelt var god, jeg gik til denne personlige VDI-vært og lavede en rede der:

• Jeg installerede en OpenVPN-klient der, som lavede en tunnel gennem internettet til min server. Klienten skulle tvinges til at gennemgå den samme Blue Coat med domænegodkendelse, men OpenVPN gjorde det, som de siger, "ud af boksen."
• Installeret OpenSSH på VDI. Nå, virkelig, hvad er Windows 7 uden SSH?

Sådan så det ud live. Lad mig minde dig om, at alt dette skal gøres gennem Citrix og 1C:

En teknik til at fremme adgang til nabocomputere er at kontrollere lokale administratoradgangskoder for en match. Her ventede heldet med det samme: NTLM-hashen for den lokale standardadministrator (som pludselig blev kaldt Administrator) blev kontaktet gennem et pass-the-hash-angreb til nabo VDI-værter, som der var flere hundrede af. Selvfølgelig ramte angrebet dem straks.

Det er her, VDI-administratorer skød sig selv i foden to gange:

• Den første gang var, da VDI-maskiner ikke blev bragt under LAPS, idet de i det væsentlige bibeholdt den samme lokale administratoradgangskode fra billedet, der var massivt distribueret til VDI.
• Standardadministratoren er den eneste lokale konto, der er sårbar over for pass-the-hash-angreb. Selv med den samme adgangskode ville det være muligt at undgå massekompromis ved at oprette en anden lokal administratorkonto med en kompleks tilfældig adgangskode og blokere standarden.

Hvorfor SSH-tjenesten på det Windows? Meget simpelt: Nu leverede OpenSSH-serveren ikke kun en praktisk interaktiv kommandoskal uden at forstyrre brugerens arbejde, men også en socks5-proxy på VDI. Gennem disse sokker oprettede jeg forbindelse via SMB og samlede cachelagrede konti fra alle disse hundredvis af VDI-maskiner, og ledte derefter efter stien til domæneadministratoren, der brugte dem i BloodHound-graferne. Med hundredvis af værter til min rådighed, fandt jeg denne måde ret hurtigt. Domæneadministratorrettigheder er opnået.

Her er et billede fra internettet, der viser en lignende søgning. Forbindelser viser, hvem der er, hvor administratoren er, og hvem der er logget ind hvor.

Husk forresten betingelsen fra starten af ​​projektet - "brug ikke social engineering." Så jeg foreslår at tænke på, hvor meget alt dette Bollywood med specielle effekter ville blive afskåret, hvis det stadig var muligt at bruge banal phishing. Men personligt var det meget interessant for mig at gøre alt dette. Jeg håber, du nød at læse dette. Selvfølgelig ser ikke alle projekter så spændende ud, men arbejdet som helhed er meget udfordrende og lader det ikke stagnere.

Sandsynligvis vil nogen have et spørgsmål: hvordan beskytter du dig selv? Selv denne artikel beskriver mange teknikker, hvoraf mange Windows-administratorer ikke engang kender til. Jeg foreslår dog at se på dem ud fra perspektivet af afslørede principper og informationssikkerhedsforanstaltninger:

• Brug ikke forældet software (husker du Windows 2003 i begyndelsen?)
• hold ikke unødvendige systemer tændt (hvorfor var der en urologs hjemmeside?)
• tjek selv brugeradgangskoder for styrke (ellers vil soldater... pentestere gøre dette)
• ikke har de samme adgangskoder til forskellige konti (VDI-kompromis)
• og andre

Det er selvfølgelig meget svært at implementere, men i den næste artikel vil vi i praksis vise, at det er ganske muligt.

Kilde: www.habr.com