Një herë e një pentest, ose Si të thyejmë gjithçka me ndihmën e një urologu dhe Roskomnadzor

Ky artikull u shkrua bazuar në një pentest shumë të suksesshëm që specialistët e Group-IB zhvilluan disa vjet më parë: ndodhi një histori që mund të përshtatej për film në Bollywood. Tani, me siguri, do të pasojë reagimi i lexuesit: "Oh, një artikull tjetër PR, përsëri po portretizohen këto, sa të mira janë, mos harroni të blini një pentest." Epo, nga njëra anë, është. Megjithatë, ka një sërë arsyesh të tjera pse u shfaq ky artikull. Doja të tregoja se çfarë bëjnë saktësisht pentestuesit, sa interesante dhe jo e parëndësishme mund të jetë kjo punë, çfarë rrethanash qesharake mund të lindin në projekte dhe më e rëndësishmja, të tregoja materiale të drejtpërdrejta me shembuj realë.

Për të rivendosur ekuilibrin e modestisë në botë, pas pak do të shkruajmë për një pentest që nuk shkoi mirë. Ne do të tregojmë se si proceset e dizajnuara mirë në një kompani mund të mbrojnë kundër një sërë sulmesh, madje edhe të përgatitura mirë, thjesht sepse këto procese ekzistojnë dhe funksionojnë në të vërtetë.

Për klientin në këtë artikull, gjithçka ishte gjithashtu përgjithësisht e shkëlqyer, të paktën më mirë se 95% e tregut në Federatën Ruse, sipas ndjenjave tona, por kishte një sërë nuancash të vogla që formuan një zinxhir të gjatë ngjarjesh, të cilat së pari çoi në një raport të gjatë mbi punën, dhe më pas në këtë artikull.

Pra, le të grumbullojmë kokoshka dhe mirë se vini në historinë e detektivëve. fjalë - Pavel Suprunyuk, drejtues teknik i departamentit “Auditim dhe Konsulencë” të Group-IB.

Pjesa 1. Mjeku Pochkin

2018 Ekziston një klient - një kompani e teknologjisë së lartë IT, e cila vetë u shërben shumë klientëve. Dëshiron të marrë një përgjigje për pyetjen: a është e mundur, pa njohuri dhe qasje fillestare, duke punuar përmes Internetit, për të marrë të drejtat e administratorit të domenit të Active Directory? Unë nuk jam i interesuar për ndonjë inxhinieri sociale (oh, por më kot), ata nuk kanë ndërmend të ndërhyjnë me qëllim në punë, por mund të ringarkojnë aksidentalisht një server që funksionon çuditërisht, për shembull. Një qëllim shtesë është të identifikohen sa më shumë vektorë të tjerë sulmi që të jetë e mundur kundër perimetrit të jashtëm. Kompania kryen rregullisht teste të tilla dhe tani ka ardhur afati për një test të ri. Kushtet janë pothuajse tipike, adekuate, të kuptueshme. Le të fillojmë.

Ekziston një emër i klientit - le të jetë "Kompania", me faqen kryesore të internetit www.company.ru. Sigurisht, klienti quhet ndryshe, por në këtë artikull gjithçka do të jetë jopersonale.
Unë kryej zbulimin e rrjetit - zbuloni se cilat adresa dhe domene janë të regjistruara me klientin, vizatoni një diagram rrjeti, si shpërndahen shërbimet në këto adresa. Unë marr rezultatin: më shumë se 4000 adresa IP të drejtpërdrejta. Unë shikoj domenet në këto rrjete: për fat të mirë, shumica dërrmuese janë rrjete të destinuara për klientët e klientit dhe ne nuk jemi të interesuar zyrtarisht për to. Klienti mendon të njëjtën gjë.

Mbetet një rrjet me 256 adresa, për të cilin në këtë moment tashmë ka një kuptim të shpërndarjes së domeneve dhe nëndomaineve sipas adresave IP, ka informacione për portet e skanuara, që do të thotë se mund të shikoni shërbimet për ato interesante. Paralelisht, të gjitha llojet e skanerëve lëshohen në adresat IP të disponueshme dhe veçmas në faqet e internetit.

Ka shumë shërbime. Zakonisht ky është gëzim për pentesterin dhe pritje e një fitoreje të shpejtë, pasi sa më shumë shërbime të ketë, aq më e madhe është fusha për sulm dhe aq më e lehtë është gjetja e një objekti. Një vështrim i shpejtë në faqet e internetit tregoi se shumica e tyre janë ndërfaqe në internet të produkteve të njohura të kompanive të mëdha botërore, të cilat në dukje ju tregojnë se nuk janë të mirëseardhura. Ata kërkojnë një emër përdoruesi dhe fjalëkalim, shkundin fushën për të futur faktorin e dytë, kërkojnë një certifikatë klienti TLS ose e dërgojnë atë në Microsoft ADFS. Disa janë thjesht të paarritshme nga interneti. Për disa, padyshim që ju duhet të keni një klient të paguar special për tre paga ose të dini URL-në e saktë për të hyrë. Le të kapërcejmë një javë tjetër dëshpërimi gradual në procesin e përpjekjes për të "shpërthyer" versionet e softuerit për dobësi të njohura, kërkimin e përmbajtjes së fshehur në shtigjet e ueb-it dhe llogarive të rrjedhura nga shërbimet e palëve të treta si LinkedIn, duke u përpjekur të hamendësojmë fjalëkalimet duke i përdorur ato, gjithashtu. si gërmimi i dobësive në faqet e internetit të shkruara vetë - meqë ra fjala, sipas statistikave, ky është vektori më premtues i sulmit të jashtëm sot. Do të vërej menjëherë armën filmike që qëlloi më pas.

