Iam sur pentesto, aŭ Kiel rompi ĉion kun la helpo de urologo kaj Roskomnadzor

Ĉi tiu artikolo estis verkita surbaze de tre sukcesa pentesto kiun specialistoj de Group-IB faris antaŭ kelkaj jaroj: okazis rakonto, kiu povus esti adaptita por filmo en Bollywood. Nun, verŝajne, sekvos la reago de la leganto: "Ho, alia PR-artikolo, denove ĉi tiuj estas portretitaj, kiel bonaj ili estas, ne forgesu aĉeti penteston." Nu, unuflanke, ĝi estas. Tamen, ekzistas kelkaj aliaj kialoj, kial ĉi tiu artikolo aperis. Mi volis montri, kion precize faras pentesteroj, kiom interesa kaj ne bagatela povas esti ĉi tiu laboro, kiaj amuzaj cirkonstancoj povas aperi en projektoj, kaj plej grave, montri vivan materialon kun realaj ekzemploj.

Por restarigi la ekvilibron de modesteco en la mondo, post iom da tempo ni skribos pri pentesto, kiu ne iris bone. Ni montros kiel bone dezajnitaj procezoj en kompanio povas protekti kontraŭ tuta gamo da atakoj, eĉ bone preparitaj, simple ĉar ĉi tiuj procezoj ekzistas kaj efektive funkcias.

Por la kliento en ĉi tiu artikolo, ĉio estis ankaŭ ĝenerale bonega, almenaŭ pli bona ol 95% de la merkato en la Rusa Federacio, laŭ niaj sentoj, sed estis kelkaj malgrandaj nuancoj, kiuj formis longan ĉenon de eventoj, kiuj unue. kondukis al longa raporto pri la laboro , kaj poste al ĉi tiu artikolo.

Do, ni provizu pufmaizon, kaj bonvenon al la detektiva rakonto. Vorto - Pavel Suprunyuk, teknika direktoro de la fako "Revizio kaj Konsultado" de Grupo-IB.

Parto 1. Pochkin kuracisto

2018 Estas kliento - altteknologia IT-kompanio, kiu mem servas multajn klientojn. Volas ricevi respondon al la demando: ĉu eblas, sen ia komenca scio kaj aliro, laborante per la Interreto, akiri rajtojn de administranto de la domajno de Active Directory? Mi ne interesiĝas pri iu ajn socia inĝenierado (ho, sed vane), ili ne intencas intence malhelpi la laboron, sed ili eble hazarde - reŝargi strange funkciantan servilon, ekzemple. Kroma celo estas identigi kiel eble plej multajn aliajn atakvektorojn kontraŭ la ekstera perimetro. La kompanio regule faras tiajn provojn, kaj nun alvenis la limdato por nova testo. La kondiĉoj estas preskaŭ tipaj, taŭgaj, kompreneblaj. Ni komencu.

Estas nomo de la kliento - ĝi estu "Firmao", kun la ĉefa retejo www.company.ru. Kompreneble, la kliento nomiĝas malsame, sed en ĉi tiu artikolo ĉio estos senpersona.
Mi faras reton-konadon - eksciu, kiuj adresoj kaj domajnoj estas registritaj ĉe la kliento, desegnas retan diagramon, kiel servoj estas distribuitaj al ĉi tiuj adresoj. Mi ricevas la rezulton: pli ol 4000 vivaj IP-adresoj. Mi rigardas la domajnojn en ĉi tiuj retoj: feliĉe, la granda plimulto estas retoj destinitaj por la klientoj de la kliento, kaj ni ne estas formale interesitaj pri ili. La kliento pensas same.

Restas unu reto kun 256 adresoj, por kiu ĉi-momente jam estas kompreno pri la distribuado de domajnoj kaj subdomajnoj laŭ IP-adresoj, ekzistas informoj pri la skanitaj havenoj, kio signifas, ke vi povas rigardi la servojn por interesaj. Paralele, ĉiuj specoj de skaniloj estas lanĉitaj sur disponeblaj IP-adresoj kaj aparte en retejoj.

Estas multaj servoj. Kutime tio estas ĝojo por la pentestro kaj la antaŭvido de rapida venko, ĉar ju pli da servoj estas, des pli granda estas la kampo por atako kaj des pli facile estas trovi artefakton. Rapida rigardo al la retejoj montris, ke la plej multaj el ili estas retaj interfacoj de konataj produktoj de grandaj tutmondaj kompanioj, kiuj laŭ ĉiuj aspektoj diras al vi, ke ili ne estas bonvenaj. Ili petas uzantnomon kaj pasvorton, skuas la kampon por enigi la duan faktoron, petas TLS-klientatestilon aŭ sendas ĝin al Microsoft ADFS. Iuj estas simple neatingeblaj de la Interreto. Por iuj, vi evidente bezonas havi specialan pagitan klienton por tri salajroj aŭ scii la ĝustan URL por eniri. Ni transsaltu alian semajnon de laŭgrada senkuraĝo en la procezo provi "trarompi" programajn versiojn por konataj vundeblecoj, serĉante kaŝitan enhavon en retvojoj kaj likitaj kontoj de triaj servoj kiel LinkedIn, provante ankaŭ diveni pasvortojn uzante ilin. kiel elfosado de vundeblecoj en memskribitaj retejoj — cetere, laŭ statistiko, ĉi tiu estas la plej promesplena vektoro de ekstera atako hodiaŭ. Mi tuj notos la filmpafilon, kiu poste pafis.

