Tento článok bol napísaný na základe veľmi úspešného pentestu, ktorý pred pár rokmi uskutočnili špecialisti Group-IB: Stal sa príbeh, ktorý by sa dal upraviť pre film v Bollywoode. Teraz zrejme bude nasledovať reakcia čitateľa: „Ach, ďalší PR článok, opäť sa zobrazujú tieto, aké sú dobré, nezabudnite si kúpiť pentest.“ No na jednej strane je. Existuje však množstvo ďalších dôvodov, prečo sa tento článok objavil. Chcel som ukázať, čo presne pentesteri robia, aká zaujímavá a netriviálna môže byť táto práca, aké vtipné okolnosti môžu nastať v projektoch, a hlavne ukázať živý materiál s reálnymi príkladmi.
Aby sme vo svete nastolili rovnováhu skromnosti, po čase napíšeme o penteste, ktorý nedopadol dobre. Ukážeme, ako dobre navrhnuté procesy vo firme dokážu ochrániť pred celým radom útokov, dokonca aj dobre pripravených, len preto, že tieto procesy existujú a skutočne fungujú.
Pre zákazníka v tomto článku bolo tiež všetko vo všeobecnosti vynikajúce, aspoň lepšie ako 95% trhu v Ruskej federácii, podľa našich pocitov, ale bolo tam niekoľko malých nuancií, ktoré tvorili dlhý reťazec udalostí, ktoré najskôr viedla k dlhej správe o práci a potom k tomuto článku.
Takže, urobme si zásoby pukancov a vitajte v detektívke. Slovo - Pavel Suprunjuk, technický manažér oddelenia „Audit a poradenstvo“ Group-IB.
Časť 1. Pochkin doktor
2018 Existuje zákazník – high-tech IT spoločnosť, ktorá sama obsluhuje mnohých klientov. Chce získať odpoveď na otázku: je možné bez počiatočných znalostí a prístupu pomocou internetu získať práva správcu domény Active Directory? Nemám záujem o žiadne sociálne inžinierstvo (), nemajú v úmysle úmyselne zasahovať do práce, ale môžu sa stať, že náhodne načítajú napríklad podivne fungujúci server. Ďalším cieľom je identifikovať čo najviac ďalších útočných vektorov proti vonkajšiemu obvodu. Spoločnosť takéto testy pravidelne vykonáva a teraz nadišiel termín na nový test. Podmienky sú takmer typické, primerané, zrozumiteľné. Začnime.
Je tam meno zákazníka - nech je to „Spoločnosť“, s hlavnou webovou stránkou . Samozrejme, že zákazník sa volá inak, ale v tomto článku bude všetko neosobné.
Vykonávam rekognoskáciu siete - zisťujem, ktoré adresy a domény má zákazník zaregistrované, nakreslím schému siete, ako sú na tieto adresy distribuované služby. Dostávam výsledok: viac ako 4000 živých IP adries. Pozerám sa na domény v týchto sieťach: našťastie drvivá väčšina sú siete určené pre klientov zákazníka, o ktoré sa formálne nezaujímame. Zákazník si myslí to isté.
Zostáva jedna sieť s 256 adresami, pre ktorú už v súčasnosti existuje porozumenie rozdelenia domén a subdomén podľa IP adries, existujú informácie o skenovaných portoch, čo znamená, že si môžete pozrieť zaujímavé služby. Paralelne sa spúšťajú všetky druhy skenerov na dostupných IP adresách a samostatne na webových stránkach.
Existuje veľa služieb. Zvyčajne je to radosť pre pentestera a očakávanie rýchleho víťazstva, pretože čím viac služieb je, tým väčšie je pole pre útok a tým ľahšie je nájsť artefakt. Letmý pohľad na webové stránky ukázal, že väčšinou ide o webové rozhrania známych produktov veľkých svetových spoločností, ktoré vám podľa všetkého hovoria, že nie sú vítané. Požiadajú o používateľské meno a heslo, vytrasú pole na zadanie druhého faktora, požiadajú o certifikát klienta TLS alebo ho pošlú do služby Microsoft ADFS. Niektoré sú jednoducho nedostupné z internetu. Pri niektorých evidentne potrebujete mať špeciálneho plateného klienta za tri platy alebo poznať presnú URL adresu, ktorú treba zadať. Preskočme ďalší týždeň postupnej skľúčenosti v procese pokusov „prelomiť“ verzie softvéru pre známe zraniteľnosti, hľadať skrytý obsah na webových cestách a uniknuté účty zo služieb tretích strán, ako je LinkedIn, pokúšať sa pomocou nich uhádnuť heslá. ako vykopávanie zraniteľností na vlastných webových stránkach – mimochodom, podľa štatistík je to dnes najsľubnejší vektor vonkajšieho útoku. Okamžite si všimnem filmovú zbraň, ktorá následne vystrelila.
Našli sme teda dve stránky, ktoré sa odlišovali od stoviek služieb. Tieto stránky mali jednu vec spoločnú: ak sa nezapájate do starostlivého prieskumu siete podľa domén, ale priamo sa pozeráte na otvorené porty alebo sa zameriavate na skener zraniteľnosti pomocou známeho rozsahu IP, potom tieto stránky uniknú skenovaniu a jednoducho nebudú viditeľné bez znalosti názvu DNS. Možno sa minuli aspoň skôr a naše automatické nástroje s nimi nenašli žiadne problémy, aj keď boli odoslané priamo do zdroja.
Mimochodom, o tom, čo predtým spustené skenery našli vo všeobecnosti. Dovoľte mi pripomenúť vám: pre niektorých ľudí je „pentest“ ekvivalentom „automatického skenovania“. Ale skenery tohto projektu nepovedali nič. No, maximum ukázali Stredné zraniteľnosti (3 z 5, pokiaľ ide o závažnosť): na niektorých službách zlý certifikát TLS alebo zastarané šifrovacie algoritmy a na väčšine stránok Clickjacking. To vás však k cieľu nedostane. Možno by tu boli užitočnejšie skenery, ale dovoľte mi pripomenúť: zákazník si môže takéto programy kúpiť a sám sa s nimi otestovať a podľa žalostných výsledkov si to už skontroloval.
Vráťme sa k „anomálnym“ stránkam. Prvým je niečo ako lokálna Wiki na neštandardnej adrese, ale v tomto článku nech je to wiki.firma[.]ru. Tiež si hneď vypýtala prihlasovacie meno a heslo, ale cez NTLM v prehliadači. Pre používateľa to vyzerá ako asketické okno s výzvou na zadanie používateľského mena a hesla. A toto je zlá prax.
Malá poznámka. NTLM na okrajových webových stránkach je zlý z niekoľkých dôvodov. Prvým dôvodom je odhalenie názvu domény Active Directory. V našom príklade sa tiež ukázalo, že je to company.ru, rovnako ako „externý“ názov DNS. Keď to viete, môžete starostlivo pripraviť niečo škodlivé, aby sa to spustilo iba na doménovom stroji organizácie a nie v nejakom karanténe. Po druhé, autentifikácia prebieha priamo cez radič domény cez NTLM (prekvapenie, však?), so všetkými funkciami „interných“ sieťových zásad, vrátane blokovania účtov, aby neprekročili počet pokusov o zadanie hesla. Ak útočník zistí prihlasovacie údaje, bude k nim hľadať heslá. Ak ste nakonfigurovaní na blokovanie účtov pri zadávaní nesprávnych hesiel, bude to fungovať a účet bude zablokovaný. Po tretie, k takejto autentifikácii nie je možné pridať druhý faktor. Ak niekto z čitateľov stále vie, ako na to, dajte mi vedieť, je to naozaj zaujímavé. Po štvrté, zraniteľnosť voči pass-the-hash útokom. ADFS bol vynájdený okrem iného na ochranu pred týmto všetkým.
Existuje jedna zlá vlastnosť produktov spoločnosti Microsoft: aj keď ste takýto NTLM konkrétne nezverejnili, predvolene sa nainštaluje prinajmenšom v OWA a Lync.
Mimochodom, autor tohto článku kedysi tou istou metódou omylom zablokoval približne 1000 účtov zamestnancov jednej veľkej banky len za hodinu a potom vyzeral akosi bledo. Aj IT služby banky boli bledé, ale všetko skončilo dobre a adekvátne, dokonca nás pochválili, že sme ako prví našli tento problém a vyvolali rýchlu a rozhodnú nápravu.
Druhá stránka mala adresu „zrejme nejaké priezvisko.spoločnosť.ru“. Našiel som to cez Google, niečo také na strane 10. Dizajn bol zo začiatku polovice XNUMX-tych rokov a slušný človek sa naň pozeral z hlavnej stránky, asi takto:
Tu som zobral destilku zo „Heart of a Dog“, ale verte mi, bola matne podobná, dokonca aj farebné prevedenie bolo v podobných tónoch. Nech sa stránka volá preobrazhensky.company.ru.
Bola to osobná stránka... urológa. Zaujímalo by ma, čo robí webová stránka urológa na subdoméne high-tech spoločnosti. Rýchly pohľad na Google ukázal, že tento lekár bol spoluzakladateľom jednej z právnických osôb nášho zákazníka a dokonca prispel približne 1000 XNUMX rubľov v základnom imaní. Stránka bola pravdepodobne vytvorená pred mnohými rokmi a ako hosting boli použité serverové zdroje zákazníka. Stránka už dávno stratila svoju relevanciu, ale z nejakého dôvodu zostala dlho fungovať.
Čo sa týka zraniteľností, samotná webová stránka bola bezpečná. Pri pohľade dopredu poviem, že išlo o súbor statických informácií – jednoduchých html stránok s vloženými ilustráciami v podobe obličiek a močového mechúra. Je zbytočné „rozbíjať“ takúto stránku.
Ale webový server pod ním bol zaujímavejší. Súdiac podľa hlavičky HTTP Server, mal IIS 6.0, čo znamená, že ako operačný systém používal Windows 2003. Skener predtým zistil, že táto konkrétna webová stránka urológa, na rozdiel od iných virtuálnych hostiteľov na tom istom webovom serveri, reagovala na príkaz PROPFIND, čo znamená, že spustila WebDAV. Mimochodom, skener vrátil tieto informácie s označením Info (v jazyku správ skenerov je to najmenšie nebezpečenstvo) - takéto veci sa zvyčajne jednoducho preskočia. V kombinácii to prinieslo zaujímavý efekt, ktorý sa ukázal až po ďalšom prekopaní Google: vzácna zraniteľnosť pretečenia vyrovnávacej pamäte spojená so sadou Shadow Brokers, konkrétne CVE-2017-7269, ktorá už mala pripravený exploit. Inými slovami, nastanú problémy, ak máte Windows 2003 a WebDAV beží na IIS. Aj keď spustiť Windows 2003 vo výrobe v roku 2018 je problém sám o sebe.
Exploit skončil v Metasploite a bol okamžite testovaný so záťažou, ktorá odoslala DNS požiadavku kontrolovanej službe – Burp Collaborator sa tradične používa na zachytenie DNS požiadaviek. Na moje prekvapenie to fungovalo prvýkrát: bol prijatý knockout DNS. Ďalej došlo k pokusu o vytvorenie spätného pripojenia cez port 80 (to znamená sieťové pripojenie zo servera k útočníkovi s prístupom k cmd.exe na hostiteľovi obete), ale potom sa stalo fiasko. Spojenie sa nepodarilo a po treťom pokuse o použitie stránky spolu so všetkými zaujímavými obrázkami navždy zmizli.
Zvyčajne po ňom nasleduje list v štýle „zákazník, zobuď sa, všetko sme nechali“. Bolo nám však povedané, že stránka nemá nič spoločné s obchodnými procesmi a funguje tam úplne bezdôvodne, ako celý server, a že tento zdroj môžeme používať, ako chceme.
Asi o deň neskôr stránka zrazu začala fungovať sama. Po vytvorení lavičky z WebDAV na IIS 6.0 som zistil, že predvolené nastavenie je reštartovať pracovné procesy IIS každých 30 hodín. To znamená, že keď ovládanie opustilo shell kód, pracovný proces IIS sa skončil, potom sa sám niekoľkokrát reštartoval a potom na 30 hodín odpočíval.
Keďže spätné pripojenie k tcp zlyhalo prvýkrát, pripisoval som tento problém uzavretému portu. To znamená, že predpokladal prítomnosť nejakého druhu firewallu, ktorý neumožňoval odchádzajúce spojenia prechádzať von. Začal som spúšťať shell kódy, ktoré prehľadávali veľa tcp a udp portov, ale bez účinku. Reverzné zaťaženie pripojenia cez http(s) z Metasploit nefungovalo - meterpreter/reverse_http(s). Zrazu sa nadviazalo spojenie s rovnakým portom 80, ale okamžite sa prerušilo. Pripisoval som to pôsobeniu stále pomyselného IPS, ktorému sa nepáčila metrová premávka. Vo svetle skutočnosti, že čisté tcp pripojenie k portu 80 neprešlo, ale http pripojenie áno, som dospel k záveru, že http proxy bol v systéme nejakým spôsobom nakonfigurovaný.
Dokonca som skúšal meterpreter cez DNS (vďaka za vaše úsilie, zachránili ste veľa projektov), pripomínajúc si úplne prvý úspech, ale nefungovalo to ani na stojane - kód shellu bol na túto zraniteľnosť príliš objemný.
V skutočnosti to vyzeralo takto: 3-4 pokusy o útok v priebehu 5 minút, potom čakanie 30 hodín. A tak tri týždne po sebe. Dokonca som si nastavil pripomienku, aby som nestrácal čas. Okrem toho bol rozdiel v správaní testovacieho a produkčného prostredia: pre túto zraniteľnosť existovali dva podobné exploity, jeden z Metasploit, druhý z internetu, konvertovaný z verzie Shadow Brokers. V boji bol teda testovaný iba Metasploit a na lavičke iba druhý, čo ešte viac sťažilo ladenie a nabúralo mozog.
Nakoniec sa osvedčil shell kód, ktorý stiahol exe súbor z daného servera cez http a spustil ho na cieľovom systéme. Kód shellu bol dostatočne malý, aby sa doň zmestil, ale aspoň fungoval. Keďže server vôbec nemal rád TCP prevádzku a http(s) boli skontrolované na prítomnosť meterpreter, rozhodol som sa, že najrýchlejším spôsobom je stiahnuť exe súbor, ktorý obsahuje DNS-meterpreter cez tento shell kód.
Tu opäť nastal problém: pri sťahovaní exe súboru a ako ukázali pokusy, bez ohľadu na to, sťahovanie sa prerušilo. Opäť sa istému bezpečnostnému zariadeniu medzi mojím serverom a urológom nepáčilo http prevádzka s exe vo vnútri. Zdá sa, že „rýchlym“ riešením bola zmena kódu shellu tak, aby zahmlieval http prevádzku za behu, takže namiesto exe by sa prenášali abstraktné binárne dáta. Nakoniec bol útok úspešný, kontrola bola prijatá cez tenký kanál DNS:
Okamžite sa ukázalo, že mám najzákladnejšie práva na pracovný tok IIS, ktoré mi neumožňujú nič robiť. Takto to vyzeralo na konzole Metasploit:
Všetky metódy pentestu dôrazne naznačujú, že pri získavaní prístupu musíte zvýšiť práva. Zvyčajne to nerobím lokálne, pretože úplne prvý prístup je vnímaný jednoducho ako vstupný bod siete a ohrozenie iného počítača v rovnakej sieti je zvyčajne jednoduchšie a rýchlejšie ako eskalácia privilégií na existujúcom hostiteľovi. To však nie je tento prípad, pretože kanál DNS je veľmi úzky a neumožňuje uvoľnenie prevádzky.
Za predpokladu, že tento server Windows 2003 nebol opravený pre slávnu zraniteľnosť MS17-010, tunelujem prevádzku na port 445/TCP cez tunel meterpreter DNS na localhost (áno, je to tiež možné) a pokúsim sa spustiť predtým stiahnutý exe cez zraniteľnosť. Útok funguje, dostávam druhé pripojenie, ale so SYSTÉMOVÝMI právami.
Je zaujímavé, že sa stále snažili chrániť server pred MS17-010 - na externom rozhraní mal vypnuté zraniteľné sieťové služby. Toto síce chráni pred útokmi cez sieť, ale útok zvnútra na localhost fungoval, keďže SMB na localhoste nemôžete len tak rýchlo vypnúť.
Ďalej sú odhalené nové zaujímavé detaily:
- S právami SYSTEM môžete jednoducho vytvoriť spätné spojenie cez TCP. Je zrejmé, že zakázanie priameho TCP je striktne problémom pre obmedzeného používateľa IIS. Spoiler: prevádzka používateľov IIS bola nejakým spôsobom zabalená do lokálneho servera ISA Proxy v oboch smeroch. Ako presne to funguje, som nezreprodukoval.
- Som v určitej „DMZ“ (a toto nie je doména Active Directory, ale PRACOVNÁ SKUPINA) – znie to logicky. Ale namiesto očakávanej súkromnej („šedej“) IP adresy mám úplne „bielu“ IP adresu, presne tú istú, akú som predtým napadol. To znamená, že spoločnosť je vo svete IPv4 adresovania taká stará, že si môže dovoliť udržiavať DMZ zónu pre 128 „bielych“ adries bez NAT podľa schémy, ako je znázornená v manuáloch Cisco z roku 2005.
Keďže server je starý, Mimikatz zaručene funguje priamo z pamäte:
Získam heslo miestneho správcu, vytunelujem prevádzku RDP cez TCP a prihlásim sa do útulnej pracovnej plochy. Keďže som si so serverom mohol robiť, čo som chcel, odstránil som antivírus a zistil som, že server je dostupný z internetu len cez TCP porty 80 a 443 a 443 nie je zaneprázdnený. Nastavil som server OpenVPN na 443, pridal som funkcie NAT pre svoju prevádzku VPN a získal som priamy prístup do siete DMZ v neobmedzenej forme prostredníctvom môjho OpenVPN. Je pozoruhodné, že ISA, ktorá má niektoré nedeaktivované funkcie IPS, zablokovala moju komunikáciu skenovaním portov, pre ktoré bolo potrebné nahradiť ju jednoduchším a kompatibilnejším RRAS. Takže pentesteri niekedy ešte musia spravovať všelijaké veci.
Pozorný čitateľ sa opýta: „A čo druhá stránka – wiki s autentifikáciou NTLM, o ktorej sa toho už toľko napísalo?“ Viac o tom neskôr.
Časť 2. Stále nešifrujete? Potom už prichádzame k vám
Existuje teda prístup do segmentu siete DMZ. Musíte ísť k správcovi domény. Prvá vec, ktorá vás napadne, je automatická kontrola bezpečnosti služieb v rámci segmentu DMZ, najmä preto, že oveľa viac z nich je teraz otvorených na výskum. Typický obraz pri penetračnom teste: vonkajší perimeter je chránený lepšie ako interné služby a pri získaní akéhokoľvek prístupu v rámci veľkej infraštruktúry je oveľa jednoduchšie získať rozšírené práva v doméne len vďaka tomu, že táto doména začína byť prístupné nástrojom a po druhé, v infraštruktúre s niekoľkými tisíckami hostiteľov bude vždy existovať niekoľko kritických problémov.
Nabíjam skenery cez DMZ cez OpenVPN tunel a čakám. Otváram správu - opäť nič vážne, zrejme niekto prešiel rovnakou metódou predo mnou. Ďalším krokom je preskúmať, ako komunikujú hostitelia v sieti DMZ. Ak to chcete urobiť, najprv spustite obvyklý Wireshark a počúvajte požiadavky na vysielanie, predovšetkým ARP. ARP pakety sa zbierali celý deň. Ukazuje sa, že v tomto segmente sa používa niekoľko brán. To sa vám bude hodiť neskôr. Kombináciou údajov o požiadavkách a odpovediach ARP a údajov o skenovaní portov som okrem služieb, ktoré boli predtým známe, ako napríklad web a pošta, našiel výstupné body používateľskej prevádzky z lokálnej siete.
Keďže som momentálne nemal prístup k iným systémom a ani jeden účet pre firemné služby, bolo rozhodnuté vyloviť z prevádzky aspoň nejaký účet pomocou ARP Spoofingu.
Cain&Abel bol spustený na serveri urológa. Berúc do úvahy identifikované toky prenosu, vybrali sa najsľubnejšie páry pre útok typu man-in-the-middle a potom sa krátkodobo spustila na 5 až 10 minút sieťová prevádzka s časovačom na reštartovanie servera. v prípade zamrznutia. Ako vo vtipe, boli tu dve novinky:
- Dobre: chytilo sa veľa poverení a útok ako celok fungoval.
- Zlé: všetky poverenia boli od vlastných klientov zákazníka. Pri poskytovaní podporných služieb sa zákaznícki špecialisti pripájali k službám klientov, ktorí nemali vždy nastavené šifrovanie prevádzky.
Vďaka tomu som získal množstvo poverení, ktoré boli v kontexte projektu nepoužiteľné, ale ako ukážka nebezpečenstva útoku rozhodne zaujímavé. Hraničné routre veľkých spoločností s telnetom, preposlané ladiace http porty do interného CRM so všetkými dátami, priamy prístup k RDP z Windows XP na lokálnej sieti a iné tmárstvo. Dopadlo to takto .
Našiel som aj vtipnú príležitosť zbierať listy z dopravy, niečo takéto. Toto je príklad hotového listu, ktorý prišiel od nášho zákazníka na port SMTP jeho klienta, opäť bez šifrovania. Istý Andrey požiada svojho menovca o opätovné zaslanie dokumentácie a tá sa nahrá na cloudový disk s prihlasovacím menom, heslom a odkazom v jednom odpovedi:
Toto je ďalšia pripomienka na šifrovanie všetkých služieb. Nie je známe, kto a kedy bude konkrétne čítať a používať vaše údaje – poskytovateľ, správca systému inej spoločnosti alebo taký pentester. O tom, že veľa ľudí dokáže jednoducho zachytiť nešifrovaný prenos, mlčím.
Napriek zdanlivému úspechu nás to k cieľu nepriblížilo. Dalo sa, samozrejme, dlho sedieť a vyloviť cenné informácie, ale nie je pravda, že by sa tam objavili a samotný útok je z hľadiska integrity siete veľmi riskantný.
Po ďalšom rýpnutí do služieb prišiel na rad zaujímavý nápad. Existuje taký nástroj s názvom Responder (pod týmto názvom je ľahké nájsť príklady použitia), ktorý „otrávením“ požiadaviek na vysielanie vyvoláva pripojenia prostredníctvom rôznych protokolov, ako sú SMB, HTTP, LDAP atď. rôznymi spôsobmi, potom požiada každého, kto sa pripája, aby sa overil a nastaví to tak, aby autentifikácia prebiehala cez NTLM a v režime transparentnom pre obeť. Útočník najčastejšie týmto spôsobom zbiera handshaky NetNTLMv2 a pomocou slovníka z nich rýchlo obnovuje heslá používateľskej domény. Tu som chcel niečo podobné, ale používatelia sedeli „za stenou“, alebo skôr, boli oddelení firewallom a pristupovali na WEB cez proxy klaster Blue Coat.
Pamätáte si, že som uviedol, že názov domény Active Directory sa zhoduje s „externou“ doménou, to znamená, že to bola company.ru? Takže Windows, presnejšie Internet Explorer (a Edge a Chrome), umožňujú užívateľovi transparentnú autentifikáciu v HTTP cez NTLM, ak sa domnievajú, že stránka sa nachádza v nejakej „intranetovej zóne“. Jedným zo znakov „intranetu“ je prístup k „sivej“ IP adrese alebo krátkemu názvu DNS, teda bez bodiek. Keďže mali server s „bielou“ IP a DNS názvom preobrazhensky.company.ru a doménové stroje zvyčajne dostávajú príponu domény Active Directory cez DHCP na zjednodušenie zadávania názvu, museli do panela s adresou napísať iba adresu URL. , aby našli správnu cestu k serveru napadnutého urológa, pričom nezabúdajú, že tento sa teraz nazýva „intranet“. To znamená, že mi zároveň dávate používateľovi NTLM handshake bez jeho vedomia. Zostáva len prinútiť klientske prehliadače, aby premýšľali o naliehavej potrebe kontaktovať tento server.
Úžasný nástroj Intercepter-NG prišiel na záchranu (vďaka ). Umožnil vám meniť premávku za chodu a fungoval skvele v systéme Windows 2003. Dokonca mal samostatnú funkčnosť na úpravu iba súborov JavaScript v toku premávky. Plánovalo sa akési masívne Cross-Site Scripting.
Proxy Blue Coat, cez ktoré používatelia pristupovali na globálny WEB, pravidelne ukladali do vyrovnávacej pamäte statický obsah. Zachytávaním premávky bolo jasné, že pracujú nepretržite a donekonečna vyžadujú často používanú statiku na zrýchlenie zobrazovania obsahu počas špičiek. BlueCoat mal navyše špecifického User-Agenta, ktorý ho jasne odlišoval od skutočného používateľa.
Bol pripravený Javascript, ktorý sa pomocou Intercepter-NG implementoval hodinu v noci pre každú odpoveď so súbormi JS pre Blue Coat. Skript urobil nasledovné:
- Používateľský agent určil aktuálny prehliadač. Ak to bol Internet Explorer, Edge alebo Chrome, fungovalo to ďalej.
- Čakal som, kým sa vytvorí DOM stránky.
- Do DOM bol vložený neviditeľný obrázok s atribútom src formulára :8080/NNNNNNNN.png, kde NNN sú ľubovoľné čísla, aby ich BlueCoat neuložil do vyrovnávacej pamäte.
- Nastavte premennú globálneho príznaku na označenie, že injekcia bola dokončená a už nie je potrebné vkladať obrázky.
Prehliadač sa pokúsil načítať tento obrázok; na porte 8080 napadnutého servera naň čakal tunel TCP do môjho notebooku, kde bol spustený rovnaký Responder, ktorý vyžadoval, aby sa prehliadač prihlásil cez NTLM.
Súdiac podľa záznamov Responder, ľudia prišli ráno do práce, zapli svoje pracovné stanice, potom hromadne a nepozorovane začali navštevovať server urológa, pričom nezabudli „vyčerpať“ NTLM handshake. Podanie rúk pršalo celý deň a jasne sa nahromadil materiál na očividne úspešný útok na obnovenie hesiel. Takto vyzerali denníky odpovedača:
Hromadné tajné návštevy používateľov na serveri urológa
Pravdepodobne ste si už všimli, že celý tento príbeh je postavený na princípe „všetko bolo v poriadku, ale potom bol trapas, potom prišlo prekonanie a potom všetko prišlo k úspechu“. Takže tu bol trapas. Z päťdesiatich unikátnych podaní rúk nebol odhalený ani jeden. A to berie do úvahy skutočnosť, že aj na notebooku s mŕtvym procesorom sú tieto NTLMv2 handshake spracované rýchlosťou niekoľkých stoviek miliónov pokusov za sekundu.
Musel som sa vyzbrojiť technikami mutácie hesla, grafickou kartou, hrubším slovníkom a čakať. Po dlhšom čase bolo odhalených niekoľko účtov s heslami v tvare “Q11111111....1111111q”, čo naznačuje, že všetci používatelia boli kedysi nútení vymyslieť veľmi dlhé heslo s rôznymi veľkosťami písmen, čo malo tiež byť komplexný. Skúseného používateľa však nemôžete oklamať, a preto si ho ľahšie zapamätal. Celkovo bolo napadnutých asi 5 účtov a iba jeden z nich mal nejaké cenné práva na služby.
Časť 3. Roskomnadzor vracia úder
Takže boli prijaté prvé doménové účty. Ak ste pri tomto dlhom čítaní nezaspali, pravdepodobne si pamätáte, že som spomenul službu, ktorá nevyžadovala druhý faktor autentifikácie: je to wiki s autentifikáciou NTLM. Samozrejme, ako prvé bolo treba tam vstúpiť. Prehrabávanie sa v internej znalostnej báze rýchlo prinieslo výsledky:
- Spoločnosť disponuje WiFi sieťou s autentifikáciou pomocou doménových účtov s prístupom do lokálnej siete. Pri súčasnom súbore údajov je to už fungujúci vektor útoku, ale musíte ísť do kancelárie nohami a nachádzať sa niekde na území kancelárie zákazníka.
- Našiel som inštrukciu, podľa ktorej existovala služba, ktorá umožňovala... nezávisle zaregistrovať autentifikačné zariadenie „druhého faktora“, ak je používateľ v lokálnej sieti a s istotou si pamätá svoje doménové meno a heslo. V tomto prípade boli „vnútri“ a „vonku“ určené dostupnosťou portu tejto služby pre používateľa. Port nebol dostupný z internetu, ale bol celkom dostupný cez DMZ.
K napadnutému účtu sa samozrejme okamžite pridal „druhý faktor“ v podobe aplikácie v mojom telefóne. Existoval program, ktorý mohol buď nahlas odoslať do telefónu požiadavku push pomocou tlačidiel „schváliť“/„neschváliť“ akciu, alebo potichu zobraziť kód OTP na obrazovke pre ďalšie nezávislé zadávanie. Navyše prvá metóda mala byť podľa návodu jediná správna, no na rozdiel od metódy OTP nefungovala.
Po prerušení „druhého faktora“ som mal prístup k pošte Outlook Web Access a vzdialenému prístupu v Citrix Netscaler Gateway. V e-maile v programe Outlook bolo prekvapenie:
Na tomto vzácnom zábere môžete vidieť, ako Roskomnadzor pomáha pentestrom
Boli to prvé mesiace po slávnom „fanúšikovskom“ blokovaní Telegramu, keď celé siete s tisíckami adries neúprosne zmizli z prístupu. Okamžite sa ukázalo, prečo to pushovanie nefungovalo a prečo moja „obeť“ nezazvonila na poplach, pretože začali používať jej účet počas otváracích hodín.
Každý, kto pozná Citrix Netscaler, si predstavuje, že je zvyčajne implementovaný tak, že používateľovi je možné sprostredkovať iba obrazové rozhranie, snažiac sa neposkytnúť mu nástroje na spúšťanie aplikácií tretích strán a prenos údajov, čo obmedzuje všetky možné akcie. cez štandardné ovládacie škrupiny. Moja „obeť“ vďaka svojmu povolaniu dostala iba 1C:
Keď som trochu prešiel okolo rozhrania 1C, zistil som, že tam sú externé moduly spracovania. Môžu byť načítané z rozhrania a budú spustené na klientovi alebo serveri v závislosti od práv a nastavení.
Požiadal som svojich priateľov programátorov 1C, aby vytvorili spracovanie, ktoré by prijalo reťazec a vykonalo ho. V jazyku 1C vyzerá spustenie procesu asi takto (prevzaté z internetu). Súhlasíte s tým, že syntax jazyka 1C udivuje rusky hovoriacich ľudí svojou spontánnosťou?
Spracovanie bolo vykonané perfektne, ukázalo sa, že je to to, čo pentesteri nazývajú „shell“ - cez to bol spustený Internet Explorer.
Predtým bola v pošte nájdená adresa systému, ktorý vám umožňuje objednávať lístky na územie. Objednal som si priepustku pre prípad, že by som musel použiť vektor útoku WiFi.
Na internete sa hovorí, že v kancelárii zákazníka bol ešte chutný bezplatný catering, ale aj tak som radšej vyvíjal útok na diaľku, je to pokojnejšie.
AppLocker bol aktivovaný na aplikačnom serveri so systémom Citrix, ale bol obídený. Ten istý Meterpreter bol načítaný a spustený cez DNS, keďže http(s) verzie sa nechceli pripojiť a ja som vtedy ešte nevedel internú proxy adresu. Mimochodom, od tohto momentu sa vonkajší pentest v podstate úplne zmenil na vnútorný.
Časť 4. Práva správcu pre používateľov sú zlé, dobre?
Prvou úlohou pentestera pri získaní kontroly nad reláciou používateľa domény je zhromaždiť všetky informácie o právach v doméne. Existuje utilita BloodHound, ktorá vám automaticky umožňuje sťahovať informácie o používateľoch, počítačoch, bezpečnostných skupinách cez protokol LDAP z radiča domény a cez SMB - informácie o tom, ktorý používateľ sa nedávno prihlásil, kde a kto je lokálnym správcom.
Typická technika prevzatia práv správcu domény vyzerá zjednodušene ako cyklus monotónnych akcií:
- Ideme do doménových počítačov, kde sú lokálne administrátorské práva na základe už zachytených doménových účtov.
- Spúšťame Mimikatz a získavame heslá uložené vo vyrovnávacej pamäti, lístky Kerberos a NTLM hash doménových účtov, ktoré sa nedávno prihlásili do tohto systému. Alebo odstránime pamäťový obraz procesu lsass.exe a urobíme to isté na našej strane. Funguje to dobre so systémom Windows mladším ako 2012R2/Windows 8.1 s predvolenými nastaveniami.
- Určujeme, kde majú napadnuté účty práva lokálneho správcu. Opakujeme prvý bod. V určitej fáze získame administrátorské práva pre celú doménu.
„Koniec cyklu“, ako by tu napísali programátori 1C.
Náš používateľ sa teda ukázal ako lokálny správca iba na jednom hostiteľovi so systémom Windows 7, ktorého názov zahŕňal slovo „VDI“ alebo „Infraštruktúra virtuálnej plochy“, osobné virtuálne stroje. Dizajnér služby VDI pravdepodobne myslel, že keďže VDI je osobný operačný systém používateľa, aj keď používateľ zmení softvérové prostredie podľa vlastného uváženia, hostiteľ môže byť stále „znova načítaný“. Tiež som si myslel, že vo všeobecnosti bol nápad dobrý, išiel som za týmto osobným hostiteľom VDI a vytvoril som si tam hniezdo:
- Nainštaloval som tam klienta OpenVPN, ktorý vytvoril tunel cez internet na môj server. Klient musel byť nútený prejsť rovnakým Blue Coat s doménovou autentifikáciou, ale OpenVPN to urobil, ako sa hovorí, „po vybalení“.
- Nainštalované OpenSSH na VDI. No, naozaj, čo je Windows 7 bez SSH?
Takto to vyzeralo naživo. Dovoľte mi pripomenúť, že toto všetko sa musí uskutočniť prostredníctvom Citrix a 1C:
Jednou z techník na podporu prístupu k susedným počítačom je kontrola hesiel miestnych správcov, či sa zhodujú. Tu okamžite čakalo šťastie: NTLM hash predvoleného lokálneho administrátora (ktorý bol zrazu nazývaný Administrator) bol oslovený prostredníctvom pass-the-hash útoku na susedných VDI hostiteľov, ktorých bolo niekoľko stoviek. Útok ich samozrejme okamžite zasiahol.
Tu si správcovia VDI dvakrát strelili do nohy:
- Prvýkrát to bolo, keď stroje VDI neboli prevedené pod LAPS, v podstate si zachovali rovnaké heslo lokálneho správcu z obrazu, ktorý bol masívne nasadený na VDI.
- Predvolený správca je jediný lokálny účet, ktorý je zraniteľný voči útokom typu pass-the-hash. Aj s rovnakým heslom by bolo možné vyhnúť sa hromadnému kompromisu vytvorením druhého lokálneho administrátorského účtu so zložitým náhodným heslom a zablokovaním predvoleného.
Prečo služba SSH na tomto systéme Windows? Veľmi jednoduché: teraz server OpenSSH poskytuje nielen pohodlný interaktívny príkazový shell bez zasahovania do práce používateľa, ale aj proxy server socks5 na VDI. Prostredníctvom týchto ponožiek som sa pripojil cez SMB a zhromaždil účty uložené vo vyrovnávacej pamäti zo všetkých týchto stoviek strojov VDI a potom som hľadal cestu k správcovi domény pomocou nich v grafoch BloodHound. So stovkami hostiteľov, ktoré mám k dispozícii, som túto cestu našiel pomerne rýchlo. Boli získané práva správcu domény.
Tu je obrázok z internetu zobrazujúci podobné vyhľadávanie. Spojenia ukazujú, kto je kde je správca a kto je kde prihlásený.
Mimochodom, pamätajte na podmienku zo začiatku projektu - „nepoužívajte sociálne inžinierstvo“. Takže navrhujem zamyslieť sa nad tým, ako veľmi by bol celý tento Bollywood so špeciálnymi efektmi odrezaný, keby bolo stále možné používať banálny phishing. Ale pre mňa osobne bolo veľmi zaujímavé toto všetko robiť. Dúfam, že sa vám to páčilo. Samozrejme, nie každý projekt vyzerá tak pútavo, ale práca ako celok je veľmi náročná a nedovolí jej stagnovať.
Pravdepodobne niekto bude mať otázku: ako sa chrániť? Dokonca aj tento článok popisuje mnoho techník, z ktorých mnohí správcovia systému Windows ani nevedia. Navrhujem však pozrieť sa na ne z pohľadu otrepaných princípov a opatrení informačnej bezpečnosti:
- nepoužívajte zastaraný softvér (pamätáte si Windows 2003 na začiatku?)
- nenechávajte zapnuté nepotrebné systémy (prečo existovala stránka urológa?)
- skontrolujte si silu používateľov sami (inak to urobia vojaci... pentestri)
- nemať rovnaké heslá pre rôzne účty (kompromit VDI)
- a ďalšie
Samozrejme, je to veľmi náročné na realizáciu, no v ďalšom článku si v praxi ukážeme, že je to celkom možné.
Zdroj: hab.com