Pra, gjetëm dy sajte që dalloheshin nga qindra shërbime. Këto sajte kishin një gjë të përbashkët: nëse nuk angazhoheni në zbulimin e përpiktë të rrjetit sipas domenit, por shikoni kokë më kokë për portet e hapura ose synoni një skaner cenueshmërie duke përdorur një gamë të njohur IP, atëherë këto sajte do t'i shpëtojnë skanimit dhe thjesht nuk do të jenë të dukshme pa e ditur emrin e DNS. Ndoshta ato u munguan më herët, të paktën, dhe mjetet tona automatike nuk gjetën ndonjë problem me to, edhe nëse ato u dërguan drejtpërdrejt në burim.

Nga rruga, në lidhje me atë që skanerët e lëshuar më parë gjetën në përgjithësi. Më lejoni t'ju kujtoj: për disa njerëz, "pentest" është e barabartë me "skanimin e automatizuar". Por skanerët në këtë projekt nuk thanë asgjë. Epo, maksimumi u tregua nga dobësitë e mesme (3 nga 5 për sa i përket ashpërsisë): në disa shërbime një certifikatë e keqe TLS ose algoritme të vjetëruara të kriptimit, dhe në shumicën e sajteve Clickjacking. Por kjo nuk do t'ju çojë në qëllimin tuaj. Ndoshta skanerët do të ishin më të dobishëm këtu, por më lejoni t'ju kujtoj: vetë klienti është në gjendje të blejë programe të tilla dhe të provojë veten me to, dhe, duke gjykuar nga rezultatet e zymta, ai tashmë ka kontrolluar.

Le të kthehemi te faqet “anormale”. E para është diçka si një Wiki lokal në një adresë jo standarde, por në këtë artikull le të jetë wiki.company[.]ru. Ajo gjithashtu kërkoi menjëherë një hyrje dhe fjalëkalim, por përmes NTLM në shfletues. Për përdoruesin, kjo duket si një dritare asketike që kërkon të fusë një emër përdoruesi dhe fjalëkalim. Dhe kjo është praktikë e keqe.

Një shënim i vogël. NTLM në faqet e internetit rrethuese është e keqe për një sërë arsyesh. Arsyeja e parë është se emri i domain-it Active Directory është zbuluar. Në shembullin tonë, doli gjithashtu të ishte company.ru, ashtu si emri "i jashtëm" DNS. Duke e ditur këtë, mund të përgatisni me kujdes diçka me qëllim të keq në mënyrë që të ekzekutohet vetëm në makinën e domenit të organizatës, dhe jo në ndonjë sandbox. Së dyti, vërtetimi kalon drejtpërdrejt përmes kontrolluesit të domenit përmes NTLM (surprizë, apo jo?), me të gjitha tiparet e politikave të rrjetit "të brendshëm", duke përfshirë bllokimin e llogarive nga tejkalimi i numrit të përpjekjeve për futjen e fjalëkalimit. Nëse një sulmues zbulon hyrjet, ai do të provojë fjalëkalime për to. Nëse jeni konfiguruar të bllokoni llogaritë nga futja e fjalëkalimeve të pasakta, do të funksionojë dhe llogaria do të bllokohet. Së treti, është e pamundur të shtohet një faktor i dytë në një vërtetim të tillë. Nëse ndonjë nga lexuesit ende e di se si, ju lutem më njoftoni, është vërtet interesante. Së katërti, cenueshmëria ndaj sulmeve pas-the-hash. ADFS u shpik, ndër të tjera, për t'u mbrojtur nga e gjithë kjo.

Ekziston një veti e keqe e produkteve të Microsoft: edhe nëse nuk e keni publikuar në mënyrë specifike një NTLM të tillë, ai do të instalohet si parazgjedhje në OWA dhe Lync, të paktën.

Nga rruga, autori i këtij artikulli dikur bllokoi aksidentalisht rreth 1000 llogari të punonjësve të një banke të madhe në vetëm një orë duke përdorur të njëjtën metodë dhe më pas dukej disi i zbehtë. Shërbimet e IT të bankës ishin gjithashtu të zbehta, por gjithçka përfundoi mirë dhe në mënyrë adekuate, madje u vlerësuam që të parët e gjetëm këtë problem dhe provokuam një zgjidhje të shpejtë dhe vendimtare.

Faqja e dytë kishte adresën "natyrisht një lloj mbiemri.company.ru". E gjeta përmes Google, diçka si kjo në faqen 10. Dizajni ishte nga fillimi i mesit të viteve XNUMX, dhe një person i respektuar po e shikonte nga faqja kryesore, diçka si kjo:

Këtu mora një foto nga "Zemra e një qeni", por më besoni, ishte paksa e ngjashme, madje edhe dizajni i ngjyrave ishte në tone të ngjashme. Le të quhet faqja preobrazhensky.company.ru.

Ishte një faqe interneti personale... për një urolog. Pyesja veten se çfarë po bënte uebsajti i një urologu në nëndomainin e një kompanie të teknologjisë së lartë. Një gërmim i shpejtë në Google tregoi se ky mjek ishte bashkëthemelues i një prej personave juridikë të klientëve tanë dhe madje kontribuoi me rreth 1000 rubla në kapitalin e autorizuar. Sajti është krijuar ndoshta shumë vite më parë dhe burimet e serverit të klientit janë përdorur si hosting. Sajti ka humbur prej kohësh rëndësinë e tij, por për disa arsye u la në punë për një kohë të gjatë.

