See artikkel on kirjutatud väga eduka pentesti põhjal, mille Group-IB spetsialistid paar aastat tagasi läbi viisid: juhtus lugu, mida sai Bollywoodis filmimiseks kohandada. Nüüd ilmselt järgneb lugeja reaktsioon: "Oh, järjekordne PR-artikkel, jälle kujutatakse neid, kui head need on, ärge unustage pentesti osta." No ühest küljest on küll. Selle artikli ilmumiseks on aga mitmeid muid põhjuseid. Tahtsin näidata, millega pentesterid täpselt tegelevad, kui huvitav ja mittetriviaalne see töö võib olla, milliseid naljakaid asjaolusid võib projektides ette tulla ja mis kõige tähtsam, näidata reaalsete näidetega elavat materjali.
Et taastada maailmas tagasihoidlikkuse tasakaal, kirjutame mõne aja pärast pentestist, mis ei läinud hästi. Näitame, kuidas hästi läbimõeldud protsessid ettevõttes suudavad kaitsta terve rea rünnakute eest, isegi hästi ettevalmistatud rünnakute eest lihtsalt seetõttu, et need protsessid on olemas ja tegelikult töötavad.
Ka selles artiklis oleva kliendi jaoks oli kõik üldiselt suurepärane, meie tunnete kohaselt vähemalt parem kui 95% Vene Föderatsiooni turust, kuid seal oli mitmeid väikseid nüansse, mis moodustasid pika sündmuste ahela, mis kõigepealt viis töö kohta pika aruandeni ja seejärel selle artiklini.
Niisiis, varume popkorni ja tere tulemast detektiivilugu. Sõna - Pavel Suprunyuk, Group-IB auditi ja nõustamise osakonna tehniline juht.
1. osa. Pochkin arst
2018 Seal on klient – kõrgtehnoloogiline IT-ettevõte, kes ise teenindab paljusid kliente. Soovib saada vastust küsimusele: kas ilma esialgsete teadmiste ja juurdepääsuta on Interneti kaudu võimalik saada Active Directory domeeni administraatori õigusi? Mind ei huvita ükski sotsiaalne manipuleerimine (), nad ei kavatse meelega tööd segada, kuid võivad kogemata - laadida uuesti näiteks veidralt töötava serveri. Täiendav eesmärk on tuvastada võimalikult palju teisi ründevektoreid välisperimeetri vastu. Ettevõte teeb selliseid teste regulaarselt ja nüüd on saabunud uue testimise tähtaeg. Tingimused on peaaegu tüüpilised, adekvaatsed, arusaadavad. Alustame.
Kliendi nimi on olemas - olgu selleks "Ettevõte" koos põhiveebisaidiga . Muidugi kutsutakse klienti erinevalt, kuid selles artiklis on kõik isikupäratu.
Teen võrguuuringut - uurin, millised aadressid ja domeenid on kliendi juures registreeritud, joonistan võrguskeemi, kuidas nendele aadressidele teenuseid jaotatakse. Saan tulemuse: rohkem kui 4000 reaalajas IP-aadressi. Vaatan nendes võrkudes olevaid domeene: õnneks on valdav enamus kliendi klientidele mõeldud võrgud ja me ei ole nendest formaalselt huvitatud. Klient arvab sama.
Alles jääb üks 256 aadressiga võrk, mille jaoks on selleks hetkeks juba arusaam domeenide ja alamdomeenide jaotusest IP-aadresside järgi, on olemas teave skannitud portide kohta, mis tähendab, et saate vaadata teenustest huvitavaid. Paralleelselt käivitatakse kõikvõimalikud skannerid saadaolevatel IP-aadressidel ja eraldi veebisaitidel.
Teenuseid on palju. Tavaliselt on see pentesteri rõõm ja kiire võidu ootus, sest mida rohkem on teenuseid, seda suurem on ründeväljak ja seda lihtsam on artefakti leida. Kiire pilk veebilehtedele näitas, et enamik neist on globaalsete suurfirmade tuntud toodete veebiliidesed, mis igati ütlevad, et need pole teretulnud. Nad küsivad kasutajanime ja parooli, raputavad välja teise teguri sisestamise välja, küsivad TLS-i kliendisertifikaati või saadavad selle Microsoft ADFS-i. Mõned neist on Internetist lihtsalt kättesaamatud. Mõne jaoks peab ilmselgelt olema spetsiaalne tasuline klient kolme palga jaoks või teadma sisestamiseks täpset URL-i. Jätame vahele veel ühe nädala järk-järgulise meeleheite protsessis, mille käigus üritatakse "läbi murda" tarkvaraversioonidest teadaolevate haavatavuste leidmiseks, peidetud sisu otsimisel veebiteedelt ja lekkinud kontodelt kolmandate osapoolte teenustest, nagu LinkedIn, ning proovida nende abil paroole ära arvata. omakirjutatud veebisaitide haavatavuste väljakaevamine - muide, statistika kohaselt on see tänapäeval kõige lootustandvam välise ründe vektor. Märkan kohe ära filmirelva, mis hiljem tulistas.
Niisiis leidsime kaks saiti, mis paistsid sadade teenuste hulgast silma. Nendel saitidel oli üks ühine joon: kui te ei tegele domeenipõhise võrguga põhjaliku uurimisega, vaid otsite otse avatud porte või sihite haavatavuse skannerit, kasutades teadaolevat IP-vahemikku, siis need saidid pääsevad skannimisest ja neid lihtsalt ei tehta. nähtav ilma DNS-nime teadmata. Võib-olla jäid need vähemalt varem vahele ja meie automaatsed tööriistad ei leidnud nendega probleeme, isegi kui need saadeti otse ressursile.
Muide, sellest, mida varem käivitatud skannerid üldiselt leidsid. Lubage mul teile meelde tuletada: mõne inimese jaoks on "pentest" samaväärne "automaatse skannimisega". Kuid selle projekti skannerid ei öelnud midagi. Noh, maksimumi näitasid keskmised haavatavused (3 viiest raskusastme järgi): mõnel teenusel halb TLS-sertifikaat või aegunud krüpteerimisalgoritmid ja enamikul saitidel Clickjacking. Kuid see ei vii teid eesmärgini. Võib-olla oleks siinkohal rohkem kasu skanneritest, kuid tuletan meelde: klient ise saab selliseid programme osta ja nendega end testida ning kurbade tulemuste põhjal otsustades on ta juba kontrollinud.
Pöördume tagasi "anomaaalsete" saitide juurde. Esimene on midagi kohaliku Wiki sarnast mittestandardsel aadressil, kuid selles artiklis olgu selleks wiki.company[.]ru. Ta küsis kohe ka sisselogimist ja parooli, kuid brauseris NTLM-i kaudu. Kasutaja jaoks tundub see askeetliku aknana, kus palutakse sisestada kasutajanimi ja parool. Ja see on halb tava.
Väike märkus. NTLM perimeetri veebisaitidel on halb mitmel põhjusel. Esimene põhjus on Active Directory domeeninime avalikustamine. Meie näites osutus see samuti ettevõtteks.ru, nagu ka "väline" DNS-nimi. Seda teades saate hoolikalt ette valmistada midagi pahatahtlikku, nii et seda käivitataks ainult organisatsiooni domeenimasinas, mitte mõnes liivakastis. Teiseks toimub autentimine otse domeenikontrolleri kaudu NTLM-i kaudu (üllatus, eks?) koos kõigi "sisemiste" võrgupoliitikate funktsioonidega, sealhulgas kontode blokeerimisega, et see ei ületaks parooli sisestamise katsete arvu. Kui ründaja saab sisselogimised teada, proovib ta nende jaoks paroole. Kui olete konfigureeritud blokeerima kontosid valede paroolide sisestamise eest, siis see toimib ja konto blokeeritakse. Kolmandaks on võimatu sellisele autentimisele lisada teist tegurit. Kui keegi lugejatest veel teab, kuidas, siis andke mulle teada, see on tõesti huvitav. Neljandaks, haavatavus pass-the-hash rünnakute suhtes. ADFS leiutati muu hulgas selleks, et kõige selle eest kaitsta.
Microsofti toodetel on üks halb omadus: isegi kui te sellist NTLM-i konkreetselt ei avaldanud, installitakse see vaikimisi vähemalt OWA-sse ja Lyncisse.
Muide, selle artikli autor blokeeris kunagi kogemata sama meetodiga ühe suure panga töötajate ligikaudu 1000 töötaja kontot ja nägi siis kuidagi kahvatu välja. Ka panga IT-teenused olid kahvatud, kuid kõik lõppes hästi ja adekvaatselt, saime isegi kiidusõnu, et leidsime selle probleemi esimesena ning kutsusime esile kiire ja otsustava lahenduse.
Teisel saidil oli aadress "ilmselgelt mingi perekonnanimi.company.ru". Leidsin selle Google'i kaudu, midagi sellist lk 10. Kujundus pärineb XNUMX. aastate algusest-keskpaigast ja üks lugupeetud inimene vaatas seda avalehelt, umbes selline:
Siin võtsin kaadri “Koera südamest”, aga uskuge mind, see oli ähmaselt sarnane, isegi värvikujundus oli sarnastes toonides. Las saiti nimetada preobrazhensky.company.ru.
See oli isiklik veebisait... uroloogi jaoks. Mõtlesin, mida teeb uroloogi veebisait kõrgtehnoloogiaettevõtte alamdomeenil. Kiire süvenemine Google'isse näitas, et see arst oli ühe meie kliendi juriidilise isiku kaasasutaja ja panustas isegi umbes 1000 rubla põhikapitali. Sait loodi tõenäoliselt palju aastaid tagasi ja majutamiseks kasutati kliendi serveriressursse. Sait on juba ammu oma aktuaalsuse kaotanud, kuid millegipärast jäi see pikaks ajaks tööle.
Haavatavuste osas oli veebisait ise turvaline. Tulevikku vaadates ütlen, et see oli staatilise teabe kogum - lihtsad html-lehed, millele on sisestatud illustratsioonid neerude ja põie kujul. Sellise saidi "lõhkumine" on mõttetu.
Kuid selle all olev veebiserver oli huvitavam. HTTP-serveri päise järgi otsustades oli sellel IIS 6.0, mis tähendab, et see kasutas operatsioonisüsteemina Windows 2003. Skänner oli varem tuvastanud, et see konkreetne uroloogi veebisait, erinevalt teistest sama veebiserveri virtuaalsetest hostidest, vastas käsule PROPFIND, mis tähendab, et see käivitas WebDAV-i. Muide, skanner tagastas selle teabe märkega Info (skannerite aruannete keeles on see madalaim oht) - tavaliselt jäetakse sellised asjad lihtsalt vahele. Kombineeritult andis see huvitava efekti, mis ilmnes alles pärast järjekordset kaevamist Google'is: Shadow Brokersi komplektiga seotud haruldane puhvri ületäitumise haavatavus, nimelt CVE-2017-7269, millel oli juba valmis ärakasutamine. Teisisõnu, kui teil on Windows 2003 ja WebDAV töötab IIS-is, tekib probleeme. Kuigi 2003. aastal on Windows 2018 tootmises töötamine omaette probleem.
Ärakasutamine sattus Metasploiti ja seda testiti kohe koormaga, mis saatis DNS-päringu kontrollitud teenusele – Burp Collaboratorit kasutatakse traditsiooniliselt DNS-i päringute püüdmiseks. Minu üllatuseks see esimesel korral toimis: saadi DNS-i knockout. Järgmisena üritati luua tagasiühendust pordi 80 kaudu (see tähendab võrguühendust serverist ründajani, ligipääsuga ohvri hosti cmd.exe-le), kuid siis juhtus fiasko. Ühendus ei tulnud läbi ja pärast kolmandat saidi kasutuskatset kadusid kõik huvitavad pildid igaveseks.
Tavaliselt järgneb sellele kiri stiilis "klient, ärka üles, me jätsime kõik maha." Kuid meile öeldi, et saidil pole äriprotsessidega midagi pistmist ja see töötab seal ilma põhjuseta, nagu kogu server, ja et me saame seda ressurssi kasutada nii, nagu soovime.
Umbes päev hiljem hakkas sait ootamatult iseseisvalt tööle. Olles koostanud WebDAV-ist pingi IIS 6.0-s, leidsin, et vaikeseade on IIS-i tööprotsesside taaskäivitamine iga 30 tunni järel. See tähendab, et kui kontroll shellkoodist väljus, lõppes IIS-i töötaja protsess, seejärel taaskäivitas see paar korda ja läks siis 30 tunniks puhkama.
Kuna tagasiühendus tcp-ga esimest korda ebaõnnestus, omistasin selle probleemi suletud pordile. See tähendab, et ta eeldas mingisuguse tulemüüri olemasolu, mis ei lasknud väljuvatel ühendustel väljast pääseda. Hakkasin käivitama shellkoode, mis otsisid läbi paljude tcp ja udp portide, efekti polnud. Pöördühenduse laadimine http(de) kaudu Metasploitist ei töötanud – meterpreter/reverse_http(s). Järsku tekkis ühendus sama pordiga 80, kuid see katkes kohe. Panin selle arvele veel kujuteldava IPS-i tegevuse arvele, millele ei meeldinud arvestite liiklus. Arvestades tõsiasja, et puhas tcp-ühendus pordiga 80 ei läinud läbi, aga http-ühendus küll, järeldasin, et süsteemis oli kuidagi konfigureeritud http-puhverserver.
Proovisin isegi DNS-i kaudu arvestit (aitäh teie jõupingutuste eest päästsite palju projekte), meenutades esimest edu, kuid see ei töötanud isegi stendil - shellkood oli selle haavatavuse jaoks liiga mahukas.
Tegelikkuses nägi see välja selline: 3-4 rünnakukatset 5 minuti jooksul, siis ootamine 30 tundi. Ja nii kolm nädalat järjest. Panin isegi meeldetuletuse, et mitte aega raisata. Lisaks ilmnes erinevus test- ja tootmiskeskkonna käitumises: selle haavatavuse jaoks oli kaks sarnast ärakasutamist, üks Metasploitist ja teine Internetist, mis on teisendatud Shadow Brokersi versioonist. Nii et lahingus testiti ainult Metasploiti ja pingil testiti ainult teist, mis muutis silumise veelgi keerulisemaks ja ajas ajusid lõhki.
Lõpuks osutus tõhusaks shellkood, mis laadis http kaudu antud serverist exe-faili ja käivitas selle sihtsüsteemis. Shellcode oli piisavalt väike, et sinna mahtuda, aga vähemalt töötas. Kuna serverile TCP liiklus üldse ei meeldinud ja http(de)l kontrolliti meterpretteri olemasolu, siis otsustasin, et kõige kiirem on selle shellkoodi kaudu alla laadida DNS-meterpreterit sisaldav exe fail.
Siin tekkis taas probleem: exe-faili allalaadimisel ja, nagu katsed näitasid, olenemata sellest, milline, allalaadimine katkes. Jällegi ei meeldinud mõnele minu serveri ja uroloogi vahelisele turvaseadmele http-liiklus, mille sees oli exe. "Kiire" lahendus tundus olevat shellkoodi muutmine nii, et see hägusaks käigult http-liiklust, nii et exe asemel edastatakse abstraktsed binaarandmed. Lõpuks oli rünnak edukas, juhtimine saadi õhukese DNS-kanali kaudu:
Kohe selgus, et mul on kõige elementaarsemad IIS-i töövoo õigused, mis lubavad mul mitte midagi teha. Selline nägi see välja Metasploiti konsoolil:
Kõik pentesti meetodid viitavad tungivalt sellele, et juurdepääsu saamiseks peate õigusi suurendama. Tavaliselt ma seda kohapeal ei tee, kuna esimest juurdepääsu peetakse lihtsalt võrgu sisenemispunktiks ja samas võrgus oleva teise masina ohustamine on tavaliselt lihtsam ja kiirem kui olemasoleva hosti õiguste suurendamine. Kuid siin see nii ei ole, kuna DNS-kanal on väga kitsas ja see ei lase liiklusel tühjeneda.
Eeldades, et seda Windows 2003 serverit pole kuulsa MS17-010 haavatavuse tõttu parandatud, tunneldan liikluse pordi 445/TCP kaudu localhosti meterpreter DNS tunneli kaudu (jah, see on ka võimalik) ja proovin selle kaudu käivitada varem allalaaditud exe. haavatavus. Rünnak töötab, saan teise ühenduse, kuid SÜSTEEMI õigustega.
Huvitav on see, et nad üritasid ikkagi serverit MS17-010 eest kaitsta - selle välisel liidesel olid haavatavad võrguteenused keelatud. See kaitseb küll võrgu kaudu toimuvate rünnakute eest, kuid seestpoolt suunatud rünnak localhostile toimis, kuna te ei saa localhostis SMB-d lihtsalt kiiresti välja lülitada.
Järgmisena avalikustatakse uusi huvitavaid detaile:
- Omades SÜSTEEMI õigusi, saate hõlpsasti luua tagasiühenduse TCP kaudu. Ilmselgelt on otsese TCP keelamine piiratud IIS-i kasutaja jaoks rangelt probleem. Spoiler: IIS-i kasutajaliiklus mähiti mõlemas suunas kuidagi kohalikku ISA puhverserveri. Kuidas see täpselt töötab, ma pole reprodutseerinud.
- Olen teatud "DMZ-s" (ja see pole Active Directory domeen, vaid TÖÖRÜHM) - see kõlab loogiliselt. Kuid oodatud privaatse (“halli”) IP-aadressi asemel on mul täiesti “valge” IP-aadress, täpselt sama, mis varem ründasin. See tähendab, et ettevõte on IPv4-aadresside maailmas nii vana, et suudab endale lubada DMZ-tsooni säilitamist 128 "valge" aadressi jaoks ilma NAT-ita vastavalt skeemile, nagu on kujutatud Cisco 2005. aasta juhendites.
Kuna server on vana, töötab Mimikatz kindlasti otse mälust:
Saan kohaliku administraatori parooli, tunneldan RDP liiklust TCP kaudu ja login sisse hubasele töölauale. Kuna sain serveriga teha, mida tahtsin, eemaldasin viirusetõrje ja avastasin, et serverile pääseb Internetist ainult TCP portide 80 ja 443 kaudu ning 443 ei olnud hõivatud. Seadistan 443-le OpenVPN-serveri, lisan oma VPN-liiklusele NAT-funktsioonid ja saan oma OpenVPN-i kaudu piiramatul kujul otsejuurdepääsu DMZ-võrgule. Tähelepanuväärne on, et ISA, millel on mõned mitte-inaktiveeritud IPS-funktsioonid, blokeeris minu liikluse pordi skaneerimisega, mille jaoks tuli see asendada lihtsama ja ühilduvama RRAS-iga. Nii et pentestijatel tuleb vahel ikka igasuguseid asju administreerida.
Tähelepanelik lugeja küsib: "Aga teine sait - NTLM-i autentimisega viki, millest on nii palju kirjutatud?" Sellest lähemalt hiljem.
2. osa. Kas te ikka ei krüpteeri? Siis me tuleme teie juurde juba siin
Seega on juurdepääs DMZ-võrgu segmendile. Peate minema domeeni administraatori poole. Esimene asi, mis meelde tuleb, on DMZ-segmendi teenuste turvalisuse automaatne kontrollimine, eriti kuna paljud neist on nüüdseks uurimistööks avatud. Tüüpiline pilt läbitungimistesti ajal: välisperimeeter on paremini kaitstud kui siseteenused ja suure infrastruktuuri sees mistahes juurdepääsu saamisel on palju lihtsam domeenis laiendatud õigusi hankida ainult tänu sellele, et see domeen hakkab olema tööriistadele juurdepääsetav ja teiseks, mitme tuhande hostiga infrastruktuuris on alati paar kriitilist probleemi.
Laen skannereid DMZ kaudu OpenVPN tunneli kaudu ja ootan. Avan raporti - jälle ei midagi tõsist, ilmselt läbis keegi sama meetodi enne mind. Järgmine samm on uurida, kuidas DMZ-võrgu hostid suhtlevad. Selleks käivitage esmalt tavaline Wireshark ja kuulake levitaotlusi, peamiselt ARP-i. ARP-pakette koguti terve päeva. Selgub, et selles segmendis kasutatakse mitut lüüsi. See tuleb hiljem kasuks. Kombineerides ARP päringute ja vastuste andmeid ning pordi skaneerimise andmeid, leidsin lisaks neile varem tuntud teenustele, nagu veeb ja meil, ka kohtvõrgu seest kasutajaliikluse väljumispunktid.
Kuna hetkel ei olnud mul ligipääsu teistele süsteemidele ja mul polnud ühtki kontot ettevõtte teenuste jaoks, siis otsustati ARP Spoofingu abil vähemalt osa konto liiklusest välja õngitseda.
Cain&Abel käivitati uroloogi serveris. Võttes arvesse tuvastatud liiklusvooge, valiti välja man-in-the-middle rünnaku kõige lootustandvamad paarid ja seejärel võeti osa võrguliiklust vastu lühiajalise käivitamise teel 5-10 minuti jooksul serveri taaskäivitamise taimeriga. külmumise korral. Nagu naljas, oli kaks uudist:
- Hea: volikirju koguti palju ja rünnak tervikuna toimis.
- Halb: kõik volikirjad pärinesid kliendi enda klientidelt. Tugiteenuseid pakkudes ühendusid kliendispetsialistid nende klientide teenustega, kellel polnud alati liikluse krüpteerimist seadistatud.
Selle tulemusel omandasin palju tunnistusi, mis olid projekti kontekstis kasutud, kuid rünnakuohu demonstratsioonina kindlasti huvitavad. Telnetiga suurfirmade piirimarsruuterid, edastatud silumise http-pordid sisemisele CRM-ile koos kõigi andmetega, Windows XP-st otsejuurdepääs RDP-le kohtvõrgus ja muu obskurantism. Selgus selline .
Leidsin ka naljaka võimaluse liiklusest kirju koguda, midagi sellist. See on näide valmis kirjast, mis läks meie kliendilt tema kliendi SMTP-porti, jällegi ilma krüptimiseta. Teatud Andrei palub oma nimekaimul dokumentatsioon uuesti saata ja see laetakse ühes vastuskirjas sisselogimise, parooli ja lingiga pilvkettale:
See on veel üks meeldetuletus kõigi teenuste krüpteerimiseks. Pole teada, kes ja millal konkreetselt teie andmeid loeb ja kasutab – pakkuja, mõne teise ettevõtte süsteemiadministraator või selline pentester. Ma vaikin sellest, et paljud inimesed saavad krüpteerimata liiklust lihtsalt pealt kuulata.
Vaatamata näilisele edule see meid eesmärgile lähemale ei viinud. Muidugi võis kaua istuda ja väärtuslikku infot välja õngitseda, aga see pole fakt, et see sinna ilmuks ja rünnak ise on võrgu terviklikkuse seisukohalt väga riskantne.
Pärast järjekordset teenustesse süvenemist tuli pähe huvitav idee. On olemas selline utiliit nimega Responder (selle nimega kasutusnäiteid on lihtne leida), mis edastustaotlusi "mürgitades" kutsub esile ühendusi mitmesuguste protokollide, näiteks SMB, HTTP, LDAP jne kaudu. erinevatel viisidel, siis palub kõigil, kes ühenduse loovad, autentida ja seadistada nii, et autentimine toimuks NTLM-i kaudu ja ohvrile läbipaistvas režiimis. Enamasti kogub ründaja sel viisil NetNTLMv2 käepigistusi ja taastab neilt sõnastiku abil kiiresti kasutaja domeeni paroolid. Siin tahtsin midagi sarnast, kuid kasutajad istusid "seina taga" või õigemini eraldati nad tulemüüriga ja pääsesid veebile Blue Coati puhverserveri klastri kaudu.
Pidage meeles, et täpsustasin, et Active Directory domeeninimi langes kokku välise domeeniga, see tähendab, et see oli company.ru? Nii et Windows, täpsemalt Internet Explorer (ja Edge ja Chrome), võimaldavad kasutajal NTLM-i kaudu HTTP-s läbipaistvalt autentida, kui nad leiavad, et sait asub mõnes sisevõrgutsoonis. Üks sisevõrgu tunnuseid on juurdepääs "hallile" IP-aadressile või lühikesele DNS-nimele, st ilma punktideta. Kuna neil oli server “valge” IP- ja DNS-nimega preobrazhensky.company.ru ning domeenimasinad saavad nime lihtsustamiseks tavaliselt DHCP kaudu Active Directory domeeni järelliite, pidid nad aadressiribale kirjutama vaid URL-i. , et nad leiaksid õige tee kahjustatud uroloogi serverisse, unustamata, et seda nimetatakse nüüd sisevõrguks. See tähendab, et samal ajal annab mulle kasutaja teadmata NTLM-käepigistus. Jääb vaid sundida kliendibrausereid mõtlema tungivale vajadusele selle serveriga ühendust võtta.
Imeline Intercepter-NG utiliit tuli appi (aitäh ). See võimaldas teil liiklust käigult muuta ja töötas suurepäraselt operatsioonisüsteemis Windows 2003. Sellel oli isegi eraldi funktsioon ainult JavaScripti failide muutmiseks liiklusvoos. Kavas oli omamoodi massiivne saidiülene skriptimine.
Blue Coati puhverserverid, mille kaudu kasutajad pääsesid ligi globaalsele veebile, salvestasid perioodiliselt staatilist sisu vahemällu. Liikluse pealtkuulamisel oli selge, et nad töötasid ööpäevaringselt, nõudes lõputult sageli kasutatavat staatilisust, et tipptundidel sisu kuvamist kiirendada. Lisaks oli BlueCoatil konkreetne User-Agent, mis eristas seda selgelt tegelikust kasutajast.
Valmistati ette Javascript, mida Intercepter-NG abil rakendati öösel tund aega iga Blue Coati JS-failidega vastuse jaoks. Skript tegi järgmist:
- Määras praeguse brauseri kasutajaagendi abil. Kui see oli Internet Explorer, Edge või Chrome, töötas see edasi.
- Ootasin kuni lehe DOM moodustati.
- Sisestas DOM-i nähtamatu kujutis vormi atribuudiga src :8080/NNNNNNN.png, kus NNN on suvalised numbrid, nii et BlueCoat seda vahemällu ei salvesta.
- Määrake globaalse lipu muutuja, mis näitab, et süstimine on lõpetatud ja pilte pole enam vaja sisestada.
Brauser proovis seda pilti laadida; ohustatud serveri pordis 8080 ootas seda minu sülearvutisse TCP tunnel, kus töötas sama Responder, mis nõudis brauserilt NTLM-i kaudu sisselogimist.
Responderi logide järgi otsustades tulid inimesed hommikul tööle, lülitasid tööjaamad sisse, seejärel hakkasid massiliselt ja märkamatult uroloogi serverit külastama, unustamata NTLM-i käepigistuste “tühjendamist”. Terve päeva sadas käepigistusi ja selgelt kogunes materjali ilmselgelt edukaks paroolide taastamise rünnakuks. Vastajate logid nägid välja sellised:
Kasutajate massilised salajased külastused uroloogi serverisse
Tõenäoliselt olete juba märganud, et kogu see lugu on üles ehitatud põhimõttel "kõik oli hästi, aga siis oli jama, siis tuli ületamine ja siis läks kõik korda." Nii et siin oli jama. Viiekümnest ainulaadsest käepigistusest ei paljastatud ainsatki. Ja see võtab arvesse asjaolu, et isegi surnud protsessoriga sülearvutis töödeldakse neid NTLMv2 käepigistust kiirusega mitusada miljonit katset sekundis.
Tuli relvastada end paroolimutatsioonitehnika, videokaardi, paksema sõnastikuga ja oodata. Üle pika aja avalikustati mitu kontot paroolidega kujul “Q11111111....1111111q”, mis viitab sellele, et kunagi olid kõik kasutajad sunnitud välja mõtlema väga pika, erineva tähesuurusega parooli, mis samuti pidi olema olla keeruline. Kuid kogenud kasutajat ei saa lollitada ja nii tegi ta endale meeldejätmise lihtsamaks. Kokku rikuti umbes 5 kontot ja ainult ühel neist oli teenustele väärtuslikke õigusi.
3. osa. Roskomnadzor lööb vastu
Seega saadi esimesed domeenikontod. Kui te pole pika lugemise järel selleks hetkeks magama jäänud, mäletate ilmselt, et mainisin teenust, mis ei nõua teist autentimist: see on NTLM-i autentimisega viki. Esimese asjana tuli muidugi sinna sisse astuda. Sisemise teadmistebaasi süvenemine tõi kiiresti tulemusi:
- Ettevõttel on WiFi-võrk, mille autentimine toimub kohaliku võrgu juurdepääsuga domeenikontode abil. Praeguse andmestikuga on see juba toimiv ründevektor, kuid kontorisse tuleb minna jalgadega ja asuda kuskil kliendi kontori territooriumil.
- Leidsin juhendi, mille järgi oli teenus, mis võimaldas... iseseisvalt registreerida “teise teguri” autentimisseade, kui kasutaja on lokaalses võrgus ja mäletab kindlalt oma domeeni sisselogimist ja parooli. Sel juhul määras "sees" ja "väljas" selle teenuse sadama juurdepääsetavus kasutajale. Port ei olnud Internetist ligipääsetav, kuid oli üsna juurdepääsetav DMZ kaudu.
Loomulikult lisandus minu telefonis oleva rakenduse näol koheselt ohustatud kontole ka “teine tegur”. Seal oli programm, mis võis kas valjuhäälselt saata telefonile tõukepäringu toimingu jaoks nuppudega “kinnita” / “mitte kinnitada” või näidata vaikselt ekraanil OTP koodi edasiseks iseseisvaks sisestamiseks. Veelgi enam, esimene meetod pidi juhiste järgi olema ainuõige, kuid erinevalt OTP-meetodist see ei töötanud.
Kuna "teine tegur" oli katki, pääsesin Citrix Netscaleri lüüsis juurde Outlook Web Accessi meilidele ja kaugjuurdepääsule. Outlooki kirjas oli üllatus:
Selles haruldases kaadris näete, kuidas Roskomnadzor pentestijaid aitab
Need olid esimesed kuud pärast Telegrami kuulsat "fänni" blokeerimist, kui terved tuhandete aadressidega võrgud kadusid paratamatult juurdepääsust. Sai selgeks, miks tõuge kohe ei toiminud ja miks minu “ohver” häirekella ei löönud, sest nad hakkasid tema kontot lahtiolekuaegadel kasutama.
Igaüks, kes tunneb Citrix Netscalerit, kujutab ette, et seda rakendatakse tavaliselt nii, et kasutajale saab edastada ainult pildiliidese, püüdes mitte anda talle tööriistu kolmandate osapoolte rakenduste käivitamiseks ja andmete edastamiseks, piirates igal võimalikul viisil toiminguid. standardsete juhtkestade kaudu. Minu "ohver" sai oma ameti tõttu ainult 1C:
Pärast 1C liideses veidi ringi kõndimist leidsin, et seal on välised töötlemismoodulid. Neid saab laadida liidesest ning need käivitatakse olenevalt õigustest ja sätetest kliendis või serveris.
Palusin oma 1C programmeerijatel luua töötlus, mis aktsepteeriks stringi ja käivitaks selle. 1C keeles näeb protsessi käivitamine välja umbes selline (võetud Internetist). Kas olete nõus, et 1C keele süntaks hämmastab venekeelseid inimesi oma spontaansusega?
Töötlemine viidi läbi suurepäraselt; selgus, et see oli see, mida pentesters nimetavad "kestaks" - selle kaudu käivitati Internet Explorer.
Varem leiti kirjast süsteemi aadress, mis võimaldab territooriumile pääsmeid tellida. Tellisin pääsme juhuks, kui peaksin kasutama WiFi ründevektorit.
Internetis räägitakse, et kliendi kontoris oli ikka maitsev tasuta toitlustus, aga eelistasin siiski ründe arendada eemalt, on rahulikum.
AppLocker aktiveeriti Citrixi kasutavas rakendusserveris, kuid sellest tehti mööda. Sama Meterpreter laaditi ja käivitati DNS-i kaudu, kuna http(de) versioonid ei tahtnud ühendust luua ja ma ei teadnud sel ajal sisemist puhverserveri aadressi. Muide, sellest hetkest muutus väline pentest sisuliselt täielikult sisemiseks.
4. osa. Kasutajate administraatoriõigused on halvad, eks?
Pentesteri esimene ülesanne domeeni kasutaja seansi üle kontrolli saavutamisel on koguda kogu teave domeeni õiguste kohta. Seal on BloodHoundi utiliit, mis võimaldab LDAP-protokolli kaudu domeenikontrollerist automaatselt alla laadida teavet kasutajate, arvutite, turvarühmade kohta ja SMB kaudu - teavet selle kohta, milline kasutaja on hiljuti sisse loginud ja kes on kohalik administraator.
Tüüpiline domeeni administraatori õiguste arestimise tehnika näib olevat lihtsustatud monotoonsete toimingute tsüklina:
- Me läheme domeeniarvutitesse, kus on juba hõivatud domeenikontode alusel kohaliku administraatori õigused.
- Käivitame Mimikatzi ja saame vahemällu salvestatud paroolid, Kerberose piletid ja hiljuti sellesse süsteemi sisse logitud domeenikontode NTLM-räsi. Või eemaldame lsass.exe protsessi mälupildi ja teeme sama meie poolel. See töötab hästi vaikeseadetega Windowsiga, mis on noorem kui 2012R2/Windows 8.1.
- Määrame kindlaks, kus on ohustatud kontodel kohaliku administraatori õigused. Kordame esimest punkti. Mingil etapil omandame kogu domeeni administraatoriõigused.
"Tsükli lõpp;", nagu 1C programmeerijad siin kirjutaksid.
Niisiis osutus meie kasutaja kohalikuks administraatoriks vaid ühes Windows 7-ga hostis, mille nimi sisaldas sõna "VDI" või "virtuaalse töölaua infrastruktuur", isiklikud virtuaalsed masinad. Tõenäoliselt pidas VDI teenuse kujundaja silmas seda, et kuna VDI on kasutaja isiklik operatsioonisüsteem, siis isegi kui kasutaja muudab tarkvarakeskkonda oma äranägemise järgi, saab hosti ikkagi "ümber laadida". Arvasin ka, et üldiselt oli idee hea, läksin selle isikliku VDI hosti juurde ja tegin sinna pesa:
- Installisin sinna OpenVPN-kliendi, mis tegi tunneli läbi Interneti minu serverisse. Klienti tuli sundida läbima domeeni autentimisega sama Blue Coati, kuid OpenVPN tegi seda, nagu öeldakse, "kastist väljas".
- Installitud OpenSSH VDI-le. Noh, tõesti, mis on Windows 7 ilma SSH-ta?
See nägi otse välja selline. Lubage mul teile meelde tuletada, et seda kõike tuleb teha Citrixi ja 1C kaudu:
Üks naaberarvutitele juurdepääsu edendamise meetod on kontrollida kohaliku administraatori paroolide sobivust. Siin ootas kohe õnn: kohaliku vaikeadministraatori (keda järsku kutsuti administraatoriks) NTLM-i räsi jõudis räsi rünnaku kaudu naabruses asuvatele VDI hostidele, mida oli mitusada. Loomulikult tabas rünnak neid kohe.
Siin tulistasid VDI administraatorid endale kaks korda jalga:
- Esimene kord oli siis, kui VDI-masinaid LAPS-i alla ei viidud, säilitades sisuliselt sama kohaliku administraatori parooli pildilt, mida VDI-s massiliselt kasutusele võeti.
- Vaikeadministraator on ainus kohalik konto, mis on räsi rünnakute suhtes haavatav. Isegi sama parooliga oleks võimalik vältida massilist kompromissi, luues keerulise juhusliku parooliga teise kohaliku administraatori konto ja blokeerides vaikeparooli.
Miks on selles Windowsis SSH-teenus? Väga lihtne: nüüd ei pakkunud OpenSSH-server mitte ainult mugavat interaktiivset käsukestat, mis ei seganud kasutaja tööd, vaid ka VDI-s socks5 puhverserverit. Nende sokkide kaudu ühendasin SMB kaudu ja kogusin vahemällu salvestatud kontosid kõigist nendest sadadest VDI-masinatest, seejärel otsisin teed domeeni administraatorini, kasutades neid BloodHoundi graafikutel. Kuna minu käsutuses oli sadu hoste, leidsin selle tee üsna kiiresti. Domeeni administraatori õigused on saadud.
Siin on pilt Internetist, millel on sarnane otsing. Ühendused näitavad, kes on seal, kus on administraator ja kes on kuhu sisse logitud.
Muide, pidage meeles tingimust projekti algusest – "ära kasuta sotsiaalset manipuleerimist." Seega teen ettepaneku mõelda, kui palju kogu see eriefektidega Bollywood ära lõigatakse, kui oleks veel võimalik kasutada banaalset andmepüügi. Aga minu jaoks isiklikult oli seda kõike väga huvitav teha. Loodan, et teile meeldis seda lugeda. Muidugi ei tundu iga projekt nii intrigeeriv, kuid töö tervikuna on väga väljakutsuv ega lase sellel soiku jääda.
Tõenäoliselt tekib kellelgi küsimus: kuidas ennast kaitsta? Isegi see artikkel kirjeldab paljusid tehnikaid, millest paljudest Windowsi administraatorid isegi ei tea. Siiski teen ettepaneku vaadata neid hakitud põhimõtete ja infoturbemeetmete vaatenurgast:
- ärge kasutage vananenud tarkvara (mäletate Windows 2003 alguses?)
- ärge hoidke mittevajalikke süsteeme sisse lülitatud (miks oli uroloogi veebisait?)
- kontrollige ise kasutajate paroolide tugevust (muidu teevad seda sõdurid... pentesterid)
- erinevate kontode jaoks pole samu paroole (VDI kompromiss)
- ja muud
Loomulikult on seda väga raske rakendada, kuid järgmises artiklis näitame praktikas, et see on täiesti võimalik.
Allikas: www.habr.com