Do, ni trovis du retejojn, kiuj elstaris el centoj da servoj. Ĉi tiuj retejoj havis unu komunan aferon: se vi ne okupiĝas pri skrupula reto-skotado laŭ domajno, sed serĉu rekte malfermitajn havenojn aŭ celas vundeblecon skanilon uzante konatan IP-amplekson, tiam ĉi tiuj retejoj evitos skanadon kaj simple ne estos. videbla sen scii la DNS-nomon. Eble ili estis maltrafitaj pli frue, almenaŭ, kaj niaj aŭtomataj iloj ne trovis problemojn ĉe ili, eĉ se ili estis senditaj rekte al la rimedo.

Parenteze, pri kio antaŭe lanĉitaj skaniloj trovis ĝenerale. Mi memorigu vin: por iuj homoj, "pentest" egalas al "aŭtomatigita skanado". Sed la skaniloj en ĉi tiu projekto diris nenion. Nu, la maksimumo estis montrita de Mezaj vundeblecoj (3 el 5 laŭ severeco): ĉe iu servo malbona TLS-atestilo aŭ malmodernaj ĉifradaj algoritmoj, kaj ĉe la plej multaj retejoj Clickjacking. Sed ĉi tio ne kondukos vin al via celo. Eble skaniloj estus pli utilaj ĉi tie, sed mi memorigu vin: la kliento mem kapablas aĉeti tiajn programojn kaj testi sin per ili, kaj, se juĝante laŭ la malgajaj rezultoj, li jam kontrolis.

Ni revenu al la "nenormalaj" retejoj. La unua estas io kiel loka Vikio ĉe nenorma adreso, sed en ĉi tiu artikolo estu wiki.company[.]ru. Ŝi ankaŭ tuj petis ensaluton kaj pasvorton, sed per NTLM en la retumilo. Por la uzanto, ĉi tio aspektas kiel asketa fenestro petante enigi uzantnomon kaj pasvorton. Kaj ĉi tio estas malbona praktiko.

Eta noto. NTLM en perimetraj retejoj estas malbona pro kelkaj kialoj. La unua kialo estas, ke la domajna nomo de Active Directory estas malkaŝita. En nia ekzemplo, ĝi ankaŭ rezultis esti company.ru, same kiel la "ekstera" DNS-nomo. Sciante tion, vi povas zorge prepari ion malican, por ke ĝi estu ekzekutita nur sur la domajna maŝino de la organizo, kaj ne en iu sablokesto. Due, aŭtentikigo iras rekte tra la domajna regilo per NTLM (surprizo, ĉu ne?), kun ĉiuj funkcioj de la "internaj" retaj politikoj, inkluzive de blokado de kontoj por superi la nombron da pasvortaj provoj. Se atakanto malkovras la ensalutojn, li serĉos pasvortojn por ili. Se vi estas agordita por bloki kontojn por enigi malĝustajn pasvortojn, ĝi funkcios kaj la konto estos blokita. Trie, estas neeble aldoni duan faktoron al tia aŭtentigo. Se iu el la legantoj ankoraŭ scias kiel, bonvolu sciigi min, ĝi estas vere interesa. Kvare, vundebleco al pas-la-haŝaj atakoj. ADFS estis inventita, interalie, por protekti kontraŭ ĉio ĉi.

Estas unu malbona propraĵo de Microsoft-produktoj: eĉ se vi ne specife publikigis tian NTLM, ĝi estos instalita defaŭlte en OWA kaj Lync, almenaŭ.

Cetere, la aŭtoro de ĉi tiu artikolo iam hazarde blokis proksimume 1000 kontojn de dungitoj de unu granda banko en nur unu horo uzante la saman metodon kaj tiam aspektis iom pala. Ankaŭ la IT-servoj de la banko estis palaj, sed ĉio finiĝis bone kaj adekvate, oni eĉ laŭdis nin, ke ni estis la unuaj, kiuj trovis ĉi tiun problemon kaj provokis rapidan kaj decidan solvon.

La dua retejo havis la adreson "evidente ia familia nomo.kompanio.ru." Trovis ĝin per Guglo, ion tian sur paĝo 10. La dezajno estis de la frua-mezo de la XNUMX-aj jaroj, kaj estiminda persono rigardis ĝin de la ĉefpaĝo, io kiel ĉi tio:

Ĉi tie mi prenis alambikon el "Koro de Hundo", sed kredu min, ĝi estis malklare simila, eĉ la kolordezajno estis en similaj tonoj. Lasu la retejon esti nomita preobrazhensky.company.ru.

Ĝi estis persona retejo... por urologo. Mi scivolis, kion la retejo de urologo faras sur la subdomajno de altteknologia kompanio. Rapida esploro en Guglo montris, ke ĉi tiu kuracisto estis kunfondinto de unu el la juraj entoj de nia kliento kaj eĉ kontribuis ĉirkaŭ 1000 rublojn en la rajtigita ĉefurbo. La retejo verŝajne estis kreita antaŭ multaj jaroj, kaj la servilaj rimedoj de la kliento estis uzataj kiel gastigado. La retejo delonge perdis sian gravecon, sed ial ĝi estis lasita funkcianta dum longa tempo.