Për sa i përket dobësive, vetë faqja e internetit ishte e sigurt. Duke parë përpara, do të them se ishte një grup informacioni statik - faqe të thjeshta html me ilustrime të futura në formën e veshkave dhe fshikëzës. Është e kotë të "thyesh" një faqe të tillë.

Por ueb serveri poshtë ishte më interesant. Duke gjykuar nga titulli i serverit HTTP, ai kishte IIS 6.0, që do të thotë se përdorte Windows 2003 si sistem operativ. Skaneri kishte identifikuar më parë se kjo faqe interneti e veçantë e urologut, ndryshe nga hostet e tjerë virtualë në të njëjtin server në internet, iu përgjigj komandës PROPFIND, që do të thotë se po ekzekutonte WebDAV. Nga rruga, skaneri e ktheu këtë informacion me shenjën Info (në gjuhën e raporteve të skanerit, ky është rreziku më i ulët) - gjëra të tilla zakonisht thjesht anashkalohen. Në kombinim, kjo dha një efekt interesant, i cili u zbulua vetëm pas një gërmimi tjetër në Google: një dobësi e rrallë e tejmbushjes së buferit e lidhur me grupin Shadow Brokers, përkatësisht CVE-2017-7269, i cili tashmë kishte një shfrytëzim të gatshëm. Me fjalë të tjera, do të ketë probleme nëse keni Windows 2003 dhe WebDAV po funksionon në IIS. Edhe pse ekzekutimi i Windows 2003 në prodhim në 2018 është një problem më vete.

Shfrytëzimi përfundoi në Metasploit dhe u testua menjëherë me një ngarkesë që dërgoi një kërkesë DNS në një shërbim të kontrolluar - Burp Collaborator përdoret tradicionalisht për të kapur kërkesat DNS. Për habinë time, funksionoi herën e parë: u mor një nokaut DNS. Më pas, u bë një përpjekje për të krijuar një lidhje prapa përmes portit 80 (d.m.th., një lidhje rrjeti nga serveri me sulmuesin, me qasje në cmd.exe në hostin e viktimës), por më pas ndodhi një fiasko. Lidhja nuk u realizua dhe pas përpjekjes së tretë për të përdorur faqen, së bashku me të gjitha fotot interesante, u zhduk përgjithmonë.

Zakonisht kjo pasohet nga një letër në stilin "klient, zgjohu, hoqëm gjithçka". Por na u tha se faqja nuk ka lidhje me proceset e biznesit dhe funksionon atje pa asnjë arsye, si i gjithë serveri, dhe se ne mund ta përdorim këtë burim sipas dëshirës.
Rreth një ditë më vonë faqja papritmas filloi të funksiononte vetë. Duke ndërtuar një stol nga WebDAV në IIS 6.0, zbulova se cilësimi i parazgjedhur është të rinisni proceset e punonjësve të IIS çdo 30 orë. Kjo do të thotë, kur kontrolli doli nga shellcode, procesi i punonjësit të IIS përfundoi, më pas ai rifilloi vetë disa herë dhe më pas shkoi në pushim për 30 orë.

Meqenëse lidhja e pasme me tcp dështoi herën e parë, ia atribuova këtë problem një porti të mbyllur. Kjo do të thotë, ai supozoi praninë e një lloj muri zjarri që nuk lejonte lidhjet dalëse të kalonin jashtë. Fillova të ekzekutoj kode shell që kërkuan nëpër shumë porta tcp dhe udp, nuk kishte asnjë efekt. Ngarkesat e kundërta të lidhjes nëpërmjet http(s) nga Metasploit nuk funksionuan - meterpreter/reverse_http(s). Papritur, u krijua një lidhje me të njëjtin port 80, por u ndërpre menjëherë. Këtë ia atribuova veprimit të IPS-së ende imagjinare, të cilës nuk i pëlqente trafiku i matësit. Në dritën e faktit se një lidhje e pastër tcp me portin 80 nuk kaloi, por një lidhje http, arrita në përfundimin se një përfaqësues http ishte disi i konfiguruar në sistem.

Unë madje provova metërprerësin përmes DNS (faleminderit d00kie për përpjekjet tuaja, kurseu shumë projekte), duke kujtuar suksesin e parë, por nuk funksionoi as në stendë - shellcode ishte shumë voluminoz për këtë cenueshmëri.

Në realitet, dukej kështu: 3-4 tentativa për sulme brenda 5 minutave, pastaj duke pritur për 30 orë. Dhe kështu me radhë për tre javë rresht. Unë madje vendosa një kujtesë për të mos humbur kohë. Për më tepër, kishte një ndryshim në sjelljen e mjediseve të testimit dhe prodhimit: për këtë cenueshmëri kishte dy shfrytëzime të ngjashme, një nga Metasploit, tjetri nga Interneti, i konvertuar nga versioni Shadow Brokers. Pra, vetëm Metasploit u testua në luftim, dhe vetëm i dyti u testua në stol, gjë që e bëri korrigjimin edhe më të vështirë dhe po shkatërronte trurin.

