Denne artikkelen ble skrevet basert på en svært vellykket test som Group-IB-spesialister gjennomførte for et par år siden: en historie skjedde som kunne tilpasses for film i Bollywood. Nå vil sannsynligvis leserens reaksjon følge: "Å, nok en PR-artikkel, igjen blir disse portrettert, hvor gode de er, ikke glem å kjøpe en pentest." Vel, på den ene siden er det det. Det er imidlertid en rekke andre grunner til at denne artikkelen dukket opp. Jeg ønsket å vise hva pentestere gjør, hvor interessant og ikke-trivielt dette arbeidet kan være, hvilke morsomme omstendigheter som kan oppstå i prosjekter, og viktigst av alt, vise levende materiale med ekte eksempler.
For å gjenopprette balansen mellom beskjedenhet i verden, vil vi etter en stund skrive om en pentest som ikke gikk bra. Vi skal vise hvordan godt utformede prosesser i en bedrift kan beskytte mot en hel rekke angrep, også godt forberedte, rett og slett fordi disse prosessene eksisterer og faktisk fungerer.
For kunden i denne artikkelen var alt også generelt utmerket, i det minste bedre enn 95% av markedet i den russiske føderasjonen, ifølge våre følelser, men det var en rekke små nyanser som dannet en lang kjede av hendelser, som først førte til en lang rapport om arbeidet , og deretter til denne artikkelen.
Så, la oss fylle på med popcorn, og velkommen til detektivhistorien. Ord - Pavel Suprunyuk, teknisk sjef for «Revisjon og rådgivning»-avdelingen i Group-IB.
Del 1. Pochkin lege
2018 Det er en kunde - et høyteknologisk IT-selskap, som selv betjener mange kunder. Ønsker å få svar på spørsmålet: er det mulig, uten noen innledende kunnskap og tilgang, å jobbe via Internett, å få Active Directory-domeneadministratorrettigheter? Jeg er ikke interessert i sosial ingeniørkunst (), de har ikke til hensikt å forstyrre arbeidet med vilje, men de kan ved et uhell - laste inn en merkelig fungerende server, for eksempel. Et ekstra mål er å identifisere så mange andre angrepsvektorer som mulig mot den ytre omkretsen. Selskapet gjennomfører jevnlig slike tester, og nå er fristen for ny test ute. Forholdene er nesten typiske, tilstrekkelige, forståelige. La oss komme i gang.
Det er et navn på kunden - la det være "Bedrift", med hovednettstedet . Selvfølgelig kalles kunden annerledes, men i denne artikkelen vil alt være upersonlig.
Jeg driver nettverksrekognosering - finner ut hvilke adresser og domener som er registrert hos kunden, tegner et nettverksdiagram, hvordan tjenester distribueres til disse adressene. Jeg får resultatet: mer enn 4000 live IP-adresser. Jeg ser på domenene i disse nettverkene: Heldigvis er de aller fleste nettverk beregnet på kundens kunder, og vi er ikke formelt interessert i dem. Kunden tenker det samme.
Det gjenstår ett nettverk med 256 adresser, som på dette tidspunktet allerede er en forståelse av fordelingen av domener og underdomener etter IP-adresser, det er informasjon om de skannede portene, noe som betyr at du kan se på tjenestene for interessante. Parallelt lanseres alle typer skannere på tilgjengelige IP-adresser og separat på nettsider.
Det er mange tjenester. Vanligvis er dette glede for pentesteren og forventningen om en rask seier, siden jo flere tjenester det er, desto større er angrepsfeltet og jo lettere er det å finne en artefakt. En rask titt på nettsidene viste at de fleste av dem er nettgrensesnitt til kjente produkter fra store globale selskaper, som etter alt å dømme forteller deg at de ikke er velkomne. De ber om brukernavn og passord, rister ut feltet for å angi den andre faktoren, ber om et TLS-klientsertifikat eller sender det til Microsoft ADFS. Noen er rett og slett utilgjengelige fra Internett. For noen må du åpenbart ha en spesiell betalt klient for tre lønner eller vite den nøyaktige URL-en du skal angi. La oss hoppe over enda en uke med gradvis motløshet i prosessen med å prøve å "bryte gjennom" programvareversjoner for kjente sårbarheter, søke etter skjult innhold i nettbaner og lekkede kontoer fra tredjepartstjenester som LinkedIn, og prøve å gjette passord ved å bruke dem, også som utgraving av sårbarheter i selvskrevne nettsteder - forresten, ifølge statistikk, er dette den mest lovende vektoren for eksternt angrep i dag. Jeg vil umiddelbart legge merke til filmpistolen som deretter avfyrte.
Så vi fant to nettsteder som skilte seg ut fra hundrevis av tjenester. Disse nettstedene hadde én ting til felles: hvis du ikke deltar i grundig nettverksrekognosering etter domene, men ser direkte etter åpne porter eller målretter mot en sårbarhetsskanner ved å bruke et kjent IP-område, vil disse nettstedene unnslippe skanning og vil rett og slett ikke bli synlig uten å vite DNS-navnet. Kanskje de ble savnet tidligere, i det minste, og våre automatiske verktøy fant ingen problemer med dem, selv om de ble sendt direkte til ressursen.
Forresten, om hva tidligere lanserte skannere fant generelt. La meg minne deg på: for noen mennesker tilsvarer "pentest" "automatisert skanning". Men skannerne på dette prosjektet sa ingenting. Vel, det maksimale ble vist ved middels sårbarheter (3 av 5 når det gjelder alvorlighetsgrad): på noen tjenester et dårlig TLS-sertifikat eller utdaterte krypteringsalgoritmer, og på de fleste nettsteder Clickjacking. Men dette vil ikke få deg til målet ditt. Kanskje ville skannere være mer nyttige her, men la meg minne deg på: kunden selv er i stand til å kjøpe slike programmer og teste seg med dem, og etter de dystre resultatene å dømme har han allerede sjekket.
La oss gå tilbake til de "anomale" nettstedene. Den første er noe som en lokal Wiki på en ikke-standard adresse, men la det i denne artikkelen være wiki.company[.]ru. Hun ba også umiddelbart om pålogging og passord, men gjennom NTLM i nettleseren. For brukeren ser dette ut som et asketisk vindu som ber om å skrive inn et brukernavn og passord. Og dette er dårlig praksis.
En liten notis. NTLM på perimeternettsteder er dårlig av flere årsaker. Den første grunnen er at Active Directory-domenenavnet blir avslørt. I vårt eksempel viste det seg også å være company.ru, akkurat som det "eksterne" DNS-navnet. Når du vet dette, kan du nøye forberede noe ondsinnet slik at det kun kjøres på organisasjonens domenemaskin, og ikke i en sandkasse. For det andre går autentisering direkte gjennom domenekontrolleren via NTLM (overraskelse, ikke sant?), med alle funksjonene til de "interne" nettverkspolicyene, inkludert blokkering av kontoer fra å overskride antall forsøk på passordinntasting. Hvis en angriper finner ut påloggingene, vil han søke etter passord for dem. Hvis du er konfigurert til å blokkere kontoer fra å skrive inn feil passord, vil det fungere og kontoen vil bli blokkert. For det tredje er det umulig å legge til en annen faktor til slik autentisering. Hvis noen av leserne fortsatt vet hvordan, vennligst gi meg beskjed, det er veldig interessant. For det fjerde, sårbarhet for pass-the-hash-angrep. ADFS ble oppfunnet blant annet for å beskytte mot alt dette.
Det er én dårlig egenskap ved Microsoft-produkter: selv om du ikke spesifikt publiserte slik NTLM, vil den bli installert som standard i OWA og Lync, i det minste.
Forresten, forfatteren av denne artikkelen blokkerte en gang ved et uhell omtrent 1000 kontoer til ansatte i en stor bank på bare én time ved å bruke samme metode og så litt blek ut. Bankens IT-tjenester var også bleke, men alt endte godt og dekkende, vi fikk til og med skryt for å være de første til å finne dette problemet og fremprovosere en rask og avgjørende løsning.
Det andre nettstedet hadde adressen "åpenbart et slags etternavn.company.ru." Fant det gjennom Google, noe sånt som dette på side 10. Designet var fra tidlig på midten av XNUMX-tallet, og en respektabel person så på det fra hovedsiden, noe sånt som dette:
Her tok jeg et stillbilde fra «Heart of a Dog», men tro meg, det var vagt likt, til og med fargedesignet var i lignende toner. La siden bli kalt preobrazhensky.company.ru.
Det var en personlig nettside... for en urolog. Jeg lurte på hva en urologs nettsted gjorde på underdomenet til et høyteknologisk selskap. En rask graving i Google viste at denne legen var en av grunnleggerne av en av kundens juridiske enheter og til og med bidro med rundt 1000 rubler i den autoriserte kapitalen. Siden ble trolig opprettet for mange år siden, og kundens serverressurser ble brukt som hosting. Siden har lenge mistet sin relevans, men av en eller annen grunn ble den stående i lang tid.
Når det gjelder sårbarheter, var selve nettsiden sikker. Ser jeg fremover vil jeg si at det var et sett med statisk informasjon – enkle html-sider med innsatte illustrasjoner i form av nyrer og blærer. Det er nytteløst å "bryte" et slikt nettsted.
Men nettserveren under var mer interessant. Etter HTTP Server-headeren å dømme hadde den IIS 6.0, noe som betyr at den brukte Windows 2003 som operativsystem. Skanneren hadde tidligere identifisert at denne spesielle urolognettstedet, i motsetning til andre virtuelle verter på samme webserver, svarte på PROPFIND-kommandoen, noe som betyr at den kjørte WebDAV. Forresten, skanneren returnerte denne informasjonen med merket Info (på språket til skannerrapporter er dette den laveste faren) - slike ting blir vanligvis bare hoppet over. I kombinasjon ga dette en interessant effekt, som ble avslørt først etter en ny graving på Google: en sjelden bufferoverløpssårbarhet knyttet til Shadow Brokers-settet, nemlig CVE-2017-7269, som allerede hadde en ferdig utnyttelse. Det vil med andre ord være problemer hvis du har Windows 2003 og WebDAV kjører på IIS. Selv om det å kjøre Windows 2003 i produksjon i 2018 er et problem i seg selv.
Utnyttelsen havnet i Metasploit og ble umiddelbart testet med en last som sendte en DNS-forespørsel til en kontrollert tjeneste – Burp Collaborator brukes tradisjonelt til å fange opp DNS-forespørsler. Til min overraskelse fungerte det første gang: en DNS-knockout ble mottatt. Deretter var det et forsøk på å opprette en tilbakekobling via port 80 (det vil si en nettverksforbindelse fra serveren til angriperen, med tilgang til cmd.exe på offerverten), men så skjedde en fiasko. Forbindelsen kom ikke gjennom, og etter det tredje forsøket på å bruke nettstedet, sammen med alle de interessante bildene, forsvant for alltid.
Vanligvis blir dette etterfulgt av et brev i stilen "kunde, våkn opp, vi droppet alt." Men vi ble fortalt at siden ikke har noe med forretningsprosesser å gjøre og fungerer der uten grunn, som hele serveren, og at vi kan bruke denne ressursen som vi vil.
Omtrent et døgn senere begynte siden plutselig å fungere av seg selv. Etter å ha bygget en benk fra WebDAV på IIS 6.0, fant jeg ut at standardinnstillingen er å starte IIS-arbeidsprosesser på nytt hver 30. time. Det vil si at når kontrollen gikk ut av shellcode, ble IIS-arbeidsprosessen avsluttet, deretter startet den seg selv på nytt et par ganger og gikk deretter til hvile i 30 timer.
Siden tilbakekoblingen til tcp mislyktes første gang, tilskrev jeg dette problemet til en lukket port. Det vil si at han antok tilstedeværelsen av en slags brannmur som ikke tillot utgående forbindelser å passere utenfor. Jeg begynte å kjøre shellcodes som søkte gjennom mange tcp- og udp-porter, det var ingen effekt. Omvendt tilkoblingsbelastning via http(er) fra Metasploit fungerte ikke - meterpreter/reverse_http(s). Plutselig ble en forbindelse til samme port 80 opprettet, men falt umiddelbart. Jeg tilskrev dette handlingen til den fortsatt imaginære IPS-en, som ikke likte målerens trafikk. I lys av at en ren tcp-forbindelse til port 80 ikke gikk gjennom, men en http-forbindelse gjorde det, konkluderte jeg med at en http-proxy på en eller annen måte var konfigurert i systemet.
Jeg prøvde til og med meterpreter via DNS (takk for innsatsen din, reddet mange prosjekter), og husker den aller første suksessen, men den fungerte ikke engang på standen - skallkoden var for omfangsrik for denne sårbarheten.
I virkeligheten så det slik ut: 3-4 forsøk på angrep innen 5 minutter, deretter vente i 30 timer. Og så videre i tre uker på rad. Jeg satte til og med inn en påminnelse for ikke å kaste bort tid. I tillegg var det en forskjell i oppførselen til test- og produksjonsmiljøene: for denne sårbarheten var det to lignende utnyttelser, en fra Metasploit, den andre fra Internett, konvertert fra Shadow Brokers-versjonen. Så det var bare Metasploit som ble testet i kamp, og bare den andre ble testet på benken, noe som gjorde feilsøking enda vanskeligere og hjernebristende.
Til slutt viste en shellcode som lastet ned en exe-fil fra en gitt server via http og lanserte den på målsystemet å være effektiv. Skallkoden var liten nok til å passe, men den fungerte i det minste. Siden serveren ikke likte TCP-trafikk i det hele tatt og http(er) ble inspisert for tilstedeværelse av meterpreter, bestemte jeg meg for at den raskeste måten var å laste ned en exe-fil som inneholdt DNS-meterpreter gjennom denne shellcode.
Her oppsto det igjen et problem: ved nedlasting av en exe-fil og, som forsøk viste, uansett hvilken, ble nedlastingen avbrutt. Igjen, en sikkerhetsenhet mellom serveren min og urologen likte ikke http-trafikk med en exe inni. Den "raske" løsningen så ut til å være å endre skallkoden slik at den ville tilsløre http-trafikk i farten, slik at abstrakte binære data ville bli overført i stedet for exe. Til slutt var angrepet vellykket, kontroll ble mottatt gjennom den tynne DNS-kanalen:
Det ble umiddelbart klart at jeg har de mest grunnleggende IIS arbeidsflytrettighetene, som lar meg gjøre ingenting. Slik så det ut på Metasploit-konsollen:
Alle pentest metoder tyder sterkt på at du må øke rettighetene når du får tilgang. Jeg gjør vanligvis ikke dette lokalt, siden den aller første tilgangen blir sett på som et nettverksinngangspunkt, og å kompromittere en annen maskin på samme nettverk er vanligvis enklere og raskere enn å eskalere rettigheter på en eksisterende vert. Men dette er ikke tilfelle her, siden DNS-kanalen er veldig smal og den vil ikke tillate trafikk å rydde opp.
Forutsatt at denne Windows 2003-serveren ikke har blitt reparert for det berømte MS17-010-sårbarheten, tunnelerer jeg trafikk til port 445/TCP gjennom meterpreter DNS-tunnelen på localhost (ja, dette er også mulig) og prøver å kjøre den tidligere nedlastede exe-en gjennom sårbarheten. Angrepet fungerer, jeg mottar en ny tilkobling, men med SYSTEM-rettigheter.
Det er interessant at de fortsatt prøvde å beskytte serveren mot MS17-010 - den hadde sårbare nettverkstjenester deaktivert på det eksterne grensesnittet. Dette beskytter mot angrep over nettverket, men angrepet innenfra på localhost fungerte, siden du ikke bare raskt kan slå av SMB på localhost.
Deretter avsløres nye interessante detaljer:
- Med SYSTEM-rettigheter kan du enkelt etablere en tilbakekobling via TCP. Å deaktivere direkte TCP er åpenbart et problem for den begrensede IIS-brukeren. Spoiler: IIS-brukertrafikken ble på en eller annen måte pakket inn i den lokale ISA-proxyen i begge retninger. Hvordan akkurat det fungerer, har jeg ikke gjengitt.
- Jeg er i en viss "DMZ" (og dette er ikke et Active Directory-domene, men en WORKGROUP) - det høres logisk ut. Men i stedet for den forventede private («grå») IP-adressen, har jeg en helt «hvit» IP-adresse, nøyaktig den samme som den jeg angrep tidligere. Dette betyr at selskapet er så gammelt i verden av IPv4-adressering at det har råd til å opprettholde en DMZ-sone for 128 "hvite" adresser uten NAT i henhold til ordningen, som vist i Cisco-manualer fra 2005.
Siden serveren er gammel, vil Mimikatz garantert fungere direkte fra minnet:
Jeg får det lokale administratorpassordet, tunnelerer RDP-trafikk over TCP og logger på et koselig skrivebord. Siden jeg kunne gjøre hva jeg ville med serveren, fjernet jeg antiviruset og fant ut at serveren kun var tilgjengelig fra Internett via TCP-portene 80 og 443, og 443 var ikke opptatt. Jeg setter opp en OpenVPN-server på 443, legger til NAT-funksjoner for VPN-trafikken min og får direkte tilgang til DMZ-nettverket i ubegrenset form gjennom min OpenVPN. Det er bemerkelsesverdig at ISA, med noen ikke-deaktiverte IPS-funksjoner, blokkerte trafikken min med portskanning, som den måtte erstattes med en enklere og mer kompatibel RRAS. Så pentestere må noen ganger fortsatt administrere alle slags ting.
En oppmerksom leser vil spørre: "Hva med det andre nettstedet - en wiki med NTLM-autentisering, som det er skrevet så mye om?" Mer om dette senere.
Del 2. Krypterer du fortsatt ikke? Da kommer vi til deg allerede her
Så det er tilgang til DMZ-nettverkssegmentet. Du må gå til domeneadministratoren. Det første du tenker på er å automatisk sjekke sikkerheten til tjenester innenfor DMZ-segmentet, spesielt siden mange flere av dem nå er åpne for forskning. Et typisk bilde under en penetrasjonstest: den eksterne omkretsen er bedre beskyttet enn interne tjenester, og når du får tilgang til en stor infrastruktur, er det mye lettere å få utvidede rettigheter i et domene bare på grunn av det faktum at dette domenet begynner å bli tilgjengelig for verktøy, og for det andre, I en infrastruktur med flere tusen verter vil det alltid være et par kritiske problemer.
Jeg lader skannerne via DMZ via en OpenVPN-tunnel og venter. Jeg åpner rapporten - igjen ikke noe alvorlig, tilsynelatende har noen gått gjennom samme metode før meg. Det neste trinnet er å undersøke hvordan verter innenfor DMZ-nettverket kommuniserer. For å gjøre dette, start først den vanlige Wiresharken og lytt etter kringkastingsforespørsler, først og fremst ARP. ARP-pakker ble samlet inn hele dagen lang. Det viser seg at flere gatewayer brukes i dette segmentet. Dette kommer godt med senere. Ved å kombinere data om ARP-forespørsler og svar og portskanningsdata, fant jeg utgangspunktene for brukertrafikk fra innsiden av det lokale nettverket i tillegg til de tjenestene som tidligere var kjent, som web og e-post.
Siden jeg for øyeblikket ikke hadde tilgang til andre systemer og ikke hadde en eneste konto for bedriftstjenester, ble det besluttet å fiske ut minst en del konto fra trafikken ved å bruke ARP Spoofing.
Cain&Abel ble lansert på urologens server. Tatt i betraktning de identifiserte trafikkstrømmene, ble de mest lovende parene for mann-i-midten-angrepet valgt, og deretter ble noe nettverkstrafikk mottatt ved korttidsoppstart i 5-10 minutter, med en tidtaker for å starte serveren på nytt ved frysing. Som i spøken var det to nyheter:
- Bra: mye legitimasjon ble samlet inn og angrepet som helhet fungerte.
- Det dårlige: all legitimasjon var fra kundens egne kunder. Mens de ga støttetjenester, koblet kundespesialister seg til tjenestene til klienter som ikke alltid hadde trafikkkryptering konfigurert.
Som et resultat skaffet jeg meg mye legitimasjon som var ubrukelig i forbindelse med prosjektet, men definitivt interessant som en demonstrasjon av faren ved angrepet. Grense-rutere til store selskaper med telnet, videresendte debug http-porter til intern CRM med alle data, direkte tilgang til RDP fra Windows XP på det lokale nettverket og annen obskurantisme. Det ble slik .
Jeg fant også en morsom mulighet til å samle brev fra trafikken, noe sånt som dette. Dette er et eksempel på et ferdig brev som gikk fra vår kunde til hans klients SMTP-port, igjen, uten kryptering. En viss Andrey ber navnebroren sin om å sende dokumentasjonen på nytt, og den lastes opp til en skydisk med pålogging, passord og lenke i ett svarbrev:
Dette er nok en påminnelse om å kryptere alle tjenester. Det er ukjent hvem og når som skal lese og bruke dataene dine spesifikt - leverandøren, systemadministratoren til et annet selskap, eller en slik pentester. Jeg er taus om det faktum at mange mennesker rett og slett kan avskjære ukryptert trafikk.
Til tross for den tilsynelatende suksessen, førte dette oss ikke nærmere målet. Det var selvsagt mulig å sitte lenge og fiske opp verdifull informasjon, men det er ikke et faktum at den ville dukket opp der, og selve angrepet er svært risikabelt med tanke på integriteten til nettverket.
Etter en ny graving i tjenestene dukket det opp en interessant idé. Det er et slikt verktøy som heter Responder (det er lett å finne eksempler på bruk med dette navnet), som, ved å "forgifte" kringkastingsforespørsler, provoserer tilkoblinger via en rekke protokoller som SMB, HTTP, LDAP, etc. på forskjellige måter, ber så alle som kobler seg om å autentisere og setter det opp slik at autentisering skjer via NTLM og i en modus som er transparent for offeret. Oftest samler en angriper NetNTLMv2-håndtrykk på denne måten og gjenoppretter raskt brukerdomenepassord fra dem ved hjelp av en ordbok. Her ville jeg ha noe lignende, men brukerne satt "bak en vegg", eller rettere sagt, de ble adskilt av en brannmur, og fikk tilgang til WEB gjennom Blue Coat proxy-klyngen.
Husk at jeg spesifiserte at Active Directory-domenenavnet falt sammen med det "eksterne" domenet, det vil si at det var company.ru? Så, Windows, mer presist Internet Explorer (og Edge og Chrome), lar brukeren autentisere seg transparent i HTTP via NTLM hvis de mener at nettstedet ligger i en "Intranettsone". Et av tegnene på et "Intranett" er tilgang til en "grå" IP-adresse eller et kort DNS-navn, det vil si uten prikker. Siden de hadde en server med et "hvitt" IP- og DNS-navn preobrazhensky.company.ru, og domenemaskiner vanligvis mottar Active Directory-domene-suffikset via DHCP for forenklet navneregistrering, måtte de bare skrive URL-en i adressefeltet , slik at de finner den rette veien til den kompromitterte urologens server, og ikke glemme at dette nå heter "Intranett". Det vil si, samtidig gi meg brukerens NTLM-håndtrykk uten hans viten. Alt som gjenstår er å tvinge klientnettlesere til å tenke på det presserende behovet for å kontakte denne serveren.
Det fantastiske Intercepter-NG-verktøyet kom til unnsetning (takk ). Det tillot deg å endre trafikk på farten og fungerte utmerket på Windows 2003. Den hadde til og med separat funksjonalitet for å endre kun JavaScript-filer i trafikkflyten. En slags massiv Cross-Site Scripting var planlagt.
Blue Coat-fullmakter, som brukere fikk tilgang til det globale WEB via, bufret statisk innhold med jevne mellomrom. Ved å avskjære trafikk var det tydelig at de jobbet døgnet rundt, og ba uendelig om hyppig brukt statisk for å få fart på visningen av innhold i rushtiden. I tillegg hadde BlueCoat en spesifikk User-Agent, som tydelig skilte den fra en ekte bruker.
Javascript ble utarbeidet, som ved hjelp av Intercepter-NG ble implementert i en time om natten for hvert svar med JS-filer for Blue Coat. Manuset gjorde følgende:
- Bestemte gjeldende nettleser av User-Agent. Hvis det var Internet Explorer, Edge eller Chrome, fortsatte det å fungere.
- Jeg ventet til DOM-en til siden ble dannet.
- Sett inn et usynlig bilde i DOM med et src-attributt for skjemaet :8080/NNNNNNNN.png, der NNN er vilkårlige tall slik at BlueCoat ikke hurtigbuffer det.
- Angi en global flaggvariabel for å indikere at injeksjonen ble fullført og at det ikke er behov for å sette inn bilder lenger.
Nettleseren prøvde å laste inn dette bildet; på port 8080 til den kompromitterte serveren ventet en TCP-tunnel på den til den bærbare datamaskinen min, der den samme Responderen kjørte, og krevde at nettleseren logget på via NTLM.
Etter svarloggene å dømme, kom folk på jobb om morgenen, slo på arbeidsstasjonene sine, og begynte så massevis og ubemerket å besøke urologens server, uten å glemme å "tømme" NTLM-håndtrykk. Håndtrykk regnet ned hele dagen og klarte akkumulert materiale for et åpenbart vellykket angrep for å gjenopprette passord. Slik så Responder-loggene ut:
Hemmelige massebesøk på urologserveren av brukere
Du har sikkert allerede lagt merke til at hele denne historien er bygd på prinsippet "alt var bra, men så var det en bummer, så var det en overvinnelse, og så kom alt til suksess." Så, det var en bummer her. Av de femti unike håndtrykkene ble ikke en eneste avslørt. Og dette tar hensyn til det faktum at selv på en bærbar datamaskin med død prosessor, behandles disse NTLMv2-håndtrykkene med en hastighet på flere hundre millioner forsøk per sekund.
Jeg måtte bevæpne meg med passordmutasjonsteknikker, et skjermkort, en tykkere ordbok og vente. Etter lang tid ble flere kontoer med passord av formen "Q11111111....1111111q" avslørt, noe som tyder på at alle brukere en gang ble tvunget til å komme opp med et veldig langt passord med forskjellige store bokstaver, som også skulle være kompleks. Men du kan ikke lure en erfaren bruker, og dette er hvordan han gjorde det lettere for seg selv å huske. Totalt ble ca 5 kontoer kompromittert, og kun én av dem hadde noen verdifulle rettigheter til tjenestene.
Del 3. Roskomnadzor slår tilbake
Så de første domenekontoene ble mottatt. Hvis du ikke har sovnet på dette tidspunktet fra en lang lesning, vil du sannsynligvis huske at jeg nevnte en tjeneste som ikke krevde en ekstra faktor for autentisering: det er en wiki med NTLM-autentisering. Det første du måtte gjøre var selvfølgelig å gå inn der. Graving i den interne kunnskapsbasen ga raskt resultater:
- Selskapet har et WiFi-nettverk med autentisering ved bruk av domenekontoer med tilgang til det lokale nettverket. Med det nåværende settet med data er dette allerede en fungerende angrepsvektor, men du må gå til kontoret med føttene og være lokalisert et sted på territoriet til kundens kontor.
- Jeg fant en instruksjon der det var en tjeneste som tillot... å uavhengig registrere en "andre faktor" autentiseringsenhet hvis brukeren er inne i et lokalt nettverk og trygt husker domenepålogging og passord. I dette tilfellet ble "inne" og "utenfor" bestemt av tilgjengeligheten til porten til denne tjenesten for brukeren. Porten var ikke tilgjengelig fra Internett, men var ganske tilgjengelig via DMZ.
Selvfølgelig ble en "andre faktor" umiddelbart lagt til den kompromitterte kontoen i form av en applikasjon på telefonen min. Det var et program som enten høylytt kunne sende en push-forespørsel til telefonen med "godkjenn"/"ikke godkjenne"-knapper for handlingen, eller stille vise OTP-koden på skjermen for videre uavhengig oppføring. Dessuten skulle den første metoden ifølge instruksjonene være den eneste riktige, men den fungerte ikke, i motsetning til OTP-metoden.
Med "den andre faktoren" brutt, fikk jeg tilgang til Outlook Web Access-post og ekstern tilgang i Citrix Netscaler Gateway. Det kom en overraskelse i posten i Outlook:
I dette sjeldne skuddet kan du se hvordan Roskomnadzor hjelper pentesters
Dette var de første månedene etter den berømte "fan"-blokkeringen av Telegram, da hele nettverk med tusenvis av adresser ubønnhørlig forsvant fra tilgang. Det ble klart hvorfor pushen ikke fungerte med en gang og hvorfor "offeret" mitt ikke slo alarm fordi de begynte å bruke kontoen hennes i åpningstidene.
Alle som er kjent med Citrix Netscaler forestiller seg at det vanligvis er implementert på en slik måte at bare et bildegrensesnitt kan formidles til brukeren, og prøver å ikke gi ham verktøyene til å starte tredjepartsapplikasjoner og overføre data, noe som begrenser handlinger på alle mulige måter gjennom standard kontrollskall. Mitt "offer", på grunn av sitt yrke, fikk bare 1C:
Etter å ha gått litt rundt i 1C-grensesnittet, fant jeg ut at det er eksterne prosesseringsmoduler der. De kan lastes fra grensesnittet, og de vil bli utført på klienten eller serveren, avhengig av rettigheter og innstillinger.
Jeg spurte mine 1C-programmerervenner om å lage en prosessering som ville akseptere en streng og utføre den. På 1C-språk ser det slik ut å starte en prosess (hentet fra Internett). Er du enig i at syntaksen til 1C-språket forbløffer russisktalende mennesker med sin spontanitet?
Behandlingen ble utført perfekt; det viste seg å være det pentesterne kaller et "skall" - Internet Explorer ble lansert gjennom det.
Tidligere ble adressen til et system som lar deg bestille pass til territoriet funnet i posten. Jeg bestilte et pass i tilfelle jeg måtte bruke en WiFi-angrepsvektor.
Det snakkes på Internett om at det fortsatt var deilig gratis catering på kundens kontor, men jeg foretrakk likevel å utvikle angrepet eksternt, det er roligere.
AppLocker ble aktivert på applikasjonsserveren som kjører Citrix, men den ble forbigått. Den samme Meterpreter ble lastet og lansert via DNS, siden http(e)-versjonene ikke ønsket å koble til, og jeg ikke visste den interne proxy-adressen på det tidspunktet. Forresten, fra dette øyeblikket ble den eksterne pentesten i hovedsak fullstendig omgjort til en intern.
Del 4. Administratorrettigheter for brukere er dårlige, ok?
Den første oppgaven til en pentester når han skal få kontroll over en domenebrukerøkt er å samle all informasjon om rettigheter i domenet. Det er et BloodHound-verktøy som automatisk lar deg laste ned informasjon om brukere, datamaskiner, sikkerhetsgrupper via LDAP-protokollen fra en domenekontroller, og via SMB - informasjon om hvilken bruker som nylig har logget på hvor og hvem som er lokal administrator.
En typisk teknikk for å beslaglegge domeneadministratorrettigheter ser forenklet ut som en syklus av monotone handlinger:
- Vi går til domenedatamaskiner der det er lokale administratorrettigheter, basert på allerede fangede domenekontoer.
- Vi lanserer Mimikatz og får hurtigbufrede passord, Kerberos-billetter og NTLM-hasher av domenekontoer som nylig har logget på dette systemet. Eller vi fjerner minnebildet til lsass.exe-prosessen og gjør det samme på vår side. Dette fungerer bra med Windows yngre enn 2012R2/Windows 8.1 med standardinnstillinger.
- Vi bestemmer hvor de kompromitterte kontoene har lokale administratorrettigheter. Vi gjentar det første punktet. På et tidspunkt får vi administratorrettigheter for hele domenet.
"End of the Cycle;", som 1C-programmerere ville skrevet her.
Så brukeren vår viste seg å være en lokal administrator på bare én vert med Windows 7, hvis navn inkluderte ordet "VDI", eller "Virtual Desktop Infrastructure", personlige virtuelle maskiner. Sannsynligvis mente designeren av VDI-tjenesten at siden VDI er brukerens personlige operativsystem, selv om brukeren endrer programvaremiljøet som han vil, kan verten fortsatt "lastes på nytt". Jeg trodde også at ideen generelt var god, jeg dro til denne personlige VDI-verten og laget et rede der:
- Jeg installerte en OpenVPN-klient der, som laget en tunnel gjennom Internett til serveren min. Klienten måtte tvinges til å gå gjennom den samme Blue Coat med domeneautentisering, men OpenVPN gjorde det, som de sier, "ut av esken."
- Installert OpenSSH på VDI. Vel, egentlig, hva er Windows 7 uten SSH?
Slik så det ut live. La meg minne deg på at alt dette må gjøres gjennom Citrix og 1C:
En teknikk for å fremme tilgang til nabodatamaskiner er å sjekke lokale administratorpassord for en match. Her ventet lykken umiddelbart: NTLM-hashen til standard lokale administrator (som plutselig ble kalt Administrator) ble kontaktet gjennom et pass-the-hash-angrep til nabo VDI-verter, som det var flere hundre av. Selvfølgelig rammet angrepet dem umiddelbart.
Det er her VDI-administratorer skjøt seg selv i foten to ganger:
- Den første gangen var da VDI-maskiner ikke ble brakt under LAPS, og i hovedsak beholdt det samme lokale administratorpassordet fra bildet som ble distribuert massivt til VDI.
- Standardadministratoren er den eneste lokale kontoen som er sårbar for pass-the-hash-angrep. Selv med det samme passordet vil det være mulig å unngå massekompromittering ved å opprette en annen lokal administratorkonto med et komplekst tilfeldig passord og blokkere standarden.
Hvorfor SSH-tjenesten på den Windows? Veldig enkelt: Nå ga OpenSSH-serveren ikke bare et praktisk interaktivt kommandoskall uten å forstyrre brukerens arbeid, men også en socks5-proxy på VDI. Gjennom disse sokkene koblet jeg til via SMB og samlet inn bufrede kontoer fra alle disse hundrevis av VDI-maskiner, og så etter stien til domeneadministratoren som brukte dem i BloodHound-grafene. Med hundrevis av verter til min disposisjon, fant jeg denne måten ganske raskt. Domeneadministratorrettigheter er oppnådd.
Her er et bilde fra Internett som viser et lignende søk. Tilkoblinger viser hvem som er hvor administratoren er og hvem som er pålogget hvor.
Husk forresten tilstanden fra starten av prosjektet - "ikke bruk sosial ingeniørkunst." Så jeg foreslår å tenke på hvor mye all denne Bollywood med spesialeffekter ville blitt avskåret hvis det fortsatt var mulig å bruke banal phishing. Men personlig var det veldig interessant for meg å gjøre alt dette. Jeg håper du likte å lese dette. Selvfølgelig ser ikke alle prosjekter så spennende ut, men arbeidet som helhet er veldig utfordrende og lar det ikke stagnere.
Sannsynligvis vil noen ha et spørsmål: hvordan beskytte deg selv? Selv denne artikkelen beskriver mange teknikker, hvorav mange Windows-administratorer ikke engang vet om. Jeg foreslår imidlertid å se på dem fra perspektivet av utslitte prinsipper og informasjonssikkerhetstiltak:
- ikke bruk utdatert programvare (husker du Windows 2003 i begynnelsen?)
- Ikke hold unødvendige systemer slått på (hvorfor var det en urologs nettside?)
- sjekk brukerpassord for styrke selv (ellers vil soldater... pentestere gjøre dette)
- ikke ha de samme passordene for forskjellige kontoer (VDI-kompromittering)
- og annen
Dette er selvfølgelig veldig vanskelig å gjennomføre, men i neste artikkel skal vi vise i praksis at det er fullt mulig.
Kilde: www.habr.com