Koncerne vundeblecojn, la retejo mem estis sekura. Rigardante antaŭen, mi diros, ke ĝi estis aro da statikaj informoj - simplaj html-paĝoj kun enmetitaj ilustraĵoj en formo de renoj kaj vezikoj. Estas senutile "rompi" tian retejon.

Sed la retservilo sube estis pli interesa. Juĝante laŭ la kaplinio de HTTP Server, ĝi havis IIS 6.0, kio signifas, ke ĝi uzis Windows 2003 kiel la operaciumon. La skanilo antaŭe identigis, ke ĉi tiu aparta retejo de urologo, male al aliaj virtualaj gastigantoj sur la sama retservilo, respondis al la komando PROPFIND, kio signifas, ke ĝi funkcias WebDAV. Cetere, la skanilo resendis ĉi tiujn informojn kun la marko Info (en la lingvo de skanaj raportoj, tio estas la plej malalta danĝero) - tiaj aferoj estas kutime simple preterlasitaj. En kombinaĵo, ĉi tio donis interesan efikon, kiu estis malkaŝita nur post alia fosado en Guglo: malofta bufra superflua vundebleco asociita kun la aro Shadow Brokers, nome CVE-2017-7269, kiu jam havis pretan ekspluatadon. Alivorte, estos problemo se vi havas Windows 2003 kaj WebDAV funkcias per IIS. Kvankam funkcii Windows 2003 en produktado en 2018 estas problemo en si mem.

La ekspluato finiĝis en Metasploit kaj tuj estis provita kun ŝarĝo, kiu sendis DNS-peton al kontrolita servo - Burp Collaborator estas tradicie uzata por kapti DNS-petojn. Je mia surprizo, ĝi funkciis la unuan fojon: DNS-knokaŭto estis ricevita. Poste, estis provo krei malantaŭan konekton per haveno 80 (tio estas, retkonekto de la servilo al la atakanto, kun aliro al cmd.exe sur la viktimo gastiganto), sed tiam okazis fiasko. La konekto ne trafis, kaj post la tria provo uzi la retejon, kune kun ĉiuj interesaj bildoj, malaperis por ĉiam.

Kutime ĉi tio estas sekvata de letero en la stilo de "kliento, vekiĝu, ni faligis ĉion." Sed oni diris al ni, ke la retejo havas nenion komunan kun komercaj procezoj kaj funkcias tie tute sen kialo, kiel la tuta servilo, kaj ke ni povas uzi ĉi tiun rimedon laŭplaĉe.
Ĉirkaŭ unu tagon poste la retejo subite ekfunkciis memstare. Konstruinte benkon de WebDAV sur IIS 6.0, mi trovis, ke la defaŭlta agordo estas rekomenci IIS-laborprocezojn ĉiujn 30 horojn. Tio estas, kiam kontrolo eliris el la ŝelkodo, la IIS-labora procezo finiĝis, tiam ĝi rekomencis sin kelkfoje kaj poste ripozis dum 30 horoj.

Ĉar la malantaŭa konekto al tcp malsukcesis la unuan fojon, mi atribuis ĉi tiun problemon al fermita haveno. Tio estas, li supozis la ĉeeston de ia fajroŝirmilo, kiu ne permesis eksteren preterpasi elirkonektoj. Mi komencis ruli ŝelkodojn kiuj serĉis tra multaj tcp kaj udp-havenoj, estis neniu efiko. Inversaj konektŝarĝoj per http(j) de Metasploit ne funkciis - meterpreter/reverse_http(s). Subite, konekto al la sama haveno 80 estis establita, sed tuj falis. Mi atribuis ĉi tion al la ago de la ankoraŭ imaga IPS, kiu ne ŝatis la meterpreter-trafikon. En lumo de la fakto ke pura tcp-konekto al haveno 80 ne trapasis, sed http-konekto faris, mi konkludis, ke http prokurilo estis iel agordita en la sistemo.

Mi eĉ provis meterpreter per DNS (dankon d00kie pro viaj klopodoj, savis multajn projektojn), rememorante la unuan sukceson, sed ĝi eĉ ne funkciis sur la stando - la ŝelkodo estis tro granda por ĉi tiu vundebleco.

Fakte, ĝi aspektis jene: 3-4 provoj de atakoj ene de 5 minutoj, poste atendante 30 horojn. Kaj tiel plu dum tri semajnoj en vico. Mi eĉ starigis memorigilon por ne perdi tempon. Aldone, estis diferenco en la konduto de la testaj kaj produktadmedioj: por ĉi tiu vundebleco estis du similaj ekspluatoj, unu de Metasploit, la dua de la Interreto, konvertita de la versio de Shadow Brokers. Do, nur Metasploit estis testita en batalo, kaj nur la dua estis testita sur la benko, kio malfaciligis senararigon kaj cerbo-rompis.