Në fund, një kod shell që shkarkoi një skedar exe nga një server i caktuar nëpërmjet http dhe e nisi atë në sistemin e synuar, u dëshmua të ishte efektiv. Shellcode ishte mjaft i vogël për t'u përshtatur, por të paktën funksionoi. Meqenëse serveri nuk e pëlqeu fare trafikun TCP dhe http(s) u kontrollua për praninë e njehsorit, vendosa që mënyra më e shpejtë ishte të shkarkoja një skedar exe që përmbante DNS-meterpreter përmes këtij shellcode.

Këtu u shfaq përsëri një problem: kur shkarkoni një skedar exe dhe, siç treguan përpjekjet, pavarësisht se cili, shkarkimi u ndërpre. Përsëri, disa pajisje sigurie midis serverit tim dhe urologut nuk i pëlqeu trafiku http me një exe brenda. Zgjidhja "e shpejtë" dukej se ishte ndryshimi i kodit të shell-it në mënyrë që të mjegullonte trafikun http në fluturim, në mënyrë që të dhënat binare abstrakte të transferoheshin në vend të exe. Më në fund, sulmi ishte i suksesshëm, kontrolli u mor përmes kanalit të hollë DNS:

Menjëherë u bë e qartë se unë kam të drejtat më themelore të rrjedhës së punës IIS, të cilat më lejojnë të bëj asgjë. Kështu dukej në tastierën Metasploit:

Të gjitha metodologjitë e pentestit sugjerojnë fuqimisht që ju duhet të rritni të drejtat kur fitoni akses. Unë zakonisht nuk e bëj këtë në nivel lokal, pasi qasja e parë shihet thjesht si një pikë hyrjeje në rrjet dhe komprometimi i një makinerie tjetër në të njëjtin rrjet është zakonisht më i lehtë dhe më i shpejtë sesa përshkallëzimi i privilegjeve në një host ekzistues. Por ky nuk është rasti këtu, pasi kanali DNS është shumë i ngushtë dhe nuk do të lejojë që trafiku të pastrohet.

Duke supozuar se ky server Windows 2003 nuk është riparuar për cenueshmërinë e famshme MS17-010, unë tuneloj trafikun në portin 445/TCP përmes tunelit të matësit DNS në localhost (po, kjo është gjithashtu e mundur) dhe përpiqem të ekzekutoj exe-në e shkarkuar më parë përmes cenueshmëria. Sulmi funksionon, marr një lidhje të dytë, por me të drejta SISTEMI.

Shtë interesante që ata ende u përpoqën të mbronin serverin nga MS17-010 - ai kishte shërbime të pambrojtura të rrjetit të çaktivizuara në ndërfaqen e jashtme. Kjo mbron nga sulmet përmes rrjetit, por sulmi nga brenda në localhost funksionoi, pasi nuk mund ta fikni shpejt SMB në localhost.

Më tej, zbulohen detaje të reja interesante:

1. Duke pasur të drejta SYSTEM, mund të krijoni lehtësisht një lidhje prapa nëpërmjet TCP. Natyrisht, çaktivizimi i TCP-së direkte është rreptësisht një problem për përdoruesin e kufizuar të IIS. Spoiler: trafiku i përdoruesve të IIS ishte disi i mbështjellë me përfaqësuesin lokal ISA në të dy drejtimet. Se si funksionon saktësisht, nuk e kam riprodhuar.
2. Unë jam në një "DMZ" të caktuar (dhe ky nuk është një domen Active Directory, por një GRUP PUNE) - tingëllon logjike. Por në vend të adresës IP të pritshme private ("gri"), unë kam një adresë IP plotësisht "të bardhë", saktësisht të njëjtë me atë që sulmova më parë. Kjo do të thotë se kompania është aq e vjetër në botën e adresimit IPv4 sa mund të përballojë të mbajë një zonë DMZ për 128 adresa "të bardha" pa NAT sipas skemës, siç përshkruhet në manualet e Cisco-s nga 2005.

Meqenëse serveri është i vjetër, Mimikatz garantohet të funksionojë drejtpërdrejt nga memoria:

Marr fjalëkalimin e administratorit lokal, tunelezoj trafikun RDP mbi TCP dhe hyj në një desktop komod. Meqenëse mund të bëja çfarë të doja me serverin, hoqa antivirusin dhe zbulova se serveri ishte i aksesueshëm nga Interneti vetëm përmes porteve TCP 80 dhe 443, dhe 443 nuk ishte i zënë. Kam ngritur një server OpenVPN në 443, shtoj funksionet NAT për trafikun tim VPN dhe kam akses të drejtpërdrejtë në rrjetin DMZ në një formë të pakufizuar përmes OpenVPN-së time. Vlen të përmendet se ISA, duke pasur disa funksione IPS pa aftësi të kufizuara, më bllokoi trafikun me skanimin e portit, për të cilin duhej zëvendësuar me një RRAS më të thjeshtë dhe më të përputhshëm. Kështu që pentestuesit ndonjëherë duhet të administrojnë të gjitha llojet e gjërave.

Një lexues i vëmendshëm do të pyesë: "Po siti i dytë - një wiki me vërtetim NTLM, për të cilin është shkruar kaq shumë?" Më shumë për këtë më vonë.

Pjesa 2. Ende nuk po kriptoni? Atëherë ne po vijmë tek ju tashmë këtu

