Тази статия е написана въз основа на много успешен пентест, който специалистите на Group-IB проведоха преди няколко години: случи се история, която може да бъде адаптирана за филм в Боливуд. Сега вероятно ще последва реакцията на читателя: „О, още една PR статия, пак ги описват, колко са добри, не забравяйте да си купите пентест.“ Е, от една страна е така. Има обаче редица други причини, поради които тази статия се появи. Исках да покажа какво точно правят пентестерите, колко интересна и нетривиална може да бъде тази работа, какви смешни обстоятелства могат да възникнат в проектите и най-важното - да покажа материал на живо с реални примери.
За да възстановим баланса на скромността в света, след известно време ще напишем за пентест, който не е минал добре. Ще покажем как добре проектираните процеси в една компания могат да предпазят от цял набор от атаки, дори и добре подготвени, просто защото тези процеси съществуват и действително работят.
За клиента в тази статия всичко също беше отлично като цяло, поне по-добро от 95% от пазара в Руската федерация, според нашите чувства, но имаше редица малки нюанси, които образуваха дълга верига от събития, които първо доведе до дълъг доклад за работата, а след това и до тази статия.
И така, нека се запасим с пуканки и добре дошли в детективската история. дума - Павел Супрунюк, технически ръководител на отдел „Одит и консултации” на Group-IB.
Част 1. Почкин лекар
2018 г Има клиент - високотехнологична IT компания, която сама обслужва много клиенти. Иска да получи отговор на въпроса: възможно ли е, без първоначални познания и достъп, работейки през Интернет, да получите администраторски права на домейн в Active Directory? Не се интересувам от социално инженерство (), те нямат намерение да пречат на работата нарочно, но могат случайно да презаредят странно работещ сървър, например. Допълнителна цел е да се идентифицират възможно най-много други вектори на атака срещу външния периметър. Компанията редовно провежда подобни тестове, а сега изтече срокът за нов тест. Условията са почти типични, адекватни, разбираеми. Да започваме.
Има име на клиента - нека бъде "Компания", с основния уебсайт . Разбира се, клиентът се нарича по различен начин, но в тази статия всичко ще бъде безлично.
Провеждам мрежово разузнаване - откривам кои адреси и домейни са регистрирани при клиента, начертавам мрежова диаграма, как услугите се разпределят на тези адреси. Получавам резултата: повече от 4000 активни IP адреса. Гледам домейните в тези мрежи: за щастие огромното мнозинство са мрежи, предназначени за клиенти на клиента, и ние не се интересуваме официално от тях. Клиентът мисли същото.
Остава една мрежа с 256 адреса, за която към този момент вече има разбиране за разпределението на домейни и поддомейни по IP адреси, има информация за сканираните портове, което означава, че можете да разгледате услугите за интересни. Успоредно с това се стартират всички видове скенери на налични IP адреси и отделно на уебсайтове.
Има много услуги. Обикновено това е радост за пентестъра и очакването за бърза победа, тъй като колкото повече услуги има, толкова по-голямо е полето за атака и толкова по-лесно е да се намери артефакт. Бърз преглед на сайтовете показа, че повечето от тях са уеб интерфейси на добре познати продукти на големи световни компании, които по всичко личи, че не са добре дошли. Те искат потребителско име и парола, разклащат полето за въвеждане на втория фактор, искат TLS клиентски сертификат или го изпращат на Microsoft ADFS. Някои просто са недостъпни от интернет. За някои очевидно трябва да имате специален платен клиент за три заплати или да знаете точния URL, за да влезете. Нека пропуснем още една седмица на постепенно униние в процеса на опити за „пробив“ софтуерни версии за известни уязвимости, търсене на скрито съдържание в уеб пътеки и изтекли акаунти от услуги на трети страни като LinkedIn, опити за отгатване на пароли, използвайки ги, както и като изкопаване на уязвимости в уебсайтове, написани от самите вас – между другото, според статистиката, това е най-обещаващият вектор на външна атака днес. Веднага ще отбележа филмовия пистолет, който впоследствие стреля.
И така, открихме два сайта, които се отличаваха от стотици услуги. Тези сайтове имаха едно общо нещо: ако не участвате в щателно мрежово разузнаване по домейн, а гледате директно за отворени портове или се насочите към скенер за уязвимости, използвайки известен IP диапазон, тогава тези сайтове ще избегнат сканирането и просто няма да бъдат видим, без да знае DNS името. Може би поне са били пропуснати по-рано и нашите автоматични инструменти не са открили проблеми с тях, дори ако са били изпратени директно към ресурса.
Между другото, за това какво откриха по-рано стартираните скенери като цяло. Нека ви напомня: за някои хора „pentest“ е еквивалентно на „автоматично сканиране“. Но скенерите по този проект не казаха нищо. Е, максимумът беше показан от средни уязвимости (3 от 5 по отношение на тежестта): на някои услуги лош TLS сертификат или остарели алгоритми за криптиране, а на повечето сайтове Clickjacking. Но това няма да ви отведе до целта ви. Може би скенерите биха били по-полезни тук, но нека ви напомня: самият клиент може да закупи такива програми и да се тества с тях и, съдейки по мрачните резултати, той вече е проверил.
Да се върнем към „аномалните“ сайтове. Първият е нещо като локално Wiki на нестандартен адрес, но в тази статия нека бъде wiki.company[.]ru. Тя също веднага поиска вход и парола, но през NTLM в браузъра. За потребителя това изглежда като аскетичен прозорец, изискващ въвеждане на потребителско име и парола. И това е лоша практика.
Малка забележка. NTLM в периметърните уебсайтове е лош поради редица причини. Първата причина е, че името на домейна на Active Directory се разкрива. В нашия пример също се оказа company.ru, точно като „външното“ DNS име. Знаейки това, можете внимателно да подготвите нещо злонамерено, така че да се изпълнява само на машината на домейна на организацията, а не в някаква пясъчна среда. Второ, удостоверяването преминава директно през домейн контролера чрез NTLM (изненада, нали?), с всички функции на „вътрешните“ мрежови политики, включително блокиране на акаунти от превишаване на броя опити за въвеждане на парола. Ако нападателят открие влизанията, той ще опита пароли за тях. Ако сте конфигурирани да блокирате акаунти от въвеждане на неправилни пароли, това ще работи и акаунтът ще бъде блокиран. Трето, невъзможно е да се добави втори фактор към такова удостоверяване. Ако някой от читателите все още знае как, моля, уведомете ме, наистина е интересно. Четвърто, уязвимост към атаки с предаване на хеш. ADFS е изобретен, наред с други неща, за защита срещу всичко това.
Има едно лошо свойство на продуктите на Microsoft: дори ако не сте публикували специално такъв NTLM, той ще бъде инсталиран по подразбиране поне в OWA и Lync.
Между другото, авторът на тази статия веднъж случайно блокира около 1000 сметки на служители на една голяма банка само за един час, използвайки същия метод и след това изглеждаше някак блед. ИТ услугите на банката също бяха бледи, но всичко завърши добре и адекватно, дори ни похвалиха, че първи сме открили този проблем и сме провокирали бързо и решително отстраняване.
Вторият сайт имаше адрес „очевидно някакво фамилно име.company.ru“. Намерих го чрез Google, нещо подобно на страница 10. Дизайнът беше от началото-средата на XNUMX-те години и уважаван човек го гледаше от главната страница, нещо подобно:
Тук взех кадър от „Кучешко сърце“, но повярвайте ми беше смътно подобен, дори цветовото оформление беше в подобни тонове. Нека сайта се нарича preobrazhensky.company.ru.
Това беше личен уебсайт... за уролог. Чудех се какво прави уебсайтът на уролог в поддомейна на високотехнологична компания. Бързо копаене в Google показа, че този лекар е съучредител на едно от юридическите лица на нашия клиент и дори е внесъл около 1000 рубли в уставния капитал. Сайтът вероятно е създаден преди много години, а сървърните ресурси на клиента са използвани като хостинг. Сайтът отдавна е загубил своята актуалност, но по някаква причина беше оставен да работи дълго време.
По отношение на уязвимостите самият уебсайт беше защитен. Гледайки напред, ще кажа, че това беше набор от статична информация - прости html страници с вмъкнати илюстрации под формата на бъбреци и пикочни мехури. Безполезно е да се „разбива“ такъв сайт.
Но уеб сървърът отдолу беше по-интересен. Съдейки по хедъра на HTTP сървъра, той имаше IIS 6.0, което означава, че използва Windows 2003 като операционна система. Скенерът преди това е идентифицирал, че този конкретен уебсайт на уролог, за разлика от други виртуални хостове на същия уеб сървър, отговаря на командата PROPFIND, което означава, че работи с WebDAV. Между другото, скенерът върна тази информация с маркировка Информация (на езика на докладите на скенера това е най-малката опасност) - такива неща обикновено просто се пропускат. В комбинация това даде интересен ефект, който беше разкрит едва след друго копаене в Google: рядка уязвимост при препълване на буфера, свързана с набора Shadow Brokers, а именно CVE-2017-7269, който вече имаше готов експлойт. С други думи, ще има проблеми, ако имате Windows 2003 и WebDAV работи на IIS. Въпреки че стартирането на Windows 2003 в производство през 2018 г. е проблем само по себе си.
Експлойтът се озова в Metasploit и веднага беше тестван с натоварване, което изпрати DNS заявка до контролирана услуга - Burp Collaborator традиционно се използва за улавяне на DNS заявки. За моя изненада, проработи за първи път: беше получен DNS нокаут. След това имаше опит за създаване на обратна връзка през порт 80 (т.е. мрежова връзка от сървъра към нападателя, с достъп до cmd.exe на хоста на жертвата), но след това се случи фиаско. Връзката не се осъществи и след третия опит за използване на сайта, заедно с всички интересни снимки, изчезна завинаги.
Обикновено това е последвано от писмо в стил „клиент, събуди се, изпуснахме всичко“. Но ни казаха, че сайтът няма нищо общо с бизнес процесите и работи там без причина, както и целият сървър, и че можем да използваме този ресурс както си искаме.
Около ден по-късно сайтът изведнъж започна да работи сам. След като създадох стенд от WebDAV на IIS 6.0, открих, че настройката по подразбиране е рестартиране на работни процеси на IIS на всеки 30 часа. Тоест, когато контролът излезе от shellcode, работният процес на IIS приключи, след това се рестартира няколко пъти и след това отиде в почивка за 30 часа.
Тъй като обратната връзка към tcp се провали първия път, отдадох този проблем на затворен порт. Тоест той предполага наличието на някаква защитна стена, която не позволява на изходящите връзки да преминават навън. Започнах да изпълнявам shellcodes, които търсиха през много tcp и udp портове, нямаше ефект. Зарежданията на обратната връзка чрез http(s) от Metasploit не работят - meterpreter/reverse_http(s). Изведнъж връзка към същия порт 80 беше установена, но веднага прекъсна. Отдадох това на действието на все още въображаемия IPS, който не харесваше трафика на meterpreter. В светлината на факта, че чиста tcp връзка към порт 80 не премина, но http връзка направи, заключих, че http прокси е някак си конфигуриран в системата.
Дори опитах meterpreter чрез DNS (благодаря за вашите усилия, спасихте много проекти), припомняйки си първия успех, но дори не проработи на щанда - шелкодът беше твърде обемист за тази уязвимост.
Реално изглеждаше така: 3-4 опита за атаки в рамките на 5 минути, след това чакане 30 часа. И така три седмици подред. Дори зададох напомняне, за да не губя време. Освен това имаше разлика в поведението на тестовата и производствената среда: за тази уязвимост имаше два подобни експлойта, единият от Metasploit, вторият от интернет, конвертиран от версията на Shadow Brokers. И така, само Metasploit беше тестван в битка и само вторият беше тестван на пейката, което направи отстраняването на грешки още по-трудно и беше смазващо.
В крайна сметка шелкод, който изтегля exe файл от даден сървър чрез http и го стартира в целевата система, се оказа ефективен. Шелкодът беше достатъчно малък, за да се побере, но поне работеше. Тъй като сървърът изобщо не харесваше TCP трафика и http(s) беше проверен за наличието на meterpreter, реших, че най-бързият начин е да изтегля exe файл, който съдържа DNS-meterpreter чрез този shellcode.
Тук отново възникна проблем: при изтегляне на exe файл и, както показаха опитите, без значение кой, изтеглянето беше прекъснато. Отново някакво устройство за сигурност между моя сървър и уролога не хареса http трафика с exe вътре. „Бързото“ решение изглежда беше да се промени шелкодът, така че да замъглява http трафика в движение, така че абстрактните двоични данни да се прехвърлят вместо exe. Накрая атаката беше успешна, контролът беше получен през тънкия DNS канал:
Веднага стана ясно, че имам най-основните права на IIS workflow, които ми позволяват да не правя нищо. Ето как изглеждаше на конзолата на Metasploit:
Всички методологии на pentest силно предполагат, че трябва да увеличите правата, когато получавате достъп. Обикновено не правя това локално, тъй като първият достъп се разглежда просто като точка за влизане в мрежата и компрометирането на друга машина в същата мрежа обикновено е по-лесно и по-бързо от увеличаването на привилегиите на съществуващ хост. Но тук не е така, тъй като DNS каналът е много тесен и няма да позволи трафикът да се изчисти.
Ако приемем, че този сървър на Windows 2003 не е поправен за известната уязвимост MS17-010, тунелирам трафик към порт 445/TCP през DNS тунела на meterpreter на localhost (да, това също е възможно) и се опитвам да стартирам изтегления преди това exe през уязвимостта. Атаката работи, получавам втора връзка, но със СИСТЕМНИ права.
Интересно е, че все пак се опитаха да защитят сървъра от MS17-010 - той имаше деактивирани уязвими мрежови услуги на външния интерфейс. Това защитава срещу атаки по мрежата, но атаката отвътре на localhost работи, тъй като не можете просто бързо да изключите SMB на localhost.
След това се разкриват нови интересни подробности:
- Имайки SYSTEM права, можете лесно да установите обратна връзка чрез TCP. Очевидно деактивирането на директния TCP е проблем само за ограничените потребители на IIS. Спойлер: потребителският трафик на IIS беше някак увит в локалния ISA прокси и в двете посоки. Как точно работи, не съм възпроизвеждал.
- Аз съм в определена „DMZ“ (и това не е домейн на Active Directory, а WORKGROUP) - звучи логично. Но вместо очаквания частен („сив“) IP адрес, имам напълно „бял“ IP адрес, точно същия като този, който атакувах по-рано. Това означава, че компанията е толкова стара в света на IPv4 адресирането, че може да си позволи да поддържа DMZ зона за 128 „бели“ адреса без NAT според схемата, както е изобразено в ръководствата на Cisco от 2005 г.
Тъй като сървърът е стар, Mimikatz гарантирано работи директно от паметта:
Получавам паролата на локалния администратор, тунелирам RDP трафик през TCP и влизам в уютен десктоп. Тъй като можех да правя каквото си искам със сървъра, махнах антивирусната и установих, че сървърът е достъпен от интернет само през TCP портове 80 и 443, а 443 не е зает. Настройвам OpenVPN сървър на 443, добавям NAT функции за моя VPN трафик и получавам директен достъп до DMZ мрежата в неограничен вид чрез моя OpenVPN. Трябва да се отбележи, че ISA, имайки някои недеактивирани IPS функции, блокира моя трафик със сканиране на портове, за което трябваше да бъде заменен с по-прост и по-съвместим RRAS. Така че пентестерите понякога все още трябва да администрират всякакви неща.
Внимателен читател ще попита: „Ами вторият сайт - wiki с NTLM удостоверяване, за който толкова много е писано?“ Повече за това по-късно.
Част 2. Все още не криптирате? Тогава идваме при вас вече тук
Така че има достъп до DMZ мрежовия сегмент. Трябва да отидете при администратора на домейна. Първото нещо, което идва на ум, е автоматично да проверявате сигурността на услугите в рамките на DMZ сегмента, особено след като много повече от тях вече са отворени за изследване. Типична картина по време на тест за проникване: външният периметър е по-добре защитен от вътрешните услуги и при получаване на какъвто и да е достъп вътре в голяма инфраструктура е много по-лесно да се получат разширени права в домейн само поради факта, че този домейн започва да бъде достъпен за инструменти, и второ, в инфраструктура с няколко хиляди хоста винаги ще има няколко критични проблема.
Зареждам скенерите през DMZ през OpenVPN тунел и чакам. Отварям доклада - пак нищо сериозно, явно някой е минал по същия метод преди мен. Следващата стъпка е да се проучи как комуникират хостове в DMZ мрежата. За да направите това, първо стартирайте обичайния Wireshark и слушайте заявки за излъчване, предимно ARP. ARP пакетите се събираха цял ден. Оказва се, че в този сегмент се използват няколко шлюза. Това ще ви бъде полезно по-късно. Чрез комбиниране на данни за ARP заявки и отговори и данни за сканиране на портове, открих изходните точки на потребителския трафик от вътрешността на локалната мрежа в допълнение към онези услуги, които бяха известни преди, като уеб и поща.
Тъй като в момента нямах достъп до други системи и нямах нито един акаунт за корпоративни услуги, беше решено да извадя поне някакъв акаунт от трафика с помощта на ARP Spoofing.
Cain&Abel беше пуснат на сървъра на уролога. Като се вземат предвид идентифицираните потоци на трафик, бяха избрани най-обещаващите двойки за атаката "човек по средата" и след това беше получен известен мрежов трафик чрез краткотрайно стартиране за 5-10 минути, с таймер за рестартиране на сървъра в случай на замръзване. Както във вица имаше две новини:
- Добре: много идентификационни данни бяха уловени и атаката като цяло проработи.
- Лошото: всички идентификационни данни бяха от собствените клиенти на клиента. Докато предоставяха услуги за поддръжка, специалистите по клиенти се свързваха с услугите на клиенти, които не винаги са имали конфигурирано криптиране на трафика.
В резултат на това придобих много идентификационни данни, които бяха безполезни в контекста на проекта, но определено интересни като демонстрация на опасността от атаката. Гранични рутери на големи компании с телнет, пренасочени debug http портове към вътрешни CRM с всички данни, директен достъп до RDP от Windows XP в локалната мрежа и други мракобесия. Оказа се така .
Намерих и забавна възможност да събирам писма от трафика, нещо подобно. Това е пример за готово писмо, изпратено от наш клиент до SMTP порта на неговия клиент, отново без криптиране. Известен Андрей моли съименника си да изпрати отново документацията и тя се качва на облачен диск с потребителско име, парола и връзка в едно отговорно писмо:
Това е още едно напомняне за шифроване на всички услуги. Не е известно кой и кога конкретно ще прочете и използва вашите данни - доставчикът, системният администратор на друга компания или такъв pentester. Мълча за факта, че много хора могат просто да прихванат некриптиран трафик.
Въпреки видимия успех, това не ни доближи до целта. Възможно е, разбира се, да седите дълго време и да извличате ценна информация, но не е факт, че ще се появи там, а самата атака е много рискована по отношение на целостта на мрежата.
След поредното ровене в услугите ми хрумна интересна идея. Има такава помощна програма, наречена Responder (лесно е да намерите примери за употреба с това име), която чрез „отравяне“ на заявки за излъчване провокира връзки чрез различни протоколи като SMB, HTTP, LDAP и т.н. по различни начини, след което моли всеки, който се свързва, да се удостовери и го настройва така, че удостоверяването да се извършва чрез NTLM и в режим, прозрачен за жертвата. Най-често атакуващият събира NetNTLMv2 ръкостискания по този начин и от тях, използвайки речник, бързо възстановява потребителските пароли на домейна. Тук исках нещо подобно, но потребителите седяха „зад стената“, или по-скоро бяха разделени от защитна стена и имаха достъп до WEB чрез прокси клъстера Blue Coat.
Не забравяйте, че уточних, че името на домейна на Active Directory съвпада с „външния“ домейн, тоест беше company.ru? И така, Windows, по-точно Internet Explorer (и Edge и Chrome), позволяват на потребителя да се удостоверява прозрачно в HTTP чрез NTLM, ако счита, че сайтът се намира в някаква „Интранет зона“. Един от признаците на „интранет“ е достъпът до „сив“ IP адрес или кратко DNS име, тоест без точки. Тъй като имаха сървър с „бяло“ IP и DNS име preobrazhensky.company.ru и машините с домейн обикновено получават суфикса на домейна на Active Directory чрез DHCP за опростено въвеждане на име, трябваше само да напишат URL адреса в адресната лента , така че да намерят правилния път до сървъра на компрометирания уролог, като не забравяме, че това вече се нарича „Интранет“. Тоест, в същото време ми дава NTLM-ръкостискане на потребителя без негово знание. Остава само да принуди клиентските браузъри да мислят за спешната нужда да се свържат с този сървър.
Прекрасната помощна програма Intercepter-NG дойде на помощ (благодаря ). Позволява ви да променяте трафика в движение и работи чудесно на Windows 2003. Дори има отделна функционалност за модифициране само на JavaScript файлове в потока на трафика. Беше планирано нещо като масивно междусайтово скриптиране.
Прокситата на Blue Coat, чрез които потребителите имат достъп до глобалната WEB, периодично кешираха статично съдържание. Чрез прихващането на трафика беше ясно, че работят денонощно, безкрайно изисквайки често използвана статика, за да ускорят показването на съдържание в пиковите часове. В допълнение, BlueCoat имаше специфичен потребителски агент, който ясно го отличаваше от истинския потребител.
Беше подготвен Javascript, който с помощта на Intercepter-NG беше реализиран за един час през нощта за всеки отговор с JS файлове за Blue Coat. Скриптът направи следното:
- Текущият браузър е определен от User-Agent. Ако беше Internet Explorer, Edge или Chrome, той продължи да работи.
- Изчаках докато се формира DOM на страницата.
- Вмъкна невидимо изображение в DOM с атрибут src на формуляра :8080/NNNNNNN.png, където NNN са произволни числа, така че BlueCoat да не го кешира.
- Задайте глобална флагова променлива, за да укажете, че инжектирането е завършено и вече няма нужда да вмъквате изображения.
Браузърът се опита да зареди това изображение; на порт 8080 на компрометирания сървър TCP тунел го чакаше към моя лаптоп, където работеше същият Responder, изискващ браузърът да влезе през NTLM.
Съдейки по регистрационните файлове на Responder, хората идваха на работа сутрин, включваха работните си станции, след което масово и незабелязано започнаха да посещават сървъра на уролога, като не забравяха да „източат“ NTLM ръкостискания. Ръкостисканията валяха цял ден и явно се натрупа материал за очевидно успешна атака за възстановяване на пароли. Ето как изглеждаха регистрационните файлове на Responder:
Масови тайни посещения на сървъра на уролога от потребители
Вероятно вече сте забелязали, че цялата тази история е изградена на принципа „всичко беше наред, но след това имаше неприятности, след това имаше преодоляване и след това всичко дойде до успех“. И така, тук имаше неприятности. От петдесетте уникални ръкостискания не беше разкрито нито едно. И това взема предвид факта, че дори на лаптоп с мъртъв процесор, тези NTLMv2 ръкостискания се обработват със скорост от няколкостотин милиона опита в секунда.
Трябваше да се въоръжа с техники за мутация на пароли, видеокарта, по-дебел речник и да чакам. След дълго време бяха разкрити няколко акаунта с пароли от формата „Q11111111....1111111q“, което предполага, че всички потребители някога са били принудени да измислят много дълга парола с различен регистър на буквите, която също е трябвало да бъди сложен. Но не можете да заблудите опитен потребител и ето как той улесни себе си да запомни. Общо около 5 акаунта бяха компрометирани и само един от тях имаше ценни права върху услугите.
Част 3. Роскомнадзор отвръща на удара
Така бяха получени първите акаунти на домейни. Ако до този момент не сте заспали от дълго четене, вероятно ще си спомните, че споменах услуга, която не изисква втори фактор за удостоверяване: това е уики с NTLM удостоверяване. Разбира се, първото нещо, което трябваше да направите, беше да влезете там. Ровенето във вътрешната база от знания бързо доведе до резултати:
- Фирмата разполага с WiFi мрежа с удостоверяване с използване на домейн акаунти с достъп до локалната мрежа. С текущия набор от данни това вече е работещ вектор за атака, но трябва да отидете в офиса с краката си и да се намирате някъде на територията на офиса на клиента.
- Намерих инструкция, според която имаше услуга, която позволяваше... самостоятелно да регистрира устройство за удостоверяване на „втори фактор“, ако потребителят е в локална мрежа и си спомня уверено данните за вход и паролата на своя домейн. В този случай „отвътре“ и „отвън“ се определят от достъпността на порта на тази услуга за потребителя. Портът не беше достъпен от интернет, но беше доста достъпен през DMZ.
Разбира се, към компрометирания акаунт веднага беше добавен „втори фактор“ под формата на приложение на моя телефон. Имаше програма, която можеше или силно да изпрати насочена заявка до телефона с бутони „одобрение“/„неодобрение“ за действието, или тихо да покаже OTP кода на екрана за по-нататъшно независимо въвеждане. Освен това първият метод трябваше да бъде единственият правилен от инструкциите, но не работи, за разлика от OTP метода.
С нарушен „втори фактор“ успях да осъществя достъп до пощата на Outlook Web Access и отдалечения достъп в Citrix Netscaler Gateway. Имаше изненада в пощата в Outlook:
В този рядък кадър можете да видите как Roskomnadzor помага на pentesters
Това бяха първите месеци след известното „фенско“ блокиране на Telegram, когато цели мрежи с хиляди адреси неумолимо изчезнаха от достъп. Стана ясно защо пушът не работи веднага и защо моята „жертва“ не алармира, защото започнаха да използват нейния акаунт в работно време.
Всеки, запознат с Citrix Netscaler, си представя, че той обикновено се изпълнява по такъв начин, че на потребителя може да бъде предаден само интерфейс за картина, като се опитва да не му дава инструментите за стартиране на приложения на трети страни и прехвърляне на данни, ограничавайки по всякакъв възможен начин действията чрез стандартни контролни черупки. Моята „жертва“, поради професията си, получи само 1C:
След като се разхождах малко из интерфейса 1C, открих, че там има външни модули за обработка. Те могат да бъдат заредени от интерфейса и ще бъдат изпълнени на клиента или сървъра, в зависимост от правата и настройките.
Помолих моите приятели програмисти от 1C да създадат обработка, която да приеме низ и да го изпълни. На езика 1C стартирането на процес изглежда така (взето от Интернет). Съгласни ли сте, че синтаксисът на езика 1C учудва рускоезичните хора със своята спонтанност?
Обработката беше изпълнена перфектно, оказа се това, което пентестерите наричат „обвивка“ - Internet Explorer беше стартиран през него.
По-рано адресът на система, която ви позволява да поръчате пропуски до територията, беше намерен в пощата. Поръчах пропуск в случай, че трябва да използвам вектор за атака на WiFi.
В интернет се говори, че все още имало вкусен безплатен кетъринг в офиса на клиента, но аз все пак предпочетох да развия атаката дистанционно, по-спокойно е.
AppLocker беше активиран на сървъра за приложения, работещ с Citrix, но беше прескочен. Същият Meterpreter беше зареден и стартиран чрез DNS, тъй като http(s) версиите не искаха да се свържат и аз не знаех вътрешния прокси адрес по това време. Между другото, от този момент нататък външният пентест по същество напълно се превърна във вътрешен.
Част 4. Администраторските права за потребителите са лоши, нали?
Първата задача на pentester при получаване на контрол върху потребителска сесия на домейн е да събере цялата информация за правата в домейна. Има помощна програма BloodHound, която автоматично ви позволява да изтегляте информация за потребители, компютри, групи за сигурност чрез LDAP протокола от домейн контролер и чрез SMB - информация за това кой потребител наскоро е влязъл къде и кой е локалният администратор.
Типична техника за отнемане на администраторски права на домейн изглежда опростена като цикъл от монотонни действия:
- Отиваме на компютри в домейна, където има локални администраторски права, въз основа на вече заснети акаунти в домейн.
- Стартираме Mimikatz и получаваме кеширани пароли, Kerberos билети и NTLM хешове на акаунти на домейни, които наскоро са влезли в тази система. Или премахваме изображението от паметта на процеса lsass.exe и правим същото от наша страна. Това работи добре с Windows по-млади от 2012R2/Windows 8.1 с настройки по подразбиране.
- Ние определяме къде компрометираните акаунти имат права на локален администратор. Повтаряме първата точка. На някакъв етап получаваме администраторски права за целия домейн.
„Край на цикъла“, както биха написали програмистите на 1C тук.
И така, нашият потребител се оказа локален администратор само на един хост с Windows 7, чието име включваше думата „VDI“ или „Инфраструктура на виртуален работен плот“, лични виртуални машини. Вероятно дизайнерът на услугата VDI е имал предвид, че тъй като VDI е личната операционна система на потребителя, дори ако потребителят промени софтуерната среда, както пожелае, хостът все още може да бъде „презареден“. Също така реших, че като цяло идеята е добра, отидох при този личен VDI хост и направих гнездо там:
- Там инсталирах OpenVPN клиент, който направи тунел през интернет към моя сървър. Клиентът трябваше да бъде принуден да премине през същото Blue Coat с удостоверяване на домейн, но OpenVPN го направи, както се казва, „извън кутията“.
- Инсталиран OpenSSH на VDI. Е, наистина, какво е Windows 7 без SSH?
Ето как изглеждаше на живо. Нека ви напомня, че всичко това трябва да се направи чрез Citrix и 1C:
Една техника за насърчаване на достъпа до съседни компютри е да се проверят паролите на локалния администратор за съвпадение. Тук незабавно очакваше късмет: NTLM хешът на локалния администратор по подразбиране (който внезапно беше наречен Администратор) беше достигнат чрез атака с предаване на хеш към съседни VDI хостове, от които имаше няколкостотин. Разбира се, атаката веднага ги удари.
Това е мястото, където VDI администраторите се простреляха два пъти в крака:
- Първият път беше, когато VDI машините не бяха поставени под LAPS, като по същество запазиха същата локална администраторска парола от изображението, което беше масово внедрено във VDI.
- Администраторът по подразбиране е единственият локален акаунт, който е уязвим на атаки с предаване на хеш. Дори със същата парола би било възможно да се избегне масов компромет чрез създаване на втори акаунт на локален администратор със сложна произволна парола и блокиране на тази по подразбиране.
Защо има SSH услуга на този Windows? Много просто: сега OpenSSH сървърът не само предоставя удобна интерактивна командна обвивка, без да пречи на работата на потребителя, но също така и socks5 прокси на VDI. Чрез този socks се свързах чрез SMB и събрах кеширани акаунти от всички тези стотици VDI машини, след което потърсих пътя до администратора на домейна, като ги използвах в графиките на BloodHound. Със стотици хостове на мое разположение намерих този начин доста бързо. Получени са администраторски права на домейн.
Ето снимка от интернет, показваща подобно търсене. Връзките показват кой къде е администраторът и кой къде е влязъл.
Между другото, помнете условието от началото на проекта - „не използвайте социално инженерство“. Така че предлагам да помислим колко ще бъде отрязан целият този Боливуд със специални ефекти, ако все още е възможно да се използва банален фишинг. Но лично на мен ми беше много интересно да правя всичко това. Надявам се да ви е харесало да прочетете това. Разбира се, не всеки проект изглежда толкова интригуващ, но работата като цяло е много предизвикателна и не й позволява да застоява.
Вероятно някой ще има въпрос: как да се предпазите? Дори тази статия описва много техники, много от които администраторите на Windows дори не знаят. Предлагам обаче да ги разгледаме от гледна точка на изтъркани принципи и мерки за информационна сигурност:
- не използвайте остарял софтуер (помните ли Windows 2003 в началото?)
- не дръжте ненужните системи включени (защо имаше уебсайт на уролог?)
- проверете сами потребителските пароли за сила (в противен случай войниците... пентестерите ще направят това)
- нямате еднакви пароли за различни акаунти (VDI компромис)
- и други
Разбира се, това е много трудно за изпълнение, но в следващата статия ще покажем на практика, че е напълно възможно.
Източник: www.habr.com