Tento článek byl napsán na základě velmi úspěšného pentestu, který specialisté Group-IB provedli před několika lety: stal se příběh, který by mohl být adaptován pro film v Bollywoodu. Teď asi bude následovat reakce čtenáře: "Aha, další PR článek, zase se líčí, jak jsou dobré, nezapomeňte si koupit pentest." No, na jednu stranu je. Existuje však řada dalších důvodů, proč se tento článek objevil. Chtěl jsem ukázat, co přesně pentesteri dělají, jak zajímavá a netriviální tato práce může být, jaké vtipné okolnosti mohou v projektech nastat, a hlavně ukázat živý materiál s reálnými příklady.
Abychom obnovili rovnováhu skromnosti ve světě, po čase napíšeme o pentestu, který se nepovedl. Ukážeme, jak dobře navržené procesy ve firmě dokážou ochránit před celou řadou útoků, a to i dobře připravených, prostě proto, že tyto procesy existují a skutečně fungují.
Pro zákazníka v tomto článku bylo také vše obecně vynikající, alespoň lepší než 95% trhu v Ruské federaci, podle našich pocitů, ale byla zde řada malých nuancí, které vytvořily dlouhý řetězec událostí, které nejprve vedlo k dlouhé zprávě o práci a poté k tomuto článku.
Pojďme se tedy zásobit popcornem a vítejte v detektivce. slovo - Pavel Suprunjuk, technický manažer oddělení „Audit a poradenství“ Group-IB.
Část 1. Pochkin lékař
2018 Existuje zákazník – high-tech IT společnost, která sama obsluhuje mnoho klientů. Chce získat odpověď na otázku: je možné bez počátečních znalostí a přístupu pomocí internetu získat práva správce domény Active Directory? Nezajímá mě žádné sociální inženýrství (), nemají v úmyslu záměrně zasahovat do práce, ale mohou náhodně - například znovu načíst podivně fungující server. Dalším cílem je identifikovat co nejvíce dalších útočných vektorů proti vnějšímu perimetru. Společnost takové testy pravidelně provádí a nyní nadešel termín nového testu. Podmínky jsou téměř typické, přiměřené, srozumitelné. Začněme.
Je tam jméno zákazníka - nechť je to „Společnost“, s hlavní webovou stránkou . Zákazník se samozřejmě jmenuje jinak, ale v tomto článku bude vše neosobní.
Provádím rekognoskaci sítě - zjistěte, které adresy a domény jsou u zákazníka registrované, nakreslím schéma sítě, jak jsou na tyto adresy distribuovány služby. Dostávám výsledek: více než 4000 živých IP adres. Dívám se na domény v těchto sítích: naštěstí je to velká většina sítí určených pro klienty zákazníka a my o ně nemáme formální zájem. Zákazník si myslí totéž.
Zůstává jedna síť s 256 adresami, pro kterou je v tuto chvíli již chápáno rozdělení domén a subdomén podle IP adres, existují informace o skenovaných portech, což znamená, že se můžete podívat na služby, které jsou zajímavé. Paralelně se spouštějí všechny druhy skenerů na dostupných IP adresách a samostatně na webových stránkách.
Služeb je spousta. Obvykle je to pro pentester radost a očekávání rychlého vítězství, protože čím více služeb je, tím větší je pole pro útok a tím snazší je najít artefakt. Letmý pohled na weby ukázal, že se většinou jedná o webová rozhraní známých produktů velkých světových společností, které vám podle všeho říkají, že nejsou vítány. Požádají o uživatelské jméno a heslo, vyklepou pole pro zadání druhého faktoru, požádají o certifikát klienta TLS nebo jej pošlou do Microsoft ADFS. Některé jsou jednoduše nedostupné z internetu. Pro některé evidentně potřebujete mít speciálního placeného klienta na tři platy nebo znát přesnou URL adresu, kterou zadáte. Přeskočme další týden postupné sklíčenosti v procesu pokusů „prolomit“ verze softwaru pro známá zranitelnost, hledání skrytého obsahu na webových cestách a uniklých účtů ze služeb třetích stran, jako je LinkedIn, a pokusů o uhodnutí hesel pomocí nich. jako vykopávání zranitelností na webech, které si sami píší — mimochodem, podle statistik je to dnes nejslibnější vektor vnějšího útoku. Okamžitě si všimnu filmové pistole, která následně vystřelila.
Našli jsme tedy dva weby, které vyčnívaly ze stovek služeb. Tyto stránky měly jednu věc společnou: pokud se nezapojíte do pečlivého průzkumu sítě podle domén, ale budete přímo hledat otevřené porty nebo se zaměříte na skener zranitelnosti pomocí známého rozsahu IP, pak tyto stránky uniknou skenování a jednoduše nebudou viditelné bez znalosti názvu DNS. Možná, že byly alespoň zmeškány dříve a naše automatické nástroje s nimi nenašly žádné problémy, i když byly odeslány přímo do zdroje.
Mimochodem, o tom, co dříve spuštěné skenery obecně našly. Dovolte mi připomenout: pro některé lidi je „pentest“ ekvivalentem „automatického skenování“. Ale skenery tohoto projektu nic neřekly. No, maximum ukázaly střední zranitelnosti (3 z 5 z hlediska závažnosti): u některých služeb špatný certifikát TLS nebo zastaralé šifrovací algoritmy a na většině webů Clickjacking. To vás ale k cíli nedostane. Možná by zde byly užitečnější skenery, ale připomenu: takové programy si může zákazník zakoupit a sám se s nimi otestovat, a soudě podle tristních výsledků již zkontroloval.
Vraťme se k „anomálním“ webům. První je něco jako místní Wiki na nestandardní adrese, ale v tomto článku nechť je to wiki.company[.]ru. Také hned požádala o přihlašovací jméno a heslo, ale přes NTLM v prohlížeči. Pro uživatele to vypadá jako asketické okno požadující zadání uživatelského jména a hesla. A to je špatná praxe.
Malá poznámka. NTLM na okrajových webech je špatný z mnoha důvodů. Prvním důvodem je odhalení názvu domény Active Directory. V našem příkladu se také ukázalo, že je to company.ru, stejně jako „externí“ název DNS. S tímto vědomím můžete pečlivě připravit něco škodlivého, aby se to spustilo pouze na doménovém počítači organizace a ne v nějaké karanténě. Za druhé, autentizace probíhá přímo přes doménový řadič přes NTLM (překvapení, že?), se všemi funkcemi „interních“ síťových zásad, včetně blokování účtů před překročením počtu pokusů o zadání hesla. Pokud útočník zjistí přihlašovací údaje, vyzkouší k nim hesla. Pokud jste nakonfigurováni k blokování účtů před zadáváním nesprávných hesel, bude to fungovat a účet bude zablokován. Za třetí, k takové autentizaci není možné přidat druhý faktor. Pokud někdo ze čtenářů stále ví jak, dejte mi prosím vědět, je to opravdu zajímavé. Za čtvrté, zranitelnost vůči pass-the-hash útokům. ADFS byl vynalezen mimo jiné proto, aby proti tomu všemu chránil.
Existuje jedna špatná vlastnost produktů společnosti Microsoft: i když jste takový NTLM konkrétně nepublikovali, bude standardně nainstalován alespoň v OWA a Lync.
Mimochodem, autor tohoto článku jednou stejnou metodou omylem zablokoval přibližně 1000 účtů zaměstnanců jedné velké banky za pouhou hodinu a pak vypadal poněkud bledě. IT služby banky byly také bledé, ale vše skončilo dobře a adekvátně, dokonce jsme byli pochváleni, že jsme jako první našli tento problém a vyprovokovali rychlou a rozhodnou nápravu.
Druhý web měl adresu „zřejmě nějaké příjmení.company.ru“. Našel jsem to přes Google, něco takového na straně 10. Návrh byl z počátku poloviny XNUMX. století a slušný člověk se na něj díval z hlavní stránky, asi takto:
Zde jsem vzal destilku ze „Heart of a Dog“, ale věřte mi, bylo to matně podobné, dokonce i barevné provedení bylo v podobných tónech. Nechte web zavolat preobrazhensky.company.ru.
Byly to osobní stránky... urologa. Zajímalo by mě, co dělá web urologa na subdoméně high-tech společnosti. Rychlý průzkum Google ukázal, že tento lékař byl spoluzakladatelem jedné z právnických osob našeho zákazníka a dokonce přispěl asi 1000 XNUMX rublů v základním kapitálu. Stránky byly pravděpodobně vytvořeny před mnoha lety a jako hosting byly použity serverové zdroje zákazníka. Stránka již dávno ztratila svou relevanci, ale z nějakého důvodu byla ponechána dlouhou dobu funkční.
Z hlediska zranitelností byl web sám o sobě bezpečný. Při pohledu dopředu řeknu, že šlo o soubor statických informací – jednoduchých html stránek s vloženými ilustracemi v podobě ledvin a močového měchýře. Je zbytečné takový web „rozbíjet“.
Ale webový server pod ním byl zajímavější. Soudě podle hlavičky HTTP Server měl IIS 6.0, což znamená, že jako operační systém používal Windows 2003. Skener již dříve zjistil, že tento konkrétní web urologa, na rozdíl od jiných virtuálních hostitelů na stejném webovém serveru, reagoval na příkaz PROPFIND, což znamená, že spouštěl WebDAV. Mimochodem, skener tuto informaci vrátil s označením Info (v jazyce hlášení skenerů je to nejmenší nebezpečí) - takové věci se většinou jednoduše přeskakují. V kombinaci to dalo zajímavý efekt, který se ukázal až po dalším překopání na Googlu: vzácná zranitelnost přetečení bufferu spojená se sadou Shadow Brokers, konkrétně CVE-2017-7269, která už měla připravený exploit. Jinými slovy, nastanou potíže, pokud máte Windows 2003 a WebDAV běží na IIS. I když provozování Windows 2003 ve výrobě v roce 2018 je problém sám o sobě.
Exploit skončil v Metasploitu a byl okamžitě testován se zátěží, která odeslala DNS požadavek na řízenou službu – Burp Collaborator se tradičně používá k zachycení DNS požadavků. K mému překvapení to fungovalo napoprvé: byl přijat knockout DNS. Dále došlo k pokusu o vytvoření backconnect přes port 80 (tj. síťové připojení ze serveru k útočníkovi s přístupem k cmd.exe na hostiteli oběti), ale pak došlo k fiasku. Spojení neproběhlo a po třetím pokusu o použití stránky spolu se všemi zajímavými obrázky nenávratně zmizely.
Obvykle následuje dopis ve stylu „zákazníku, probuď se, všechno jsme nechali“. Bylo nám ale řečeno, že stránka nemá nic společného s obchodními procesy a funguje tam bezdůvodně, stejně jako celý server, a že tento zdroj můžeme používat, jak chceme.
Asi o den později začal web najednou fungovat sám. Po vytvoření lavice z WebDAV na IIS 6.0 jsem zjistil, že výchozí nastavení je restartovat pracovní procesy IIS každých 30 hodin. To znamená, že když ovládání opustilo shell kód, pracovní proces IIS skončil, pak se sám několikrát restartoval a pak přešel na 30 hodin do klidu.
Vzhledem k tomu, že zpětné připojení k tcp selhalo napoprvé, připisoval jsem tento problém uzavřenému portu. To znamená, že předpokládal přítomnost nějakého druhu firewallu, který neumožňoval odchozí spojení procházet ven. Začal jsem spouštět shell kódy, které prohledávaly mnoho tcp a udp portů, ale žádný efekt. Reverzní zatížení připojení přes http(s) z Metasploit nefungovalo - meterpreter/reverse_http(s). Najednou bylo navázáno spojení se stejným portem 80, ale okamžitě přerušeno. Přičítal jsem to akci stále imaginárního IPS, kterému se nelíbila provoz meterpretu. Ve světle skutečnosti, že čisté tcp připojení k portu 80 neprošlo, ale http připojení ano, jsem usoudil, že http proxy je v systému nějak nakonfigurována.
Dokonce jsem zkusil meterpreter přes DNS (díky za vaše úsilí, zachránili jste mnoho projektů), připomněli si úplně první úspěch, ale nefungovalo to ani na stojanu - kód shellu byl pro tuto chybu zabezpečení příliš objemný.
Ve skutečnosti to vypadalo takto: 3-4 pokusy o útok během 5 minut, pak čekání 30 hodin. A tak tři týdny po sobě. Dokonce jsem si nastavil připomenutí, abych neztrácel čas. Navíc byl rozdíl v chování testovacího a produkčního prostředí: pro tuto zranitelnost existovaly dva podobné exploity, jeden z Metasploitu, druhý z internetu, převedený z verze Shadow Brokers. V boji byl tedy testován pouze Metasploit a na lavičce byl testován pouze druhý, což ještě více ztěžovalo ladění a lámalo mozek.
Nakonec se osvědčil shell kód, který stáhl exe soubor z daného serveru přes http a spustil jej na cílovém systému. Shell kód byl dost malý, aby se do něj vešel, ale alespoň fungoval. Protože se serveru vůbec nelíbil TCP provoz a http(s) bylo zkontrolováno na přítomnost meterpreteru, rozhodl jsem se, že nejrychlejším způsobem je stáhnout exe soubor, který obsahuje DNS-meterpreter přes tento shell kód.
Zde opět nastal problém: při stahování exe souboru a jak ukázaly pokusy, bez ohledu na to, bylo stahování přerušeno. Opět se některému zabezpečovacímu zařízení mezi mým serverem a urologem nelíbil provoz http s exe uvnitř. Zdálo se, že „rychlým“ řešením je změnit kód shellu tak, aby za provozu zatemňoval http provoz, takže by se místo exe přenášela abstraktní binární data. Nakonec byl útok úspěšný, kontrola byla přijata přes tenký kanál DNS:
Okamžitě bylo jasné, že mám nejzákladnější práva k pracovnímu postupu IIS, která mi neumožňují nic nedělat. Takto to vypadalo na konzoli Metasploit:
Všechny metodologie pentestu důrazně naznačují, že při získávání přístupu musíte zvýšit práva. Obvykle to nedělám lokálně, protože úplně první přístup je vnímán jednoduše jako vstupní bod sítě a kompromitace jiného počítače ve stejné síti je obvykle jednodušší a rychlejší než eskalace oprávnění na stávajícím hostiteli. To však není tento případ, protože kanál DNS je velmi úzký a nedovolí, aby se provoz vyčistil.
Za předpokladu, že tento server Windows 2003 nebyl opraven pro slavnou chybu zabezpečení MS17-010, tuneluji provoz na port 445/TCP tunelem DNS meterpreter na localhost (ano, je to také možné) a pokusím se spustit dříve stažené exe přes zranitelnost. Útok funguje, dostávám druhé připojení, ale se SYSTÉMOVÝMI právy.
Je zajímavé, že se stále snažili chránit server před MS17-010 - měl na externím rozhraní vypnuté zranitelné síťové služby. To sice chrání před útoky přes síť, ale útok zevnitř na localhost fungoval, protože nemůžete jen tak rychle vypnout SMB na localhost.
Dále jsou odhaleny nové zajímavé detaily:
- S právy SYSTEM můžete snadno navázat zpětné spojení přes TCP. Je zřejmé, že zakázání přímého protokolu TCP je striktně problémem pro omezeného uživatele IIS. Spoiler: uživatelský provoz IIS byl nějak zabalen v místním ISA proxy v obou směrech. Jak přesně to funguje, jsem nereprodukoval.
- Jsem v určité „DMZ“ (a toto není doména Active Directory, ale PRACOVNÍ SKUPINA) – zní to logicky. Ale místo očekávané soukromé („šedé“) IP adresy mám úplně „bílou“ IP adresu, přesně stejnou, jakou jsem napadl dříve. To znamená, že společnost je ve světě IPv4 adres tak stará, že si může dovolit udržovat DMZ zónu pro 128 „bílých“ adres bez NAT podle schématu, jak je znázorněno v manuálech Cisco z roku 2005.
Vzhledem k tomu, že server je starý, je zaručeno, že Mimikatz bude pracovat přímo z paměti:
Získám heslo místního správce, vytuneluji provoz RDP přes TCP a přihlásím se na útulnou plochu. Protože jsem si se serverem mohl dělat, co jsem chtěl, odstranil jsem antivirus a zjistil jsem, že server je přístupný z internetu pouze přes TCP porty 80 a 443 a 443 není vytížený. Nastavil jsem server OpenVPN na 443, přidal funkce NAT pro svůj provoz VPN a získal přímý přístup k síti DMZ v neomezené podobě prostřednictvím mého OpenVPN. Je pozoruhodné, že ISA, která má některé nedeaktivované funkce IPS, zablokovala můj provoz skenováním portů, kvůli čemuž musela být nahrazena jednodušším a vyhovujícím RRAS. Takže pentesteri občas ještě musí spravovat nejrůznější věci.
Pozorný čtenář se zeptá: „A co druhý web – wiki s ověřováním NTLM, o které toho bylo napsáno tolik?“ Více o tom později.
Část 2. Stále nešifrujete? Pak už k vám přicházíme
Existuje tedy přístup do segmentu sítě DMZ. Musíte se obrátit na správce domény. První věc, která vás napadne, je automatická kontrola zabezpečení služeb v rámci segmentu DMZ, zejména proto, že mnohem více z nich je nyní otevřeno pro výzkum. Typický obrázek při penetračním testu: externí perimetr je chráněn lépe než interní služby a při získávání jakéhokoli přístupu uvnitř velké infrastruktury je mnohem snazší získat rozšířená práva v doméně jen díky tomu, že tato doména začíná být přístupné nástrojům a za druhé, v infrastruktuře s několika tisíci hostiteli bude vždy existovat několik kritických problémů.
Nabiju skenery přes DMZ přes OpenVPN tunel a čekám. Otevírám zprávu - opět nic vážného, zřejmě někdo prošel stejnou metodou přede mnou. Dalším krokem je prozkoumat, jak komunikují hostitelé v síti DMZ. Chcete-li to provést, nejprve spusťte obvyklý Wireshark a poslouchejte požadavky na vysílání, především ARP. Pakety ARP byly shromažďovány po celý den. Ukazuje se, že v tomto segmentu se používá několik bran. To se bude hodit později. Kombinací dat o ARP požadavku-odpovědích a dat skenování portů jsem kromě služeb, které byly dříve známé, jako je web a pošta, našel výstupní body uživatelského provozu z místní sítě.
Vzhledem k tomu, že jsem v tuto chvíli neměl přístup k jiným systémům a neměl ani jediný účet pro firemní služby, bylo rozhodnuto vylovit z provozu alespoň nějaký účet pomocí ARP Spoofingu.
Cain&Abel byl spuštěn na serveru urologa. S ohledem na identifikované toky provozu byly vybrány nejslibnější páry pro útok typu man-in-the-middle a poté byl krátkodobě spouštěn po dobu 5-10 minut nějaký síťový provoz s časovačem pro restartování serveru. v případě zamrznutí. Stejně jako ve vtipu byly dvě novinky:
- Dobrý: chytilo se hodně pověření a útok jako celek fungoval.
- Špatné: všechny přihlašovací údaje pocházely od vlastních klientů zákazníka. Při poskytování podpůrných služeb se zákazničtí specialisté připojovali ke službám klientů, kteří neměli vždy nastaveno šifrování provozu.
Díky tomu jsem získal spoustu přihlašovacích údajů, které byly v kontextu projektu k ničemu, ale jako ukázka nebezpečí útoku rozhodně zajímavé. Hraniční routery velkých společností s telnetem, přeposlané ladicí http porty do interního CRM se všemi daty, přímý přístup k RDP z Windows XP na lokální síti a další tmářství. Dopadlo to takto .
Také jsem našel vtipnou příležitost sbírat dopisy z provozu, něco takového. Toto je příklad hotového dopisu, který odešel od našeho zákazníka na SMTP port jeho klienta, opět bez šifrování. Jistý Andrey požádá svého jmenovce o opětovné zaslání dokumentace a ta se nahraje na cloudový disk s přihlašovacím jménem, heslem a odkazem v jednom dopise s odpovědí:
Toto je další připomínka šifrování všech služeb. Není známo, kdo a kdy bude konkrétně číst a používat vaše data – poskytovatel, správce systému jiné společnosti nebo takový pentester. O tom, že mnoho lidí dokáže jednoduše zachytit nešifrovaný provoz, mlčím.
Přes zdánlivý úspěch nás to k cíli nepřiblížilo. Dalo se samozřejmě dlouho sedět a vylovit cenné informace, ale není fakt, že by se tam objevily a samotný útok je velmi riskantní z hlediska integrity sítě.
Po dalším kopání do služeb přišel na mysl zajímavý nápad. Existuje takový nástroj s názvem Responder (s tímto názvem lze snadno najít příklady použití), který „otrávením“ požadavků na vysílání vyvolává připojení prostřednictvím různých protokolů, jako je SMB, HTTP, LDAP atd. různými způsoby, pak požádá každého, kdo se připojí, aby se ověřil, a nastaví to tak, aby ověřování probíhalo přes NTLM a v režimu transparentním pro oběť. Nejčastěji útočník tímto způsobem sbírá handshaky NetNTLMv2 a pomocí slovníku z nich rychle obnovuje hesla uživatelských domén. Tady jsem chtěl něco podobného, ale uživatelé seděli „za zdí“, respektive byli odděleni firewallem a přistupovali na WEB přes proxy cluster Blue Coat.
Pamatujete si, že jsem uvedl, že název domény Active Directory se shodoval s „externí“ doménou, to znamená, že to bylo company.ru? Takže Windows, přesněji Internet Explorer (a Edge a Chrome), umožňují uživateli transparentní autentizaci v HTTP přes NTLM, pokud usoudí, že se stránka nachází v nějaké „zóně intranetu“. Jedním ze znaků „intranetu“ je přístup k „šedé“ IP adrese nebo krátkému názvu DNS, tedy bez teček. Vzhledem k tomu, že měli server s „bílou“ IP a DNS názvem preobrazhensky.company.ru a doménové stroje obvykle dostávají příponu domény Active Directory přes DHCP pro zjednodušené zadávání názvu, museli pouze napsat URL do adresního řádku. , aby našli správnou cestu k serveru napadeného urologa, přičemž nezapomněli, že se tomu nyní říká „intranet“. To znamená, že mi zároveň dáváte NTLM handshake uživatele bez jeho vědomí. Nezbývá než donutit klientské prohlížeče, aby přemýšlely o naléhavé potřebě kontaktovat tento server.
Nádherná utilita Intercepter-NG přišla na záchranu (díky ). Umožnil vám měnit provoz za běhu a fungoval skvěle na Windows 2003. Dokonce měl samostatnou funkci pro úpravu pouze souborů JavaScriptu v toku provozu. Bylo naplánováno jakési masivní Cross-Site Scripting.
Proxy Blue Coat, přes které uživatelé přistupovali na globální WEB, pravidelně ukládaly do mezipaměti statický obsah. Zachycováním provozu bylo jasné, že pracují nepřetržitě a donekonečna požadují často používanou statiku pro zrychlení zobrazování obsahu ve špičce. BlueCoat měl navíc specifického User-Agenta, který jej jasně odlišoval od skutečného uživatele.
Byl připraven Javascript, který byl pomocí Intercepter-NG implementován hodinu v noci pro každou odpověď s JS soubory pro Blue Coat. Skript provedl následující:
- Určení aktuálního prohlížeče pomocí User-Agent. Pokud to byl Internet Explorer, Edge nebo Chrome, fungovalo to dál.
- Čekal jsem, až se vytvoří DOM stránky.
- Vložil neviditelný obrázek do DOM s atributem src formuláře :8080/NNNNNNNN.png, kde NNN jsou libovolná čísla, aby je BlueCoat neukládal do mezipaměti.
- Nastavte proměnnou globálního příznaku, která označí, že injekce byla dokončena a již není potřeba vkládat obrázky.
Prohlížeč se pokusil načíst tento obrázek, na portu 8080 napadeného serveru na něj čekal TCP tunel do mého notebooku, kde běžel stejný Responder, který vyžadoval přihlášení prohlížeče přes NTLM.
Soudě podle záznamů Responderu lidé přišli ráno do práce, zapnuli své pracovní stanice, pak hromadně a nepozorovaně začali navštěvovat server urologa a nezapomněli „vyčerpat“ NTLM handshake. Potřesení rukou pršelo celý den a jasně se nahromadil materiál pro evidentně úspěšný útok na obnovu hesel. Takto vypadaly protokoly Responderu:
Hromadné tajné návštěvy uživatelů na serveru urologa
Pravděpodobně jste si již všimli, že celý tento příběh je postaven na principu „všechno bylo v pořádku, ale pak došlo k průšvihu, pak došlo k překonání a pak se vše podařilo. Takže tady byl průšvih. Z padesáti unikátních podání rukou nebyl odhalen ani jeden. A to bere v úvahu skutečnost, že i na notebooku s mrtvým procesorem jsou tyto NTLMv2 handshaky zpracovávány rychlostí několika set milionů pokusů za sekundu.
Musel jsem se vyzbrojit technikami mutace hesel, grafickou kartou, tlustším slovníkem a čekat. Po dlouhé době bylo odhaleno několik účtů s hesly ve tvaru „Q11111111....1111111q“, což naznačuje, že všichni uživatelé byli kdysi nuceni přijít s velmi dlouhým heslem s odlišnou velikostí písmen, což také mělo být být komplexní. Ale ostříleného uživatele nemůžete oklamat, a tak si usnadnil zapamatování. Celkem bylo kompromitováno asi 5 účtů a pouze jeden z nich měl nějaká cenná práva ke službám.
Část 3. Roskomnadzor vrací úder
Byly tedy přijaty první doménové účty. Pokud jste tímto bodem z dlouhého čtení nezaspali, pravděpodobně si vzpomenete, že jsem zmínil službu, která nevyžadovala druhý faktor ověřování: je to wiki s ověřováním NTLM. Samozřejmě, že první věc, kterou bylo třeba udělat, bylo vstoupit tam. Prozkoumání interní znalostní báze rychle přineslo výsledky:
- Společnost disponuje WiFi sítí s autentizací pomocí doménových účtů s přístupem do lokální sítě. Se současnou sadou dat je to již fungující vektor útoku, ale musíte jít do kanceláře nohama a nacházet se někde na území kanceláře zákazníka.
- Našel jsem pokyn, podle kterého existovala služba, která umožňovala... nezávisle zaregistrovat autentizační zařízení „druhého faktoru“, pokud je uživatel v místní síti a s jistotou si pamatuje přihlašovací jméno a heslo své domény. V tomto případě byly „uvnitř“ a „venku“ určeny dostupností portu této služby pro uživatele. Port nebyl přístupný z internetu, ale byl docela dostupný přes DMZ.
K napadenému účtu se samozřejmě okamžitě přidal „druhý faktor“ v podobě aplikace v mém telefonu. Existoval program, který dokázal buď hlasitě odeslat do telefonu požadavek push pomocí tlačítek „schválit“/„neschválit“ akci, nebo tiše ukázat OTP kód na obrazovce pro další nezávislé zadání. Navíc první metoda měla být podle návodu jediná správná, ale na rozdíl od metody OTP nefungovala.
S nefunkčním „druhým faktorem“ jsem měl přístup k poště Outlook Web Access a vzdálenému přístupu v Citrix Netscaler Gateway. V e-mailu v Outlooku bylo překvapení:
Na tomto vzácném záběru můžete vidět, jak Roskomnadzor pomáhá pentesterům
Byly to první měsíce po slavném „fanouškovském“ zablokování Telegramu, kdy z přístupu neúprosně mizely celé sítě s tisíci adresami. Okamžitě se ukázalo, proč push nefungoval a proč moje „oběť“ nezazvonila na poplach, protože začali používat její účet během otevírací doby.
Každý, kdo je obeznámen s Citrix Netscaler, si představuje, že je obvykle implementován tak, že uživateli může být zprostředkováno pouze obrázkové rozhraní, snaží se nedávat mu nástroje pro spouštění aplikací třetích stran a přenos dat, což všemožným způsobem omezuje akce. prostřednictvím standardních ovládacích skořápek. Moje „oběť“ díky svému povolání dostala pouze 1C:
Poté, co jsem trochu prošel rozhraním 1C, zjistil jsem, že tam jsou externí moduly pro zpracování. Lze je načíst z rozhraní a budou spuštěny na klientovi nebo serveru v závislosti na právech a nastaveních.
Požádal jsem své přátele programátory 1C, aby vytvořili zpracování, které by přijalo řetězec a provedlo jej. V jazyce 1C vypadá spuštění procesu asi takto (převzato z internetu). Souhlasíte s tím, že syntaxe jazyka 1C udivuje rusky mluvící lidi svou spontánností?
Zpracování bylo provedeno perfektně, ukázalo se, že je to to, co pentesteri nazývají „shell“ - byl přes něj spuštěn Internet Explorer.
Dříve byla v e-mailu nalezena adresa systému, který umožňuje objednávat propustky na území. Objednal jsem si propustku pro případ, že bych musel použít vektor útoku WiFi.
Na internetu se mluví o tom, že v zákaznické kanceláři byl ještě výborný bezplatný catering, ale i tak jsem raději vyvíjel útok na dálku, je to klidnější.
AppLocker byl aktivován na aplikačním serveru se systémem Citrix, ale byl vynechán. Stejný Meterpreter byl načten a spuštěn přes DNS, protože verze http(s) se nechtěly připojit a v té době jsem neznal interní adresu proxy. Mimochodem, od této chvíle se vnější pentest v podstatě zcela změnil na vnitřní.
Část 4. Práva správce pro uživatele jsou špatná, ano?
Prvním úkolem pentestera při získávání kontroly nad uživatelskou relací domény je shromáždit všechny informace o právech v doméně. Existuje utilita BloodHound, která automaticky umožňuje stahovat informace o uživatelích, počítačích, bezpečnostních skupinách přes protokol LDAP z řadiče domény a přes SMB - informace o tom, který uživatel se kde naposledy přihlásil a kdo je místním správcem.
Typická technika pro získání práv správce domény vypadá zjednodušeně jako cyklus monotónních akcí:
- Jdeme do doménových počítačů, kde jsou práva lokálního správce, na základě již zachycených doménových účtů.
- Spouštíme Mimikatz a získáváme hesla uložená v mezipaměti, lístky Kerberos a NTLM hash doménových účtů, které se nedávno přihlásily do tohoto systému. Nebo odstraníme obraz paměti procesu lsass.exe a uděláme totéž na naší straně. To funguje dobře s Windows mladšími než 2012R2/Windows 8.1 s výchozím nastavením.
- Zjistíme, kde mají napadené účty práva místního správce. Opakujeme první bod. V určité fázi získáváme administrátorská práva pro celou doménu.
„Konec cyklu“, jak by zde napsali programátoři 1C.
Náš uživatel se tedy ukázal být místním správcem pouze jednoho hostitele s Windows 7, jehož název zahrnoval slovo „VDI“ nebo „Infrastruktura virtuální plochy“, osobní virtuální stroje. Návrhář služby VDI měl pravděpodobně na mysli, že vzhledem k tomu, že VDI je osobní operační systém uživatele, i když uživatel změní softwarové prostředí podle libosti, hostitele lze stále „znovu načíst“. Také jsem si myslel, že obecně je nápad dobrý, šel jsem za tímto osobním hostitelem VDI a udělal jsem si tam hnízdo:
- Nainstaloval jsem tam klienta OpenVPN, který udělal tunel přes internet na můj server. Klient musel být nucen projít stejným Blue Coat s doménovou autentizací, ale OpenVPN to udělal, jak se říká, „po vybalení“.
- Nainstalovaný OpenSSH na VDI. No, opravdu, co je Windows 7 bez SSH?
Takhle to vypadalo naživo. Dovolte mi, abych vám připomněl, že toto vše musí být provedeno prostřednictvím Citrixu a 1C:
Jednou z technik podpory přístupu k sousedním počítačům je kontrola hesel místních administrátorů, zda se shodují. Zde okamžitě čekalo štěstí: NTLM hash výchozího místního správce (který byl náhle nazýván Administrator) byl osloven pomocí pass-the-hash útoku na sousední VDI hostitele, kterých bylo několik stovek. Útok je samozřejmě okamžitě zasáhl.
Zde se správci VDI dvakrát střelili do nohy:
- Poprvé to bylo, když stroje VDI nebyly převedeny pod LAPS a v podstatě si zachovaly stejné heslo místního správce z bitové kopie, která byla masivně nasazena na VDI.
- Výchozí správce je jediný místní účet, který je zranitelný vůči útokům typu pass-the-hash. I se stejným heslem by bylo možné předejít hromadnému kompromisu vytvořením druhého lokálního administrátorského účtu se složitým náhodným heslem a zablokováním výchozího.
Proč je na tom Windows služba SSH? Velmi jednoduché: OpenSSH server nyní poskytuje nejen pohodlný interaktivní příkazový shell, aniž by zasahoval do práce uživatele, ale také Socks5 proxy na VDI. Prostřednictvím těchto ponožek jsem se připojil přes SMB a shromáždil účty uložené v mezipaměti ze všech těchto stovek strojů VDI a poté hledal cestu ke správci domény pomocí nich v grafech BloodHound. Se stovkami hostitelů, které mám k dispozici, jsem tuto cestu našel docela rychle. Byla získána práva správce domény.
Zde je obrázek z internetu ukazující podobné vyhledávání. Spojení ukazují, kdo je kde je správce a kdo je kde přihlášen.
Mimochodem, pamatujte na podmínku ze začátku projektu – „nepoužívejte sociální inženýrství“. Navrhuji tedy přemýšlet o tom, jak moc by byl celý tento Bollywood se speciálními efekty odříznut, kdyby bylo stále možné používat banální phishing. Ale osobně pro mě bylo velmi zajímavé tohle všechno dělat. Doufám, že se vám to líbilo. Samozřejmě ne každý projekt vypadá tak zajímavě, ale práce jako celek je velmi náročná a nedovolí, aby stagnovala.
Pravděpodobně někoho napadne otázka: jak se chránit? Dokonce i tento článek popisuje mnoho technik, o mnoha z nich správci Windows ani nevědí. Navrhuji však podívat se na ně z pohledu otřepaných principů a opatření pro bezpečnost informací:
- nepoužívejte zastaralý software (pamatujete si Windows 2003 na začátku?)
- nenechávejte zapnuté zbytečné systémy (proč existoval web urologa?)
- sami si zkontrolujte uživatelská hesla na sílu (jinak to udělají vojáci... pentestři)
- nemají stejná hesla pro různé účty (kompromit VDI)
- a další
To je samozřejmě velmi obtížné realizovat, ale v dalším článku si v praxi ukážeme, že je to docela možné.
Zdroj: www.habr.com