Pra, ka qasje në segmentin e rrjetit DMZ. Duhet të shkoni te administratori i domenit. Gjëja e parë që ju vjen në mendje është të kontrolloni automatikisht sigurinë e shërbimeve brenda segmentit DMZ, veçanërisht pasi shumë prej tyre tani janë të hapura për kërkime. Një pamje tipike gjatë një testi depërtimi: perimetri i jashtëm mbrohet më mirë se shërbimet e brendshme, dhe kur fitoni ndonjë akses brenda një infrastrukture të madhe, është shumë më e lehtë të merrni të drejta të zgjeruara në një domen vetëm për faktin se ky domen fillon të jetë të aksesueshme për mjetet, dhe së dyti, në një infrastrukturë me disa mijëra hoste, gjithmonë do të ketë disa probleme kritike.

I ngarkoj skanerët përmes DMZ përmes një tuneli OpenVPN dhe pres. Unë hap raportin - përsëri asgjë serioze, me sa duket dikush kaloi të njëjtën metodë para meje. Hapi tjetër është të ekzaminoni se si hostet brenda rrjetit DMZ komunikojnë. Për ta bërë këtë, fillimisht nisni Wireshark-un e zakonshëm dhe dëgjoni për kërkesat e transmetimit, kryesisht ARP. Paketat ARP u mblodhën gjatë gjithë ditës. Rezulton se në këtë segment përdoren disa porta. Kjo do të jetë e dobishme më vonë. Duke kombinuar të dhënat për kërkesat dhe përgjigjet ARP dhe të dhënat e skanimit të porteve, gjeta pikat e daljes së trafikut të përdoruesve nga brenda rrjetit lokal, përveç atyre shërbimeve që njiheshin më parë, si web dhe postë.

Meqenëse për momentin nuk kisha akses në sisteme të tjera dhe nuk kisha një llogari të vetme për shërbimet e korporatës, u vendos që të nxirrja të paktën disa llogari nga trafiku duke përdorur ARP Spoofing.

Cain&Abel u lançua në serverin e urologut. Duke marrë parasysh flukset e identifikuara të trafikut, u zgjodhën çiftet më premtuese për sulmin njeri në mes, dhe më pas një pjesë e trafikut të rrjetit u mor me nisje afatshkurtër për 5-10 minuta, me një kohëmatës për të rindezur serverin në rast ngrirjeje. Si në shaka, kishte dy lajme:

1. Mirë: u mblodhën shumë kredenciale dhe sulmi në tërësi funksionoi.
2. E keqja: të gjitha kredencialet ishin nga vetë klientët e klientit. Gjatë ofrimit të shërbimeve mbështetëse, specialistët e klientëve u lidhën me shërbimet e klientëve të cilët nuk kishin gjithmonë të konfiguruar enkriptimin e trafikut.

Si rezultat, mora shumë kredenciale që ishin të padobishme në kontekstin e projektit, por padyshim interesante si një demonstrim i rrezikut të sulmit. Ruterët kufitarë të kompanive të mëdha me telnet, portet http të debugimit të përcjella në CRM të brendshme me të gjitha të dhënat, akses i drejtpërdrejtë në RDP nga Windows XP në rrjetin lokal dhe obskurantizëm tjetër. Doli kështu Kompromisi i Zinxhirit të Furnizimit sipas matricës MITER.

Gjeta gjithashtu një mundësi qesharake për të mbledhur letra nga trafiku, diçka e tillë. Ky është një shembull i një letre të gatshme që shkoi nga klienti ynë në portin SMTP të klientit të tij, përsëri, pa kriptim. Një farë Andrey i kërkon adashit të tij të ridërgojë dokumentacionin dhe ai ngarkohet në një disk cloud me një hyrje, fjalëkalim dhe lidhje në një letër përgjigjeje:

Ky është një tjetër kujtesë për të enkriptuar të gjitha shërbimet. Nuk dihet se kush dhe kur do t'i lexojë dhe përdorë specifikisht të dhënat tuaja - ofruesi, administratori i sistemit të një kompanie tjetër, apo një pentester i tillë. Unë hesht për faktin se shumë njerëz thjesht mund të përgjojnë trafikun e pakriptuar.

Pavarësisht suksesit në dukje, kjo nuk na afroi qëllimit. Sigurisht, ishte e mundur të ulesh për një kohë të gjatë dhe të merrte informacione të vlefshme, por nuk është fakt që do të shfaqej atje, dhe vetë sulmi është shumë i rrezikshëm për sa i përket integritetit të rrjetit.

Pas një gërmimi tjetër në shërbimet, një ide interesante erdhi në mendje. Ekziston një mjet i tillë i quajtur Responder (është e lehtë të gjesh shembuj të përdorimit me këtë emër), i cili, duke "helmuar" kërkesat e transmetimit, provokon lidhje përmes një sërë protokollesh si SMB, HTTP, LDAP, etj. në mënyra të ndryshme, më pas pyet të gjithë ata që lidhen për të vërtetuar dhe e konfigurojnë atë në mënyrë që vërtetimi të bëhet nëpërmjet NTLM dhe në një mënyrë transparente për viktimën. Më shpesh, një sulmues mbledh shtrëngime duarsh NetNTLMv2 në këtë mënyrë dhe prej tyre, duke përdorur një fjalor, rikuperon shpejt fjalëkalimet e domenit të përdoruesit. Këtu doja diçka të ngjashme, por përdoruesit u ulën "prapa një muri", ose më mirë, ata u ndanë nga një mur zjarri dhe hynë në WEB përmes grupit të proxy Coat Blue.