En la fino, ŝelkodo kiu elŝutis exe dosieron de antaŭfiksita servilo per http kaj lanĉis ĝin sur la celsistemo pruvis esti efika. La ŝelkodo estis sufiĉe malgranda por konveni, sed almenaŭ ĝi funkciis. Ĉar la servilo tute ne ŝatis TCP-trafikon kaj http(j) estis inspektita por la ĉeesto de meterpreter, mi decidis ke la plej rapida maniero estis elŝuti exe-dosieron kiu enhavis DNS-meterpreter per ĉi tiu ŝelkodo.

Ĉi tie denove aperis problemo: dum elŝuto de exe-dosiero kaj, kiel provoj montris, negrave kiu, la elŝuto estis interrompita. Denove, iu sekureca aparato inter mia servilo kaj la urologo ne ŝatis http-trafikon kun exe ene. La "rapida" solvo ŝajnis esti ŝanĝi la ŝelkodon tiel ke ĝi malklarigu http-trafikon sur la flugo, tiel ke abstraktaj binaraj datumoj estus transdonitaj anstataŭ exe. Fine, la atako sukcesis, kontrolo estis ricevita per la maldika DNS-kanalo:

Tuj evidentiĝis, ke mi havas la plej bazajn rajtojn pri laborfluo de IIS, kiuj permesas al mi fari nenion. Jen kiel ĝi aspektis sur la Metasploit-konzolo:

Ĉiuj pentest-metodaroj forte sugestas, ke vi devas pliigi rajtojn kiam vi akiras aliron. Mi kutime ne faras tion loke, ĉar la plej unua aliro estas rigardata simple kiel reto enirpunkto, kaj kompromiti alian maŝinon sur la sama reto estas kutime pli facila kaj pli rapida ol eskalado de privilegioj sur ekzistanta gastiganto. Sed ĉi tio ne estas la kazo ĉi tie, ĉar la DNS-kanalo estas tre mallarĝa kaj ĝi ne permesos al trafiko klariĝi.

Supozante, ke ĉi tiu Windows 2003-servilo ne estis riparita por la fama MS17-010 vundebleco, mi tunelas trafikon al haveno 445/TCP tra la meterpreter DNS-tunelo al localhost (jes, tio ankaŭ eblas) kaj provas ruli la antaŭe elŝutitan exe tra. la vundebleco. La atako funkcias, mi ricevas duan konekton, sed kun SYSTEM-rajtoj.

Estas interese, ke ili ankoraŭ provis protekti la servilon kontraŭ MS17-010 - ĝi havis vundeblajn retajn servojn malŝaltitaj sur la ekstera interfaco. Ĉi tio ja protektas kontraŭ atakoj tra la reto, sed la atako de interne sur localhost funkciis, ĉar vi ne povas rapide malŝalti SMB sur localhost.

Poste, novaj interesaj detaloj estas malkaŝitaj:

1. Havante SYSTEM-rajtojn, vi povas facile establi malantaŭan konekton per TCP. Evidente, malŝalti rektan TCP estas strikte problemo por la limigita IIS-uzanto. Spoiler: la uzanttrafiko de IIS estis iel envolvita en la loka ISA Proxy en ambaŭ direktoj. Kiel ĝuste ĝi funkcias, mi ne reproduktis.
2. Mi estas en certa "DMZ" (kaj ĉi tio ne estas Active Directory-domajno, sed LABORKRUPO) - ĝi sonas logike. Sed anstataŭ la atendata privata ("griza") IP-adreso, mi havas tute "blankan" IP-adreson, ekzakte la saman kiel tiu, kiun mi atakis antaŭe. Ĉi tio signifas, ke la kompanio estas tiel malnova en la mondo de IPv4-adresado, ke ĝi povas pagi konservi DMZ-zonon por 128 "blankaj" adresoj sen NAT laŭ la skemo, kiel prezentita en Cisco-manlibroj de 2005.

Ĉar la servilo estas malnova, Mimikatz estas garantiita funkcii rekte de memoro:

Mi ricevas la pasvorton de loka administranto, tunelas RDP-trafikon super TCP kaj ensalutas en komfortan labortablon. Ĉar mi povis fari ĉion, kion mi volis per la servilo, mi forigis la antiviruson kaj trovis, ke la servilo estas alirebla de Interreto nur per TCP-havenoj 80 kaj 443, kaj 443 ne estas okupata. Mi starigis OpenVPN-servilon sur 443, aldonas NAT-funkciojn por mia VPN-trafiko kaj ricevas rektan aliron al la DMZ-reto en senlima formo per mia OpenVPN. Estas rimarkinde, ke ISA, havante kelkajn nemalfunkciigitajn IPS-funkciojn, blokis mian trafikon per havena skanado, por kiu ĝi devis esti anstataŭigita per pli simpla kaj pli konforma RRAS. Do pentesteroj foje ankoraŭ devas administri ĉiajn aferojn.

Atenta leganto demandos: "Kion pri la dua retejo - vikio kun NTLM-aŭtentigo, pri kiu tiom multe estis skribita?" Pli pri tio poste.

Parto 2. Ĉu ankoraŭ ne ĉifri? Tiam ni venas al vi jam ĉi tie

