Tämä artikkeli on kirjoitettu erittäin onnistuneen pentestin perusteella, jonka Group-IB:n asiantuntijat suorittivat pari vuotta sitten: tapahtui tarina, joka voitiin sovittaa elokuvaan Bollywoodissa. Nyt luultavasti seuraa lukijan reaktio: "Voi, toinen PR-artikkeli, taas näitä kuvataan, kuinka hyviä ne ovat, älä unohda ostaa pentestiä." No, toisaalta on. On kuitenkin monia muita syitä, miksi tämä artikkeli ilmestyi. Halusin näyttää, mitä pentesterit tarkalleen ottaen tekevät, kuinka mielenkiintoista ja ei-triviaalia tämä työ voi olla, mitä hauskoja tilanteita projekteissa voi syntyä, ja mikä tärkeintä, näyttää live-materiaalia oikeilla esimerkeillä.
Maailman vaatimattomuuden tasapainon palauttamiseksi kirjoitamme hetken kuluttua pentestistä, joka ei mennyt hyvin. Näytämme, kuinka hyvin suunnitellut prosessit yrityksessä voivat suojautua useilta hyökkäyksiltä, jopa hyvin valmistautuneilta, yksinkertaisesti siksi, että nämä prosessit ovat olemassa ja toimivat.
Tämän artikkelin asiakkaalle kaikki oli myös yleisesti erinomaista, ainakin tunteidemme mukaan parempi kuin 95% Venäjän federaation markkinoista, mutta siellä oli useita pieniä vivahteita, jotka muodostivat pitkän tapahtumaketjun, joka ensin johti pitkään työstä kertovaan raporttiin ja sitten tähän artikkeliin.
Joten, varataanpa popcornia ja tervetuloa salapoliisiin. Sana - Pavel Suprunyuk, Group-IB:n Audit and Consulting -osaston tekninen johtaja.
Osa 1. Pochkin lääkäri
2018 On asiakas - korkean teknologian IT-yritys, joka itse palvelee monia asiakkaita. Haluatko saada vastauksen kysymykseen: onko mahdollista saada Active Directory -verkkotunnuksen järjestelmänvalvojan oikeudet ilman alkutietoa ja pääsyä Internetin kautta? En ole kiinnostunut sosiaalisesta suunnittelusta (), he eivät aio häiritä työtä tarkoituksella, mutta voivat vahingossa - ladata uudelleen esimerkiksi oudosti toimivan palvelimen. Lisätavoitteena on tunnistaa mahdollisimman monia muita hyökkäysvektoreita ulkokehää vastaan. Yritys tekee säännöllisesti tällaisia testejä, ja nyt uuden testin määräaika on saapunut. Olosuhteet ovat lähes tyypilliset, riittävät, ymmärrettävät. Aloitetaan.
Asiakkaalla on nimi - olkoon se "Yritys", pääsivustolla . Tietysti asiakasta kutsutaan eri tavalla, mutta tässä artikkelissa kaikki on persoonatonta.
Teen verkkotutkinnan - selvitän mitkä osoitteet ja verkkotunnukset on rekisteröity asiakkaalle, piirrän verkkokaavion, miten palvelut jaetaan näihin osoitteisiin. Saan tuloksen: yli 4000 elävää IP-osoitetta. Katson verkkotunnuksia näissä verkostoissa: onneksi valtaosa on asiakkaan asiakkaille tarkoitettuja verkkoja, emmekä ole niistä muodollisesti kiinnostuneita. Asiakas ajattelee samoin.
Jäljellä on yksi verkko, jossa on 256 osoitetta, jolle tällä hetkellä on jo käsitys toimialueiden ja aliverkkotunnusten jakautumisesta IP-osoitteiden mukaan, on tietoa skannatuista porteista, joten voit katsoa palveluista mielenkiintoisia. Samanaikaisesti kaikenlaisia skannereita käynnistetään saatavilla oleviin IP-osoitteisiin ja erikseen verkkosivustoille.
Palveluita on paljon. Yleensä tämä on iloa pentesterille ja nopean voiton odotusta, sillä mitä enemmän palveluita on, sitä suurempi on hyökkäyskenttä ja sitä helpompi on löytää artefakti. Nopea vilkaisu sivustoille osoitti, että suurin osa niistä on suurten globaalien yritysten tunnettujen tuotteiden verkkorajapintoja, jotka ilmeisesti kertovat, että ne eivät ole tervetulleita. He kysyvät käyttäjätunnusta ja salasanaa, ravistelevat kenttää toisen tekijän syöttämistä varten, pyytävät TLS-asiakasvarmennetta tai lähettävät sen Microsoft ADFS:lle. Jotkut ovat yksinkertaisesti saavuttamattomissa Internetistä. Joillekin sinun täytyy luonnollisesti olla erityinen maksettu asiakas kolmea palkkaa varten tai tietää tarkka URL-osoite syöttämistä varten. Ohitetaan toinen viikko asteittaista epätoivoa yrittäessämme "murtautua" läpi ohjelmistoversioista tunnettujen haavoittuvuuksien varalta, etsiä piilotettua sisältöä verkkopoluilta ja vuotaneita tilejä kolmansien osapuolien palveluista, kuten LinkedIn, sekä yrittää arvata salasanoja niiden avulla. itse kirjoitettujen verkkosivustojen haavoittuvuuksien kaivamiseen - muuten, tilastojen mukaan tämä on lupaavin ulkoisen hyökkäyksen vektori nykyään. Panen heti merkille elokuva-ase, joka ampui myöhemmin.
Löysimme siis kaksi sivustoa, jotka erottuivat sadoista palveluista. Näillä sivustoilla oli yksi yhteinen piirre: jos et tee huolellista verkkotutkintaa verkkotunnuksen mukaan, vaan etsit avoimia portteja tai kohdistat haavoittuvuustarkistin tunnettuun IP-alueeseen, nämä sivustot välttyvät skannauksesta eikä niitä yksinkertaisesti tehdä. näkyy ilman DNS-nimeä. Ehkä ne jäivät väliin ainakin aikaisemmin, eivätkä automaattityökalumme löytäneet niistä mitään ongelmia, vaikka ne olisi lähetetty suoraan resurssille.
Muuten, siitä, mitä aiemmin käynnistetyt skannerit löysivät yleensä. Muistutan teitä: joillekin ihmisille "pentest" vastaa "automaattista skannausta". Mutta tämän projektin skannerit eivät sanoneet mitään. No, maksimin osoittivat keskikokoiset haavoittuvuudet (vakavuuden suhteen 3 viidestä): joissakin palveluissa huono TLS-sertifikaatti tai vanhentuneet salausalgoritmit ja useimmilla sivustoilla Clickjacking. Mutta tämä ei vie sinua tavoitteellesi. Ehkä skannerit olisivat tässä hyödyllisempiä, mutta muistutan teitä: asiakas voi itse ostaa tällaisia ohjelmia ja testata itseään niillä, ja hän on surkeiden tulosten perusteella jo tarkistanut.
Palataan "poikkeaviin" sivustoihin. Ensimmäinen on jotain paikallista Wikiä epätyypillisessä osoitteessa, mutta tässä artikkelissa se on wiki.company[.]ru. Hän pyysi myös heti kirjautumistunnusta ja salasanaa, mutta selaimen NTLM:n kautta. Käyttäjälle tämä näyttää askeettiselta ikkunalta, jossa pyydetään antamaan käyttäjätunnus ja salasana. Ja tämä on huono käytäntö.
Pieni huomautus. NTLM kehäsivustoilla on huono useista syistä. Ensimmäinen syy on se, että Active Directory -toimialueen nimi paljastetaan. Esimerkissämme se osoittautui myös nimellä company.ru, aivan kuten "ulkoinen" DNS-nimi. Tämän tietäen voit huolellisesti valmistella jotain haitallista niin, että se suoritetaan vain organisaation verkkotunnuksen koneella, ei jossain hiekkalaatikossa. Toiseksi todennus kulkee suoraan toimialueen ohjaimen kautta NTLM:n kautta (yllätys, eikö?), ja siinä on kaikki "sisäisten" verkkokäytäntöjen ominaisuudet, mukaan lukien tilien estäminen ylittämästä salasanan syöttöyritysten määrää. Jos hyökkääjä saa tietää kirjautumiset, hän yrittää salasanoja niille. Jos olet määritetty estämään tilejä antamasta vääriä salasanoja, se toimii ja tili estetään. Kolmanneksi on mahdotonta lisätä toista tekijää tällaiseen todentamiseen. Jos joku lukijoista vielä tietää miten, kerro minulle, se on todella mielenkiintoista. Neljänneksi haavoittuvuus pass-the-hash-hyökkäyksille. ADFS keksittiin muun muassa suojaamaan kaikkea tätä vastaan.
Microsoft-tuotteissa on yksi huono ominaisuus: vaikka et erityisesti julkaissut tällaista NTLM:ää, se asennetaan oletuksena ainakin OWA:ssa ja Lyncissä.
Muuten, tämän artikkelin kirjoittaja sulki kerran vahingossa noin 1000 yhden suuren pankin työntekijöiden tiliä vain yhdessä tunnissa samalla menetelmällä ja näytti sitten hieman kalpealta. Myös pankin IT-palvelut olivat kalpeat, mutta kaikki päättyi hyvin ja asianmukaisesti, saimme jopa kiitosta siitä, että löysimme tämän ongelman ensimmäisinä ja saimme nopean ja päättäväisen ratkaisun.
Toisella sivustolla oli osoite "ilmeisesti jonkinlainen sukunimi.company.ru". Löysin sen Googlen kautta, jotain tällaista sivulta 10. Suunnittelu oli XNUMX-luvun alusta ja puolivälissä, ja kunniallinen henkilö katseli sitä pääsivulta, jotakuinkin näin:
Tässä otin still-kuvan "Koiran sydämestä", mutta uskokaa minua, se oli epämääräisesti samanlainen, jopa värisuunnittelu oli samanlaisissa sävyissä. Anna sivuston kutsua preobrazhensky.company.ru.
Se oli henkilökohtainen verkkosivusto... urologille. Mietin, mitä urologin verkkosivusto teki korkean teknologian yrityksen aliverkkotunnuksella. Nopea kaivaus Googleen osoitti, että tämä lääkäri oli yksi asiakkaamme oikeushenkilön perustajista ja jopa lahjoitti noin 1000 XNUMX ruplaa osakepääomaan. Sivusto on luultavasti luotu monta vuotta sitten ja isännöinninä käytettiin asiakkaan palvelinresursseja. Sivusto on pitkään menettänyt merkityksensä, mutta jostain syystä se jätettiin toimimaan pitkään.
Haavoittuvuuksien suhteen sivusto itsessään oli turvallinen. Tulevaisuudessa sanon, että se oli joukko staattisia tietoja - yksinkertaisia html-sivuja, joihin oli lisätty munuaisten ja rakkojen muodossa olevia kuvia. Tällaista sivustoa on turha "rikota".
Mutta alla oleva verkkopalvelin oli mielenkiintoisempi. HTTP Server -otsikon perusteella siinä oli IIS 6.0, mikä tarkoittaa, että se käytti käyttöjärjestelmänä Windows 2003:a. Skanneri oli aiemmin havainnut, että tämä tietty urologin verkkosivusto, toisin kuin muut saman verkkopalvelimen virtuaaliset isännät, vastasi PROPFIND-komentoon, mikä tarkoittaa, että se käytti WebDAV:ia. Muuten, skanneri palautti nämä tiedot merkillä Info (skanneriraporttien kielellä tämä on pienin vaara) - tällaiset asiat yleensä ohitetaan. Yhdessä tämä antoi mielenkiintoisen vaikutuksen, joka paljastui vasta toisen Googlen kaivauksen jälkeen: Shadow Brokers -sarjaan liittyvä harvinainen puskurin ylivuotohaavoittuvuus, nimittäin CVE-2017-7269, jolla oli jo valmis hyväksikäyttö. Toisin sanoen, sinulla on ongelmia, jos sinulla on Windows 2003 ja WebDAV toimii IIS:ssä. Vaikka Windows 2003:n käyttö tuotannossa vuonna 2018 on ongelma sinänsä.
Hyökkäys päätyi Metasploitiin ja sitä testattiin välittömästi kuormalla, joka lähetti DNS-pyynnön valvotulle palvelulle - Burp Colaboratoria käytetään perinteisesti DNS-pyyntöjen sieppaamiseen. Yllätyksekseni se toimi ensimmäisellä kerralla: DNS-knockout vastaanotettiin. Seuraavaksi yritettiin luoda takaisinkytkentä portin 80 kautta (eli verkkoyhteys palvelimelta hyökkääjälle, pääsy uhripalvelimen cmd.exe-tiedostoon), mutta sitten tapahtui fiasko. Yhteys ei tullut perille, ja kolmannen sivuston käyttöyrityksen jälkeen kaikki mielenkiintoiset kuvat katosivat ikuisesti.
Yleensä tätä seuraa kirje tyyliin "asiakas, herää, pudotimme kaiken". Mutta meille kerrottiin, että sivustolla ei ole mitään tekemistä liiketoimintaprosessien kanssa ja se toimii siellä ilman syytä, kuten koko palvelin, ja että voimme käyttää tätä resurssia haluamallamme tavalla.
Noin päivää myöhemmin sivusto alkoi yhtäkkiä toimia itsenäisesti. Olen rakentanut penkin WebDAV:sta IIS 6.0:ssa ja huomasin, että oletusasetus on käynnistää IIS-työntekijäprosessit uudelleen 30 tunnin välein. Eli kun ohjaus poistui shellkoodista, IIS-työntekijäprosessi päättyi, sitten se käynnistyi uudelleen muutaman kerran ja meni sitten lepäämään 30 tunniksi.
Koska takaisinkytkentä tcp:hen epäonnistui ensimmäisen kerran, annoin tämän ongelman johtuvan suljetusta portista. Toisin sanoen hän oletti jonkinlaisen palomuurin olemassaolon, joka ei sallinut lähtevien yhteyksien kulkea ulos. Aloin ajaa shellkoodeja, jotka hakivat useista tcp- ja udp-porteista, ei vaikutusta. Käänteiset yhteyden lataukset http:n kautta Metasploitista eivät toimineet - meterpreter/reverse_http(s). Yhtäkkiä yhteys samaan porttiin 80 muodostettiin, mutta se katkesi välittömästi. Löysin tämän vielä kuvitteellisen IPS:n toiminnasta, joka ei pitänyt mittariliikenteestä. Ottaen huomioon sen tosiasian, että puhdas tcp-yhteys porttiin 80 ei mennyt läpi, mutta http-yhteys meni, päätin, että http-välityspalvelin oli jotenkin konfiguroitu järjestelmään.
Kokeilin jopa meterpreteria DNS:n kautta (kiitos ponnisteluistasi, pelasti monia projekteja), muistutti ensimmäisestä menestyksestä, mutta se ei toiminut edes jalustalla - shell-koodi oli liian suuri tälle haavoittuvuudelle.
Todellisuudessa se näytti tältä: 3-4 hyökkäysyritystä 5 minuutin sisällä, sitten odotus 30 tuntia. Ja niin kolme viikkoa peräkkäin. Laitoin jopa muistutuksen, jotta en tuhlaa aikaa. Lisäksi testi- ja tuotantoympäristöjen käyttäytymisessä oli ero: tälle haavoittuvuudelle oli kaksi samanlaista hyväksikäyttöä, yksi Metasploitista, toinen Internetistä, muunnettu Shadow Brokers -versiosta. Joten vain Metasploitia testattiin taistelussa ja vain toista testattiin penkillä, mikä teki virheenkorjauksesta entistä vaikeampaa ja oli aivot murskaava.
Lopulta shell-koodi, joka latasi exe-tiedoston tietystä palvelimesta http:n kautta ja käynnisti sen kohdejärjestelmässä, osoittautui tehokkaaksi. Shellcode oli tarpeeksi pieni mahtumaan, mutta ainakin se toimi. Koska palvelin ei pitänyt TCP-liikenteestä ollenkaan ja http(t) tarkastettiin meterpreterin varalta, päätin, että nopein tapa oli ladata DNS-meterpreterin sisältävä exe-tiedosto tämän shell-koodin kautta.
Tässä taas ilmeni ongelma: exe-tiedostoa ladattaessa ja, kuten yritykset osoittivat, lataus keskeytettiin riippumatta siitä, mikä. Jälleen jokin turvalaite palvelimeni ja urologin välillä ei pitänyt http-liikenteestä, jonka sisällä oli exe. "Nopea" ratkaisu tuntui olevan shell-koodin muuttaminen niin, että se hämärtäisi http-liikennettä lennossa, jolloin abstraktia binaaridataa siirrettäisiin exe:n sijaan. Lopulta hyökkäys onnistui, ohjaus vastaanotettiin ohuen DNS-kanavan kautta:
Heti kävi selväksi, että minulla on alkeellisimmat IIS-työnkulkuoikeudet, joiden ansiosta en voi tehdä mitään. Tältä se näytti Metasploit-konsolissa:
Kaikki pentest-menetelmät viittaavat vahvasti siihen, että sinun on lisättävä oikeuksia pääsyä varten. En yleensä tee tätä paikallisesti, koska aivan ensimmäinen pääsy nähdään yksinkertaisesti verkon sisääntulopisteenä, ja toisen koneen vaarantaminen samassa verkossa on yleensä helpompaa ja nopeampaa kuin oikeuksien laajentaminen olemassa olevaan isäntään. Mutta näin ei ole tässä tapauksessa, koska DNS-kanava on hyvin kapea ja se ei salli liikenteen tyhjenemistä.
Olettaen, että tätä Windows 2003 -palvelinta ei ole korjattu kuuluisan MS17-010-haavoittuvuuden vuoksi, tunnelin liikenteen porttiin 445/TCP localhostin meterpreter DNS-tunnelin kautta (kyllä, tämä on myös mahdollista) ja yritän suorittaa aiemmin ladatun exe-tiedoston. haavoittuvuus. Hyökkäys toimii, saan toisen yhteyden, mutta JÄRJESTELMÄ-oikeuksilla.
On mielenkiintoista, että he silti yrittivät suojata palvelinta MS17-010:lta - sen ulkoisesta rajapinnasta oli poistettu käytöstä haavoittuvat verkkopalvelut. Tämä suojaa verkon kautta tapahtuvilta hyökkäyksiltä, mutta hyökkäys sisältäpäin localhostia vastaan toimi, koska et voi vain sammuttaa SMB:tä localhostissa.
Seuraavaksi paljastetaan uusia mielenkiintoisia yksityiskohtia:
- SYSTEM-oikeuksilla voit helposti muodostaa takaisinyhteyden TCP:n kautta. On selvää, että suoran TCP:n poistaminen käytöstä on ehdottomasti rajoitetun IIS-käyttäjän ongelma. Spoileri: IIS-käyttäjäliikenne oli jotenkin kääritty paikalliseen ISA-välityspalvelimeen molempiin suuntiin. Miten se tarkalleen toimii, en ole kopioinut.
- Olen tietyssä "DMZ:ssä" (ja tämä ei ole Active Directory -verkkotunnus, vaan TYÖRYHMÄ) - se kuulostaa loogiselta. Mutta odotetun yksityisen ("harmaan") IP-osoitteen sijasta minulla on täysin "valkoinen" IP-osoite, täsmälleen sama kuin se, jota hyökkäsin aiemmin. Tämä tarkoittaa, että yritys on niin vanha IPv4-osoitteiden maailmassa, että sillä on varaa ylläpitää DMZ-vyöhykettä 128 "valkoiselle" osoitteelle ilman NAT:ia järjestelmän mukaisesti, kuten Ciscon käsikirjoissa vuodelta 2005 on kuvattu.
Koska palvelin on vanha, Mimikatz toimii taatusti suoraan muistista:
Saan paikallisen järjestelmänvalvojan salasanan, tunnelin RDP-liikenteen TCP:n kautta ja kirjaudun mukavalle työpöydälle. Koska pystyin tekemään palvelimella mitä halusin, poistin virustorjunnan ja huomasin, että palvelin oli käytettävissä Internetistä vain TCP-porttien 80 ja 443 kautta ja 443 ei ollut varattu. Asensin OpenVPN-palvelimen 443:een, lisään NAT-toiminnot VPN-liikenteeseeni ja saan suoran pääsyn DMZ-verkkoon rajoittamattomassa muodossa OpenVPN:ni kautta. On huomionarvoista, että ISA, jolla oli joitakin ei-käytöstä poistettuja IPS-toimintoja, esti liikennettäni porttiskannauksella, jota varten se piti korvata yksinkertaisemmalla ja yhteensopivalla RRAS:lla. Joten pentesters joskus vielä hoitaa kaikenlaisia asioita.
Huomaavainen lukija kysyy: "Entä toinen sivusto - NTLM-todennus wiki, josta on kirjoitettu niin paljon?" Tästä lisää myöhemmin.
Osa 2. Etkö vieläkään salaa? Sitten tulemme luoksesi jo täällä
Joten on pääsy DMZ-verkkosegmenttiin. Sinun on mentävä verkkotunnuksen järjestelmänvalvojaan. Ensimmäisenä tulee mieleen DMZ-segmentin palveluiden turvallisuuden automaattinen tarkistaminen, varsinkin kun monet muut niistä ovat nyt avoimia tutkimusta varten. Tyypillinen kuva tunkeutumistestin aikana: ulkokehä on paremmin suojattu kuin sisäiset palvelut, ja suuren infrastruktuurin sisällä on paljon helpompaa saada laajennettuja oikeuksia verkkotunnukseen vain siksi, että tämä verkkoalue alkaa olla työkalujen käytettävissä, ja toiseksi infrastruktuurissa, jossa on useita tuhansia isäntiä, tulee aina olemaan pari kriittistä ongelmaa.
Lataan skannerit DMZ:n kautta OpenVPN-tunnelin kautta ja odotan. Avaan raportin - ei taaskaan mitään vakavaa, ilmeisesti joku kävi läpi saman menetelmän ennen minua. Seuraava askel on tutkia, kuinka DMZ-verkon isännät kommunikoivat. Tätä varten käynnistä ensin tavallinen Wireshark ja kuuntele lähetyspyyntöjä, ensisijaisesti ARP:tä. ARP-paketteja kerättiin koko päivän. Osoittautuu, että tässä segmentissä käytetään useita yhdyskäytäviä. Tästä on hyötyä myöhemmin. Yhdistämällä ARP-pyyntöjen ja -vastausten tietoja sekä porttien skannaustietoja löysin paikallisverkon sisältä käyttäjäliikenteen poistumispisteet aiemmin tunnettujen palveluiden, kuten webin ja sähköpostin, lisäksi.
Koska minulla ei tällä hetkellä ollut pääsyä muihin järjestelmiin eikä yhtään yrityspalveluiden tiliä, päätettiin kalastaa liikenteestä ainakin osa tilistä ARP Spoofingin avulla.
Cain&Abel käynnistettiin urologin palvelimella. Tunnistetut liikennevirrat huomioiden valittiin man-in-the-middle-hyökkäyksen lupaavimmat parit, ja sitten jonkin verran verkkoliikennettä vastaanotettiin lyhytaikaisella 5-10 minuutin käynnistyksellä ajastimella palvelimen uudelleenkäynnistämiseksi. jäätymisen sattuessa. Kuten vitsissä, uutisia oli kaksi:
- Hyvä: paljon valtuuksia saatiin kiinni ja hyökkäys kokonaisuutena toimi.
- Huono: kaikki valtuustiedot olivat asiakkaan omilta asiakkailta. Tukipalveluita tarjoaessaan asiakasasiantuntijat olivat yhteydessä sellaisten asiakkaiden palveluihin, joilla ei aina ollut liikenteen salausta määritettynä.
Tuloksena sain paljon valtuuksia, jotka olivat hyödyttömiä projektin kannalta, mutta ehdottomasti mielenkiintoisia osoituksena hyökkäyksen vaarasta. Suuryritysten rajareitittimet telnetillä, edelleenlähetetyt http-virheenkorjausportit sisäiseen CRM:ään kaikilla tiedoilla, suora pääsy RDP:hen Windows XP:stä paikallisverkossa ja muuta hämärää. Siitä tuli näin .
Löysin myös hauskan tilaisuuden kerätä kirjeitä liikenteestä, jotain tällaista. Tämä on esimerkki valmiista kirjeestä, joka meni asiakkaaltamme hänen asiakkaansa SMTP-porttiin, jälleen ilman salausta. Tietty Andrey pyytää kaimaansa lähettämään asiakirjat uudelleen, ja se ladataan pilvilevylle kirjautumistunnuksen, salasanan ja linkin kera yhdessä vastauskirjeessä:
Tämä on toinen muistutus kaikkien palveluiden salaamisesta. Ei ole tiedossa, kuka ja milloin lukee ja käyttää tietojasi nimenomaan - palveluntarjoaja, toisen yrityksen järjestelmänvalvoja tai sellainen pentesteri. Olen hiljaa siitä tosiasiasta, että monet ihmiset voivat yksinkertaisesti siepata salaamatonta liikennettä.
Ilmeisestä menestyksestä huolimatta tämä ei vienyt meitä lähemmäksi maalia. Oli tietysti mahdollista istua pitkään ja kalastaa arvokasta tietoa, mutta se ei ole tosiasia, että se näkyisi siellä, ja hyökkäys itsessään on erittäin riskialtista verkon eheyden kannalta.
Palveluihin tutustumisen jälkeen tuli mieleen mielenkiintoinen idea. On olemassa sellainen Responder-niminen apuohjelma (tällä nimellä on helppo löytää esimerkkejä käytöstä), joka "myrkyttämällä" lähetyspyyntöjä provosoi yhteyksiä useiden eri protokollien, kuten SMB, HTTP, LDAP jne., kautta. eri tavoin, pyytää sitten kaikkia yhteyden muodostavia todentamaan ja määrittää sen niin, että todennus tapahtuu NTLM:n kautta ja uhrille läpinäkyvässä tilassa. Useimmiten hyökkääjä kerää tällä tavalla NetNTLMv2-kättelyjä ja palauttaa niistä nopeasti verkkotunnuksen käyttäjien salasanat sanakirjan avulla. Täällä halusin jotain vastaavaa, mutta käyttäjät istuivat "seinän takana", tai paremminkin, heidät erotettiin palomuurilla ja he pääsivät WEBiin Blue Coat -välitysklusterin kautta.
Muista, että määritin, että Active Directory -verkkotunnuksen nimi on sama kuin "ulkoinen" verkkotunnus, eli se oli company.ru? Joten Windows, tarkemmin sanottuna Internet Explorer (ja Edge ja Chrome), antavat käyttäjälle mahdollisuuden todentaa läpinäkyvästi HTTP:ssä NTLM:n kautta, jos he katsovat, että sivusto sijaitsee jossain "Intranet-vyöhykkeessä". Yksi "intranetin" merkkejä on pääsy "harmaaseen" IP-osoitteeseen tai lyhyeen DNS-nimeen, toisin sanoen ilman pisteitä. Koska heillä oli palvelin, jolla oli "valkoinen" IP- ja DNS-nimi preobrazhensky.company.ru, ja verkkotunnuksen koneet saavat yleensä Active Directory -verkkotunnuksen päätteen DHCP:n kautta yksinkertaistettua nimensyöttöä varten, heidän piti kirjoittaa vain URL-osoite osoitepalkkiin. , jotta he löytävät oikean polun vaarantuneen urologin palvelimelle unohtamatta, että tätä kutsutaan nyt nimellä "Intranet". Eli samalla antaa minulle käyttäjän NTLM-kättely hänen tietämättään. Jäljelle jää vain pakottaa asiakasselaimet miettimään kiireellistä tarvetta ottaa yhteyttä tähän palvelimeen.
Upea Intercepter-NG-apuohjelma tuli apuun (kiitos ). Sen avulla voit muuttaa liikennettä lennossa ja toimi erinomaisesti Windows 2003:ssa. Siinä oli jopa erillinen toiminto vain JavaScript-tiedostojen muokkaamiseen liikennevirrassa. Suunniteltiin eräänlainen massiivinen Cross-Site Scripting.
Blue Coat -välityspalvelimet, joiden kautta käyttäjät pääsivät maailmanlaajuiseen verkkoon, tallensivat ajoittain staattista sisältöä välimuistiin. Sieppaamalla liikennettä oli selvää, että he työskentelivät ympäri vuorokauden ja pyysivät loputtomasti usein käytettyä staattista sähköä nopeuttamaan sisällön näyttämistä ruuhka-aikoina. Lisäksi BlueCoatilla oli erityinen User-Agent, joka erotti sen selvästi oikeasta käyttäjästä.
Valmisteltiin Javascript, jota Intercepter-NG:tä käyttäen toteutettiin tunnin ajan yöllä jokaista vastausta varten Blue Coatin JS-tiedostoilla. Käsikirjoitus teki seuraavaa:
- Määritti nykyisen selaimen User-Agentin avulla. Jos se oli Internet Explorer, Edge tai Chrome, se jatkoi toimintaansa.
- Odotin, kunnes sivun DOM muodostettiin.
- Lisättiin näkymätön kuva DOM:iin lomakkeen src-attribuutilla :8080/NNNNNNN.png, jossa NNN ovat mielivaltaisia numeroita, jotta BlueCoat ei tallenna sitä välimuistiin.
- Aseta yleinen lippumuuttuja osoittamaan, että injektio on valmis eikä kuvia tarvitse enää lisätä.
Selain yritti ladata tämän kuvan; vaarantuneen palvelimen portissa 8080 TCP-tunneli odotti sitä kannettavaan tietokoneeseeni, jossa sama Responder oli käynnissä vaatien selaimen kirjautumista NTLM:n kautta.
Responder-lokien perusteella ihmiset tulivat töihin aamulla, käynnistivät työasemansa ja alkoivat sitten massana ja huomaamatta vierailla urologin palvelimella unohtamatta "tyhjentää" NTLM-kättelyjä. Kädenpuristuksia satoi koko päivän ja kertynyt materiaalia selvästi onnistuneeseen salasanojen palautushyökkäykseen. Vastaajalokit näyttivät tältä:
Käyttäjien joukkosalaisia käyntejä urologin palvelimella
Olet varmaankin jo huomannut, että tämä koko tarina on rakennettu periaatteelle "kaikki oli hyvin, mutta sitten oli kolari, sitten tuli voittaminen ja sitten kaikki onnistui." Joten, tässä oli hämmennystä. Viidestäkymmenestä ainutlaatuisesta kättelystä ei paljastunut yhtäkään. Ja tämä ottaa huomioon sen tosiasian, että jopa kannettavassa tietokoneessa, jossa on kuollut prosessori, nämä NTLMv2-kättelyt käsitellään useiden satojen miljoonien yritysten sekunnissa.
Minun piti aseistaa itseni salasanamutaatiotekniikoilla, näytönohjaimella, paksummalla sanakirjalla ja odottaa. Pitkän ajan jälkeen paljastettiin useita tilejä, joiden salasanat olivat muotoa "Q11111111....1111111q", mikä viittaa siihen, että kaikki käyttäjät joutuivat aikoinaan keksimään erittäin pitkän salasanan, jossa oli eri kirjainkokoja, minkä piti myös olla monimutkaisia. Mutta kokenutta käyttäjää ei voi huijata, ja näin hän teki muistamisen helpommaksi. Kaikkiaan noin 5 tiliä vaarantui, ja vain yhdellä niistä oli arvokkaita oikeuksia palveluihin.
Osa 3. Roskomnadzor iskee takaisin
Joten ensimmäiset verkkotunnustilit vastaanotettiin. Jos et ole tähän mennessä nukahtanut pitkän lukemisen jälkeen, muistat varmaan, että mainitsin palvelun, joka ei vaatinut toista todennustekijää: se on wiki, jossa on NTLM-todennus. Tietenkin ensimmäinen asia oli mennä sinne. Sisäiseen tietopohjaan kaivautuminen tuotti nopeasti tuloksia:
- Yrityksellä on WiFi-verkko, jossa on todennus käyttämällä verkkotunnustilejä, joilla on pääsy paikallisverkkoon. Nykyisellä tietojoukolla tämä on jo toimiva hyökkäysvektori, mutta sinun on mentävä toimistoon jaloin ja sijaittava jossain asiakkaan toimiston alueella.
- Löysin ohjeen, jonka mukaan oli palvelu, joka salli... rekisteröidä itsenäisesti "toisen tekijän" todennuslaitteen, jos käyttäjä on lähiverkon sisällä ja muistaa luotettavasti verkkotunnuksensa kirjautumistunnuksensa ja salasanansa. Tässä tapauksessa "sisällä" ja "ulkopuolella" määritettiin tämän palvelun portin saavutettavuus käyttäjälle. Portti ei ollut käytettävissä Internetistä, mutta se oli melko saavutettavissa DMZ: n kautta.
Tietysti "toinen tekijä" lisättiin välittömästi vaarantuneeseen tiliin sovelluksen muodossa puhelimeeni. Siellä oli ohjelma, joka saattoi joko lähettää äänekkäästi push-pyynnön puhelimeen "hyväksy"/"hylätä"-painikkeilla toimintoa varten tai näyttää äänettömästi OTP-koodin näytöllä itsenäistä lisäsyöttöä varten. Lisäksi ohjeiden mukaan ensimmäinen menetelmä oli ainoa oikea, mutta se ei toiminut toisin kuin OTP-menetelmä.
Kun "toinen tekijä" oli rikki, pääsin Outlook Web Access -postiin ja etäkäyttöön Citrix Netscaler Gatewayssa. Outlookin postissa oli yllätys:
Tässä harvinaisessa otoksessa näet, kuinka Roskomnadzor auttaa kiusaajia
Nämä olivat ensimmäiset kuukaudet kuuluisan Telegramin ”fanien” eston jälkeen, jolloin kokonaiset verkot tuhansilla osoitteilla katosivat väistämättä pääsystä. Kävi selväksi, miksi työntö ei toiminut heti ja miksi "uhrini" ei soittanut hälytystä, koska he alkoivat käyttää hänen tiliään aukioloaikoina.
Jokainen, joka tuntee Citrix Netscalerin, kuvittelee, että se on yleensä toteutettu siten, että käyttäjälle voidaan välittää vain kuvarajapinta, yrittäen olla antamatta hänelle työkaluja kolmannen osapuolen sovellusten käynnistämiseen ja tietojen siirtämiseen, rajoittaen toimintaa kaikin mahdollisin tavoin. standardien ohjauskuoren kautta. "Uhrini" sai ammattinsa vuoksi vain 1C:
Käveltyäni hieman 1C-rajapinnassa huomasin, että siellä on ulkoisia käsittelymoduuleja. Ne voidaan ladata käyttöliittymästä ja ne suoritetaan asiakkaalla tai palvelimella oikeuksista ja asetuksista riippuen.
Pyysin 1C-ohjelmoijakavereitani luomaan käsittelyn, joka hyväksyisi merkkijonon ja suorittaisi sen. 1C-kielellä prosessin aloittaminen näyttää suunnilleen tältä (otettu Internetistä). Oletko samaa mieltä siitä, että 1C-kielen syntaksi hämmästyttää venäjänkielisiä ihmisiä spontaanisuudellaan?
Prosessointi suoritettiin täydellisesti; se osoittautui se, mitä pentesters kutsuvat "kuoreksi" - Internet Explorer käynnistettiin sen kautta.
Aiemmin postista löytyi järjestelmän osoite, jonka avulla voit tilata lippuja alueelle. Tilasin passin siltä varalta, että joudun käyttämään WiFi-hyökkäysvektoria.
Netissä puhutaan, että asiakkaan toimistossa oli vielä herkullista ilmaista ruokailua, mutta hyökkäystä halusin silti kehittää etänä, se on rauhallisempaa.
AppLocker aktivoitiin Citrixiä käyttävällä sovelluspalvelimella, mutta se ohitettiin. Sama Meterpreter ladattiin ja käynnistettiin DNS:n kautta, koska http-versiot eivät halunneet muodostaa yhteyttä, enkä tiennyt tuolloin sisäistä välityspalvelinosoitetta. Muuten, tästä hetkestä lähtien ulkoinen pentest muuttui olennaisesti kokonaan sisäiseksi.
Osa 4. Käyttäjien järjestelmänvalvojan oikeudet ovat huonot, okei?
Pentesterin ensimmäinen tehtävä verkkotunnuksen käyttäjäistunnon hallinnassa on kerätä kaikki tiedot toimialueen oikeuksista. On olemassa BloodHound-apuohjelma, jonka avulla voit automaattisesti ladata tietoja käyttäjistä, tietokoneista, suojausryhmistä LDAP-protokollan kautta toimialueen ohjaimesta ja SMB:n kautta - tietoja siitä, mikä käyttäjä on äskettäin kirjautunut sisään ja kuka on paikallinen järjestelmänvalvoja.
Tyypillinen verkkotunnuksen järjestelmänvalvojan oikeuksien takavarikointitekniikka näyttää yksinkertaistetulta yksitoikkoisten toimien sykliltä:
- Siirrymme toimialuetietokoneisiin, joissa on paikalliset järjestelmänvalvojan oikeudet, jotka perustuvat jo kaapattuihin verkkotunnustileihin.
- Käynnistämme Mimikatzin ja saamme välimuistiin tallennetut salasanat, Kerberos-liput ja NTLM-tiivisteet verkkotunnustileistä, jotka ovat äskettäin kirjautuneet tähän järjestelmään. Tai poistamme lsass.exe-prosessin muistikuvan ja teemme samoin puolellamme. Tämä toimii hyvin Windowsissa, joka on nuorempi kuin 2012R2/Windows 8.1 oletusasetuksella.
- Määritämme, missä vaarantuneissa tileissä on paikalliset järjestelmänvalvojan oikeudet. Toistamme ensimmäisen kohdan. Jossain vaiheessa saamme koko verkkotunnuksen järjestelmänvalvojan oikeudet.
"Kielen loppu;", kuten 1C-ohjelmoijat kirjoittaisivat tänne.
Joten käyttäjämme osoittautui paikalliseksi järjestelmänvalvojaksi vain yhdessä isännässä, jossa oli Windows 7, jonka nimi sisälsi sanan "VDI" tai "Virtual Desktop Infrastructure", henkilökohtaisten virtuaalikoneiden. Todennäköisesti VDI-palvelun suunnittelija tarkoitti sitä, että koska VDI on käyttäjän henkilökohtainen käyttöjärjestelmä, vaikka käyttäjä muuttaa ohjelmistoympäristöä haluamallaan tavalla, isäntä voidaan silti "ladata uudelleen". Minusta idea oli myös yleisesti ottaen hyvä, menin tämän henkilökohtaisen VDI-isäntälle ja tein sinne pesän:
- Asensin sinne OpenVPN-asiakkaan, joka loi tunnelin Internetin kautta palvelimelleni. Asiakas oli pakotettava käymään läpi sama Blue Coat verkkotunnuksen todennuksella, mutta OpenVPN teki sen, kuten he sanovat, "pakkauksesta käsin".
- OpenSSH asennettu VDI:lle. No, todellakin, mitä on Windows 7 ilman SSH:ta?
Tältä se näytti livenä. Haluan muistuttaa, että kaikki tämä on tehtävä Citrixin ja 1C:n kautta:
Yksi tapa edistää pääsyä naapuritietokoneisiin on tarkistaa paikallisten järjestelmänvalvojien salasanat. Täällä onni odotti välittömästi: oletusarvoisen paikallisen ylläpitäjän (jota yhtäkkiä kutsuttiin järjestelmänvalvojaksi) NTLM-hajautus lähetettiin pass-the-hash-hyökkäyksen kautta viereisiin VDI-isänteihin, joita oli useita satoja. Tietenkin hyökkäys osui heihin välittömästi.
Tässä VDI-järjestelmänvalvojat ampuivat itseään jalkaan kahdesti:
- Ensimmäinen kerta oli silloin, kun VDI-koneita ei tuotu LAPS:n piiriin, sillä se säilytti käytännössä saman paikallisen järjestelmänvalvojan salasanan vedessä, jota otettiin massiivisesti käyttöön VDI:ssä.
- Oletusjärjestelmänvalvoja on ainoa paikallinen tili, joka on alttiina pass-the-hash-hyökkäyksille. Jopa samalla salasanalla olisi mahdollista välttää massakompromissit luomalla toinen paikallinen järjestelmänvalvojatili monimutkaisella satunnaisella salasanalla ja estämällä oletussalasana.
Miksi siinä Windowsissa on SSH-palvelu? Hyvin yksinkertainen: nyt OpenSSH-palvelin ei tarjonnut vain kätevää interaktiivista komentokullia häiritsemättä käyttäjän työtä, vaan myös socks5-välityspalvelimen VDI:ssä. Näiden sukkien kautta liityin SMB:n kautta ja keräsin välimuistissa olevat tilit kaikista näistä sadoista VDI-koneista ja etsin sitten polun verkkotunnuksen järjestelmänvalvojalle käyttämällä niitä BloodHoundin kaavioissa. Koska käytössäni oli satoja isäntiä, löysin tämän tavan melko nopeasti. Verkkotunnuksen järjestelmänvalvojan oikeudet on hankittu.
Tässä on kuva Internetistä, jossa näkyy samanlainen haku. Yhteydet osoittavat, kuka on missä ylläpitäjä on ja kuka on kirjautunut sisään missä.
Muuten, muista ehto projektin alusta lähtien - "älä käytä sosiaalista suunnittelua". Joten ehdotan pohtimaan kuinka paljon kaikkea tätä Bollywoodia erikoistehosteineen leikattaisiin pois, jos banaalia tietojenkalastelua olisi edelleen mahdollista käyttää. Mutta henkilökohtaisesti minulle oli erittäin mielenkiintoista tehdä tämä kaikki. Toivottavasti pidit tämän lukemisesta. Tietenkään jokainen projekti ei näytä niin kiehtovalta, mutta työ kokonaisuudessaan on erittäin haastavaa eikä anna sen pysähtyä.
Todennäköisesti jollakulla on kysymys: kuinka suojautua? Jopa tässä artikkelissa kuvataan monia tekniikoita, joista monet Windows-järjestelmänvalvojat eivät edes tiedä. Ehdotan kuitenkin tarkastelemaan niitä hakkeroitujen periaatteiden ja tietoturvatoimien näkökulmasta:
- älä käytä vanhentuneita ohjelmistoja (muistatko Windows 2003:n alussa?)
- älä pidä tarpeettomia järjestelmiä päällä (miksi siellä oli urologin verkkosivusto?)
- tarkista käyttäjien salasanat itse (muuten sotilaat... pentesters tekevät tämän)
- ei ole samoja salasanoja eri tileille (VDI-kompromissi)
- ja muut
Tämä on tietysti erittäin vaikea toteuttaa, mutta seuraavassa artikkelissa näytämme käytännössä, että se on täysin mahdollista.
Lähde: will.com