Ovaj je članak napisan na temelju vrlo uspješnog pentesta koji su stručnjaci Group-IB-a proveli prije nekoliko godina: dogodila se priča koja bi se mogla adaptirati za film u Bollywoodu. Sada će vjerojatno uslijediti reakcija čitatelja: “Ma, još jedan PR članak, opet se ovi prikazuju, kako su dobri, ne zaboravite kupiti pentest.” Pa, s jedne strane, jest. Međutim, postoji niz drugih razloga zašto se ovaj članak pojavio. Htio sam pokazati što točno rade pentesteri, koliko ovaj posao može biti zanimljiv i netrivijalan, koje se smiješne okolnosti mogu pojaviti u projektima, i što je najvažnije, prikazati materijal uživo sa stvarnim primjerima.
Kako bismo vratili ravnotežu skromnosti u svijetu, nakon nekog vremena pisat ćemo o pentestu koji nije dobro prošao. Pokazat ćemo kako dobro osmišljeni procesi u poduzeću mogu zaštititi od cijelog niza napada, čak i dobro pripremljenih, jednostavno zato što ti procesi postoje i stvarno funkcioniraju.
Za kupca u ovom članku također je sve bilo općenito izvrsno, barem bolje od 95% tržišta u Ruskoj Federaciji, prema našim osjećajima, ali postojao je niz malih nijansi koje su tvorile dugi lanac događaja, koji su prvi dovela je do dugog izvješća o radu, a zatim do ovog članka.
Dakle, opskrbimo se kokicama i dobrodošli u detektivsku priču. Riječ - Pavel Suprunjuk, tehnički voditelj odjela “Revizija i savjetovanje” Group-IB.
Dio 1. Pochkin liječnik
2018 Postoji kupac - visokotehnološka IT tvrtka, koja sama opslužuje mnoge klijente. Želi dobiti odgovor na pitanje: je li moguće, bez ikakvog početnog znanja i pristupa, radeći putem interneta, dobiti administratorska prava Active Directory domene? Ne zanima me nikakav društveni inženjering (), ne namjeravaju namjerno ometati rad, ali mogu slučajno - ponovno učitati poslužitelj koji čudno radi, na primjer. Dodatni cilj je identificirati što više drugih vektora napada protiv vanjskog perimetra. Tvrtka redovito provodi takva testiranja, a sada je stigao rok za novi test. Uvjeti su gotovo tipični, primjereni, razumljivi. Započnimo.
Postoji naziv kupca - neka bude "Tvrtka", s glavnom web stranicom . Naravno, kupac se zove drugačije, ali u ovom članku sve će biti bezlično.
Provodim mrežno izviđanje - saznajte koje su adrese i domene registrirane kod kupca, nacrtajte mrežni dijagram, kako se usluge distribuiraju na te adrese. Dobivam rezultat: više od 4000 živih IP adresa. Gledam domene u tim mrežama: srećom, velika većina su mreže namijenjene klijentima kupca i one nas formalno ne zanimaju. Kupac misli isto.
Ostaje jedna mreža s 256 adresa, za koju do ovog trenutka već postoji razumijevanje distribucije domena i poddomena po IP adresama, postoje informacije o skeniranim priključcima, što znači da možete pogledati usluge za zanimljive. Paralelno se pokreću sve vrste skenera na dostupnim IP adresama i zasebno na web stranicama.
Postoji puno usluga. Obično je to radost za pentester i iščekivanje brze pobjede, jer što je više servisa, to je veće polje za napad i lakše je pronaći artefakt. Letimičan pregled web stranica pokazao je da se većinom radi o web sučeljima poznatih proizvoda velikih svjetskih kompanija, koji po svemu sudeći govore da nisu dobrodošli. Traže korisničko ime i lozinku, protresu polje za upis drugog faktora, traže TLS klijentski certifikat ili ga pošalju Microsoft ADFS-u. Neki su jednostavno nedostupni s interneta. Za neke očito morate imati posebno plaćenog klijenta za tri plaće ili znati točan URL za ulazak. Preskočimo još jedan tjedan postupnog malodušja u procesu pokušaja "probijanja" verzija softvera za poznate ranjivosti, traženja skrivenog sadržaja u web stazama i procurjelih računa sa usluga trećih strana poput LinkedIna, pokušaja pogađanja lozinki pomoću njih, kao i kao iskopavanje ranjivosti u web stranicama koje smo sami napisali — usput, prema statistikama, ovo je vektor vanjskog napada koji danas najviše obećava. Odmah ću primijetiti filmski pištolj koji je naknadno opalio.
Dakle, pronašli smo dvije stranice koje su se izdvajale od stotina usluga. Ova su mjesta imala jednu zajedničku stvar: ako se ne bavite pedantnim mrežnim izviđanjem po domeni, nego direktno tražite otvorene portove ili ciljate skener ranjivosti koristeći poznati raspon IP-ova, tada će ta mjesta izbjeći skeniranje i jednostavno ih neće biti vidljiv bez poznavanja DNS imena. Možda su barem ranije propušteni, a naši automatski alati nisu pronašli nikakve probleme s njima, čak i ako su poslani izravno na resurs.
Usput, o tome što su prethodno pokrenuti skeneri općenito pronašli. Dopustite da vas podsjetim: za neke ljude, "pentest" je ekvivalentan "automatskom skeniranju". Ali skeneri na ovom projektu nisu rekli ništa. Pa, najviše su pokazale srednje ranjivosti (3 od 5 u smislu ozbiljnosti): na nekim uslugama loš TLS certifikat ili zastarjeli algoritmi enkripcije, a na većini stranica Clickjacking. Ali to vas neće dovesti do vašeg cilja. Možda bi skeneri ovdje bili korisniji, ali da vas podsjetim: kupac sam može kupiti takve programe i testirati se s njima, a sudeći po lošim rezultatima, već je provjerio.
Vratimo se na “anomalna” mjesta. Prvi je nešto poput lokalnog Wikija na nestandardnoj adresi, ali u ovom članku neka bude wiki.company[.]ru. Također je odmah tražila prijavu i lozinku, ali kroz NTLM u pregledniku. Za korisnika ovo izgleda kao asketski prozor koji traži unos korisničkog imena i lozinke. A ovo je loša praksa.
Mala napomena. NTLM na perimetralnim web stranicama je loš iz više razloga. Prvi razlog je otkrivanje naziva domene Active Directory. U našem primjeru također se pokazalo da je company.ru, baš kao i "vanjski" DNS naziv. Znajući to, možete pažljivo pripremiti nešto zlonamjerno tako da se izvrši samo na stroju domene organizacije, a ne u nekom sandboxu. Drugo, provjera autentičnosti ide izravno kroz kontroler domene putem NTLM-a (iznenađenje, zar ne?), sa svim značajkama "internih" mrežnih pravila, uključujući blokiranje računa od prekoračenja broja pokušaja unosa lozinke. Ako napadač otkrije prijave, pokušat će unijeti zaporke za njih. Ako ste konfigurirani da blokirate račune od unosa netočnih zaporki, to će raditi i račun će biti blokiran. Treće, nemoguće je takvoj autentifikaciji dodati drugi faktor. Ako netko od čitatelja još uvijek zna kako, neka mi javi, stvarno je zanimljivo. Četvrto, ranjivost na pass-the-hash napade. ADFS je izmišljen, između ostalog, za zaštitu od svega toga.
Postoji jedno loše svojstvo Microsoftovih proizvoda: čak i ako niste posebno objavili takav NTLM, on će biti instaliran prema zadanim postavkama u OWA i Lync, najmanje.
Inače, autor ovog članka jednom je slučajno istom metodom u samo sat vremena blokirao oko 1000 računa zaposlenika jedne velike banke i tada izgledao nekako blijedo. Blijede su bile i informatičke službe banke, no sve je završilo dobro i primjereno, čak smo dobili pohvale da smo prvi pronašli ovaj problem i isprovocirali brzo i odlučno rješenje.
Druga stranica imala je adresu "očito nekakvo prezime.company.ru." Pronašao preko Googlea, ovako nešto na stranici 10. Dizajn je bio s početka-sredine XNUMX-ih, a ugledna osoba ga je gledala s glavne stranice, otprilike ovako:
Ovdje sam uzeo kadar iz “Pasjeg srca”, ali vjerujte mi, bio je neodređeno sličan, čak je i dizajn boja bio u sličnim tonovima. Neka se stranica zove preobrazhensky.company.ru.
Bila je to osobna web stranica... za urologa. Pitao sam se što web stranica urologa radi na poddomeni visokotehnološke tvrtke. Brzo kopanje po Googleu pokazalo je da je ovaj liječnik bio suosnivač jednog od pravnih subjekata našeg klijenta i da je čak uložio oko 1000 rubalja u temeljni kapital. Stranica je vjerojatno napravljena prije mnogo godina, a resursi poslužitelja korisnika korišteni su kao hosting. Stranica je odavno izgubila relevantnost, ali je iz nekog razloga dugo ostala raditi.
Što se tiče ranjivosti, sama je web stranica bila sigurna. Gledajući unaprijed, reći ću da je to bio skup statičnih informacija - jednostavnih html stranica s umetnutim ilustracijama u obliku bubrega i mjehura. Beskorisno je "slomiti" takvu stranicu.
Ali web poslužitelj ispod bio je zanimljiviji. Sudeći prema zaglavlju HTTP Servera, imao je IIS 6.0, što znači da je koristio Windows 2003 kao operativni sustav. Skener je prethodno identificirao da je ova web stranica urologa, za razliku od drugih virtualnih hostova na istom web poslužitelju, odgovorila na naredbu PROPFIND, što znači da je pokrenula WebDAV. Usput, skener je tu informaciju vratio s oznakom Info (u jeziku izvješća skenera, to je najmanja opasnost) - takve stvari se obično jednostavno preskoče. U kombinaciji, to je dalo zanimljiv učinak, koji je otkriven tek nakon još jednog kopanja na Googleu: rijetka ranjivost prekoračenja međuspremnika povezana sa setom Shadow Brokers, točnije CVE-2017-7269, koji je već imao gotov exploit. Drugim riječima, bit će problema ako imate Windows 2003 i WebDAV radi na IIS-u. Iako je pokretanje Windowsa 2003 u proizvodnji u 2018. samo po sebi problem.
Eksploatacija je završila u Metasploitu i odmah je testirana s opterećenjem koje šalje DNS zahtjev kontroliranom servisu - Burp Collaborator se tradicionalno koristi za hvatanje DNS zahtjeva. Na moje iznenađenje, uspjelo je prvi put: primljen je DNS knockout. Sljedeći je bio pokušaj stvaranja povratne veze preko porta 80 (odnosno mrežne veze od poslužitelja do napadača, s pristupom cmd.exe na hostu žrtve), ali tada se dogodio fijasko. Veza nije uspjela, a nakon trećeg pokušaja korištenja stranica je zajedno sa svim zanimljivim slikama nestala zauvijek.
Obično nakon toga slijedi pismo u stilu “kupče, probudi se, sve smo ispustili”. No rečeno nam je da stranica nema nikakve veze s poslovnim procesima i radi bez ikakvog razloga, kao i cijeli server, te da mi možemo koristiti taj resurs kako hoćemo.
Otprilike dan kasnije stranica je odjednom počela raditi sama od sebe. Nakon što sam napravio bench iz WebDAV-a na IIS 6.0, otkrio sam da je zadana postavka ponovno pokretanje IIS radnih procesa svakih 30 sati. To jest, kada je kontrola izašla iz shellcodea, radni proces IIS-a je završio, zatim se sam ponovno pokrenuo nekoliko puta i zatim otišao u mirovanje na 30 sati.
Budući da povratna veza s tcp-om nije uspjela prvi put, pripisao sam ovaj problem zatvorenom portu. To jest, pretpostavio je prisutnost neke vrste vatrozida koji nije dopuštao odlaznim vezama da prođu van. Počeo sam pokretati shellcodeove koji su pretraživali mnoge tcp i udp portove, nije bilo efekta. Učitavanja obrnute veze putem http(s) iz Metasploita nisu radila - meterpreter/reverse_http(s). Odjednom je uspostavljena veza s istim portom 80, ali je odmah prekinuta. To sam pripisao djelovanju još imaginarnog IPS-a, kojem se nije svidio meterpreter promet. U svjetlu činjenice da čista tcp veza na port 80 nije prošla, ali http veza jest, zaključio sam da je http proxy nekako konfiguriran u sustavu.
Čak sam probao meterpreter putem DNS-a (hvala za vaš trud, spasio mnoge projekte), prisjećajući se prvog uspjeha, ali nije funkcionirao ni na postolju - shellcode je bio previše obiman za ovu ranjivost.
U stvarnosti je to izgledalo ovako: 3-4 pokušaja napada unutar 5 minuta, pa čekanje 30 sati. I tako tri tjedna zaredom. Čak sam postavio i podsjetnik da ne gubim vrijeme. Osim toga, postojala je razlika u ponašanju testnog i proizvodnog okruženja: za ovu ranjivost postojala su dva slična exploita, jedan s Metasploita, drugi s interneta, pretvoren iz verzije Shadow Brokers. Dakle, samo je Metasploit testiran u borbi, a tek drugi je testiran na klupi, što je dodatno otežavalo otklanjanje pogrešaka i razbijalo mozak.
Na kraju se učinkovitim pokazao shellcode koji je preuzeo exe datoteku s određenog poslužitelja putem http-a i pokrenuo je na ciljnom sustavu. Shellcode je bio dovoljno malen da stane, ali barem je radio. Budući da se poslužitelju uopće nije sviđao TCP promet i http(s) je pregledan radi prisutnosti meterpreter-a, odlučio sam da je najbrži način da preuzmem exe datoteku koja je sadržavala DNS-meterpreter kroz ovaj shellcode.
Ovdje se opet pojavio problem: prilikom preuzimanja exe datoteke i, kako su pokušaji pokazali, bez obzira na koju, preuzimanje je prekinuto. Opet, neki sigurnosni uređaj između mog poslužitelja i urologa nije volio http promet s exe-om unutra. Činilo se da je "brzo" rješenje promijeniti shellcode tako da zamagljuje http promet u hodu, tako da bi se apstraktni binarni podaci prenosili umjesto exe. Konačno, napad je bio uspješan, kontrola je primljena kroz tanki DNS kanal:
Odmah je postalo jasno da imam najosnovnija IIS radna prava, koja mi dopuštaju da ne radim ništa. Ovako je to izgledalo na Metasploit konzoli:
Sve pentest metodologije snažno sugeriraju da morate povećati prava prilikom dobivanja pristupa. Obično to ne radim lokalno, budući da se prvi pristup vidi jednostavno kao mrežna ulazna točka, a kompromitiranje drugog stroja na istoj mreži obično je lakše i brže od eskalacije privilegija na postojećem računalu. Ali ovdje to nije slučaj, jer je DNS kanal vrlo uzak i neće dopustiti da se promet očisti.
Pod pretpostavkom da ovaj Windows 2003 poslužitelj nije popravljen za poznatu ranjivost MS17-010, tuneliram promet na port 445/TCP kroz meterpreter DNS tunel na lokalnom hostu (da, to je također moguće) i pokušavam pokrenuti prethodno preuzeti exe kroz ranjivost. Napad radi, primam drugu vezu, ali sa SYSTEM pravima.
Zanimljivo je da su poslužitelj ipak pokušali zaštititi od MS17-010 - imao je onemogućene ranjive mrežne usluge na vanjskom sučelju. Ovo doista štiti od napada preko mreže, ali napad iznutra na localhost je uspio, budući da ne možete jednostavno brzo isključiti SMB na localhost.
Zatim se otkrivaju novi zanimljivi detalji:
- Imajući SYSTEM prava, možete jednostavno uspostaviti povratnu vezu putem TCP-a. Očito je da je onemogućavanje izravnog TCP-a problem isključivo za ograničene korisnike IIS-a. Spoiler: korisnički promet IIS-a bio je nekako umotan u lokalni ISA proxy u oba smjera. Kako točno radi, nisam reproducirao.
- Nalazim se u određenom "DMZ" (a ovo nije domena Active Directory, već RADNA GRUPA) - zvuči logično. Ali umjesto očekivane privatne ("sive") IP adrese, imam potpuno "bijelu" IP adresu, potpuno istu kao ona koju sam ranije napao. To znači da je tvrtka toliko stara u svijetu IPv4 adresiranja da si može priuštiti održavanje DMZ zone za 128 "bijelih" adresa bez NAT-a prema shemi, kako je prikazano u Ciscovim priručnicima iz 2005. godine.
Budući da je poslužitelj star, Mimikatz zajamčeno radi izravno iz memorije:
Dobivam lozinku lokalnog administratora, tuneliram RDP promet preko TCP-a i prijavljujem se na ugodnu radnu površinu. Kako sam sa serverom mogao raditi što god sam htio, maknuo sam antivirus i ustanovio da je server dostupan s interneta samo preko TCP portova 80 i 443, a 443 nije bio zauzet. Postavio sam OpenVPN poslužitelj na 443, dodao NAT funkcije za svoj VPN promet i dobio izravan pristup DMZ mreži u neograničenom obliku putem svog OpenVPN-a. Važno je napomenuti da je ISA, s nekim neonemogućenim IPS funkcijama, blokirao moj promet skeniranjem portova, za što ga je morao zamijeniti jednostavnijim i kompatibilnijim RRAS-om. Dakle, pentesteri ponekad ipak moraju upravljati raznim stvarima.
Pažljivi čitatelj će pitati: "Što je s drugim mjestom - wikijem s NTLM autentifikacijom, o kojem je toliko napisano?" Više o ovome kasnije.
Dio 2. Još uvijek ne šifrirate? Onda dolazimo k vama već ovdje
Dakle, postoji pristup segmentu DMZ mreže. Morate otići do administratora domene. Prvo što pada na pamet je automatska provjera sigurnosti servisa unutar DMZ segmenta, tim više što ih je sada mnogo više otvoreno za istraživanje. Tipična slika tijekom testa penetracije: vanjski perimetar je bolje zaštićen od internih servisa, a kada se dobije bilo kakav pristup unutar velike infrastrukture, puno je lakše dobiti proširena prava u domeni samo zbog činjenice da ta domena počinje biti dostupan alatima, i drugo, u infrastrukturi s nekoliko tisuća hostova uvijek će postojati nekoliko kritičnih problema.
Punim skenere preko DMZ-a preko OpenVPN tunela i čekam. Otvaram izvješće - opet ništa ozbiljno, očito je netko prije mene prošao istu metodu. Sljedeći korak je ispitati kako hostovi unutar DMZ mreže komuniciraju. Da biste to učinili, prvo pokrenite uobičajeni Wireshark i osluškujte zahtjeve za emitiranje, prvenstveno ARP. ARP paketi su prikupljani cijeli dan. Ispada da se u ovom segmentu koristi nekoliko pristupnika. Ovo će vam kasnije dobro doći. Kombinirajući podatke o ARP zahtjevima-odgovorima i podatke skeniranja portova, pronašao sam izlazne točke korisničkog prometa unutar lokalne mreže uz one servise koji su ranije bili poznati, kao što su web i pošta.
Budući da trenutno nisam imao pristup drugim sustavima i niti jedan račun za korporativne usluge, odlučeno je da iz prometa izvučem barem neki račun koristeći ARP Spoofing.
Cain&Abel je pokrenut na serveru urologa. Uzimajući u obzir identificirane tokove prometa, odabrani su najperspektivniji parovi za napad čovjek-u-sredini, a zatim je dio mrežnog prometa primljen kratkotrajnim pokretanjem u trajanju od 5-10 minuta, s timerom za ponovno pokretanje poslužitelja u slučaju smrzavanja. Kao u vicu, bile su dvije novosti:
- Dobro: uhvaćeno je puno vjerodajnica i napad je u cjelini uspio.
- Loše: sve vjerodajnice bile su od klijentovih vlastitih klijenata. Tijekom pružanja usluga podrške, stručnjaci za korisnike spajali su se na usluge klijenata koji nisu uvijek imali konfiguriranu enkripciju prometa.
Kao rezultat toga, stekao sam puno vjerodajnica koje su bile beskorisne u kontekstu projekta, ali svakako zanimljive kao demonstracija opasnosti od napada. Granični routeri velikih tvrtki s telnetom, proslijeđenim debug http portovima u interni CRM sa svim podacima, direktnim pristupom RDP-u iz Windows XP-a na lokalnoj mreži i ostalom mračnjaštvu. Ispalo je ovako .
Našao sam i smiješnu priliku za skupljanje pisama iz prometa, otprilike ovako. Ovo je primjer gotovog pisma koje je naš kupac otišao na SMTP port njegovog klijenta, opet, bez enkripcije. Izvjesni Andrey zamoli svog imenjaka da ponovno pošalje dokumentaciju, a ona biva postavljena na cloud disk s prijavom, lozinkom i linkom u jednom odgovoru:
Ovo je još jedan podsjetnik za šifriranje svih usluga. Nepoznato je tko će i kada konkretno čitati i koristiti vaše podatke - pružatelj, sistemski administrator druge tvrtke ili takav pentester. Šutim o tome da mnogi ljudi mogu jednostavno presresti nekriptirani promet.
Unatoč vidljivom uspjehu, to nas nije približilo cilju. Bilo je moguće, naravno, dugo sjediti i loviti vrijedne informacije, ali nije činjenica da će se tamo pojaviti, a sam napad je vrlo rizičan u smislu integriteta mreže.
Nakon još jednog kopanja po uslugama, pala mi je na pamet zanimljiva ideja. Postoji takav uslužni program koji se zove Responder (lako je pronaći primjere korištenja pod tim imenom), koji "trovanjem" zahtjeva za emitiranjem provocira veze preko raznih protokola kao što su SMB, HTTP, LDAP itd. na različite načine, zatim traži autentifikaciju od svih koji se spajaju i postavlja ga tako da se autentifikacija odvija preko NTLM-a iu načinu transparentnom za žrtvu. Najčešće napadač na ovaj način skuplja NetNTLMv2 rukovanja i iz njih pomoću rječnika brzo vraća korisničke lozinke domene. Ovdje sam htio nešto slično, ali su korisnici sjedili “iza zida”, točnije, bili su odvojeni vatrozidom i pristupali WEB-u preko Blue Coat proxy klastera.
Zapamtite, naveo sam da se ime domene Active Directory podudara s "vanjskom" domenom, odnosno da je to company.ru? Dakle, Windowsi, točnije Internet Explorer (te Edge i Chrome), omogućuju korisniku transparentnu autentifikaciju u HTTP-u preko NTLM-a ako smatraju da se stranica nalazi u nekoj “Intranet zoni”. Jedan od znakova “Intraneta” je pristup “sivoj” IP adresi ili kratkom DNS imenu, odnosno bez točkica. Budući da su imali poslužitelj s "bijelim" IP i DNS nazivom preobrazhensky.company.ru, a strojevi s domenom obično primaju sufiks domene Active Directory putem DHCP-a za pojednostavljeni unos imena, morali su samo napisati URL u adresnu traku , kako bi pronašli pravi put do servera kompromitiranog urologa, ne zaboravljajući da se to sada zove "Intranet". To jest, u isto vrijeme mi daje korisnikovo NTLM rukovanje bez njegovog znanja. Sve što ostaje je prisiliti klijentske preglednike da razmišljaju o hitnoj potrebi kontaktiranja ovog poslužitelja.
Prekrasan uslužni program Intercepter-NG priskočio je u pomoć (hvala ). Omogućavao vam je promjenu prometa u hodu i odlično je radio na Windowsima 2003. Čak je imao i zasebnu funkciju za izmjenu samo JavaScript datoteka u tijeku prometa. Planirana je vrsta masivnog Cross-Site skriptiranja.
Blue Coat proxiji, preko kojih su korisnici pristupali globalnom WEB-u, povremeno su spremali statični sadržaj u predmemoriju. Po presretanju prometa bilo je jasno da rade danonoćno, tražeći u nedogled često korištenu statiku kako bi se ubrzao prikaz sadržaja u vršnim satima. Osim toga, BlueCoat je imao specifičnog korisničkog agenta, koji ga je jasno razlikovao od pravog korisnika.
Pripremljen je Javascript koji je pomoću Intercepter-NG implementiran sat vremena noću za svaki odgovor s JS datotekama za Blue Coat. Skripta je učinila sljedeće:
- Odredio je trenutni preglednik pomoću korisničkog agenta. Ako je bio Internet Explorer, Edge ili Chrome, nastavio je raditi.
- Čekao sam da se DOM stranice formira.
- Umetnuta je nevidljiva slika u DOM s atributom src obrasca :8080/NNNNNNN.png, gdje su NNN proizvoljni brojevi tako da ih BlueCoat ne sprema u predmemoriju.
- Postavite varijablu globalne zastave koja označava da je ubrizgavanje dovršeno i da više nema potrebe za umetanjem slika.
Preglednik je pokušao učitati ovu sliku; na portu 8080 kompromitiranog poslužitelja čekao ju je TCP tunel do mog prijenosnog računala, gdje je bio pokrenut isti Responder, zahtijevajući da se preglednik prijavi putem NTLM-a.
Sudeći prema zapisima Respondera, ljudi su ujutro dolazili na posao, uključivali svoje radne stanice, a zatim su masovno i neprimjetno počeli posjećivati server urologa, ne zaboravljajući "isprazniti" NTLM rukovanje. Rukovanje je pljuštalo cijeli dan i očito je nakupljeno materijala za očito uspješan napad za vraćanje lozinki. Ovako su izgledali zapisnici Respondera:
Masovni tajni posjeti serveru urologa od strane korisnika
Vjerojatno ste već primijetili da se cijela ova priča gradi na principu “sve je bilo u redu, ali onda je došlo do kvara, zatim je došlo do prevladavanja, a onda je sve došlo do uspjeha”. Dakle, ovdje je bio problem. Od pedeset jedinstvenih rukovanja, niti jedno nije otkriveno. A to uzima u obzir činjenicu da se čak i na prijenosnom računalu s mrtvim procesorom ova NTLMv2 rukovanja obrađuju brzinom od nekoliko stotina milijuna pokušaja u sekundi.
Morao sam se naoružati tehnikama mutacije lozinki, video karticom, podebljim rječnikom i čekati. Nakon dugo vremena otkriveno je nekoliko računa s lozinkama oblika “Q11111111....1111111q”, što sugerira da su svi korisnici nekada bili prisiljeni smisliti vrlo dugu lozinku s različitim malim slovima, koja je također trebala biti složen. Ali iskusnog korisnika ne možete prevariti, a ovako si je olakšao pamćenje. Ukupno je kompromitirano oko 5 računa, a samo je jedan od njih imao vrijedna prava na usluge.
Dio 3. Roskomnadzor uzvraća udarac
Tako su primljeni prvi domenski računi. Ako do ovog trenutka niste zaspali od dugog čitanja, vjerojatno ćete se sjetiti da sam spomenuo uslugu koja nije zahtijevala drugi faktor autentifikacije: to je wiki s NTLM autentifikacijom. Naravno, prvo je trebalo ući tamo. Kopanje po internoj bazi znanja brzo je donijelo rezultate:
- Tvrtka ima WiFi mrežu s autentifikacijom pomoću domenskih računa s pristupom lokalnoj mreži. S trenutnim skupom podataka, ovo je već radni vektor napada, ali morate ići u ured svojim nogama i nalaziti se negdje na teritoriju ureda kupca.
- Pronašao sam uputu prema kojoj je postojala usluga koja je dopuštala... samostalno registrirati uređaj za autentifikaciju "drugog faktora" ako se korisnik nalazi unutar lokalne mreže i pouzdano se sjeća prijave i lozinke svoje domene. U ovom slučaju, "unutra" i "vani" određeni su dostupnošću porta ove usluge korisniku. Priključak nije bio dostupan s interneta, ali je bio prilično dostupan kroz DMZ.
Naravno, na kompromitirani račun odmah je dodan i “drugi faktor” u obliku aplikacije na mom telefonu. Postojao je program koji je mogao ili glasno poslati push zahtjev na telefon s tipkama "odobri"/"ne odobri" za radnju ili tiho prikazati OTP kod na zaslonu za daljnji neovisni unos. Štoviše, prva metoda je prema uputama trebala biti jedina ispravna, ali nije uspjela, za razliku od OTP metode.
S pokvarenim "drugim faktorom", mogao sam pristupiti Outlook Web Access pošti i daljinskom pristupu u Citrix Netscaler Gatewayu. Bilo je iznenađenje u pošti u programu Outlook:
U ovoj rijetkoj snimci možete vidjeti kako Roskomnadzor pomaže pentesterima
Bili su to prvi mjeseci nakon famozne “navijačke” blokade Telegrama, kada su čitave mreže s tisućama adresa neumitno nestale iz pristupa. Postalo je jasno zašto push nije uspio odmah i zašto moja "žrtva" nije oglasila alarm jer su njezin račun počeli koristiti tijekom radnog vremena.
Svatko tko je upoznat s Citrix Netscaler zamišlja da je obično implementiran na takav način da se korisniku može prenijeti samo slikovno sučelje, pokušavajući mu ne dati alate za pokretanje aplikacija trećih strana i prijenos podataka, ograničavajući radnje na sve moguće načine kroz standardne kontrolne ljuske. Moja “žrtva” je zbog svog zanimanja dobila samo 1C:
Nakon što sam malo prošetao 1C sučeljem, otkrio sam da tamo postoje vanjski moduli za obradu. Mogu se učitati iz sučelja, a izvršit će se na klijentu ili poslužitelju, ovisno o pravima i postavkama.
Zamolio sam svoje prijatelje 1C programere da kreiraju obradu koja bi prihvatila niz i izvršila ga. U jeziku 1C, pokretanje procesa izgleda otprilike ovako (preuzeto s interneta). Slažete li se da sintaksa jezika 1C zadivljuje ljude koji govore ruski svojom spontanošću?
Obrada je izvršena savršeno, pokazalo se da je to ono što pentesteri zovu "ljuska" - Internet Explorer je pokrenut kroz njega.
Ranije je u pošti pronađena adresa sustava koji vam omogućuje naručivanje propusnica za teritorij. Naručio sam propusnicu u slučaju da moram upotrijebiti vektor napada WiFi.
Na internetu se priča da je još uvijek bilo ukusnog besplatnog cateringa u uredu kupaca, ali ipak sam radije razvio napad na daljinu, mirnije je.
AppLocker je bio aktiviran na aplikacijskom poslužitelju koji pokreće Citrix, ali je zaobiđen. Isti Meterpreter je učitan i pokrenut preko DNS-a, budući da se http(s) verzije nisu htjele spojiti, a ja tada nisam znao internu proxy adresu. Usput, od ovog trenutka vanjski pentest se u biti potpuno pretvorio u unutarnji.
Dio 4. Administratorska prava za korisnike su loša, u redu?
Prvi zadatak pentestera prilikom preuzimanja kontrole nad korisničkom sesijom domene je prikupljanje svih informacija o pravima u domeni. Postoji uslužni program BloodHound koji automatski omogućuje preuzimanje informacija o korisnicima, računalima, sigurnosnim grupama putem LDAP protokola s kontrolera domene, a putem SMB-a - informacije o tome koji se korisnik gdje nedavno prijavio i tko je lokalni administrator.
Tipična tehnika za oduzimanje administratorskih prava domene izgleda pojednostavljeno kao ciklus monotonih radnji:
- Idemo na domenska računala gdje postoje lokalna administratorska prava, na temelju već snimljenih domenskih računa.
- Pokrećemo Mimikatz i dobivamo predmemorirane lozinke, Kerberos ulaznice i NTLM hash račune domene koji su se nedavno prijavili na ovaj sustav. Ili uklanjamo memorijsku sliku procesa lsass.exe i činimo isto s naše strane. Ovo dobro funkcionira sa sustavom Windows mlađim od 2012R2/Windows 8.1 sa zadanim postavkama.
- Određujemo gdje ugroženi računi imaju lokalna administratorska prava. Ponavljamo prvu točku. U nekoj fazi dobivamo administratorska prava za cijelu domenu.
“Kraj ciklusa;”, kako bi ovdje napisali 1C programeri.
Dakle, ispostavilo se da je naš korisnik lokalni administrator na samo jednom hostu sa sustavom Windows 7, čije je ime uključivalo riječ “VDI”, ili “Virtual Desktop Infrastructure”, osobni virtualni strojevi. Vjerojatno je dizajner VDI usluge mislio da budući da je VDI korisnikov osobni operacijski sustav, čak i ako korisnik promijeni softversko okruženje kako želi, host se još uvijek može "ponovno učitati". Također sam mislio da je općenito ideja dobra, otišao sam do ovog osobnog VDI hosta i napravio gnijezdo tamo:
- Tamo sam instalirao OpenVPN klijent koji je napravio tunel kroz internet do mog servera. Klijent je morao biti prisiljen proći kroz isti Blue Coat s autentifikacijom domene, ali OpenVPN je to učinio, kako kažu, "iz kutije".
- Instaliran OpenSSH na VDI. Pa, stvarno, što je Windows 7 bez SSH?
Ovako je to izgledalo uživo. Podsjetit ću vas da sve ovo morate učiniti kroz Citrix i 1C:
Jedna tehnika za promicanje pristupa susjednim računalima je provjera podudarnosti lozinki lokalnog administratora. Ovdje je odmah čekala sreća: NTLM hash zadanog lokalnog administratora (koji je iznenada nazvan Administrator) pristupljen je putem pass-the-hash napada susjednim VDI hostovima, kojih je bilo nekoliko stotina. Naravno, napad ih je odmah pogodio.
Ovdje su si VDI administratori dvaput pucali u nogu:
- Prvi put je to bilo kada VDI strojevi nisu stavljeni pod LAPS, u biti su zadržali istu lozinku lokalnog administratora iz slike koja je bila masovno postavljena na VDI.
- Zadani administrator je jedini lokalni račun koji je ranjiv na napade prijenosa raspršivanja. Čak i s istom lozinkom, bilo bi moguće izbjeći masovni kompromis stvaranjem drugog lokalnog administratorskog računa sa složenom nasumičnom lozinkom i blokiranjem zadane.
Zašto postoji SSH usluga na tom Windowsu? Vrlo jednostavno: sada OpenSSH poslužitelj ne samo da pruža prikladnu interaktivnu naredbenu ljusku bez ometanja rada korisnika, već i socks5 proxy na VDI. Preko ove čarape povezao sam se putem SMB-a i prikupio predmemorirane račune sa svih tih stotina VDI strojeva, a zatim potražio put do administratora domene koristeći ih u BloodHound grafovima. Sa stotinama hostova koji su mi bili na raspolaganju, vrlo brzo sam pronašao ovaj način. Dobivena su administratorska prava domene.
Evo slike s interneta koja prikazuje sličnu pretragu. Veze pokazuju tko je gdje administrator i tko je gdje prijavljen.
Usput, zapamtite uvjet s početka projekta - "nemojte koristiti društveni inženjering." Dakle, predlažem razmisliti o tome koliko bi sav taj Bollywood sa specijalnim efektima bio odsječen da je još uvijek moguće koristiti banalni phishing. Ali osobno mi je bilo jako zanimljivo sve ovo raditi. Nadam se da ste uživali čitajući ovo. Naravno, ne izgleda svaki projekt tako intrigantno, ali posao u cjelini je vrlo izazovan i ne dopušta da stagnira.
Vjerojatno će netko imati pitanje: kako se zaštititi? Čak i ovaj članak opisuje mnoge tehnike, za mnoge od kojih Windows administratori niti ne znaju. Međutim, predlažem da ih pogledate iz perspektive otrcanih načela i mjera informacijske sigurnosti:
- nemojte koristiti zastarjeli softver (sjećate se Windows 2003 na početku?)
- nemojte držati uključene nepotrebne sustave (zašto je postojala web stranica urologa?)
- sami provjerite snagu korisničkih lozinki (inače će to učiniti vojnici... pentesteri)
- nemaju iste lozinke za različite račune (VDI kompromis)
- i druge
Naravno, to je jako teško izvedivo, ali u sljedećem ćemo članku u praksi pokazati da je itekako moguće.
Izvor: www.habr.com