Do, ekzistas aliro al la retsegmento DMZ. Vi devas iri al la domajna administranto. La unua afero, kiu venas al la menso, estas aŭtomate kontroli la sekurecon de servoj ene de la DMZ-segmento, precipe ĉar multaj pli da ili estas nun malfermitaj por esplorado. Tipa bildo dum penetrotesto: la ekstera perimetro estas pli bone protektita ol internaj servoj, kaj kiam oni akiras ajnan aliron ene de granda infrastrukturo, estas multe pli facile akiri plilongigitajn rajtojn en domajno nur pro la fakto, ke ĉi tiu domajno komencas esti. alirebla al iloj, kaj due, En infrastrukturo kun pluraj miloj da gastigantoj, ĉiam estos kelkaj kritikaj problemoj.

Mi ŝargas la skaniloj per DMZ per OpenVPN-tunelo kaj atendas. Mi malfermas la raporton - denove nenio serioza, ŝajne iu trairis la saman metodon antaŭ mi. La sekva paŝo estas ekzameni kiel komunikas gastigantoj en la reto DMZ. Por fari tion, unue lanĉu la kutiman Wireshark kaj aŭskultu elsendajn petojn, ĉefe ARP. ARP-pakoj estis kolektitaj la tutan tagon. Rezultas, ke pluraj enirejoj estas uzataj en ĉi tiu segmento. Ĉi tio utilos poste. Kombinante datumojn pri ARP-petoj kaj respondoj kaj havenskanado-datumoj, mi trovis la elirpunktojn de uzanttrafiko de ene de la loka reto krom tiuj servoj kiuj antaŭe estis konataj, kiel ekzemple retejo kaj poŝto.

Ĉar nuntempe mi ne havis neniun aliron al aliaj sistemoj kaj ne havis ununuran konton por kompaniaj servoj, oni decidis elkapti almenaŭ iun konton el la trafiko per ARP Spoofing.

Cain&Abel estis lanĉita sur la servilo de la urologo. Konsiderante la identigitajn trafikfluojn, la plej promesplenaj paroj por la viro-en-la-meza atako estis elektitaj, kaj tiam iom da rettrafiko estis ricevita per mallongdaŭra lanĉo dum 5-10 minutoj, kun tempigilo por rekomenci la servilon. en kazo de frosto. Kiel en la ŝerco, estis du novaĵoj:

1. Bona: multaj akreditaĵoj estis kaptitaj kaj la atako entute funkciis.
2. La malbona: ĉiuj akreditaĵoj estis de la propraj klientoj de la kliento. Provizante helpservojn, klientspecialistoj konektis al la servoj de klientoj, kiuj ne ĉiam havis trafikan ĉifradon agordita.

Rezulte, mi akiris multajn akreditaĵojn, kiuj estis senutilaj en la kunteksto de la projekto, sed certe interesaj kiel pruvo de la danĝero de la atako. Limaj enkursigiloj de grandaj kompanioj kun telnet, plusendis sencimigajn http-havenojn al interna CRM kun ĉiuj datumoj, rekta aliro al RDP de Windows XP en la loka reto kaj alia obskurantismo. Ĝi rezultis tiel Provizoĉeno-Kopromiso laŭ la MITRE-matrico.

Mi trovis ankaŭ amuzan ŝancon kolekti leterojn el trafiko, ion tian. Ĉi tio estas ekzemplo de preta letero, kiu iris de nia kliento al la SMTP-haveno de sia kliento, denove, sen ĉifrado. Certo Andrey petas sian samnomulo resendi la dokumentaron, kaj ĝi estas alŝutita al nuba disko kun ensalutado, pasvorto kaj ligilo en unu respondletero:

Ĉi tio estas alia memorigilo por ĉifri ĉiujn servojn. Oni ne scias, kiu kaj kiam legos kaj uzos viajn datumojn specife - la provizanto, la sistemadministranto de alia kompanio, aŭ tia pentester. Mi silentas pri la fakto, ke multaj homoj simple povas kapti neĉifritan trafikon.

Malgraŭ la ŝajna sukceso, tio ne proksimigis nin al la celo. Eblis, kompreneble, sidi dum longa tempo kaj fiŝi valorajn informojn, sed ne estas fakto, ke ĝi aperus tie, kaj la atako mem estas tre riska laŭ la integreco de la reto.

Post alia fosado en la servoj, venis en menso interesa ideo. Estas tia ilo nomata Responder (estas facile trovi ekzemplojn de uzo sub ĉi tiu nomo), kiu, "venenante" elsendajn petojn, provokas konektojn per diversaj protokoloj kiel SMB, HTTP, LDAP, ktp. en malsamaj manieroj, tiam petas ĉiun kiu konektas aŭtentikigi kaj starigas ĝin tiel ke aŭtentikigo okazas per NTLM kaj en reĝimo travidebla al la viktimo. Plej ofte, atakanto kolektas NetNTLMv2 manpremojn tiamaniere kaj de ili, uzante vortaron, rapide reakiras uzantdomajnajn pasvortojn. Ĉi tie mi deziris ion similan, sed la uzantoj sidis "malantaŭ muro", aŭ pli ĝuste, ili estis apartigitaj per fajroŝirmilo, kaj aliris la RETEJO per la prokurilo Blue Coat.