Mos harroni, unë specifikova që emri i domain-it Active Directory përkoi me domenin "të jashtëm", ​​domethënë ishte company.ru? Pra, Windows, më saktë Internet Explorer (dhe Edge dhe Chrome), i lejojnë përdoruesit të vërtetojë në mënyrë transparente në HTTP përmes NTLM nëse konsiderojnë se faqja ndodhet në ndonjë "Zonë Intranet". Një nga shenjat e një "Intraneti" është qasja në një adresë IP "gri" ose një emër të shkurtër DNS, domethënë pa pika. Meqenëse ata kishin një server me një IP "të bardhë" dhe emër DNS preobrazhensky.company.ru, dhe makinat e domenit zakonisht marrin prapashtesën e domenit Active Directory nëpërmjet DHCP për futjen e thjeshtuar të emrit, atyre u duhej vetëm të shkruanin URL-në në shiritin e adresave. preobrazhensky, në mënyrë që ata të gjejnë rrugën e duhur për në serverin e urologut të komprometuar, duke mos harruar që tani quhet "Intranet". Kjo do të thotë, në të njëjtën kohë më jepni shtrëngimin e duarve NTLM të përdoruesit pa dijeninë e tij. E tëra që mbetet është të detyrojmë shfletuesit e klientëve të mendojnë për nevojën urgjente për të kontaktuar këtë server.

Shërbimi i mrekullueshëm Intercepter-NG erdhi në shpëtim (faleminderit Përgjues). Ai ju lejoi të ndryshoni trafikun menjëherë dhe funksionoi shkëlqyeshëm në Windows 2003. Madje kishte funksionalitet të veçantë për të modifikuar vetëm skedarët JavaScript në rrjedhën e trafikut. Ishte planifikuar një lloj skriptimi masiv ndër-vend.

Proxies Blue Coat, përmes të cilave përdoruesit aksesonin WEB-in global, ruanin periodikisht përmbajtjen statike. Duke përgjuar trafikun, ishte e qartë se ata po punonin gjatë gjithë orës, duke kërkuar pafundësisht statiken e përdorur shpesh për të shpejtuar shfaqjen e përmbajtjes gjatë orëve të pikut. Për më tepër, BlueCoat kishte një agjent përdoruesi specifik, i cili e dallonte qartë nga një përdorues i vërtetë.

U përgatit Javascript, i cili, duke përdorur Intercepter-NG, u zbatua për një orë natën për çdo përgjigje me skedarë JS për Blue Coat. Skenari bëri si më poshtë:

• Përcaktoi shfletuesin aktual nga agjenti i përdoruesit. Nëse ishte Internet Explorer, Edge ose Chrome, ai vazhdoi të funksiononte.
• Prita derisa të formohej DOM-i i faqes.
• Futet një imazh i padukshëm në DOM me një atribut src të formës preobrazhensky:8080/NNNNNN.png, ku NNN janë numra arbitrar në mënyrë që BlueCoat të mos e ruajë atë në cache.
• Vendosni një ndryshore të flamurit global për të treguar se injektimi ka përfunduar dhe nuk ka më nevojë të futni imazhe.

Shfletuesi u përpoq të ngarkonte këtë imazh; në portin 8080 të serverit të komprometuar, një tunel TCP po e priste në laptopin tim, ku po funksiononte i njëjti Responder, duke kërkuar që shfletuesi të identifikohej përmes NTLM.

Duke gjykuar nga regjistrat e Responder, njerëzit erdhën në punë në mëngjes, ndezën stacionet e tyre të punës, pastaj masivisht dhe pa u vënë re filluan të vizitonin serverin e urologut, duke mos harruar të "kullonin" shtrëngimet e duarve NTLM. Shtrëngimet e duarve ranë shi gjatë gjithë ditës dhe u grumbulluan qartë materiale për një sulm dukshëm të suksesshëm për të rikuperuar fjalëkalimet. Ja si dukeshin regjistrat e Përgjigjes:

Vizita masive sekrete në serverin e urologut nga përdoruesit

Ju ndoshta keni vënë re tashmë se e gjithë kjo histori është ndërtuar mbi parimin "gjithçka ishte në rregull, por më pas pati një fatkeqësi, pastaj pati një kapërcim dhe më pas gjithçka erdhi në sukses". Pra, këtu ishte një turp. Nga pesëdhjetë shtrëngimet unike të duarve, asnjë e vetme nuk u zbulua. Dhe kjo merr parasysh faktin se edhe në një laptop me një procesor të vdekur, këto shtrëngime duarsh NTLMv2 përpunohen me një shpejtësi prej disa qindra milionë përpjekjesh në sekondë.

Më duhej të armatosja veten me teknikat e ndryshimit të fjalëkalimit, një kartë video, një fjalor më të trashë dhe të prisja. Pas një kohe të gjatë, u zbuluan disa llogari me fjalëkalime të formës “Q11111111....1111111q”, gjë që sugjeron se të gjithë përdoruesit dikur u detyruan të krijonin një fjalëkalim shumë të gjatë me shkronja të ndryshme karakteresh, i cili gjithashtu supozohej të të jetë kompleks. Por nuk mund të mashtrosh një përdorues të kalitur, dhe kështu ai ia ka bërë më të lehtë vetes të kujtojë. Në total, rreth 5 llogari u komprometuan dhe vetëm njëra prej tyre kishte të drejta të vlefshme për shërbimet.

Pjesa 3. Roskomnadzor kundërpërgjigjet

Pra, u morën llogaritë e para të domenit. Nëse nuk ju ka zënë gjumi deri në këtë pikë nga një lexim i gjatë, ndoshta do të mbani mend që përmenda një shërbim që nuk kërkonte një faktor të dytë vërtetimi: është një wiki me vërtetim NTLM. Natyrisht, gjëja e parë që duhet bërë ishte të hyje atje. Gërmimi në bazën e brendshme të njohurive solli shpejt rezultate:

• Kompania ka një rrjet WiFi me vërtetim duke përdorur llogaritë e domenit me qasje në rrjetin lokal. Me grupin aktual të të dhënave, ky është tashmë një vektor sulmi funksional, por ju duhet të shkoni në zyrë me këmbët tuaja dhe të jeni të vendosur diku në territorin e zyrës së klientit.
• Gjeta një udhëzim sipas të cilit ekzistonte një shërbim që lejonte... të regjistronte në mënyrë të pavarur një pajisje vërtetimi "faktori i dytë" nëse përdoruesi është brenda një rrjeti lokal dhe kujton me siguri hyrjen dhe fjalëkalimin e domenit të tij. Në këtë rast, "brenda" dhe "jashtë" përcaktoheshin nga aksesueshmëria e portit të këtij shërbimi për përdoruesit. Porti nuk ishte i aksesueshëm nga interneti, por ishte mjaft i aksesueshëm përmes DMZ.

Sigurisht, një "faktor i dytë" u shtua menjëherë në llogarinë e komprometuar në formën e një aplikacioni në telefonin tim. Kishte një program që ose mund të dërgonte me zë të lartë një kërkesë shtytje në telefon me butonat "mirato"/"Mos mirato" për veprimin, ose të shfaqte në heshtje kodin OTP në ekran për hyrje të mëtejshme të pavarur. Për më tepër, metoda e parë supozohej nga udhëzimet të ishte e vetmja e saktë, por nuk funksionoi, ndryshe nga metoda OTP.

Me "faktorin e dytë" të prishur, unë munda të hyja në postën e Outlook Web Access dhe qasje në distancë në Citrix Netscaler Gateway. Kishte një surprizë në postë në Outlook:

Në këtë fotografi të rrallë mund të shihni se si Roskomnadzor ndihmon pentestuesit

Këta ishin muajt e parë pas bllokimit të famshëm "tifoz" të Telegramit, kur rrjete të tëra me mijëra adresa u zhdukën në mënyrë të pashmangshme nga aksesi. U bë e qartë pse shtytja nuk funksionoi menjëherë dhe pse "viktima" ime nuk dha alarmin sepse ata filluan të përdorin llogarinë e saj gjatë orëve të hapura.

Kushdo që është i njohur me Citrix Netscaler imagjinon që ai zakonisht zbatohet në atë mënyrë që vetëm një ndërfaqe fotografie mund t'i transmetohet përdoruesit, duke u përpjekur të mos i japë atij mjetet për të nisur aplikacione të palëve të treta dhe për të transferuar të dhëna, duke kufizuar në çdo mënyrë veprimet e mundshme. përmes predhave standarde të kontrollit. "Viktima" ime, për shkak të profesionit të tij, mori vetëm 1C:

Pasi eca pak rreth ndërfaqes 1C, zbulova se ka module të jashtme të përpunimit atje. Ato mund të ngarkohen nga ndërfaqja, dhe ato do të ekzekutohen në klient ose server, në varësi të të drejtave dhe cilësimeve.

U kërkova miqve të mi programues 1C të krijonin një përpunim që do të pranonte një varg dhe do ta ekzekutonte atë. Në gjuhën 1C, fillimi i një procesi duket diçka si kjo (marrë nga Interneti). A jeni dakord që sintaksa e gjuhës 1C mahnit njerëzit që flasin rusisht me spontanitetin e saj?

Përpunimi u ekzekutua në mënyrë të përsosur; doli të ishte ajo që pentestuesit e quajnë "guaskë" - Internet Explorer u lançua përmes tij.

Më parë, adresa e një sistemi që ju lejon të porosisni kalimet në territor u gjet në postë. Urdhërova një kalim në rast se më duhej të përdorja një vektor sulmi WiFi.

Flitet në internet se kishte ende ushqim të shijshëm falas në zyrën e klientit, por unë prapë preferova ta zhvilloja sulmin nga distanca, është më e qetë.

AppLocker u aktivizua në serverin e aplikacionit që funksiononte Citrix, por ai u anashkalua. I njëjti Meterpreter u ngarkua dhe u nis përmes DNS, pasi versionet http(s) nuk donin të lidheshin dhe unë nuk e dija adresën e brendshme të përfaqësuesit në atë kohë. Nga rruga, që nga ky moment, pentesti i jashtëm në thelb u shndërrua plotësisht në një të brendshëm.

Pjesa 4. Të drejtat e administratorit për përdoruesit janë të këqija, mirë?

Detyra e parë e një pentester kur fiton kontrollin e një sesioni të përdoruesit të domenit është të mbledhë të gjithë informacionin rreth të drejtave në domen. Ekziston një mjet BloodHound që automatikisht ju lejon të shkarkoni informacione rreth përdoruesve, kompjuterëve, grupeve të sigurisë përmes protokollit LDAP nga një kontrollues domeni dhe nëpërmjet SMB - informacione se cili përdorues është regjistruar së fundi ku dhe kush është administratori lokal.

Një teknikë tipike për kapjen e të drejtave të administratorit të domenit duket e thjeshtuar si një cikël veprimesh monotone:

• Ne shkojmë te kompjuterët e domenit ku ka të drejta të administratorit lokal, bazuar në llogaritë e domenit të kapur tashmë.
• Ne lëshojmë Mimikatz dhe marrim fjalëkalime të ruajtura në memorie, bileta Kerberos dhe hash NTLM të llogarive të domenit që janë identifikuar së fundi në këtë sistem. Ose heqim imazhin e kujtesës së procesit lsass.exe dhe bëjmë të njëjtën gjë nga ana jonë. Kjo funksionon mirë me Windows më të rinj se 2012R2/Windows 8.1 me cilësimet e paracaktuara.
• Ne përcaktojmë se ku llogaritë e komprometuara kanë të drejta administratori lokal. Ne përsërisim pikën e parë. Në një fazë fitojmë të drejta administratori për të gjithë domenin.

"Fundi i ciklit;", siç do të shkruanin këtu programuesit 1C.

Pra, përdoruesi ynë doli të ishte një administrator lokal në vetëm një host me Windows 7, emri i të cilit përfshinte fjalën "VDI" ose "Infrastrukturë Virtual Desktop", makina personale virtuale. Ndoshta, projektuesi i shërbimit VDI do të thoshte që duke qenë se VDI është sistemi operativ personal i përdoruesit, edhe nëse përdoruesi ndryshon mjedisin e softuerit ashtu siç dëshiron, hosti mund të "ringarkohet". Unë gjithashtu mendova se në përgjithësi ideja ishte e mirë, shkova te ky host personal VDI dhe bëra një fole atje:

• Unë instalova një klient OpenVPN atje, i cili bëri një tunel përmes Internetit në serverin tim. Klienti duhej të detyrohej të kalonte të njëjtën shtresë blu me vërtetimin e domenit, por OpenVPN e bëri atë, siç thonë ata, "jashtë kutisë".
• OpenSSH është instaluar në VDI. Epo, me të vërtetë, çfarë është Windows 7 pa SSH?

Kështu dukej live. Më lejoni t'ju kujtoj se e gjithë kjo duhet të bëhet përmes Citrix dhe 1C:

Një teknikë për promovimin e aksesit në kompjuterët fqinjë është të kontrolloni fjalëkalimet e administratorit lokal për një përputhje. Këtu e priste fati menjëherë: hash-i NTLM i administratorit lokal të paracaktuar (i cili u quajt papritur Administrator) u afrua përmes një sulmi pasues ndaj hosteve fqinjë VDI, nga të cilët kishte disa qindra. Natyrisht, sulmi i goditi menjëherë.

Ja ku administratorët e VDI qëlluan veten dy herë në këmbë:

• Hera e parë ishte kur makinat VDI nuk u futën nën LAPS, duke mbajtur në thelb të njëjtin fjalëkalim të administratorit lokal nga imazhi që u shpërnda në masë në VDI.
• Administratori i parazgjedhur është e vetmja llogari lokale që është e cenueshme ndaj sulmeve të kalimit të hashit. Edhe me të njëjtin fjalëkalim, do të ishte e mundur të shmangni kompromisin masiv duke krijuar një llogari të dytë administratori lokal me një fjalëkalim kompleks të rastësishëm dhe duke bllokuar atë të paracaktuar.

Pse shërbimi SSH në atë Windows? Shumë e thjeshtë: tani serveri OpenSSH jo vetëm që siguroi një guaskë komanduese të përshtatshme ndërvepruese pa ndërhyrë në punën e përdoruesit, por edhe një përfaqësues socks5 në VDI. Nëpërmjet këtyre çorapeve, unë u lidha nëpërmjet SMB dhe mblodha llogari të ruajtura në memorie nga të gjitha këto qindra makina VDI, më pas kërkova rrugën drejt administratorit të domenit duke i përdorur ato në grafikët e BloodHound. Me qindra mikpritës në dispozicionin tim, e gjeta këtë mënyrë mjaft shpejt. Të drejtat e administratorit të domenit janë marrë.

Këtu është një foto nga Interneti që tregon një kërkim të ngjashëm. Lidhjet tregojnë se kush është ku është administratori dhe kush është identifikuar ku.

Nga rruga, mbani mend gjendjen që nga fillimi i projektit - "mos përdorni inxhinierinë sociale". Pra, unë propozoj të mendojmë se sa do të ndërpritet i gjithë ky Bollywood me efekte speciale nëse do të ishte akoma i mundur përdorimi i phishing banal. Por personalisht, ishte shumë interesante për mua të bëja të gjitha këto. Shpresoj se ju pëlqeu duke lexuar këtë. Sigurisht, jo çdo projekt duket kaq intrigues, por puna në tërësi është shumë sfiduese dhe nuk e lejon të ngecë.

Ndoshta dikush do të ketë një pyetje: si të mbroheni? Edhe ky artikull përshkruan shumë teknika, shumë prej të cilave administratorët e Windows as nuk i dinë. Sidoqoftë, unë propozoj t'i shikojmë ato nga këndvështrimi i parimeve të hakmatura dhe masave të sigurisë së informacionit:

• mos përdorni softuer të vjetëruar (kujtoni Windows 2003 në fillim?)
• mos i mbani të ndezura sistemet e panevojshme (pse kishte uebfaqe të një urologu?)
• kontrolloni vetë fjalëkalimet e përdoruesve për forcë (përndryshe ushtarët ... pentestuesit do ta bëjnë këtë)
• nuk kanë të njëjtat fjalëkalime për llogari të ndryshme (kompromis VDI)
• dhe të tjera

Sigurisht, kjo është shumë e vështirë për t'u zbatuar, por në artikullin vijues do të tregojmë në praktikë se është mjaft e mundur.

Burimi: www.habr.com