Memoru, mi precizigis, ke la domajna nomo de Active Directory koincidis kun la "ekstera" domajno, tio estas, ke ĝi estis company.ru? Do, Vindozo, pli precize Internet Explorer (kaj Edge kaj Chrome), permesas al la uzanto travideble aŭtentigi en HTTP per NTLM, se ili konsideras, ke la retejo situas en iu "Intranet Zone". Unu el la signoj de "Intranet" estas aliro al "griza" IP-adreso aŭ mallonga DNS-nomo, tio estas, sen punktoj. Ĉar ili havis servilon kun "blanka" IP kaj DNS-nomo preobrazhensky.company.ru, kaj domajnaj maŝinoj kutime ricevas la domajnan sufikson de Active Directory per DHCP por simpligita nomo-eniro, ili nur devis skribi la URL en la adresbreto. preobraĵenskij, por ke ili trovu la ĝustan vojon al la servilo de la kompromitita urologo, ne forgesante, ke ĉi tio nun nomiĝas "Intranet". Tio estas, samtempe donante al mi la NTLM-manpremon de la uzanto sen lia scio. Restas nur devigi klientajn retumiloj pensi pri la urĝa bezono kontakti ĉi tiun servilon.

La mirinda Intercepter-NG-servaĵo venis al la savo (dankon Interkaptisto). Ĝi permesis al vi ŝanĝi trafikon sur la flugo kaj bonege funkciis en Vindozo 2003. Ĝi eĉ havis apartan funkciecon por modifi nur JavaScript dosierojn en la trafikfluo. Speco de masiva Cross-Site Scripting estis planita.

Blue Coat prokuriloj, per kiuj uzantoj aliris la tutmondan RETEJO, periode konservis senmovan enhavon. Interkaptante trafikon, estis klare, ke ili laboras ĉirkaŭ la horloĝo, senfine petante ofte uzatan statikon por akceli la montradon de enhavo dum pintaj horoj. Krome, BlueCoat havis specifan Uzanto-Agent, kiu klare distingis ĝin de vera uzanto.

Javascript estis preparita, kiu, uzante Intercepter-NG, estis efektivigita dum unu horo nokte por ĉiu respondo kun JS-dosieroj por Blue Coat. La manuskripto faris la sekvantan:

• Determinis la nunan retumilon de Uzanto-Agente. Se ĝi estis Internet Explorer, Edge aŭ Chrome, ĝi daŭre funkciis.
• Mi atendis ĝis la DOM de la paĝo formiĝis.
• Enmetis nevideblan bildon en la DOM kun src-atributo de la formo preobraĵenskij:8080/NNNNNNN.png, kie NNN estas arbitraj nombroj por ke BlueCoat ne konservu ĝin en kaŝmemoron.
• Agordu tutmondan flagvariablon por indiki, ke la injekto estis finita kaj ne plu necesas enmeti bildojn.

La retumilo provis ŝargi ĉi tiun bildon; sur la haveno 8080 de la kompromitita servilo, TCP-tunelo atendis ĝin al mia tekkomputilo, kie la sama Responder funkciis, postulante la retumilon ensaluti per NTLM.

Juĝante laŭ la protokoloj de Responder, homoj venis al laboro matene, ŝaltis siajn laborstaciojn, tiam amase kaj nerimarkite komencis viziti la servilon de la urologo, ne forgesante "dreni" NTLM-manpremojn. Manpremoj pluvis dum la tuta tago kaj klare amasigis materialon por evidente sukcesa atako por reakiri pasvortojn. Jen kiel aspektis la protokoloj de Responder:

Amassekretaj vizitoj al la urologo-servilo de uzantoj

Vi verŝajne jam rimarkis, ke ĉi tiu tuta rakonto estas konstruita laŭ la principo "ĉio estis bona, sed tiam estis fuŝo, tiam estis venkado, kaj tiam ĉio sukcesis." Do, estis ĉagreno ĉi tie. El la kvindek unikaj manpremoj, neniu unu estis rivelita. Kaj ĉi tio konsideras la fakton, ke eĉ sur tekkomputilo kun senviva procesoro, ĉi tiuj NTLMv2-manpremoj estas procesitaj kun rapido de kelkcent milionoj da provoj sekundo.

Mi devis armi min per pasvortaj mutacioteknikoj, vidkarto, pli dika vortaro kaj atendi. Post longa tempo, pluraj kontoj kun pasvortoj de la formo "Q11111111....1111111q" estis rivelitaj, kio sugestas, ke ĉiuj uzantoj iam estis devigitaj elpensi tre longan pasvorton kun malsama kazo de karakteroj, kiu ankaŭ supozis. esti kompleksa. Sed vi ne povas trompi spertan uzanton, kaj jen kiel li faciligis al si mem memori. Entute, ĉirkaŭ 5 kontoj estis endanĝerigitaj, kaj nur unu el ili havis iujn ajn valorajn rajtojn al la servoj.

Parto 3. Roskomnadzor batas reen

Do, la unuaj domajnaj kontoj estis ricevitaj. Se vi ne endormiĝis ĝis ĉi tiu punkto de longa legado, vi verŝajne memoros, ke mi menciis servon, kiu ne postulis duan faktoron de aŭtentigo: ĝi estas vikio kun NTLM-aŭtentikigo. Kompreneble, la unua afero estis eniri tien. Fosi en la internan sciobazon rapide alportis rezultojn:

• La kompanio havas WiFi-reton kun aŭtentikigo per domajnaj kontoj kun aliro al la loka reto. Kun la nuna aro de datumoj, ĉi tio jam estas funkcianta atakvektoro, sed vi devas iri al la oficejo per viaj piedoj kaj troviĝi ie sur la teritorio de la oficejo de la kliento.
• Mi trovis instrukcion laŭ kiu ekzistis servo, kiu permesis... sendepende registri "duan faktoron" aŭtentikan aparaton se la uzanto estas ene de loka reto kaj memfide memoras sian domajnan ensaluton kaj pasvorton. En ĉi tiu kazo, "interne" kaj "ekstere" estis determinitaj de la alirebleco de la haveno de ĉi tiu servo al la uzanto. La haveno ne estis alirebla de la Interreto, sed estis sufiĉe alirebla tra la DMZ.

Kompreneble, "dua faktoro" tuj aldoniĝis al la kompromitita konto en formo de aplikaĵo ĉe mia telefono. Estis programo kiu povis aŭ laŭte sendi puŝpeton al la telefono kun "aprobi"/"malaprobi" butonojn por la ago, aŭ silente montri la OTP-kodon sur la ekrano por plua sendependa eniro. Krome, la unua metodo laŭ la instrukcioj supozis esti la sola ĝusta, sed ĝi ne funkciis, male al la OTP-metodo.

Kun la "dua faktoro" rompita, mi povis aliri retpoŝton de Outlook Web Access kaj foran aliron en Citrix Netscaler Gateway. Estis surprizo en la poŝto en Outlook:

En ĉi tiu malofta pafo vi povas vidi kiel Roskomnadzor helpas pentesterojn

Ĉi tiuj estis la unuaj monatoj post la fama "fan" blokado de Telegramo, kiam tutaj retoj kun miloj da adresoj neeviteble malaperis de aliro. Evidentiĝis kial la puŝo ne funkciis tuj kaj kial mia "viktimo" ne sonigis alarmon ĉar ili komencis uzi ŝian konton dum malfermaj horoj.

Ĉiu, kiu konas Citrix Netscaler, imagas, ke ĝi estas kutime efektivigita tiel, ke nur bildinterfaco povas esti transdonita al la uzanto, provante ne doni al li la ilojn por lanĉi triapartajn aplikaĵojn kaj translokigi datumojn, limigante ĉiel ajn agojn. tra normaj kontrolkonkoj. Mia "viktimo", pro sia okupo, ricevis nur 1C:

Iom ĉirkaŭpaŝante la 1C-interfacon, mi trovis, ke tie estas eksteraj prilaboraj moduloj. Ili povas esti ŝarĝitaj de la interfaco, kaj ili estos ekzekutitaj sur la kliento aŭ servilo, depende de la rajtoj kaj agordoj.

Mi petis miajn programistojn de 1C krei prilaboradon, kiu akceptus ŝnuron kaj ekzekutu ĝin. En 1C lingvo, komenci procezon aspektas kiel ĉi tio (prenita de la Interreto). Ĉu vi konsentas, ke la sintakso de la lingvo 1C mirigas ruslingvanojn per sia spontaneco?

La pretigo estis plenumita perfekte; ĝi rezultis esti tio, kion pentesteroj nomas "ŝelo" - Interreto Explorer estis lanĉita per ĝi.

Antaŭe, la adreso de sistemo, kiu permesas mendi enirpermesilojn al la teritorio, estis trovita en la poŝto. Mi mendis enirpermesilon, se mi devus uzi WiFi-atakan vektoron.

Oni parolas en la Interreto, ke ankoraŭ estis bongusta senpaga manĝado ĉe la oficejo de la kliento, sed mi tamen preferis disvolvi la atakon malproksime, ĝi estas pli trankvila.

AppLocker estis aktivigita sur la aplika servilo kurante Citrix, sed ĝi estis preterpasita. La sama Meterpreter estis ŝargita kaj lanĉita per DNS, ĉar la http(j) versioj ne volis konektiĝi, kaj mi ne konis la internan prokuradreson tiutempe. Cetere, de ĉi tiu momento, la ekstera pentesto esence tute transformiĝis en internan.

Parto 4. Adminrajtoj por uzantoj estas malbonaj, ĉu bone?

La unua tasko de pentester kiam akiras kontrolon de domajna uzantsesio estas kolekti ĉiujn informojn pri rajtoj en la domajno. Estas BloodHound-ilo, kiu aŭtomate permesas elŝuti informojn pri uzantoj, komputiloj, sekurecaj grupoj per la LDAP-protokolo de domajna regilo, kaj per SMB - informoj pri kiu uzanto ĵus ensalutinta kie kaj kiu estas la loka administranto.

Tipa tekniko por konfiski domajnan administrantajn rajtojn aspektas simpligita kiel ciklo de monotonaj agoj:

• Ni iras al domajnaj komputiloj kie ekzistas lokaj administrantoj, bazitaj sur jam kaptitaj domajnaj kontoj.
• Ni lanĉas Mimikatz kaj ricevas kaŝmemorajn pasvortojn, Kerberos-biletojn kaj NTLM-haŝojn de domajnaj kontoj, kiuj ĵus ensalutis en ĉi tiun sistemon. Aŭ ni forigas la memorbildon de la procezo lsass.exe kaj faras la samon ĉe nia flanko. Ĉi tio funkcias bone kun Vindozo pli juna ol 2012R2/Vindozo 8.1 kun defaŭltaj agordoj.
• Ni determinas kie la kompromititaj kontoj havas lokajn administrantajn rajtojn. Ni ripetas la unuan punkton. En iu etapo ni akiras administrantajn rajtojn por la tuta domajno.

"Fino de la Ciklo;", kiel 1C-programistoj skribus ĉi tie.

Do, nia uzanto montriĝis loka administranto sur nur unu gastiganto kun Windows 7, kies nomo inkludis la vorton "VDI", aŭ "Virtuala Labortabla Infrastrukturo", personaj virtualaj maŝinoj. Verŝajne, la dizajnisto de la VDI-servo signifis, ke ĉar VDI estas la persona operaciumo de la uzanto, eĉ se la uzanto ŝanĝas la programaran medion laŭplaĉe, la gastiganto ankoraŭ povas esti "reŝargita". Mi ankaŭ opiniis, ke ĝenerale la ideo estis bona, mi iris al ĉi tiu persona VDI-gastiganto kaj faris neston tie:

• Mi instalis tie OpenVPN-klienton, kiu faris tunelon tra la Interreto al mia servilo. La kliento devis esti devigita trairi la saman Bluan Manteton kun domajna aŭtentigo, sed OpenVPN faris tion, kiel oni diras, "el la skatolo".
• Instalita OpenSSH sur VDI. Nu, vere, kio estas Vindozo 7 sen SSH?

Jen kiel ĝi aspektis vive. Mi memorigu vin, ke ĉio ĉi devas esti farita per Citrix kaj 1C:

Unu tekniko por antaŭenigi aliron al najbaraj komputiloj estas kontroli lokajn administrantajn pasvortojn por kongruo. Ĉi tie la bonŝanco tuj atendis: la NTLM-haŝiŝo de la defaŭlta loka administranto (kiu estis subite nomita Administranto) estis alproksimigita per pas-la-haŝa atako al najbaraj VDI-gastigantoj, el kiuj estis kelkcent. Kompreneble, la atako tuj trafis ilin.

Jen kie administrantoj de VDI pafis sin en la piedon dufoje:

• La unua fojo estis kiam VDI-maŝinoj ne estis alportitaj sub LAPS, esence retenante la saman lokan administranpasvorton de la bildo kiu estis masive deplojita al VDI.
• La defaŭlta administranto estas la nura loka konto, kiu estas vundebla al pas-la-haŝaj atakoj. Eĉ kun la sama pasvorto, eblus eviti amasan kompromison kreante duan lokan administrankonton kun kompleksa hazarda pasvorto kaj blokante la defaŭltan.

Kial la SSH-servo sur tiu Vindozo? Tre simpla: nun la servilo OpenSSH ne nur disponigis oportunan interagan komandan ŝelon sen malhelpi la laboron de la uzanto, sed ankaŭ socks5-prokurilon sur VDI. Per ĉi tiuj ŝtrumpetoj, mi konektis per SMB kaj kolektis kaŝmemoritajn kontojn de ĉiuj ĉi tiuj centoj da VDI-maŝinoj, poste serĉis la vojon al la domajna administranto uzante ilin en la BloodHound-grafikoj. Kun centoj da gastigantoj je mia dispono, mi trovis ĉi tiun manieron sufiĉe rapide. Domajna administrantorajtoj estis akiritaj.

Jen bildo el Interreto montranta similan serĉon. Konektoj montras kiu estas kie la administranto estas kaj kiu estas ensalutinta kie.

Cetere, memoru la kondiĉon de la komenco de la projekto - "ne uzu socian inĝenieristikon." Do, mi proponas pensi pri kiom multe ĉi tiu Bollywood kun specialaj efektoj estus fortranĉita, se ankoraŭ eblus uzi banalan phishing. Sed persone, estis tre interese por mi fari ĉion ĉi. Mi esperas, ke vi ĝuis legi ĉi tion. Kompreneble, ne ĉiu projekto aspektas tiel interesa, sed la laboro entute estas tre malfacila kaj ne permesas al ĝi stagni.

Verŝajne iu havos demandon: kiel protekti vin? Eĉ ĉi tiu artikolo priskribas multajn teknikojn, pri kiuj multaj Vindozaj administrantoj eĉ ne scias. Tamen mi proponas rigardi ilin el la perspektivo de truditaj principoj kaj informsekurecaj mezuroj:

• ne uzu malmodernan programaron (memoru Vindozon 2003 en la komenco?)
• ne konservu nenecesajn sistemojn ŝaltitaj (kial estis retejo de urologo?)
• kontrolu uzantpasvortojn por forto mem (alie soldatoj... pentesteroj faros tion)
• ne havas la samajn pasvortojn por malsamaj kontoj (VDI-kompromiso)
• kaj alia

Kompreneble, ĉi tio estas tre malfacile efektivigi, sed en la sekva artikolo ni montros praktike, ke ĝi estas tute ebla.

fonto: www.habr.com